This is the mail archive of the
java-discuss@sourceware.cygnus.com
mailing list for the Java project.
Re: NullPointerException / threads
- To: aph at pasanda dot cygnus dot co dot uk (Andrew Haley)
- Subject: Re: NullPointerException / threads
- From: Godmar Back <gback at cs dot utah dot edu>
- Date: Tue, 14 Mar 2000 10:16:52 -0700 (MST)
- Cc: GChambers at provsol dot com, java-discuss at sourceware dot cygnus dot com
>
> > From: Glenn Chambers <GChambers@provsol.com>
> > Date: Tue, 14 Mar 2000 09:18:46 -0500
> >
> > > In order to solve this problem, we could create a new
> > > NullPointerException in the context of the signal handler, but that
> > > may crash if the SEGV occurs in the memory allocator itself. Also,
> > > fillInStackTrace calls JvNewByteArray to hold the stack trace, and if
> > > this fails we'll crash anyway, so maybe a SEGV handler shouldn't even
> > > be calling fillInStackTrace.
> > >
> > > I suppose we could create a NullPointerException and a pre-allocated
> > > stacktrace for each thread when it starts, but that seems rather
> > > nasty.
> >
> > Can you tell at SEGV-time if you're currently in the allocator? If so,
> > you could preallocate an 'emergency' exception+array
>
> Right, but it may not help; If the SEGV was *caused* by heap
> corruption we'd still crash even if the point at which the SEGV occurs
> is in user code.
Isn't crashing what you want in this case?
Or are you aiming for a system so robust that it can continue
with a corrupted heap?
- Godmar