Re: [Swarm-Support] I have the strangest seg fault (ever)!

[Paul Johnson]

Thanks.  I think I need to understand the implications of this more 
broadly.  Here I have an array of character strings that is not 
protected in memory, so it gets written over, causing the crash. Right?

If that same memory had been declared as an

id x;

or

AThing * x;

and then I did the createBegin/createEnd to allocate, that is basically 
the same as using malloc.  So even though the variable is declared 
inside a method, it is protected from being written over. Correct?

Do you think it would be better if the EZGraph made a copy of the color 
array?  Rather than just keeping a pointer to some memory?

I still haven't figured why the backtrace looks so different on various 
Fedora 3 systems.  Only on one do I see all the tcl warnings that led to 
the solution.

With Swarm built without-jdkdir (the swarm-nojdk rpm) I get a more 
informative backtrace that points right at the color issue.

I would have figured this out sooner from this:

Program received signal SIGSEGV, Segmentation fault.
0x464bdca3 in strlen () from /lib/tls/libc.so.6
(gdb) bt
#0  0x464bdca3 in strlen () from /lib/tls/libc.so.6
#1  0x46492155 in vfprintf () from /lib/tls/libc.so.6
#2  0x464a9fbb in vsprintf () from /lib/tls/libc.so.6
#3  0xb7edec97 in -[TclInterp eval:] (self=0xbfff426c, _cmd=0xb7f9dec8,
    fmt=0x8 <Address 0x8 out of bounds>)
    at /usr/src/debug/swarm-2.2/src/tclobjc/TclInterp.m:347
#4  0xb7ecfe20 in -[GraphElement setColor:] (self=0x8436478, 
_cmd=0xb7f65d60,
    color=0x8 <Address 0x8 out of bounds>)
    at /usr/src/debug/swarm-2.2/src/tkobjc/Graph.m:244
#5  0xb7e8d448 in -[EZGraph 
createGraphSequence:forSequence:withFeedFrom:andSelector:] (
    self=0x82e4ea0, _cmd=0xb7f65de8, aName=0xbfffc5e0 "Seats 5", 
aSeq=0x841b100,
    anObj=0x8428180, aSel=0x805e7a0) at 
/usr/src/debug/swarm-2.2/src/analysis/EZGraph.m:300
#6  0xb7e8d98b in -[EZGraph createSequence:withFeedFrom:andSelector:] 
(self=0x82e4ea0,
    _cmd=0x805e540, aName=0x0, anObj=0x0, aSel=0x0)
    at /usr/src/debug/swarm-2.2/src/analysis/EZGraph.m:367
#7  0x08055f97 in -[Output createSequencesParty:] (self=0x82b3678, 
_cmd=0x805e520, i=5)
    at Output.m:983
#8  0x080564a8 in -[Output addNewPartyAt:] (self=0x82b3678, 
_cmd=0x80812f0, x=0)
    at Output.m:1050
#9  0xb7f1abcb in L10 () from /usr/lib/swarm/libswarm.so.0
#10 0x082b3678 in ?? ()
#11 0x080812f0 in ?? ()
#12 0x00000000 in ?? ()


Marcus G. Daniels wrote:
> Paul Johnson wrote:
>
> > You are a little over my head.  How can call sequences be impossible 
> > if they show up in the backtrace?
>
>
> gdb is just interpreting what it finds in the stack, and the stack can 
> be corrupted by a malfunctioning program...
>
> > Am I declaring "colors" wrongly?
>
>
> You do have an automatic variable in -createGraphWriter that will use 
> local stack space to store the pointers to the color strings and it will 
> become invalid as soon as the method leaves.  If you assign that pointer 
> as in [prSeatGraph setColors: colors count: 9], then prSeatGraph will be 
> holding a invalid reference to the color array after leaving the method. 
>  So you either have to malloc that array, put it in an ivar, or make it 
> `static'.     _______________________________________________
> Support mailing list
> address@hidden
> http://www.swarm.org/mailman/listinfo/support


--
Paul E. Johnson                       email: address@hidden
Dept. of Political Science            http://lark.cc.ku.edu/~pauljohn
1541 Lilac Lane, Rm 504
University of Kansas                  Office: (785) 864-9086
Lawrence, Kansas 66044-3177           FAX: (785) 864-5700