[Home] [Groups] - Message: [Prev in Group] [Next in Group]

nu.kanga.list.mud-dev

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

[Full Header] [Plain Text]
From: Shawn Halpenny <malachai@iname.com>
Newsgroups: nu.kanga.list.mud-dev
Date: Wed, 17 Jun 1998 11:37:31 -0400
References: [1] [2] [3] <-newest
Organization: Kanga.Nu
On Tue, Jun 16, 1998 at 06:30:38PM -0700, Jon Leonard wrote:
> 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@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. 

<<this is the second of Kat's MUD-dev responses to
this thread which I haven't received, so the threading of this message
will be somewhat borked--local mail delivery problems I think>>

<<JCL:  When I searched the archives (on 6/17/98, 11am EDT) for the missing
messages, the dates given in the result list were all June, 1998--the dates
the messages were indexed, I assume).  Would it be possible to have the
date the message was posted appear in the result list instead?

[ Responding to Kat's post ]

It is best not to rely on when the SIGSEGV will actually be handled in the
child (unless perhaps on a single OS with which you are familiar with the
kernel).  You are right that the sleep() is not necessary, but there needs
to be something in place there (I agree it should be pause() ) so that the
next signal to the child will continue processing.  After the pause(), do
your exit().  Mind you, like Jon Leonard said, abort() was made for things
like this and dispenses with the explicit use of kill() entirely.

Note that depending on your OS it may be possible to externally generate a core
image of a running process (and leave it running) using the gcore utility.

--
Shawn Halpenny

I know that you believe you understand what you think I said, but,
I am not sure you realize that what you heard is not what I meant.