Hello,
I have been using the spirit parser library, and other boost pieces (date,
test, variant, ...), along with Mozilla.
I recently merged in some parts of the application that were running
separately, and the program started hanging.
I did a bit of searching, but couldn't find anything significantly wrong,
especially since the individual parts are working correctly.
The problem seems to be related to threads, as the stack indicates (cf
stack at the end), and as the strace output shows here:
parsing:*****************************:
) = 240
time([1093872322]) = 1093872322
futex(0x4045b860, FUTEX_WAIT, 2, NULL) = -1 EAGAIN (Resource temporarily
unavailable)
futex(0x4045b860, FUTEX_WAIT, 2, NULL) = -1 EAGAIN (Resource temporarily
unavailable)
[... ad vitam eternam]
I compiled this program using
gcc (GCC) 3.4.1 (Debian 3.4.1-7)
using
-DBOOST_MPL_NO_PREPROCESSED_HEADERS -DBOOST_SPIRIT_DEBUG -fPIC
-I/usr/X11R6/include -frtti -fexceptions -Wall -Wconversion -Wpointer-arith
-Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy
-Wno-non-virtual-dtor -Wno-long-long -pedantic -fshort-wchar -pthread -pipe
-DDEBUG -D_DEBUG -DDEBUG_root -DTRACING -g -fno-inline
-I/usr/X11R6/include -DMOZILLA_CLIENT -include
I don't know exactly what those threads are doing behind my back, but I'd
appreciate if someone could provide some suggestion for fixing this
problem. Thanks.
Matt
stack:
#0 0x4040c791 in pthread_setcanceltype () from /lib/tls/libc.so.6
#1 0x4045b860 in __after_morecore_hook () from /lib/tls/libc.so.6
#2 0x4045aedc in ?? () from /lib/tls/libc.so.6
#3 0x00000031 in ?? ()
#4 0x4039ad63 in posix_memalign () from /lib/tls/libc.so.6
#5 0x00000012 in ?? ()
#6 0x409c91fc in ~lightweight_mutex (this=0x819eb40) at lwm_pthreads.hpp:53
#7 0x409c9d24 in ~sp_counted_base_impl (this=0x819eb40)
at nsCXExpRecord.cpp:219
#8 0x409c96e2 in boost::detail::sp_counted_base::destruct (this=0x819eb40)
at shared_count.hpp:115
#9 0x409b2a7e in boost::detail::sp_counted_base::weak_release (this=0x819eb40)
at shared_count.hpp:173
#10 0x409bd6de in boost::detail::weak_count::operator= (this=0x40b3bb3c,
r=@0x41749188) at shared_count.hpp:492
#11 0x409bd68f in boost::weak_ptr
Matt Paindavoine. wrote:
Hello,
I have been using the spirit parser library, and other boost pieces (date, test, variant, ...), along with Mozilla. I recently merged in some parts of the application that were running separately, and the program started hanging. I did a bit of searching, but couldn't find anything significantly wrong, especially since the individual parts are working correctly. The problem seems to be related to threads, as the stack indicates (cf stack at the end), and as the strace output shows here:
[...]
futex(0x4045b860, FUTEX_WAIT, 2, NULL) = -1 EAGAIN (Resource temporarily [...]
#6 0x409c91fc in ~lightweight_mutex (this=0x819eb40) at lwm_pthreads.hpp:53 #7 0x409c9d24 in ~sp_counted_base_impl (this=0x819eb40) at nsCXExpRecord.cpp:219 #8 0x409c96e2 in boost::detail::sp_counted_base::destruct (this=0x819eb40) at shared_count.hpp:115 #9 0x409b2a7e in boost::detail::sp_counted_base::weak_release (this=0x819eb40) at shared_count.hpp:173
This can happen if some parts of your multithreaded program were compiled without multithreading support (or vice versa). The pthread_mutex_destroy call in ~lightweight_mutex expects to find a pthread_mutex at &m_, but the shared_ptr was created by unthreaded code, and an empty lightweight_mutex got used.
Thank you Peter! Bull's eye. I had to link with xxx-mt-xxx versions of some boost libraries, make sure that my Jamfiles had a <threading>multi, and it ran smoothly. thanks again, Matt. On Mon, Aug 30, 2004 at 10:08:05PM +0300, Peter Dimov wrote:
Matt Paindavoine. wrote:
Hello,
I have been using the spirit parser library, and other boost pieces (date, test, variant, ...), along with Mozilla. I recently merged in some parts of the application that were running separately, and the program started hanging. I did a bit of searching, but couldn't find anything significantly wrong, especially since the individual parts are working correctly. The problem seems to be related to threads, as the stack indicates (cf stack at the end), and as the strace output shows here:
[...]
futex(0x4045b860, FUTEX_WAIT, 2, NULL) = -1 EAGAIN (Resource temporarily [...]
#6 0x409c91fc in ~lightweight_mutex (this=0x819eb40) at lwm_pthreads.hpp:53 #7 0x409c9d24 in ~sp_counted_base_impl (this=0x819eb40) at nsCXExpRecord.cpp:219 #8 0x409c96e2 in boost::detail::sp_counted_base::destruct (this=0x819eb40) at shared_count.hpp:115 #9 0x409b2a7e in boost::detail::sp_counted_base::weak_release (this=0x819eb40) at shared_count.hpp:173
This can happen if some parts of your multithreaded program were compiled without multithreading support (or vice versa). The pthread_mutex_destroy call in ~lightweight_mutex expects to find a pthread_mutex at &m_, but the shared_ptr was created by unthreaded code, and an empty lightweight_mutex got used.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
Matt Paindavoine. -
Peter Dimov