Re: another mysterious segfault

[Knut Auvor Grythe]

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:

  knuta@kokosbolle:~$ cat <<EOF > bug.c
  > #include <stdio.h>
  > int main()
  > {
  >         // Printing of a bogus memory address
  >         puts((char*)5);
  >         return 0;
  > }       
  > EOF
  knuta@kokosbolle:~$ cc -o bug bug.c  
  knuta@kokosbolle:~$ ./bug
  bash: segmentation fault  ./bug
  knuta@kokosbolle:~$ 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