[prev in list] [next in list] [prev in thread] [next in thread] 

List:       hpux-devtools
Subject:    Re: HPUX-DEVTOOLS: gdb stack analysis help needed
From:       Mike Stroyan <stroyan () hpstryn ! fc ! hp ! com>
Date:       2002-08-23 20:17:49
[Download RAW message or body]

On Fri, Aug 23, 2002 at 12:14:55PM -0400, MATUSZAK,ED (HP-USA,ex3) wrote:
...
> hangs in prog b (close to 100% cpu)
> 
> tusc shows no system calls while looping, gdb stack after attaching and
> <cntrl>C is:
> 
> (gdb) where
> #0  0xc0198f0c in free () from /lib/libc.2
...
> #11 0xcdf84d84 in signal_handler_catch () from
> /cobol/prod/svrexp-2.0.10/coblib/libcobrts.sl
> #12 <signal handler called>
> #13 0xcdfb4a28 in mFi_rt_cdc_init_200 () from
> /cobol/prod/svrexp-2.0.10/coblib/libcobrts.sl
...
> #25 0xcdf84d84 in signal_handler_catch () from
> /cobol/prod/svrexp-2.0.10/coblib/libcobrts.sl
> #26 <signal handler called>
> #27 0xc0198f0c in free () from /lib/libc.2
> #28 0xc0324bf0 in __dla () from /lib/libCsup.2
> #29 0xc2390040 in __dt__22psftFiniteStateMachineXTUcTUl_Fv () from
> /data3/ps/m830f21p/bin/libpsbtunicode.sl
> #30 0xc23925b0 in psftRomajiToKatakanaParser::__dt () from
> /data3/ps/m830f21p/bin/libpsbtunicode.sl
> #31 0xc03258f8 in __shlTerm__FP16mapped_shl_entryPC15__staticArray_tT2 ()
> from /lib/libCsup.2
...
> #38 0xc018340c in exit () from /lib/libc.2
...
> #47 0x3204 in main ()
> (gdb) 
> 
> Can anyone tell me what is going on here? 

  It looks like the misadventure starts in stack frame #27.
__dt__22psftFiniteStateMachineXTUcTUl_Fv, also known as
psftFiniteStateMachine<unsigned char,unsigned long>::~psftFiniteStateMachine()

  The program has called exit, and as part of unloading shared libraries
that destructor function was called.  It either tried to deallocate a
bad array address, or tripped over corrupted memory when deallocating a
good address.  The free function caught a SIGSEGV or SIGBUS.

  Next the cobal signal handler caught that signal and tried to do
something about it.  That signal handler tried to do something too
clever and caused a second signal, probably a SIGSEGV or SIGBUS again.

  Now it gets rather ugly, as the cobal signal handler doesn't know when
to call it quits.  It again tries to do something clever about the signal
that it caught under its own signal handler.  It calls code that calls
free, and free probably gets into either a circular linked list chase or
some endless attempt to mutex lock against a lock it is already holding.

  There are at least two defects here.  The original signal is some
ordinary, but possibly difficult to characterize defect.  The nested
signal handlers and the calls that they make come from a design defect
in trying to do too much inside of a signal handler.  There is very little
that can be safely done inside of a signal handler.  Calling malloc/free
or printf are definitely not safe.

-- 
Mike Stroyan, mike_stroyan@hp.com
 _________________________________________________________________
 To leave this mailing list, send mail to majordomo@cxx.cup.hp.com
    with the message UNSUBSCRIBE hpux-devtools
 _________________________________________________________________
[prev in list] [next in list] [prev in thread] [next in thread]