MOO-cows Mailing List Archive


Panic dump with 1.8.0alpha6p1

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);
41:       else
42:         add_property(duplicate, name, OBJ.(name), property_info(OBJ, name));
43:       endif
44:     endif
45:   endfor
46:   OBJ = parent(OBJ);
47: endwhile

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() ?).]


Home | Subject Index | Thread Index