[15] RFR: 8248476: No helpful NullPointerException message after calling fillInStackTrace

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Tue Jun 30 08:57:21 UTC 2020

Hi David, 

The message is synthesized when getMessage() is called.
Thus, after calling fillInStackTrace().

The algorithm gets the bci where it starts to analyze the 
code in javaClasses.cpp java_lang_Throwable::get_top_method_and_bci() 
FillInStackTrace changes the information used there, the original bci
is lost.
So in 
 Exception ex = new NullPointerException();
 printStackTrace()   // correctly prints empty message 
 printStackTrace()   // wronly tried to synthesize a message: Cannot call fillInStackTrace because ex is null

the second printStackTrace did include the wrong method.
This is fixed.
As consequence, the following does not print the message:

ex = null
ex.hashCode()  // getMessage on the exception thrown here prints: Cannot call hashCode because ex is null.
ex.fillInStackTrace // getMessage() on the exception thrown here returns empty message.

Does this answer your question?

I'll copy the example from Christoph's mail into the 

Best regards,

(I sent this yesterday, but after Remis mail figured I skipped the list.)

> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Sent: Monday, June 29, 2020 3:19 PM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
> dev at openjdk.java.net
> Subject: Re: [15] RFR: 8248476: No helpful NullPointerException message
> after calling fillInStackTrace
> Hi Goetz,
> On 29/06/2020 9:17 pm, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > If changing the stack trace by calling fillInStackTrace in user code, the
> > NPE algorithm lacks the proper information to compute the message.
> > Thus, we must omit it after that call.
> For those of us who didn't follow this work in detail could you outline
> exactly when in the lifecycle of a NPE the detailed error message is
> created. I'm having trouble understanding the exact nature of the
> problem, and thus the fix.
> Thanks,
> David
> -----
> > I implement this by checking for a call to fillInStackTrace at the bci
> > recorded in the exception.
> > http://cr.openjdk.java.net/~goetz/wr20/8248476-NPE_fillInStackTrace-
> jdk15/01/
> >
> > Is there any other way of changing the stack trace?  setStackTrace() is
> > no problem as it does not change the internal backtrace datastructure.
> >
> > I'll push the change to jdk/submit and run it through our CI before pushing.
> >
> > Best regards,
> >    Goetz.
> >
> >

More information about the hotspot-runtime-dev mailing list