About Reading GDB Backtraces: Here's a good one: #0 0x405ab4e1 in __kill () from /lib/libc.so.6 #1 0x405ab156 in raise (sig=6) at ../sysdeps/posix/raise.c:27 #2 0x405ac868 in abort () at ../sysdeps/generic/abort.c:88 #3 0x40223336 in Letext () at /usr/local/src/redhat/BUILD/swarm-2.0.1.20000209/src/misc/debugabort.c:9 #4 0x401b06f8 in _i_Error_c__raiseEvent_ () at /usr/local/src/redhat/BUILD/swarm-2.0.1.20000209/src/defobj/Symbol.m:173 #5 0x401b9998 in nil_method (receiver=0x0, op=0x804efb0) at /usr/local/src/redhat/BUILD/swarm-2.0.1.20000209/src/defobj/internal.m:1345 #6 0x804a229 in _i_Voter__reportX_Y_ (self=0x813d370, _cmd=0x804f330, p=0x0, c=0x8141048) at Voter.m:48 Note #6 is the first one that refers to a file in my code, Voter.m. The voter's reportX:Y: method is supposed to get two arguments that are objects, which should have addresses like 0x8141048, which the final argument does. But, the argument p=0x0, it is nil, which is the cause of the crash. ---------------------------------------------------------- Re: building gdb, Marcus said: I just use the development sources of GDB. I grab it out of CVS, typically, but Cygnus has tarballs too. This is what seems to me to be the sensible source tree to use when investigating problems with GDB. http://sourceware.cygnus.com/gdb ftp://sourceware.cygnus.com/pub/gdb/snapshots I install it in a local area ($HOME/packages) so as not to interfere with the system-provided gdb and other files in /usr. These newer GDBs have other advantages like better thread management, which is useful for debugging native thread JDK things. Here is an example build script: #!/bin/sh P=$HOME/packages SRC=$S/gdb $SRC/configure --prefix=$P --srcdir=$SRC make /*MD Jan 7, 2000 */ DC> Have I any recourse after the message: DC> "GDB can't read core files on this machine." Run the model inside gdb, like this: $ gdb mymodel (gdb) run (I can't get the current snapshot of gdb to build on Windows, and I don't see anything in the ChangeLogs that suggests support for core dumps have been added.) /*Marcus Daniels Nov. 22, 1999 */ PJ> I've got the grid of objects that is receiving the message from PJ> the rightclick on the raster. In each of these objects, there is a PJ> list of agents, and I take the first one of those agents and PJ> create a probe for it. Then when I right click on the class name PJ> in the probe, I get a crash and here is the backtrace. These literal commands are intended for Swarm 2.0.1 on Redhat. (But *think about* this process, don't just type it in.) $ gdb .libs/your-app (gdb) run ...wait for control panel, bring up the probe display [press control-C] (gdb) sharedlibrary (gdb) break VarProbe.m:556 (gdb) c ..now right click on class name (I guess you mean the blue name in the upper left?) (gdb) print *self (gdb) c (gdb) print *self ..repeat continue/print cycle until you get the crash. Then think about why the last one reported might not be valid. >>>>> "MM" == Matthew M Murphy writes: MM> #0 objc_msg_lookup (receiver=0x815ec10, op=0x804d580) at MM> objc/sarray.h:232 #1 0x8049764 in _i_Bug__receiveUtteranceFrom_ This says that receiveUtteranceFrom is sending a message (0x804d580) to receiver 0x815ec10. You can look at the class of the target by using "print ((Class *) receiver)->name" and you can look at the selector name by using "call sel_get_name (op)". The latter will probably not work unless you have a version of Swarm you built your self without inlining. Typically this sort of thing happens when you send a message to an object that has been dropped, or you have an uninitialized target variable, or the message you are sending doesn't exist in the target (e.g. a typo). /* This works if your gdb is "up to date" from cvs */ B> PS. I'm using the Debian gdb 4.17 with (useless) Objective-C patches (aka B> gdb 4.17.m68k.objc.threads.hwwp.fpu.gnat) which simply ignores 'call B> xprint(obj) or 'xfprint(collection)'. Here's a new build: ftp://ftp.santafe.edu/pub/swarm/needed-software/gdb-20000105.i586-pc-linux-gnu.gz Try this: $ gdb .libs/testxprint (gdb) break main (gdb) run (gdb) next 4 (gdb) call xfprint (aList) ------------------------------------ PJ> I ran gdb, put a break on "main" then did "run" and then used "s" PJ> to proceed. To catch this one, the thing to do would be to say "break nil_method", after the main breakpoint was hit, then "c". _________________________________- Rick Riolo said this, which made sense: frankly, I almost never use a debugger, other that just to very occassionally try a backtrace to see where something might be going amiss. I much prefer a) incremental code changes, so I know if a seg fault shows up, it must be in that last method I added, b) use of my own DMSG's, so I can tune them to put out semantically useful information. I find that just a few (b) type messages narrows the problem's down very fast, and then a minute or two of code review (good to do anyway) finds the array bounds violation, the failure to initialize, or whatever is the problem. the typical scenario is "oh it crashed just after agents played and just before they began updating, so it must be at the end of method x or the start of method y. ah, I see i forgot to do A at the beginning..." I'll admit it may be a no-accounting-for-taste situation, but I find that relying on debuggers encourages people to not pay attention to the substance of what they are trying to get their programs to do. - r ______________________________