RE: gdb, stderr, totally baffing experience!

[Paul Box]

Hi Paul

the last time I had such baffling errors (printf statements "causing" 
segfaults, other methods that worked beautifully suddenly producing errors 
when a seemingly unrelated statement was added), it turned out to be an array 
that I had hardcoded its dimensions in one part of the code, and then gave 
illegal dimensions to that array through a probe.  In my case, I was drawing a 
histogram of the age distribution of a population in an observerswarm, which 
got its information from a variable called ageclasses[20] declared in the 
modelswarm.  Sloppy coding allowed other parts of the program to request that 
variable's contents as ageclasses[whatever].  If you passed a value of 
'whatever' greater than 20, all kinds of unpredictable things would happen at 
run time.

Is there anything similar in your case?

>===== Original Message From Paul Johnson <address@hidden> =====
>Hello everybody:
>
>One of the Swarm users sent me a program that has a seg fault.  I ran it
>through gdb and found that the line causing the trouble was a call to a
>+createBegin method. I mean, literally, the top line in the backtrace
>was in the ModelSwarm
>
>newAgent = [Agent createBegin: self];
>
>That was the one the debugger pointed to in step 1. That is somewhat
>unusual in my experience because usually gdb points at something you can
>see would cause a segfault.  If the cause is inside +createBegin, for
>example, it would list a line in there.
>
>So I rewrote the class to eliminate the need for it to override
>SwarmObject's +createBegin, so I could comment out +createBegin.  Then
>the backtrace started pointing at a call to Swarm's built in uniformIntRand.
>
>So I was starting to think that something is so dramatically wrong that
>gdb has no idea what to do, and I started putting in debug prints like this:
>
>fprintf(stderr,"update family num_family is %d\n",num_family);
>
>And then, to my total surprise and astonishment, I started getting
>bactraces where the fprintf was the causing the seg fault.  Here's the
>bit from the backtrace
>
>Program received signal SIGSEGV, Segmentation fault.
>0x420503da in vfprintf () from /lib/i686/libc.so.6
>(gdb) bt
>#0  0x420503da in vfprintf () from /lib/i686/libc.so.6
>#1  0x4205a297 in fprintf () from /lib/i686/libc.so.6
>#2  0x08050ff4 in _i_Agent__updateFamily (self=0x8b6d2d8,
>_cmd=0x8058790) at Agent.m:438
>#3  0x08050907 in _i_Agent__step (self=0x8b6d2d8, _cmd=0x8056e00) at
>Agent.m:256
>#4  0x40017ddb in L10 () from /usr/lib/swarm/libswarm.so.0
>#5  0x40205120 in objc_call (fa=0x8c36f10)
>
>If I change all those fprintf statements to printf, then I still get the
>  seg fault pointing at the fprintf, but it is back pointing at
>uniformIntRand or such.
>
>So there's obviously something about gdb or stderr I don't understand.
>Do you?
>
>One bit of information about this program. It is rather like the
>ArtificialStockMarket when I started revising that code--liberal use of
>C (structs, C arrays) interspersed with Obj-C.  There could be
>significant array problems, like accesses of value[-1] or value[N+1] in
>an array that has valid index values from 0 to N.
>
>Is it possible that, when some part of a program accesses memory so
>badly that it could damage memory in use by uniformIntRand in a way that
>totally baffles the gdb?
>
>
>--
>Paul E. Johnson                       email: address@hidden
>Dept. of Political Science            http://lark.cc.ku.edu/~pauljohn
>University of Kansas                  Office: (785) 864-9086
>Lawrence, Kansas 66045                FAX: (785) 864-5700
>
>
>                  ==================================
>   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.

////////////////////////////////////////
// Paul Box
// Aquatic, Watershed, and Earth Resources
// Utah State University


                  ==================================
   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.