On Mon, Aug 29, 2005 at 11:01:47PM -0700, Lars Damerow wrote: > I built a static cfagent and kickstarted with it. I got the same segmentation > fault.
Have you tried reproducing the problem inside valgrind? Valgrind ( http://valgrind.org/ ) is a lovely debugging tool for such mysterious segfaults (and many other problems as well). It could give valuable hints about what caused the problem. Allow me to provide a small example: [EMAIL PROTECTED]:~$ cat <<EOF > bug.c > #include <stdio.h> > int main() > { > // Printing of a bogus memory address > puts((char*)5); > return 0; > } > EOF [EMAIL PROTECTED]:~$ cc -o bug bug.c [EMAIL PROTECTED]:~$ ./bug bash: segmentation fault ./bug [EMAIL PROTECTED]:~$ valgrind ./bug ==4472== Memcheck, a memory error detector. ==4472== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==4472== Using LibVEX rev 1367, a library for dynamic binary translation. ==4472== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==4472== Using valgrind-3.0.1, a dynamic binary instrumentation framework. ==4472== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==4472== For more details, rerun with: -v ==4472== [snip lots of output] ==4472== ==4472== Invalid read of size 1 ==4472== at 0x11B1D9F2: strlen (mac_replace_strmem.c:243) ==4472== by 0x11C8756A: puts (in /lib/libc-2.3.5.so) ==4472== by 0x4004B5: main (in /home/knuta/bug) ==4472== Address 0x5 is not stack'd, malloc'd or (recently) free'd ==4472== ==4472== Process terminating with default action of signal 11 (SIGSEGV) ==4472== Access not within mapped region at address 0x5 ==4472== at 0x11B1D9F2: strlen (mac_replace_strmem.c:243) ==4472== by 0x11C8756A: puts (in /lib/libc-2.3.5.so) ==4472== by 0x4004B5: main (in /home/knuta/bug) ==4472== ==4472== ERROR SUMMARY: 9 errors from 9 contexts (suppressed: 0 from 0) ==4472== malloc/free: in use at exit: 0 bytes in 0 blocks. ==4472== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==4472== For counts of detected errors, rerun with: -v ==4472== No malloc'd blocks -- no leaks are possible. As you can see, the problem is now pinpointed to a call of puts inside main. The problem is significantly easier to track down, and combined with a few carefully positioned debug-prints the problem should be relatively easy to track down. -- Knut Auvor Grythe ITEA Systemdrift _______________________________________________ Help-cfengine mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-cfengine
