Re: [Boost-users] Catching boost::thread_interrupted
Hi, sorry, forgot to send the attachment in the original positing... Regards, Roland Hi, currently I am making my first steps using Boost.Thread (1.36.0). The interrupt feature looks very cool, so I tried to use it, but somehow failed to catch boost::thread_interrupted. The code is attached to this mail. I was expecting to see something like Thread 0x60b050 got interrupted Thread 0x60b3e0 got interrupted Instead I got Thread 0x60b050 caught something else Thread 0x60b3e0 caught something else Can somebody please enlighten me? Thanks and regards, Roland
AMDG rbock@eudoxos.de wrote:
I was expecting to see something like
Thread 0x60b050 got interrupted Thread 0x60b3e0 got interrupted
Instead I got
Thread 0x60b050 caught something else Thread 0x60b3e0 caught something else
It works for me. What compiler are you using? You might try catching by reference. In Christ, Steven Watanabe
Hi, I am using gcc 4.2.3 on Ubuntu8.04(64bit): $ g++ --version g++ (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7) $ uname -a Linux rbock 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008 x86_64 GNU/Linux Catching by reference does not change the result. Regards, Roland Steven Watanabe wrote:
AMDG
rbock@eudoxos.de wrote:
I was expecting to see something like Thread 0x60b050 got interrupted Thread 0x60b3e0 got interrupted
Instead I got
Thread 0x60b050 caught something else Thread 0x60b3e0 caught something else
It works for me. What compiler are you using? You might try catching by reference.
In Christ, Steven Watanabe
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
AMDG Dr. Roland Bock wrote:
Hi,
I am using gcc 4.2.3 on Ubuntu8.04(64bit):
$ g++ --version g++ (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
$ uname -a Linux rbock 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008 x86_64 GNU/Linux
Catching by reference does not change the result.
I can't reproduce this on cygwin. You might try to find out what exception /is/ being thrown. catch(std::exception& e) { boost::mutex::scoped_lock lock(mutex_); cerr << "Thread " << boost::this_thread::get_id() << " caught std::exception" << e.what() << endl; } In Christ, Steven Watanabe
Steven, it does not seem to be a std::exception, either. I still get $ ./src/BoostThreads Thread 0x60b050 caught something else Thread 0x60b3e0 caught something else I attached the complete code again (just to be sure). I also checked linkage: $ ldd src/BoostThreads linux-vdso.so.1 => (0x00007fff757fe000) libboost_thread-gcc42-mt-1_36.so.1.36.0 => /home/rbock/Software/Binaries/boost/1.36.0/lib/libboost_thread-gcc42-mt-1_36.so.1.36.0 (0x00007f4d6d34b000) libboost_date_time-gcc42-mt-1_36.so.1.36.0 => /home/rbock/Software/Binaries/boost/1.36.0/lib/libboost_date_time-gcc42-mt-1_36.so.1.36.0 (0x00007f4d6d137000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f4d6ce2c000) libm.so.6 => /lib/libm.so.6 (0x00007f4d6cbab000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f4d6c99d000) libc.so.6 => /lib/libc.so.6 (0x00007f4d6c63b000) librt.so.1 => /lib/librt.so.1 (0x00007f4d6c432000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f4d6c216000) /lib64/ld-linux-x86-64.so.2 (0x00007f4d6d55d000) Looks fine to me... Regards, Roland Steven Watanabe wrote:
I can't reproduce this on cygwin. You might try to find out what exception /is/ being thrown.
catch(std::exception& e) { boost::mutex::scoped_lock lock(mutex_); cerr << "Thread " << boost::this_thread::get_id() << " caught std::exception" << e.what() << endl; }
$ ./src/BoostThreads Thread 0x60b050 caught something else Thread 0x60b3e0 caught something else
...
libboost_thread-gcc42-mt-1_36.so.1.36.0 =>
Can you try the same test with the static Boost.Threads library? Maybe your configuration doesn't support catching non-polymorphic exceptions thrown across .so boundaries. You could also try adding a virtual destructor to thread_interrupted.
Peter, a) virtual destructor: did not change anything b) using static libraries: works fine! Hm. I have not had such a problem before and I we are using quite a few shared objects that throw exception which are caught elsewhere. Maybe this is related to nm not seeing any symbols? $ nm lib/libboost_thread-gcc42-mt-1_36.so.1.36.0 nm: lib/libboost_thread-gcc42-mt-1_36.so.1.36.0: no symbols We are using the gcc option -fvisibility=hidden for our own projects and we require to specify classes or functions which we explicitly want to be exported by shared objects by putting DSOEXPORT in front of the classname. It is defined in the following way: #ifdef _MSC_VER #ifdef BUILDING_DSO #define DSOEXPORT __declspec(dllexport) #else #define DSOEXPORT __declspec(dllimport) #endif #define DSOLOCAL #else #define DSOEXPORT __attribute__ ((visibility("default"))) #define DSOLOCAL __attribute__ ((visibility("hidden"))) #endif Exceptions declared and thrown in shared objects have to use DSOEXPORT in order to be catched elsewhere. Regards, Roland Peter Dimov wrote:
$ ./src/BoostThreads Thread 0x60b050 caught something else Thread 0x60b3e0 caught something else
...
libboost_thread-gcc42-mt-1_36.so.1.36.0 =>
Can you try the same test with the static Boost.Threads library? Maybe your configuration doesn't support catching non-polymorphic exceptions thrown across .so boundaries. You could also try adding a virtual destructor to thread_interrupted. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
2008/9/8 Dr. Roland Bock <rbock@eudoxos.de>
Peter,
a) virtual destructor: did not change anything b) using static libraries: works fine!
Hm. I have not had such a problem before and I we are using quite a few shared objects that throw exception which are caught elsewhere.
Maybe this is related to nm not seeing any symbols?
$ nm lib/libboost_thread-gcc42-mt-1_36.so.1.36.0 nm: lib/libboost_thread-gcc42-mt-1_36.so.1.36.0: no symbols
We are using the gcc option -fvisibility=hidden for our own projects and we require to specify classes or functions which we explicitly want to be exported by shared objects by putting DSOEXPORT in front of the classname. It is defined in the following way:
#ifdef _MSC_VER #ifdef BUILDING_DSO #define DSOEXPORT __declspec(dllexport) #else #define DSOEXPORT __declspec(dllimport) #endif #define DSOLOCAL #else #define DSOEXPORT __attribute__ ((visibility("default"))) #define DSOLOCAL __attribute__ ((visibility("hidden"))) #endif
Exceptions declared and thrown in shared objects have to use DSOEXPORT in order to be catched elsewhere.
Boost does not use __attribute__ ((visibility("default"))), therefore typeinfo for exceptions is not exported and you can't catch exceptions thrown by boost. Roman.
Regards,
Roland
Peter Dimov wrote:
$ ./src/BoostThreads
Thread 0x60b050 caught something else Thread 0x60b3e0 caught something else
...
libboost_thread-gcc42-mt-1_36.so.1.36.0 =>
Can you try the same test with the static Boost.Threads library? Maybe your configuration doesn't support catching non-polymorphic exceptions thrown across .so boundaries. You could also try adding a virtual destructor to thread_interrupted. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Hi,
Boost does not use __attribute__ ((visibility("default"))), therefore typeinfo for exceptions is not exported and you can't catch exceptions thrown by boost.
Please forgive me if this is a stupid question: Is that a bug or a feature? Wouldn't it be good to be able to catch exceptions thrown by boost? Regards, Roland
Dr. Roland Bock:
Boost does not use __attribute__ ((visibility("default"))), therefore typeinfo for exceptions is not exported and you can't catch exceptions thrown by boost.
Please forgive me if this is a stupid question:
Is that a bug or a feature? Wouldn't it be good to be able to catch exceptions thrown by boost?
I'm not sure I understand. Have you built Boost with an additional -fvisibility-hidden parameter? If you didn't, the default visibility should be the appropriately named "default", should it not? What effect would __attribute__ ((visibility("default"))) then have?
Hi,
Boost does not use __attribute__ ((visibility("default"))), therefore typeinfo for exceptions is not exported and you can't catch exceptions thrown by boost.
Please forgive me if this is a stupid question:
Is that a bug or a feature? Wouldn't it be good to be able to catch exceptions thrown by boost?
I'm not sure I understand. Have you built Boost with an additional -fvisibility-hidden parameter? If you didn't, the default visibility should be the appropriately named "default", should it not? What effect would __attribute__ ((visibility("default"))) then have?
Even if boost is compiled with default visibility, Roland's compile is still going to see it has hidden since the class declaration in question (boost::thread_interrupted) hasn't been explicitly exported in the g++ symbol visibility-enabled case. Roland, you should be able to work around the lack of g++ symbol visibility support in boost::thread by wrapping your boost #include<>s with the appropriate pragmas, e.g: #pragma GCC visibility push(default) #include <boost/...> #include <boost/...> #pragma GCC visibility pop It's ugly, but it should get you going until the g++ symbol visibility issues in boost::thread are addressed. HTH, -Ossama
Hi, cool, that works! Thanks to all of you who showed interest in this thread. It was my first posting to boost-users and I am very much impressed with the speed and accuracy of the answers. As suggested by Peter, I filed the missing visibility support in boost::thread as a bug. Thanks again and best regards from Bavaria, Roland Othman, Ossama wrote:
Hi,
Boost does not use __attribute__ ((visibility("default"))), therefore typeinfo for exceptions is not exported and you can't catch exceptions thrown by boost. Please forgive me if this is a stupid question:
Is that a bug or a feature? Wouldn't it be good to be able to catch exceptions thrown by boost? I'm not sure I understand. Have you built Boost with an additional -fvisibility-hidden parameter? If you didn't, the default visibility should be the appropriately named "default", should it not? What effect would __attribute__ ((visibility("default"))) then have?
Even if boost is compiled with default visibility, Roland's compile is still going to see it has hidden since the class declaration in question (boost::thread_interrupted) hasn't been explicitly exported in the g++ symbol visibility-enabled case.
Roland, you should be able to work around the lack of g++ symbol visibility support in boost::thread by wrapping your boost #include<>s with the appropriate pragmas, e.g:
#pragma GCC visibility push(default) #include <boost/...> #include <boost/...> #pragma GCC visibility pop
It's ugly, but it should get you going until the g++ symbol visibility issues in boost::thread are addressed.
HTH, -Ossama _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Hmm. No, I built boost the "normal" way. Through this thread, though, we saw several things: a) boost::thread_interrupted is not caught when using the shared object b) it works fine with the static c) nm shows no symbols I wondered if c) is the reason for a) and took a rather wild guess about the reason for c): Symbols are not exported "by accident". Is there some compile option that can/should be used so that I can catch exceptions thrown by boost shared objects? Thanks and regards, Roland Peter Dimov wrote:
Dr. Roland Bock:
Boost does not use __attribute__ ((visibility("default"))), therefore typeinfo for exceptions is not exported and you can't catch exceptions thrown by boost.
Please forgive me if this is a stupid question:
Is that a bug or a feature? Wouldn't it be good to be able to catch exceptions thrown by boost?
I'm not sure I understand. Have you built Boost with an additional -fvisibility-hidden parameter? If you didn't, the default visibility should be the appropriately named "default", should it not? What effect would __attribute__ ((visibility("default"))) then have? _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Dr. Roland Bock:
Hmm. No, I built boost the "normal" way. Through this thread, though, we saw several things:
a) boost::thread_interrupted is not caught when using the shared object b) it works fine with the static c) nm shows no symbols
I wondered if c) is the reason for a) and took a rather wild guess about the reason for c): Symbols are not exported "by accident".
As it turns out, the reason is that your -fvisibility=hidden overrides the default visibility in the .so, as explained in http://gcc.gnu.org/wiki/Visibility Interesting (and quite counter-intuitive, I might add). You should probably file a trac ticket for this issue.
2008/9/8 Dr. Roland Bock <rbock@eudoxos.de>
Hmm. No, I built boost the "normal" way. Through this thread, though, we saw several things:
a) boost::thread_interrupted is not caught when using the shared object b) it works fine with the static c) nm shows no symbols
c) is probably because binary is stripped. It does not affect correctness of programs but makes debugging harder. Roman.
participants (4)
-
Dr. Roland Bock -
Othman, Ossama -
Peter Dimov -
rbock＠eudoxos.de
-
Roman Perepelitsa -
Steven Watanabe