RE: Problems with -static and GDB

[Steven J Clark]

> To be honest to me "debugging Swarm" until now has meant liberal uses
> of
> printfs (a highly inefficient method to be sure).
> 
> Amen to that!  However, a good debugger is not the solution to every
> problem.
> 
>  Problem is that GDB only comes up with this:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x400d566e in __libc_free ()
> (gdb) bt
> #0  0x400d566e in __libc_free ()
> #1  0x81abc10 in ?? ()
> #2  0xffffffff in ?? ()
> Cannot access memory at address 0x31.
> 
>  Which is not much of a help. Obviously I have poked around all
> instances of free() in my program (there is exactly one), but the
> crash
> is not coming from my part of the code.
> 
> It sure looks as if your stack got mangled.  If that's the case, then
> the cause can be arbitrarily far away from the symptom, and a debugger
> will be of little use.  You need to find some piece of code that
> overwrites random areas of memory.  Look especially for a mismatch
> between the interpretation of arguments in a function (or method) call
> and their interpretation within the function (method).  I've had that
> problem even though the types did match.
> 
> One occasionally runs into memory allocation debugging tools that
> would help.  I know Centerline and NextStep have them, and I think
> Rogue Wave has one.  Gnu, to my knowledge, does not.  Such tools do
> things like monitor all reads and writes of memory to catch reads of
> uninitialized data, writes on freed or unallocated memory, etc.
> Needless to say, they slow down your program and tend towards
> complicated to use.  But they can catch unbelievably amazingly
> difficult bugs!  Too bad there isn't one for Gnu.
> 
>  So the only idea that I could come up with was that GDB needed all
> the
> dynamically loaded stuff to be statically linked before he could be of
> any help.
> 
> That I don't know.  I would expect so, though.
> 
> Steven J. Clark    address@hidden    313-769-4396
> Center for Electronic Commerce, Industrial Technology Institute
> Box 1485, Ann Arbor, MI 48106
> 

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.
                  ==================================