On Wed, 4 Oct 1995, Daniel Koepke wrote:
>
>
> On Wed, 4 Oct 1995, Entreri wrote:
>
> > Hello,
> > Is there any easy way to check for the cause of a segmentation
> > fault? I am getting an annoying seg fault seemingly randomly. What can
> > I do to find out the cause?
> >
> > entreri@netcom.com
> > Realms of Syldain <netcom19.netcom.com 4000>
> >
>
> Segmentation faults, which are done by the UNIX, should core dump unless
> the UNIX is told not to core dump (I suspect this is done via the 'limit'
> command in bash, which I know allows you to change the max size of
> cores), these can be checked with gdb ('info' should have information on
> gdb).
>
> However, this is all rather unuseful for you, since netcom doesn't make
> core dumps, and, although I'm uncertain, I doubt you're permitted to play
> with 'limit'. In any case, find a real site and then you'll have a much
> easier time, until then, you'll need to crash the MUD purposely to find
> out what code is causing the crash and then painstakingly comb over it to
> find the bugs - often times it's a simple mistake, and many other times
> it's like trying to find a needle in a haystack.
>
> Daniel Koepke (dkoepke@california.com)
Whenever Unix C tries to execute a program it cannot handle, it dumps
whatever data it failed to handle from memory into a file, commonly
called core dump; and, usually, as a consequence of segmentation fault,
bus error, memory fault, and pipeline error ( just naming some that has
happened to me ). You can decipher whatever went wrong with the help of a
debugger such as gdb.
Although I am currently working with envy, my suggestion is general and
applies to you. Just type gdb circle (circle being your execuable file),
fol by core 1011.core, where 1011.core is an example of a core dump you
might get on netcom. It should then tell you at what line in your program
UNIX gave up.
Note that the core dump is the *effect* of the problems in your coding,
not the source. So frequently, you will spend additional time tracking
down the real problem, usually not the one reported in the core dump.
There is a hacker.txt from merc documents ( I believe it is included in
circle as well) that might help you somewhat.
As far as the allegation of no core-dumps on netcom, it is completely
false. I should know --- I am coding spells on my account and have my
share of core-dumps. You might want to check your shell script (.cshrc)
to make sure you have no limit coredumpsize 0. There is some motivation
for adding limit coredumpsize, namely the disk space quota --- more disk
space usage, higher account charge. So, I suggest you run the mud from
usr/hack/tmp directory.
Running your mud on nectom is fine for developmental purposes or if you
have a small player-base. Netcome is noticeably sluggish at peak time and
you will hear complains from your players about the lag once your mud
expands. And then, it is time for a better site.
Jason Huang
This archive was generated by hypermail 2b30 : 12/07/00 PST