[MUD-Dev] Re: Technical C/C++ coding question
Shawn Halpenny
malachai at iname.com
Wed Jun 17 11:37:31 CEST 1998
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 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.
<<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.
More information about the mud-dev-archive
mailing list