help-cfengine
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

cfservd core dumps due to SIGTERM


From: Joe Buehler
Subject: cfservd core dumps due to SIGTERM
Date: Mon, 16 Jan 2006 09:09:11 -0500
User-agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)

The cfservd binary core dumps sometimes under AIX when it is
sent SIGTERM.  Here is a stack trace:

Program terminated with signal 11, Segmentation fault.
#0  0xd00194a8 in spin_lock_global_ppc_mp ()
   from /usr/lib/libpthreads.a(shr_xpg5.o)
(gdb) bt
bt
#0  0xd00194a8 in spin_lock_global_ppc_mp ()
   from /usr/lib/libpthreads.a(shr_xpg5.o)
#1  0xd017c028 in __heap_lock () from /usr/lib/libc.a(shr.o)
#2  0xd017d6bc in malloc () from /usr/lib/libc.a(shr.o)
#3  0xd0007f84 in _pthread_cleanup_push ()
   from /usr/lib/libpthreads.a(shr_xpg5.o)
#4  0xd0192d68 in printf () from /usr/lib/libc.a(shr.o)
#5  0x1000f6dc in CfLog ()
#6  0x1000eac4 in HandleSignal ()
#7  0x10005f7c in ExitCleanly ()
#8  0x00004778 in ?? ()
#9  0x00004778 in ?? ()
Previous frame identical to this frame (corrupt stack?)
(gdb)

The problem is that you're not allowed to call printf() from inside
a signal handler.  The calls you can make from a signal handler
are limited because many of the usual UNIX system calls
and library functions are not re-entrant.

There is a POSIX spec on this -- the information is summarised in
section 10.6 of the Stevens' "Advanced Programming in the UNIX
Environment" book (the best UNIX reference of which I have knowledge...).

There is a good intro article regarding these issues here:

http://www-128.ibm.com/developerworks/linux/library/l-reent.html?ca=dgr-lnxw03Reentrant

Another issue with the current signal-handling code is the use
of the "signal" function.  This function is defined to reset the signal
handler to the default value upon entry to the handler.  This means
that even if you call signal() right at the start of the handler
to set the handler back to its proper value, there is still a window
during which another signal of the same type will cause a malfunction.
The newer signal-handling function sigaction() has more reliable
semantics and should be used instead of signal() on those machines that
support it.
-- 
Joe Buehler





reply via email to

[Prev in Thread] Current Thread [Next in Thread]