MOO-cows Mailing List Archive
Panic dump with 1.8.0alpha6p1
Date: Sat, 27 Jan 1996 03:42:18 PST
From: Michael Brundage <email@example.com>
Content-Type: text/plain; charset=US-ASCII
Got a panic with the 1.8.0alpha6 version of the server (with the patch to
execute.c installed). Relevant (edited) info from the log:
Jan 27 04:22:28: *** PANIC: Caught signal 11
Jan 27 04:22:28: object:blah, line 39: server panic
Jan 27 04:22:28: ... called from #-1:Input to EVAL, line 3
Jan 27 04:22:28: ... called from built-in function eval()
Jan 27 04:22:28: ... called from #58:eval_cmd_string (this == #142), line 18
Jan 27 04:22:28: ... called from #58:eval*-d (this == #142), line 12
Jan 27 04:22:28: (End of traceback)
Panic dumping db, etc.
The relevant lines in object:blah are
35: OBJ = original;
36: while (valid(OBJ))
37: for name in (properties(OBJ))
38: if (!clear_property(OBJ, name))
39: if (this:has_property(duplicate, name))
40: duplicate.(name) = OBJ.(name);
42: add_property(duplicate, name, OBJ.(name), property_info(OBJ, name));
46: OBJ = parent(OBJ);
As you can see, I had erroneously named a variable with the reserved
keyword OBJ, so that's probably the boo-boo here (though surely it
doesn't merit a PANIC dump).
Obtaining a stack trace didn't work out so well:
% dbx moo core
dbx version 2.10.1
Type 'help' for help.
Corefile produced from file "moo"
Child died at pc 0x43a0a0 of signal : Illegal instruction
reading symbolic information ...
dbx: internal error: Proc symbol (begin_code_allocation:F19) without proc table entry
and then dbx exited, so that's that.
[If it makes any difference, I was listening to an additional port at the time,
though nothing was connected through it. And I had also previously noticed a
slight increase in memory usage after @grep'ing the db for an expression
(small memory leak in match() ?).]
Subject Index |