[DGD] DGD Crash

[Petter Nyström]

>> In the past two months, my DGD-based mud has crashed twice without any
>> clue in the log. I have realized that DGD is a very robust program, but
>> that it do lean on the mudlib for some things or it will go down hard. For
>> example, I have previously had DGD crashing when there has been functions
>> missing in the driver object. But I have previously always got a helpful
>> error message in the log, which has then helped me to successfully fix up
>> my mudlib to prevent the problem from reaching the driver. This time I
>> feel I am more stuck.
>
> This is most likely infinite recursion in the mudlib without a limit on
> ticks or stack depth.  But it might be a genuine bug in DGD.  When
> running into such errors, the best thing to do is to enable coredumps
> (I assume you're using linux or another unix derivate) and to examine
> the core left after any crash.
>
> This doesn't prevent crashes, but it will pinpoint the cause, either
> allowing you to fix a bug in your mudlib later, or letting file a
> bugreport which will allow me to fix a bug in DGD.

It is me with another crash again. This mail is probably of no interest to 
anyone but me and Dworkin, maybe I should be mailing it directly to him. I 
will however be grateful for help offered by anyone.

This time I have both a coredump and some more of the last ouput from the 
driver before it died. From the clues therein, I made a small effort of 
trying to crash the driver intentionally but without succes. So I still do 
not know what exactly causes the driver to die.

I have looked over the possibilities of infinite recursion in my lib, and 
cannot see where it could happen. The only places I use rlimits, I use 
finite limits on both ticks and stack depth. I impose rlimits on code 
running from receive_message() in the user object and on all code called 
by call_out(). This leaves code run from the driver object on demand from 
the driver itself, and though I have not checked this it does not feel 
likely as I don't have much code in the driver object.

This is the last output from the driver:

[...]
Runtime Error - Thu Aug  4 15:06:59 2005
-------------------------------------------------------------------------------
Bad argument 2 for kfun call_out
-------------------------------------------------------------------------------
@ LINE    FUNCTION               PROGRAM                        OBJECT
   298     call_out               /kernel/lib/auto               player#331
   1012    healing_tick           /std/lib/injuries              player#331
   269     receive_call_out       /kernel/lib/auto               player#331
-------------------------------------------------------------------------------
Segmentation fault (core dumped)

I do not know the exact time of the crash, and therefore I cannot link the 
last runtime error to it. Trying to crash the driver by calling call_out() 
with bad arguments did not alone crash the driver when I tried it.

Here is the call in my /std/lib/injuries causing the runtime error, if 
for some reason it holds any clues:

     handle = call_out("healing_tick", next[1], next[0]);

Because of the gdb results, I was thinking maybe the values being taken 
from arrays hade some meaning. But truly, I am clueless on this one.

Running gdb on the core gave these results:

[jimorie at cust bin]$ gdb dgd-1.2.111-ansi ../lib/core.29356
GNU gdb 6.2-2mdk (Mandrakelinux)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-mandrake-linux-gnu"...Using host 
libthread_db library "/lib/tls/libthread_db.so.1".


warning: core file may not match specified executable file.
Core was generated by `./dgd-1.2.111-ansi ../lib/kernel/dgd/boris.dgd'.
Program terminated with signal 11, Segmentation fault.

warning: current_sos: Can't read pathname for load map: Input/output error

Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x0804d293 in arr_del (a=0x401f4358) at array.c:195
195     array.c: No such file or directory.
         in array.c
(gdb) bt
#0  0x0804d293 in arr_del (a=0x401f4358) at array.c:195
#1  0x0805d902 in d_import (imp=0xbfffd1b0, data=0x40326278, 
val=0x402c29ac,
     n=1) at data.c:1843
#2  0x0805dac8 in d_import (imp=0xbfffd1b0, data=0x40326278, 
val=0x4026c848,
     n=4) at data.c:1888
#3  0x0805dac8 in d_import (imp=0xbfffd1b0, data=0x40326278, 
val=0x401eff3c,
     n=16) at data.c:1888
#4  0x0805db77 in d_export () at data.c:1917
#5  0x0806cfe4 in endthread () at dgd.c:68
#6  0x08060c2e in comm_receive (f=0x80c60c0, timeout=0, mtime=127)
     at comm.c:1145
#7  0x0806d280 in dgd_main (argc=2, argv=0xbffff314) at dgd.c:177
#8  0x080a9b2d in main (argc=2, argv=0xbffff314) at local.c:25
(gdb)

That is all the info I've got.

Thanks for all the help so far,

Jimorie