help-cfengine
[Top][All Lists]
Advanced

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

Re: Seg Fault w/ cfenvd


From: Mark . Burgess
Subject: Re: Seg Fault w/ cfenvd
Date: Fri, 14 Jan 2005 23:24:33 +0100 (MET)

The signals seems to be signal 11 (seg fault) from gdb, but the stack
has been destroyed y something. It will be difficult to figure out what the
cause is. One problem that several folks have had is in mixing versions
of Berkely DB. Be careful you haven't compiled with the header file from
one version and the lib from another.

M

On 14 Jan, Eric Sorenson wrote:
> 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.
> 



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Work: +47 22453272            Email:  Mark.Burgess@iu.hio.no
Fax : +47 22453205            WWW  :  http://www.iu.hio.no/~mark
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~




reply via email to

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