[Top][All Lists]

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

Re: another mysterious segfault

From: Lars Damerow
Subject: Re: another mysterious segfault
Date: Mon, 29 Aug 2005 23:01:47 -0700
User-agent: Mutt/1.5.6i

>From Frank Smith <address@hidden>, Mon, Aug 29, 2005 at 07:02:22PM -0500:
> --On Monday, August 29, 2005 16:20:15 -0700 Lars Damerow <address@hidden> 
> wrote:
> > I have a very naive question--is there any reason aside from speed that
> > cfengine is written in C? The sysadmin in me can't help but think that a
> > scripting language would have better error reporting than
> > "Segmentation fault." ;)
> As a former C programmer, in my opinion there is no reason for a well-written
> C program to segfault other than HW failures.  In cfengine's case, I would
> hope that the likely culprit is linking in and calling library functions
> whose actual parameters and return values are different from the way they
> are defined in the header files it was compiled against, usually due to a
> version mismatch between the headers available at compile time and the actual
> libraries linked in at runtime. If this is your problem you might consider
> building cfengine statically for your kickstart install.

I built a static cfagent and kickstarted with it. I got the same segmentation


>   The other option is that someone made some (bad) coding assumptions that
> all data passed to it would be of the correct type and value range, that all
> function calls would return successfully, and that any decision tree accounts
> for all possible cases, and thus skipped adding all the necessary error-
> checking code to exit cleanly with a meaningful error message under any
> of those situations.  If cfengine is in this category then it needs fixing.

lars damerow
button pusher
pixar animation studios

I was never cool in school--I'm sure you don't remember me.
And now it's been ten years; I'm still wondering who to be,
and I'd love to mix in circles, cliques and social coterie...

reply via email to

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