public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
* RE: NullPointerException / threads
@ 2000-03-14  6:20 Glenn Chambers
  2000-03-14  6:56 ` Andrew Haley
  2000-04-01  0:00 ` Glenn Chambers
  0 siblings, 2 replies; 14+ messages in thread
From: Glenn Chambers @ 2000-03-14  6:20 UTC (permalink / raw)
  To: 'Andrew Haley', java-discuss

> 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, and use it only
in that case.  The non-allocator case would create a new object normally.

This would fail if multiple threads SEGV in the memory 
allocator, but by that point you may be dead anyway...

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: NullPointerException / threads
  2000-03-14  6:20 NullPointerException / threads Glenn Chambers
@ 2000-03-14  6:56 ` Andrew Haley
  2000-03-14  9:17   ` Godmar Back
  2000-04-01  0:00   ` Andrew Haley
  2000-04-01  0:00 ` Glenn Chambers
  1 sibling, 2 replies; 14+ messages in thread
From: Andrew Haley @ 2000-03-14  6:56 UTC (permalink / raw)
  To: GChambers; +Cc: java-discuss

> 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.

Andrew.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: NullPointerException / threads
  2000-03-14  6:56 ` Andrew Haley
@ 2000-03-14  9:17   ` Godmar Back
  2000-03-14  9:19     ` Andrew Haley
  2000-04-01  0:00     ` Godmar Back
  2000-04-01  0:00   ` Andrew Haley
  1 sibling, 2 replies; 14+ messages in thread
From: Godmar Back @ 2000-03-14  9:17 UTC (permalink / raw)
  To: Andrew Haley; +Cc: GChambers, java-discuss

> 
> > 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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: NullPointerException / threads
  2000-03-14  9:17   ` Godmar Back
@ 2000-03-14  9:19     ` Andrew Haley
  2000-04-01  0:00       ` Andrew Haley
  2000-04-01  0:00     ` Godmar Back
  1 sibling, 1 reply; 14+ messages in thread
From: Andrew Haley @ 2000-03-14  9:19 UTC (permalink / raw)
  To: gback; +Cc: GChambers, java-discuss

> From: Godmar Back <gback@cs.utah.edu>
> Date: Tue, 14 Mar 2000 10:16:52 -0700 (MST)
> > > 
> > > 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?

Of course not.  I want a readable backtrace.

Andrew.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: NullPointerException / threads
  2000-03-14  9:19     ` Andrew Haley
@ 2000-04-01  0:00       ` Andrew Haley
  0 siblings, 0 replies; 14+ messages in thread
From: Andrew Haley @ 2000-04-01  0:00 UTC (permalink / raw)
  To: gback; +Cc: GChambers, java-discuss

> From: Godmar Back <gback@cs.utah.edu>
> Date: Tue, 14 Mar 2000 10:16:52 -0700 (MST)
> > > 
> > > 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?

Of course not.  I want a readable backtrace.

Andrew.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: NullPointerException / threads
  2000-03-14  6:56 ` Andrew Haley
  2000-03-14  9:17   ` Godmar Back
@ 2000-04-01  0:00   ` Andrew Haley
  1 sibling, 0 replies; 14+ messages in thread
From: Andrew Haley @ 2000-04-01  0:00 UTC (permalink / raw)
  To: GChambers; +Cc: java-discuss

> 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.

Andrew.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* RE: NullPointerException / threads
  2000-03-14  6:20 NullPointerException / threads Glenn Chambers
  2000-03-14  6:56 ` Andrew Haley
@ 2000-04-01  0:00 ` Glenn Chambers
  1 sibling, 0 replies; 14+ messages in thread
From: Glenn Chambers @ 2000-04-01  0:00 UTC (permalink / raw)
  To: 'Andrew Haley', java-discuss

> 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, and use it only
in that case.  The non-allocator case would create a new object normally.

This would fail if multiple threads SEGV in the memory 
allocator, but by that point you may be dead anyway...

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: NullPointerException / threads
  2000-03-14  9:17   ` Godmar Back
  2000-03-14  9:19     ` Andrew Haley
@ 2000-04-01  0:00     ` Godmar Back
  1 sibling, 0 replies; 14+ messages in thread
From: Godmar Back @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Andrew Haley; +Cc: GChambers, java-discuss

> 
> > 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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: NullPointerException / threads
  2000-03-14 10:21   ` Godmar Back
@ 2000-04-01  0:00     ` Godmar Back
  0 siblings, 0 replies; 14+ messages in thread
From: Godmar Back @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Andrew Haley, java-discuss

> 
> Some VMs create the stack trace lazily.  I don't know how they do
> this.  Could we do it somehow?
> 

My understanding is that the stacktrace is associated with the
exception object, not the throw site.  In other words, an exception
can be created in a callee, returned to and thrown by a caller, and the
stacktrace would have to include the callee's frame.

What we've implemented in kaffe is the following: the stacktrace is filled
in when the exception is created; but it's only an array of pc/fp pairs.
What is done lazily (only when the exception is dispatched or when someone 
tries to print the backtrace), however, is mapping the pc to the corresponding 
method to extract its name/line numbers for printing or exception handlers
for dispatch.

I don't know if that's what you mean by "lazily", but I'd be interested in
learning how you could do it even more lazily.

	- Godmar

^ permalink raw reply	[flat|nested] 14+ messages in thread

* NullPointerException / threads
  2000-03-14  6:14 Andrew Haley
  2000-03-14 10:00 ` Tom Tromey
@ 2000-04-01  0:00 ` Andrew Haley
  1 sibling, 0 replies; 14+ messages in thread
From: Andrew Haley @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

When gcj first starts, we create a single NullPointerException which
is thrown whenever a SEGV is caught by the runtime.  In order to give
the user some useful information about where the exception occurred,
we call the exception's fillInStackTrace method before throwing.
Clearly, this will cause problems if two threads throw the same
NullPointerException at the same time; one will corrupt the other's
backtrace.

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.

Opinions?

Andrew.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: NullPointerException / threads
  2000-03-14 10:00 ` Tom Tromey
  2000-03-14 10:21   ` Godmar Back
@ 2000-04-01  0:00   ` Tom Tromey
  1 sibling, 0 replies; 14+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Andrew Haley; +Cc: java-discuss

Andrew> When gcj first starts, we create a single NullPointerException
Andrew> which is thrown whenever a SEGV is caught by the runtime.

It seems like this will be a problem with arith exceptions and the
out-of-memory error too (the latter because it could be received by
two threads which would decide to call fillInStackTrace on it).

Andrew> I suppose we could create a NullPointerException and a
Andrew> pre-allocated stacktrace for each thread when it starts, but
Andrew> that seems rather nasty.

Are there other options?

It is nice to get the stack trace information, but maybe it isn't
always necessary.  This would be more true if the debugger had better
exception handling support.

Some VMs create the stack trace lazily.  I don't know how they do
this.  Could we do it somehow?

Tom

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: NullPointerException / threads
  2000-03-14 10:00 ` Tom Tromey
@ 2000-03-14 10:21   ` Godmar Back
  2000-04-01  0:00     ` Godmar Back
  2000-04-01  0:00   ` Tom Tromey
  1 sibling, 1 reply; 14+ messages in thread
From: Godmar Back @ 2000-03-14 10:21 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Andrew Haley, java-discuss

> 
> Some VMs create the stack trace lazily.  I don't know how they do
> this.  Could we do it somehow?
> 

My understanding is that the stacktrace is associated with the
exception object, not the throw site.  In other words, an exception
can be created in a callee, returned to and thrown by a caller, and the
stacktrace would have to include the callee's frame.

What we've implemented in kaffe is the following: the stacktrace is filled
in when the exception is created; but it's only an array of pc/fp pairs.
What is done lazily (only when the exception is dispatched or when someone 
tries to print the backtrace), however, is mapping the pc to the corresponding 
method to extract its name/line numbers for printing or exception handlers
for dispatch.

I don't know if that's what you mean by "lazily", but I'd be interested in
learning how you could do it even more lazily.

	- Godmar

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: NullPointerException / threads
  2000-03-14  6:14 Andrew Haley
@ 2000-03-14 10:00 ` Tom Tromey
  2000-03-14 10:21   ` Godmar Back
  2000-04-01  0:00   ` Tom Tromey
  2000-04-01  0:00 ` Andrew Haley
  1 sibling, 2 replies; 14+ messages in thread
From: Tom Tromey @ 2000-03-14 10:00 UTC (permalink / raw)
  To: Andrew Haley; +Cc: java-discuss

Andrew> When gcj first starts, we create a single NullPointerException
Andrew> which is thrown whenever a SEGV is caught by the runtime.

It seems like this will be a problem with arith exceptions and the
out-of-memory error too (the latter because it could be received by
two threads which would decide to call fillInStackTrace on it).

Andrew> I suppose we could create a NullPointerException and a
Andrew> pre-allocated stacktrace for each thread when it starts, but
Andrew> that seems rather nasty.

Are there other options?

It is nice to get the stack trace information, but maybe it isn't
always necessary.  This would be more true if the debugger had better
exception handling support.

Some VMs create the stack trace lazily.  I don't know how they do
this.  Could we do it somehow?

Tom

^ permalink raw reply	[flat|nested] 14+ messages in thread

* NullPointerException / threads
@ 2000-03-14  6:14 Andrew Haley
  2000-03-14 10:00 ` Tom Tromey
  2000-04-01  0:00 ` Andrew Haley
  0 siblings, 2 replies; 14+ messages in thread
From: Andrew Haley @ 2000-03-14  6:14 UTC (permalink / raw)
  To: java-discuss

When gcj first starts, we create a single NullPointerException which
is thrown whenever a SEGV is caught by the runtime.  In order to give
the user some useful information about where the exception occurred,
we call the exception's fillInStackTrace method before throwing.
Clearly, this will cause problems if two threads throw the same
NullPointerException at the same time; one will corrupt the other's
backtrace.

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.

Opinions?

Andrew.

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2000-04-01  0:00 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-03-14  6:20 NullPointerException / threads Glenn Chambers
2000-03-14  6:56 ` Andrew Haley
2000-03-14  9:17   ` Godmar Back
2000-03-14  9:19     ` Andrew Haley
2000-04-01  0:00       ` Andrew Haley
2000-04-01  0:00     ` Godmar Back
2000-04-01  0:00   ` Andrew Haley
2000-04-01  0:00 ` Glenn Chambers
  -- strict thread matches above, loose matches on Subject: below --
2000-03-14  6:14 Andrew Haley
2000-03-14 10:00 ` Tom Tromey
2000-03-14 10:21   ` Godmar Back
2000-04-01  0:00     ` Godmar Back
2000-04-01  0:00   ` Tom Tromey
2000-04-01  0:00 ` Andrew Haley

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).