[Top][All Lists]

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

Re: Seg Fault w/ cfenvd

From: Eric Sorenson
Subject: Re: Seg Fault w/ cfenvd
Date: Fri, 14 Jan 2005 13:21:27 -0800 (PST)

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.


 - Eric Sorenson - Explosive Networking - -

reply via email to

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