Boost.signals with -pthread
Hi, all!
I am novice in this list, so don't beat freely :)
I confronted with a strange thing using boost.signals on SLES 9 SP3. I
don't shure Boost.signals bug, becase on FC4 and RHEL AS 3 all fine.
Test case:
--------------------- CUT HERE ------------------
#include
Pavel Syomin escribió:
Hi, all! I am novice in this list, so don't beat freely :)
I confronted with a strange thing using boost.signals on SLES 9 SP3. I don't shure Boost.signals bug, becase on FC4 and RHEL AS 3 all fine.
... Programm will not exit never.
Boost version: 1.31.0 (from SuSE rpm) GCC version: c++ (GCC) 3.3.3 (SuSE Linux)
I run this test on other SuSE boxes with same results. Any ideas?
I have tried your example with boost 1.33.1; gcc 4.0.1; in Mandrake 2006 and HP-UX 11.11; with and without threads, and it works. Have you tried to debug this test? If so, where is it hanging? (By the way, I don't like to use "test" as the name of the executable. Too many times it happens to me that the system fools me (PATH, alias, etc). Try to change the name.)
Hi!
I have tried your example with boost 1.33.1; gcc 4.0.1; in Mandrake 2006 and HP-UX 11.11; with and without threads, and it works. Have you tried to debug this test? If so, where is it hanging? I think that this bug is SuSE-specific, because I can't reproduce it on other unices. I run sample code with gdb and what is I see:
This GDB was configured as "i586-suse-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run Starting program: /home/syomin/boost-test [Thread debugging using libthread_db enabled] [New Thread 1076168384 (LWP 11562)] [There I press Ctrl+C] Program received signal SIGINT, Interrupt. [Switching to Thread 1076168384 (LWP 11562)] 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x4013028e in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0 #2 0x4012d040 in _L_mutex_lock_34 () from /lib/tls/libpthread.so.0 #3 0x4000ce90 in _dl_runtime_resolve () from /lib/ld-linux.so.2 #4 0x0804a7e7 in scoped_lock (this=0x804c5d4, m=@0x4024d8a0) at lwm_pthreads.hpp:73 #5 0x0804a7e7 in scoped_lock (this=0xbfffdeb0, m=@0x804c5d4) at lwm_pthreads.hpp:73 #6 0x0804a74d in boost::detail::sp_counted_base::release (this=0x804c5c8) at shared_count.hpp:141 #7 0x0804a565 in ~shared_count (this=0xbfffdf94) at shared_count.hpp:379 #8 0x0804a14f in ~shared_ptr (this=0xbfffdf90) at connection.hpp:62 #9 0x08049443 in ~connection (this=0xbfffdf90) at connection.hpp:134 #10 0x08049061 in main () at test.cc:16
Pavel Syomin escribió:
... (gdb) run Starting program: /home/syomin/boost-test [Thread debugging using libthread_db enabled] [New Thread 1076168384 (LWP 11562)]
[There I press Ctrl+C]
Program received signal SIGINT, Interrupt. [Switching to Thread 1076168384 (LWP 11562)] 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x4013028e in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0 #2 0x4012d040 in _L_mutex_lock_34 () from /lib/tls/libpthread.so.0 #3 0x4000ce90 in _dl_runtime_resolve () from /lib/ld-linux.so.2 #4 0x0804a7e7 in scoped_lock (this=0x804c5d4, m=@0x4024d8a0) at lwm_pthreads.hpp:73 #5 0x0804a7e7 in scoped_lock (this=0xbfffdeb0, m=@0x804c5d4) at lwm_pthreads.hpp:73
That's weird.
It seems that the library has created two mutex and it is blocked in one
of them.
Can you try this program?:
--------------<cut>------
/*
g++ mux_bloq.cc -o mux_bloq -pthread
*/
#include
Pavel Syomin escribió:
Raúl Huertas wrote:
Can you try this program?: [...]
You will laugh, but this code work fine with or without -pthread :) Can my problems be concerned with gcc or glibc version?
Oh. You are right, the program doesn't need pthread because glibc resolve pthread_mutex_init and pthread_mutex_lock. Perhaps it's a problem with Glibc. But the code worked, so it doesn't reproduce the problem with Boost.Signal. Sorry, but I have no more ideas... :(
participants (2)
-
Pavel Syomin -
Raúl Huertas