On 2009 November 07, Saturday 10:33:42 [email protected] wrote:
Hi,
about the patch below: is using the getpid() here correct? Every thread will
have the same pid (at least on linux (maybe not with NPTL?)). Shouldn't we use
pthread_self() instead?
I ask this because I'm experiencing some problems with the shutdown process,
once in a while it gets stuck with a backtrace like this:
#0 0xb7fa9424 in __kernel_vsyscall ()
#1 0xb7c3bef6 in nanosleep () from /lib/i686/cmov/libc.so.6
#2 0xb7c7948c in usleep () from /lib/i686/cmov/libc.so.6
#3 0x080d2ddc in AmSessionContainer::dispose () at AmSessionContainer.cpp:67
#4 0x0806a3a4 in sig_usr_un (signo=15) at sems.cpp:105
#5 <signal handler called>
#6 0xb7f64638 in pthread_create@@GLIBC_2.1 () from
/lib/i686/cmov/libpthread.so.0
#7 0x080e6536 in AmThread::start (this=0x921d860, realtime=false) at
AmThread.cpp:130
#8 0x0806c973 in main (argc=4, argv=0xbfac3404) at sems.cpp:414
I couldn't find the problem yet, but I see this kind of log:
(9024) DEBUG: [b7b9e6c0] clean_sessions (AmSessionContainer.cpp:77): Session
cleaner starting its work
(9024) WARNING: [b7b9e6c0] stop (AmThread.cpp:157): pthread_detach failed with
code ESRCH: thread could not be found.
other times it stucks with this backtrace:
(gdb) thread 1
[Switching to thread 1 (Thread 0xb7b696c0 (LWP 16142))]#0 0xb7f74424 in
__kernel_vsyscall ()
(gdb) bt
#0 0xb7f74424 in __kernel_vsyscall ()
#1 0xb7c06ef6 in nanosleep () from /lib/i686/cmov/libc.so.6
#2 0xb7c4448c in usleep () from /lib/i686/cmov/libc.so.6
#3 0x080baefc in AmRtpReceiver::dispose () at AmRtpReceiver.cpp:90
#4 0x0806a3a9 in sig_usr_un (signo=15) at sems.cpp:107
#5 <signal handler called>
#6 0xb7f74424 in __kernel_vsyscall ()
#7 0xb7c47fb9 in mprotect () from /lib/i686/cmov/libc.so.6
#8 0xb7f2fd60 in pthread_create@@GLIBC_2.1 () from
/lib/i686/cmov/libpthread.so.0
#9 0x080e6536 in AmThread::start (this=0x9bfa8b0, realtime=false) at
AmThread.cpp:130
#10 0x0806ca7b in main (argc=4, argv=0xbfc905d4) at sems.cpp:423
(gdb) thread 2
[Switching to thread 2 (Thread 0xb6ffdb90 (LWP 16142))]#0 0xb7f74424 in
__kernel_vsyscall ()
(gdb) bt
#0 0xb7f74424 in __kernel_vsyscall ()
#1 0xb7c06ef6 in nanosleep () from /lib/i686/cmov/libc.so.6
#2 0xb7c4448c in usleep () from /lib/i686/cmov/libc.so.6
#3 0x080baefc in AmRtpReceiver::dispose () at AmRtpReceiver.cpp:90
#4 0x0806a3a9 in sig_usr_un (signo=15) at sems.cpp:107
#5 <signal handler called>
#6 0xb7f74424 in __kernel_vsyscall ()
#7 0xb7c47fb9 in mprotect () from /lib/i686/cmov/libc.so.6
#8 0xb7f2fd60 in pthread_create@@GLIBC_2.1 () from
/lib/i686/cmov/libpthread.so.0
#9 0x080e6536 in AmThread::start (this=0x9bfa8b0, realtime=false) at
AmThread.cpp:130
#10 0x0806ca7b in main (argc=4, argv=0xbfc905d4) at sems.cpp:423
As you can see two threads are in the signal handler, I don't know how is that
even possible.
any ideas?
br
Szo
> Author: sayer
> Date: 2009-11-07 10:33:41 +0100 (Sat, 07 Nov 2009)
> New Revision: 1616
>
> Modified:
> trunk/core/sems.cpp
> Log:
> removing PID file as last action. thanks to juha for reporting.
>
> Modified: trunk/core/sems.cpp
> ===================================================================
> --- trunk/core/sems.cpp 2009-11-06 20:35:48 UTC (rev 1615)
> +++ trunk/core/sems.cpp 2009-11-07 09:33:41 UTC (rev 1616)
> @@ -92,7 +92,6 @@
> WARN("Signal %d received.\n", signo);
>
> if (!main_pid || (main_pid == getpid())) {
> - unlink(pid_file.c_str());
>
> static AmMutex clean_up_mut;
> static AmCondition<bool> need_clean(true);
> @@ -118,6 +117,8 @@
>
> INFO("Finished.\n");
>
> + unlink(pid_file.c_str());
> +
> exit(0);
> }
>
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
