[MUD-Dev] Re: Technical C/C++ coding question

[Jon Leonard]

On Tue, Jun 16, 1998 at 06:20:53PM -0500, Katrina McClelan wrote:
> On Tue, 16 Jun 1998, Jon Leonard wrote:
> > On Sun, Jun 14, 1998 at 07:57:38AM -0700, J C Lawrence wrote:
> > > Katrina McClelan<kitkat at the486.bradley.edu> wrote:
> > > 
> > > > 	if(!fork()) { /* child copy starts here */
> > > >         kill(getpid(),SIGSEGV); /* this'll dump core */ 
> > > >         sleep(10); /* make sure it stops here */ 
> > > >         /* dead by here */ 
> > > >       }
> > > > 	/* parent continues unaware */
> > > 
> > If I read the code right, the sleep is in the child, to keep the child
> > from executing additional parent code.  I'd include an exit() after the
> > sleep, so that if the kill doesn't work (SIGSEGV blocked?), the child
> > doesn't do any damage.
> 
> This is probably good.... the code I submitted was not meant (in my mind) 
> to be fail safe.  The exit makes sure the child does no damage and is thus
> good.  It's not really elegant, but then how elegant can you be when
> you're trying to dump core ;)?  I assume this is only a tool and not going
> to be a part of the finished server?  Even if it is, Ben can figure out
> how to make it "perfect" from there.  SIGSEGV can be blocked, but
> shouldn't be.  Actually I think the sleep is unneeded since the child
> kills itself which is executed linear, so kill won't return until the
> signal is sent and received thus killing the process in kill().  The exit
> should be used incase kill fails. 

A lot depends on how paranoid the coding is.  It's certainly not necessary
to put all of the debug checking into example code -- it makes it harder
to read, for one thing.  Still, I like to list the things that one might
want to check for or otherwise worry about.

Some programs may trap SIGSEGV for memory management purposes.  Assuming
exacting knowlege of the memory map, you can just assume you have enough
memory, and if you don't, brk() some more.  Icky (breaks malloc, etc.),
but I think "sh" does this...  Basically, if you use a signal to dump core,
make sure it's not also used for something else in the program.

I'm also not completely sure about the signal from kill getting to the
process immediately.  The word "asynchronous" in the man page gives a
lot of freedom to the OS.

> > That said, I'd use abort() instead of kill, and not bother with the sleep.
> > I'd keep the exit() because I'm paranoid, and some older OSes may return
> > from abort.  If the appropriate signal is precise, the sleep is useless
> > anyway.
> 
> This is a better way to go, since abort can't return accd to the man page.

Depends on your man page.  My SunOS system claims it can return if SIGIOT is
caught or ignored.  Portability to SunOS may be a bigger issue to me than
anyone else here, of course.

> > Failure to fork would be good to test for.  If you're willing to accept
> > a failure mode of no core file, the above code is find.  
> 
> I was assuming Ben was looking for just a quick and easy way and that he'd
> add his own error checking.

Quite possibly.  But If I'd included a debugging feature like this in my MUD,
I'd leave it in production code.  Doesn't hurt much, and you never know
when you'll need it, and something might break if you take it out (due to
typos, etc).

The other feature I might add would be the ability to specify a (possibly new)
directory for it to go into.  This would allow multiple core dumps without
worrying about overwriting.

Jon Leonard