Re: strange messages

[Roger Burkhart]

It's good to see that the stack trace for nil_method is the same as
when you force the error by setting the instance variable to a known
invalid value.  The trace through activity run levels is what there
ought to be.  For some reason, one of your actions is trying to send a
message to the location at that instance variable, as if that instance
were the start of an object, which it obviously is not.

One possible cause is memory corruption, perhaps caused by continuing
to use some allocated space after it's freed or improperly using some
newly allocated space.  Unfortunately, in the style of C memory bugs,
this invalid allocation use could occur by nearly any code running in
the program and leaving effects that other code uncovers.  We don't
know of any problems in Swarm library code but that's not saying there
isn't any.

Does your application change the actions to be executed?  Is there any
chance an action was created to an object that was later dropped?

As general debugging approach I'd recommend chasing the nil_method case
and see if you can make sense of the action sent to that nil value.  Try
simplifying any other parts of the program to see if you can eliminate any
other program sections that might be creating the situation.  The self
argument in the following stack trace line is the action object which is
being fired:

#1  0x3b618 in _i_ActionTo_0___performAction__ (self=0x1d5090, _cmd=0x116768, 
    anActivity=0x1dba18) at Action.m:161

When stopped in nil_method, you could print the internal contents of that
ActionTo_0 object (getting into activity library internals) using the
gdb command:

p *(struct ActionTo_0 *)0x1d5090

This will print the instance variables of the internal action object;
the variables "target" and "selector" are from an earlier createAction
statement as follows:

  [aGroup createActionTo: target message: (SEL)selector];

The other thing to figure out is when and where this particular
troublesome action was created.  Rather than a memory bug, it could be
there are pointer-based statements writing at the wrong locations and
messing up the action after it's created.  If so, once you've seen the
action after it's messed up, you can back up to breakpoints earlier and
earlier in the program, printing the contents of the action object
until you find when and where it first goes wrong.

For now, there's just the low level debugger statements to dump the
internals of an action object, but later there will be special print
statements callable from the debugger that don't require knowledge of
internals.