SegmentationFault

What's a segmentation fault and how to deal with it

A segmentation violation happens when you try to access part of someone else's orange. Assuming of course that the RAM in your computer is made of oranges...

Your code is trying to access data at a memory location that doesn't belong to it. Common causes include:

1. Dereferencing a NULL pointer:

    OBJ_DATA* pObj = NULL;

    printf( "object name: %s\n", pObj->name );

2. Accessing freed memory:

    char* something = strdup("something");

    free(something);

    printf( "something: %s\n", something );

3. Dereferencing an uninitialised or bad pointer:

   OBJ_DATA* pObj;

   printf( "object name: %s\n", pObj->name );

Variation on 3. Stack trampling:

    char buf[5];

    OBJ_DATA* pObj = pointer_to_a_real_object;

    strcpy( buf, "something" );

    printf( "object name: %s\n", pObj->name );

There are plenty of other ways to access memory that doesn't belong to you too.

When your Mud crashed it probably left a "core" file behind in your area/ directory. A core file is a dump of the mud's memory area at the exact moment the game crashed, and GDB allows you to examine it. First thing you ought to do is make sure that the mud has been compiled with GDB-friendly debugging symbols built-in. This is done by adding an option to the CFLAGS section of your makefile: CFLAGS = -ggdb <other flags here> Then cause the mud to crash again, so that you have a crash core file generated from your new exe.

From the area/ directory, you then run GDB as follows:

    gdb <exe path> ./core

This will launch the interactive GDB program, and will already be telling you exactly what line the program crashed at, preceeded by a "#0".

Sometimes that info is not very useful, e.g. if you're in some rather generic function like alloc_mem() or if you can't see why one of the input parameters is already NULL, so to see the calling function, and the stack of calling functions above that, you issue the "bt" command. This shows you what functions were called to get to this point. You can move up and down the call stack with the "frame" command, and then analyse variables with the "print" command. "quit" will exit you back to the shell prompt. I suggest you read and digest the help information available on these commands, and then experiment with them until you see how they function.

GDB is quite feature-rich and can do lots else besides, but with this small set of commands in your toolkit you'll have all you need in order to analyse a crashed mud to see what caused the segmentation violation.

Genghis