Re: Segmentation fault

From: Christopher Busch (
Date: 09/18/95

On Mon, 18 Sep 1995, Rasmus Rxnlev wrote:

> Well, considering my last days of futration I decided to write a little 
> message here.
> I've been changing some assorted stuff in the Circle3.00, patchlevel8 code.
> It's run at a remote computer, but due to limited disk space I decided to 
> work at the source at home, testing it and so forth... 
> My own setup is Linux based, and as far as programming and compiling the 
> prgram seems error free.
> The problem arises when I transfer the sourcecocode to the remote mashine 
> (SunOS), the source still compiles without errors, and seemingly runs fine...
> BUT, MOSTLY when fighting, sometimes even when the mud is more or less 
> idle it CRASHES ... the program returns "Segmentation Fault"..
> NOW, considering this I thought... Well.. Has to be my code.. BUT, 

Unfortunately, this happened to me once, BUT in reverse!!  And I did 
track it down to a bug.  (It wasnt a mud but something else.)

Since running a mud in a debugger doesnt work too well if at all, I 
suggest trapping the SIGSEGV signal and printing a dump of internal 
variables.   In an unrelated project I found it useful to store trace 
code.  This is how I did it, basically.

/* number each file by a thousand*/
#define TRACENUM 1000

void foofunc()
    tracer(TRACENUM + __LINE__);
   /* rest of the function*/


 #define  tracer(x)
 #define  printtrace()
 void tracer(int);
 void printtrace();

/*The call to tracer(int) will store the function number in an array.*/

enum {tracemax=4};
int tracenums[tracemax];

void tracer(int number)
   /*i avoided for() loop since it would be slower*/

Well you can fill in the rest....

Now if you get the output:
		12023 23345 1002 3302
That means the last functions encountered was in file 12 line 23, file 23
line 345, file 1 line 2, file 3 line 302.

But heck come to think of it,  You could have trace take two params, and
then the trace function could be:
		trace( __FILE__,__LINE__);
Also i think gcc/g++ may define __FUNCTION__.

Then trap the SIGSEGV:

You guys get the idea.

Now you have your own built in debugger!

> whatever I do It's IMPOSSIBLE to reproduce the event at my Linux setup... 
> What I wndered is, if anyone knows why the mud gets a segmentation 
> fault.. and if it's possibly the remote systems recources that arent 
> adequate... ?
> Anyways, any comments are appreciated... actually flames too 8)
> Regards,
> Rasmus R, aka. Con.

Christopher G Busch                                                    Wanted: Nifty Quote

This archive was generated by hypermail 2b30 : 12/07/00 PST