Explicitly constructed NPE is showing (wrong) message

[Lindenmaier, Goetz]

Hi,

Thanks for reporting this issue.
You analyzed it well, and the simple repro case was also 
helpful.

I filed https://bugs.openjdk.java.net/browse/JDK-8248476
and will send RFR for this in a minute.
It's probably best to continue discussion there. 

Best regards,
  Goetz.


> -----Original Message-----
> From: hotspot-runtime-dev <hotspot-runtime-dev-retn at openjdk.java.net>
> On Behalf Of Remi Forax
> Sent: Saturday, June 27, 2020 2:41 PM
> To: Christoph Dreis <christoph.dreis at freenet.de>
> Cc: hotspot-runtime-dev <hotspot-runtime-dev at openjdk.java.net>; core-
> libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Re: Explicitly constructed NPE is showing (wrong) message
> 
> ----- Mail original -----
> > De: "Christoph Dreis" <christoph.dreis at freenet.de>
> > À: "hotspot-runtime-dev" <hotspot-runtime-dev at openjdk.java.net>
> > Envoyé: Samedi 27 Juin 2020 11:54:19
> > Objet: Explicitly constructed NPE is showing (wrong) message
> 
> > Hi,
> 
> Hi Christoph,
> 
> >
> > I hope this is the correct mailing list.
> >
> > The latest changes on JDK-8233014 to enable
> ShowCodeDetailsInExceptionMessages
> > by default have uncovered a likely bug (I think).
> >
> > To my understanding explicitly created NullPointerExceptions should not
> print
> > any message.
> > With the following example:
> >
> > public class Main {
> >	public static void main(String[] args) {
> >		NullPointerException ex = new NullPointerException();
> >		Throwable throwable = ex.fillInStackTrace();
> >		System.out.println(throwable);
> >	}
> > }
> >
> > I see the following output though:
> >
> > java.lang.NullPointerException: Cannot invoke
> > "java.lang.NullPointerException.fillInStackTrace()" (on slot 0) because "ex"
> is
> > null
> >
> > Which obviously is not really true.
> > I was debugging the thing (hence the additional "on slot 0") output, but
> > couldn't find the error so far.
> >
> > I'm suspecting the error to be somewhere around bytecodeUtils.cpp 1155:
> >
> >        if (name != vmSymbols::object_initializer_name()) {
> >          int     type_index = cp-
> >signature_ref_index_at(name_and_type_index);
> >          Symbol* signature  = cp->symbol_at(type_index);
> >          // The 'this' parameter was null. Return the slot of it.
> >          return ArgumentSizeComputer(signature).size();
> >        } else {
> >          return NPE_EXPLICIT_CONSTRUCTED;
> >        }
> >
> > I initially hoped to find a fix for it directly, but I would probably need a bit
> > more time for it, so I decided to report it.
> > Is this a bug even or am I chasing ghosts here? In case it is, I would be
> happy
> > about a mentioning somewhere in an eventual commit.
> 
> I see the issue.
> The idea of the algorithm is to use the backtrace stored in the exception to
> try to find where the NPE occurs, here by calling fillStackTrace() emplicitly,
> you are changing the backtrace so getExtendedNPEMessage now use the new
> backtrace reporting the error in main() :(
> 
> One way to fix the issue is to record if fillInStackTrace is called more than
> once (by having two sentinels by example) and to not call
> getExtendedNPEMessage if it's the case. Obviously the new added sentinel
> has to work with the serialization.
> 
> >
> > Cheers,
> > Christoph
> 
> regards,
> Rémi