[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Boids lives! ClupeoidsV1&2 live! (was Re: [Swarm-Support] crash from [co
From: |
Paul Johnson |
Subject: |
Boids lives! ClupeoidsV1&2 live! (was Re: [Swarm-Support] crash from [controlPanel setStateStopped] |
Date: |
Sun, 23 Jan 2005 02:34:33 -0600 |
User-agent: |
Mozilla Thunderbird 0.9 (X11/20041127) |
OK, found an answer. Can someone please explain this to me?
After I cleared away all possible causes of crashes I could find (
memory glitches, array-out-of-range, use of "id" as a variable name,
missing createEnd) it still crashed. I started checking to see which
methods were actually used in the program. A method that was not called
explicitly anywhere turnes out to cause the seg fault outlined below.
I packaged this up in case you are an adventurer who can tell me why
this happens.
http://lark.cc.ku.edu/~pauljohn/Swarm/MySwarmCode/NewBoids-4.tar.gz
Look at the end of boidSpace.m, you see this message from me:
// 2005-01-21 PJ Strange but true. If you remove the comments
// on the next lines 68-78, this program crashes.
// I wildly hypothesize it is a bug in gcc that gets confused on the
// drawself as opposed to drawSelf: that it really wants.
// - drawSelf
// {
// SimObject * obj;
// id <Index> index =[boidList begin: [self getZone]];
// while ((obj = [index next]))
// [obj drawSelfOn: boidRaster];
// return self;
// }
Seeing that NewBoids works, I was feeling good about myself and was
going to bed.
But No! I wonder, could this same problem explain why the sons of
NewBoids, ClupeoidsV1 and ClupeoidsV2 stopped working? There were some
accusations in this list that we had made some change in the Swarm
library itself that disabled features that these programs used and I
never checked into it. But I'm happy to so, NO PROBLEM. I've not fixed
any of the code in there except commenting out that unused method, an
voila, they work. Sample for yourselves.
http://lark.cc.ku.edu/~pauljohn/Swarm/MySwarmCode/ClupeoidsV1.2.tar.gz
http://lark.cc.ku.edu/~pauljohn/Swarm/MySwarmCode/ClupeoidsV2.2.tar.gz
It seems to me that these programs have "things" in them that might
cause trouble. I could swear I've had trouble in the past in other
projects when there's no "createEnd" but they still run.
Here's an example of something that has hurt me in other projects:
[agent init: ++agentID : OBSTACLE
: [position init: worldXSize/4 : worldYSize/2.0] :
velocity : 20.0];
[agent initModel: self];
[agent createEnd];
-----------------
At the end, it should have
agent = [agent createEnd];
But I'm happy to say these run. They were wrongly given up for dead as
victims of library updates, I think.
And I don't understand why it compiles at all when "id" is used as a
variable name. That used to drive gcc crazy.
pj
Paul Johnson wrote:
I'm working on Fedora Core 3 with Swarm-2.2 rc1.
I wanted a boids program and found Newboids in swarm FTP. I found, to
my surprise, that it DOES still run if you tell it to use the canvas
display, but not with the Raster display. I've gone through the code
over and over, looking for the usual sorts of mistakes that cause
unpredictable crashes (createBegin without createEnd, nil objects).
Every time I found one of them, my heart would soar thinking I had found
the problem. But no.
I've hacked it to a point now that makes me think it hits some
vulnerability in tclObjc. The seg fault now follows the observer's use
of [controlPanel setStateStopped]. The backtrace is below. If you have
seen anything like it, please give me a heads up!
I will gladly give this code to anybody who wants to see.
Program received signal SIGSEGV, Segmentation fault.
0xb7ed0de2 in tclObjc_objectToName (obj=0x1)
at /usr/src/debug/swarm-2.2/src/tclobjc/tclObjc.m:54
54 sprintf(name, "%s%c" PTRHEXFMT, obj->class_pointer->name,
ATDELIMCHAR, obj);
(gdb) bt
#0 0xb7ed0de2 in tclObjc_objectToName (obj=0x1)
at /usr/src/debug/swarm-2.2/src/tclobjc/tclObjc.m:54
#1 0xb7ed18e5 in tclObjc_msgSendToClientData (clientData=0x8198b40,
interp=0x80c4320,
argc=2, argv=0xbfffe4c4) at
/usr/src/debug/swarm-2.2/src/tclobjc/tclObjc.m:356
#2 0xb7ed1a5b in tclObjc_msgSendToArgv1 (clientData=0x0,
interp=0x80c4320, argc=3,
argv=0xbfffe4c0) at /usr/src/debug/swarm-2.2/src/tclobjc/tclObjc.m:466
#3 0x4f54ce3c in TclInvokeStringCommand () from /usr/lib/libtcl8.4.so
#4 0x4f54e708 in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so
#5 0x4f54fd50 in Tcl_EvalEx () from /usr/lib/libtcl8.4.so
#6 0x4f550870 in Tcl_EvalObjEx () from /usr/lib/libtcl8.4.so
#7 0x4f5a65c6 in Tcl_UplevelObjCmd () from /usr/lib/libtcl8.4.so
#8 0x4f54e708 in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so
#9 0x4f5792ff in TclExprFloatError () from /usr/lib/libtcl8.4.so
#10 0x4f57cbb5 in TclCompEvalObj () from /usr/lib/libtcl8.4.so
#11 0x4f5a6da7 in TclObjInterpProc () from /usr/lib/libtcl8.4.so
#12 0x4f54e708 in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so
#13 0x4f54e564 in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so
#14 0x4f54fd50 in Tcl_EvalEx () from /usr/lib/libtcl8.4.so
#15 0x4f5501c0 in Tcl_Eval () from /usr/lib/libtcl8.4.so
#16 0x4f550b07 in Tcl_GlobalEval () from /usr/lib/libtcl8.4.so
#17 0x4f5f4627 in Tk_BindEvent () from /usr/lib/libtk8.4.so
#18 0x4f5f6b48 in TkBindEventProc () from /usr/lib/libtk8.4.so
#19 0x4f5fe1d8 in Tk_HandleEvent () from /usr/lib/libtk8.4.so
#20 0x4f5fea28 in TkQueueEventForAllChildren () from /usr/lib/libtk8.4.so
#21 0x4f59c923 in Tcl_ServiceEvent () from /usr/lib/libtcl8.4.so
#22 0x4f59cb5f in Tcl_DoOneEvent () from /usr/lib/libtcl8.4.so
#23 0xb7ecb24c in tkobjc_doOneEventSync ()
at /usr/src/debug/swarm-2.2/src/tkobjc/common.m:157
#24 0xb7e846b5 in -[ControlPanel setStateStopped] (self=0x8113a18,
_cmd=0x804e4f8)
at /usr/src/debug/swarm-2.2/src/simtoolsgui/ControlPanel.m:151
#25 0x08049217 in -[ObserverSwarm buildObjects] (self=0x8112a18,
_cmd=0x804e218)
at ObserverSwarm.m:71
#26 0x08048eef in main (argc=1, argv=0x1) at main.m:19
--
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