Phantasmal Site > DGD > Running a MUD > DGD Crashes

When Might DGD Legitimately Crash?

There are actually several times that DGD might crash, hang, or otherwise get into an unusable state.

The simplest times are when you tell it to - if you set the tick limit to -1 and then get into an infinite loop, for instance, that'll do it. Similarly, if you block input and then never turn it back on, your MUD will be pretty thoroughly unusable.

DGD is a lot more prone to crash if you have serious problems when you're starting up - if your code doesn't compile originally, for instance, or if you have an uncaught fatal error when initializing your very first object. 'Crash' is perhaps too strong a word, but it will cease running. You can also get a crash in certain circumstances if you do something funny enough with your error handling. If your handler for runtime_error gets a runtime error immediately, for instance, you're pretty screwed and DGD will tend to give up and die.

DGD can also crash if a guest programmer allocates all free memory. There isn't really a good way around this. If you're allowing guest programmers full LPC access, they can allocate all your RAM and bring your MUD to its knees. Some libs, like LPMOO, get around this by allowing guest programming in a language *other* than LPC so there are some restrictions on this.

From: dgd at list.imaginary.com (Felix A. Croes)
Date: Thu Mar 21 10:57:01 2002
Subject: [DGD] Printing out nil?

Jay Shaffstall wrote:

> >Crashes?  I find that hard to believe, do you perhaps mean that you
> >get a runtime error along the lines of  "Bad argument 2 for kfun +"?
>
> No, it's a crash.  Full stop, access violation in Windows, the whole 
> shebang.  From what you say,  I suspect I might have corrupted my 
> compiler/runtime error handling in some fashion (they were both working 
> about a week ago, but now I get crashes instead).

When you find out what makes the difference between crashing and not
crashing, please let me know.  DGD should never crash.

Regards,
Dworkin

From: dgd at list.imaginary.com (Jay Shaffstall)
Date: Thu Mar 21 12:06:01 2002
Subject: [DGD] Printing out nil?

>When you find out what makes the difference between crashing and not
>crashing, please let me know.  DGD should never crash.

Okay, here it is.  It was a silly error on my part, in my logging daemon:

         #include <config.h>
         #include <std.h>

         private int next;

         void log (string message)
         {
                 /* For now, use a generic log file...later use specific ones
                    for specific types of messages */

                 if (! next)
                 {
                         log ("Start of run-------------------\n");
                         next = 1;
                 }

                 write_file (LOG_DIR + "/log.txt", "\n" + message + "\n");
         }

The first time in, a recursive call to itself it made.  However, the flag 
to stop the recursion isn't set first, so I was getting an infinite 
recursion, which ended in a DGD crash.  Since I was logging compile and 
runtime errors to a file, any compile or runtime error would seemingly 
cause the crash.

Not sure what you can do in DGD about this type of thing, since it's 
impossible to tell the difference between infinite recursion and a 
recursion that simply isn't finished yet (at least until you run out of 
stack space).

Hope this helps,
Jay

From: dgd at list.imaginary.com (Felix A. Croes)
Date: Thu Mar 21 12:14:01 2002
Subject: [DGD] Printing out nil?

Jay Shaffstall wrote:

> >When you find out what makes the difference between crashing and not
> >crashing, please let me know.  DGD should never crash.
>
>[...]
> Not sure what you can do in DGD about this type of thing, since it's 
> impossible to tell the difference between infinite recursion and a 
> recursion that simply isn't finished yet (at least until you run out of 
> stack space).

This is indeed the one case where a crash may "naturally" occur.

Regards,
Dworkin

From: dgd at list.imaginary.com (Felix A. Croes)
Date: Fri Oct 24 08:07:01 2003
Subject: [DGD] dgd crashes on fatal errors

Soja wrote:

> I have discovered that dgd crashes (dumps core) after reporting a fatal 
> error. For example if you remove the binary_connect() function from a driver
> object, dgd crashes with following messages: 
>
>   Oct 23 19:31:34 ** DGD 1.2.66
>   Oct 23 19:31:34 ** Initializing...
>   Oct 23 19:31:36 ** Initialization complete. 
>
>   Fatal error: missing function in driver object: binary_connect
>   Aborted (core dumped) 

A momentous discovery.  This is how things are supposed to be :)

Fatal errors are for when something is <really> wrong, and a coredump
helps debugging such a case.  So why for missing functions in the
driver object?  Because this may mean that the function table of the
driver object was trashed (this has happened with some bugs in the
past), rather than the programmer forgetting to include a function.
And in the latter case, hopefully the programmer is pointed out the
error of his ways with additional emphasis.

Regards,
Dworkin

From: dgd at list.imaginary.com (Par Winzell)
Date: Fri Oct 24 09:06:01 2003
Subject: [DGD] dgd crashes on fatal errors

> IMHO this is a bug. Even if the driver should go down on a fatal error, it
> should not go down in flames :) 

I'm pointlessly writing to agree with what Felix has already said. The
driver object is LPC at the lowest level, and DGD is correct to expect
consistency from it. Dumping core is not 'going down in flames', it's
just not high-level cuddly.

Zell

From: dgd at list.imaginary.com (Michael McKiel)
Date: Fri Mar 19 14:50:01 2004
Subject: [DGD] DGD crashing under Cygwin

For anyone that might run into almost instantaneous odd crashing behaviour of
the driver under Cygwin, when it previously had been fine - and want to blame
it on Windows ;) Check for circular function calls.

I wanted to test that receive_message was working for mobs in thing.c before
I had mobs, so I changed the user's receive_message() which had been working
fine with its ::receive_message(str); bit, to action(str); which is a
function in the inheritable thing.c that just calls into receive_message() in
thing.c

But since its inherited into the user object, it was just calling the user's
receive_message() which called action() which called...hehe

The only way to test, wound up temporarily making receive_message private, or
change its name to receive_message2 to get rid of the circular call-crash.

Anyways, unfortunately not everything is Windows fault.

Zam.

From dgd@dworkin.nl  Sat Jul 16 14:46:01 2005
From: dgd@dworkin.nl (Felix A. Croes)
Date: Sat Jul 16 13:46:01 2005
Subject: [DGD] DGD Segmentation Fault

"Neil McBride" wrote:

> Whilst playing around with the kernel lib and trying to build my own
> object manager, I inadvertantly put a call_other within its forbid_call
> function.  Upon startup, after having my initd call set_object_manager in
> the driver, I then have it call setup() in the object manager - which then
> triggers the crash ;)
>
> Obviously my code is doomed to fail whilst going in circles, but I would
> have thought the driver might have caught the error and given some sort of
> message.  Is the seg fault intended or have I stumbled across a bug
> through my *cough* fault tolerance testing *cough* ??

The key to this mystery is not how it occurred, but where.

While the kernel library tries to protect you, there are a few places
where code can still run without a limit on stack or ticks usage, and
the object manager is one of them.  Your code crashed the server
because it ran out of stack space.

DGD takes the view that any hard limit on stack or ticks usage is
arbitrary, and instead provides the programmer with the necessary
tools to impose his own limits.

Regards,
Dworkin

From dgd@dworkin.nl  Mon Aug  1 00:53:01 2005
From: dgd@dworkin.nl (Felix A. Croes)
Date: Sun Jul 31 23:53:01 2005
Subject: [DGD] Requirements of a healthy mudlib

=?ISO-8859-1?Q?Petter_Nystr=F6m?= wrote:

> 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.
>
> I am running DGD version 1.2.111 hacked to allow ansi, using the
> following command line: ./dgd-1.2.111-ansi mud.dgd 2> log.txt &

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.

Enabling core dumps in linux:

    ulimit -c unlimited

before starting DGD, or within the script that (re)starts DGD.  Once
you have a core dump,

    gdb dgd-1.2.111-ansi path-to-core

and

    bt

to see the stack backtrace.

Regards,
Dworkin