On Fri, 14 Jan 2005, David E. Nelson wrote:
No, 'bt full' didn't add anything more. I agree, the signum looks suspicious.
According to the man page, it's an 'int' and 1191328 sure looks awfully big
for an int.
BTW, I found a handfull of Solaris systems this AM that had cfenvd core files
- all the same problem.
Also, locks.c:104 is:
snprintf(OUTPUT,CF_BUFSIZE*2,"Received signal %d (%s) while doing
[%s]",signum,SIGNALS[signum],CFLOCK);
I've never used gdb before, so just for my education, did the segfault occur
at '#0' or '#2' below? I take it that '??' means it couldn't find any symbol
info at the memory address 0xff1b3200...correct?
#0 was the last thing to execute. 0xff1b3200 was the program counter value
at that point in execution (the fact that it's there means the program had
actually executed that function). You're right the '??' means there was no
symbol information, usually this is because it has stepped off into libc
(or other external library), might be stripped of debugging symbols.
What strikes me as odd about this is that the topmost frame is
HandleSignal, rather than the normal sleep() loop (which would show
StartServer as the topmost frame, I believe). This suggests that the
unhandle-able signal was raised by something outside of cfenvd.
Are you by chance running with -T / --tcpdump ? Looking at cfenvd.c,
that enables some additional code that might be problematic.