swarm-support
[Top][All Lists]
Advanced

[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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]