[Ace-users] [tao-users] if stuck in corba call SIGUSR1 is not getting catched
Douglas C. Schmidt
schmidt at dre.vanderbilt.edu
Mon Oct 15 06:56:55 CDT 2007
Thanks for using the PRF.
> ACE_VERSION: 5.5
> TAO_VERSION: 1.5
ACE+TAO x.5 is old. Please upgrade to ACE+TAO+CIAO x.6.1 (i.e.,
ACE 5.6.1, TAO 1.6.1, and CIAO 0.6.1), which you can download from
under the heading: "Latest Beta Kit."
The DOC groups at Washington University, UC Irvine, and Vanderbilt
University only provide "best effort" support for non-sponsors for the
latest release, as described in
Thus, if you need more "predictable" help for earlier versions of
ACE+TAO, I recommend that you check out
for a list of companies that will provide you with ACE+TAO commercial
> HOST SYSTEM:
> $ uname -a
> SunOS ipms-x4200-2 5.10 Generic_118855-33 i86pc i386 i86pc
> I my CORBA server i have following architecture.
> for every request i get on the server i spawn a worker thread for it.
> this thread works on the request and send the result through callback.
> now it is quite possible that this worker thread gets stuck in the DB operations.
> so i have a heart beating mechanism in place if this thread gets stuck the HB monitor will kill it by sending SIGUSR1.
> now to graefully shutdown i have already registered a signal handler for SIGUSR1 in the worker thread.
> A strange thing happened if the above worker thread is stuck in the callback method, due to some problem on CORBA client.
> this thread misses HB update for more that 3 times, so HB monitor send SIGUSR1 to this worker, and surprisingly
> the whole process gets down. Why this signal is not catched in the signal handlers.
> Other thing is if this worker is not stuck in callback method and some where else the above HB mechanism works just well.
> Am I missing anything?
> This is the stack trace.
> Program received signal SIGUSR1, User defined signal 1.
> [Switching to LWP 5]
> 0xfe23ff7b in __lwp_park () from /lib/libc.so.1
> (gdb) bt
> #0 0xfe23ff7b in __lwp_park () from /lib/libc.so.1
> #1 0xfe23a6e3 in cond_sleep_queue () from /lib/libc.so.1
> #2 0xfe23a7f5 in cond_wait_queue () from /lib/libc.so.1
> #3 0xfe23acee in _cond_wait () from /lib/libc.so.1
> #4 0xfe23ad30 in cond_wait () from /lib/libc.so.1
> #5 0xfe23ad69 in pthread_cond_wait () from /lib/libc.so.1
> #6 0xfe8600fe in ACE_Condition_Thread_Mutex::wait (this=0x81d444c, mutex=@0xfe23ff7b, abstime=0x0) at OS_NS_Thread.inl:410
> #7 0xfe860126 in ACE_Condition_Thread_Mutex::wait (this=0x4d, abstime=0x0) at ../../../ace/Condition_Thread_Mutex.cpp:107
> #8 0xfea527be in TAO_Leader_Follower::wait_for_event (this=0x8197180, event=0xfd61d048, transport=0x4d, max_wait_time=0x0)
> at LF_Follower.inl:15
> #9 0xfea9e310 in TAO_Wait_On_Leader_Follower::wait (this=0x81e3ca0, max_wait_time=0x0, rd=@0xfd61d040)
> at ../../../../TAO/tao/Wait_On_Leader_Follower.cpp:72
> #10 0xfea7f17a in TAO::Synch_Twoway_Invocation::wait_for_reply (this=0xfd61d310, ?max_wait_time=0x0, rd=@0xfd61d040, bd=
> @0xfd61d020) at Transport.inl:47
> #11 0xfea7f768 in TAO::Synch_Twoway_Invocation::remote_twoway (this=0xfd61d310, max_wait_time=0x0) at ../../../../TAO/tao/
> #12 0xfea4fc2e in TAO::Invocation_Adapter::invoke_twoway (this=0xfd61d5b0, details=@0xfd61d500, effective_target=
> @0xfd61d490, r=@0xfd61d3b0,
> max_wait_time=@0x4d) at ../../../../TAO/tao/Invocation_Adapter.cpp:299
> #13 0xfea4f6e5 in TAO::Invocation_Adapter::invoke_remote_i (this=0xfd61d5b0, stub=0x81d6e00, details=@0xfd61d500,
> max_wait_time=@0xfd61d41c) at ../../../../TAO/tao/Invocation_Adapter.cpp:271
> #14 0xfea4fe60 in TAO::Invocation_Adapter::invoke_i (this=0xfd61d5b0, stub=0x81d6e00, details=@0xfd61d500)
> at ../../../../TAO/tao/Invocation_Adapter.cpp:88
> #15 0xfea4f4aa in TAO::Invocation_Adapter::invoke (this=0xfd61d5b0, ex_data=0x4d, ex_count=77) at ../../../../TAO/tao/
> "There is no substitute for intelligence, experience, common sense, and good taste." - Bjarne Stroustrup
> - Vikram Karandikar
> tao-users mailing list
> tao-users at mail.cse.wustl.edu
More information about the Ace-users