Re: debugging a swarm model

[Roger Burkhart]

> Sorry to bother you again...:)  I've traced through the problem I mentioned
> last time and figured out how to print the variables.  Now, when I look at the
> addresses of the variables and messages in the function where the program,
> dies, I find that all of them have the <Address 0xXXXXXXXX out of bounds
> message.  Somehow, the function is being set to an address much higher than
> possible.  Off hand, would you say the problem lies in my code, you code,
> or GNU's code?

Just off hand, I'd guess in the same order you just suggested (your code,
Swarm code, and finally GNU code, which is very unlikely).  But that's in
the absence of any other information.

On the variables you're now able to print, they could have invalid values
because they've never been initialized, because something else trashed
them, or various other reasons.  The next step might be to set an earlier
breakpoint, such as on entry to the function, to see if they ever have
values you expect, and if so you could then step through statement by
statement to see exactly when they get corrupted.  It's unfortunate but
true that coding in C often requires recourse to tedious, low-level
debugging such as this.  Because Objective C is nothing but C plus a
messaging layer, its debugging requirments aren't any better and have
the additional complication of message calls to methods in classes.

Eventually we'll be able to provide some better debugging support with
both interactive and gdb-callable tools, and future versions of gdb
are finally supposed to provide better native support for Objective
C, but as long as we're dealing with C some problems can remain
frustrating to track down without use of every debugging trick you can,
not only in gdb, but by other means such as simplifying your program
down to the simplest possible cases that either work or don't work.

Sorry I'm not giving very specific suggestions but without the same
source to exercise there's not a whole lot more I could do.  Another
approach is to try to rebuild the elements of your program just one
added piece at a time and try to find just when and if things seem
to start going wrong.  It's a long path but can be pretty relentless
in finding a problem.  But usually breakpoint debugging on the original
program along with a little headscratching is enough.

Roger Burkhart