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*/
}
-----------------tracer.h
#ifdef NOTRACER
#define tracer(x)
#define printtrace()
#else
void tracer(int);
void printtrace();
#endif
----------------tracer.c
/*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*/
tracenums[0]=tracenums[1];
tracenums[1]=tracenums[2];
tracenums[2]=tracenums[3];
tracenums[3]=number;
}
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:
signal(SIGSEGV,printtrace);
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
cbusch@d.umn.edu Wanted: Nifty Quote
http://www.d.umn.edu/~cbusch/
This archive was generated by hypermail 2b30 : 12/07/00 PST