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

[Lindenmaier, Goetz]

Thanks Remi, that's a very precise explanation.

Best regards,
  Goetz.

> -----Original Message-----
> From: Remi Forax <forax at univ-mlv.fr>
> Sent: Tuesday, June 30, 2020 10:13 AM
> To: David Holmes <david.holmes at oracle.com>
> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-dev
> <hotspot-runtime-dev at openjdk.java.net>
> Subject: Re: [15] RFR: 8248476: No helpful NullPointerException message
> after calling fillInStackTrace
> 
> ----- Mail original -----
> > De: "David Holmes" <david.holmes at oracle.com>
> > À: "Goetz Lindenmaier" <goetz.lindenmaier at sap.com>, "hotspot-runtime-
> dev" <hotspot-runtime-dev at openjdk.java.net>
> > Envoyé: Lundi 29 Juin 2020 15:19:29
> > Objet: 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.
> 
> I"m not Goetz but let me try,
> you want to provide helpful error message for NPE but without any runtime
> cost for the other exceptions or if the NPE is not printed (or if it is the special
> shared unmutable NPE used by Hotspot).
> the idea is to inspect the backtrace of the NPE only when getMessage is called
> on a NPE and the detailMessage is null [1].
> getExtendedNPEMessage() is a native method that will extract the first stack
> frame and use the bci to find where the error occurs and try using an
> abstract interpretation of the bytecode to provide information about the
> context.
> 
> The current bug is that fillInStackTrace can be called on an existing NPE
> instance thus changing the backtrace to a place that will confuse the
> algorithm that calculate the context so the helpful message provided in that
> case is useless. The proposed way to fix that is to detect if fillInStackTrace() is
> the first stack frame of the backtrace and in that can to not compute the
> helpful message. This fix works well but for one case if null.fillInStackTrace()
> is called.
> 
> >
> > Thanks,
> > David
> > -----
> 
> 
> [1]
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/ja
> va/lang/NullPointerException.java#L92
> 
> >
> >> 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.
> >>