MOO-cows Mailing List Archive

[Prev][Next][Index][Thread]

[SERVER] possible bug with verb args



E_MOO recently server paniced when the URL /objbrowse/$building_utils was
requested.  The log contained something along the lines of:

Dec 16 23:29:37: *** PANIC: Caught signal 11
Dec 16 23:29:37: #285:bf_verb_args (this == #0), line 11:  server panic
....
Dec 16 23:29:37: (End of traceback)

(where .... are the traceback lines that lead up to the call to
$bf:bf_verb_args, and are illrelevant).
The PANIC db was written okay, so I restarted with that and did a:

@d $building_utils:

It paniced again, with the same traceback, but after it printed info for the
first three verbs.  Contents of :bf_verb_args are:

@program $bf:bf_verb_args   this none this
 1:  programmer = caller_perms();
 2:  if (this != $sys)
 3:    set_task_perms(programmer);
 4:    return $sys:(verb)(@args);
 5:  endif
 6:  {object, method} = args;
 7:  info = verb_info(object, method);
 8:  if (!programmer.programmer || !(index(info[2], "r") ||
`programmer:controls_method(object, method, info) ! ANY'))
 9:    raise(E_PERM);
10:  else
11:    return verb_args(@args);
12:  endif
13:  return info;

Then restarted it again and did a @list $building_utils:parse_names (which I
determined was the fourth verb via ;verbs()) and it crashed.
Restart again, still with the same original PANIC db, and
;verb_code($building_utils, 4) worked.

In order to attempt to fix this, I did a ;set_verb_args($building_utils, 4,
{"this", "none", "this"}), which succeeded, and then @d and verb_args()
worked again, ie didn't panic the server, when I ran them on $building_utils
and $builting_utils:parse_names, respectively.

I have not gone in to determine the differences between the panic db and a
good db at the raw text level.  It appears that the server is loading the db
okay (or at least not catching a possible error condition) on reading args
in, which is making memory bad when the args are assigned at load time.  I
have not tested this, it is my guess.

I've created objects recently on this db, which does end up calling
:parse_names, so executing it works.  I've proven to myself that the code is
okay, the names are okay, executing it is okay, but the args are not, and
apparently, the args to this verb are written out bad to the database during
checkpointing.

I still have the db that caused the problem.

Has something similar to this happened to anyone else, and/or could this be
related to the notes in the Changelog concerning suspended tasks and calls
to overloaded bfs?

Did I leave any important info out?

Andy.




Home | Subject Index | Thread Index