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 <[email protected]> > On Behalf Of Remi Forax > Sent: Saturday, June 27, 2020 2:41 PM > To: Christoph Dreis <[email protected]> > Cc: hotspot-runtime-dev <[email protected]>; core- > libs-dev <[email protected]> > Subject: Re: Explicitly constructed NPE is showing (wrong) message > > ----- Mail original ----- > > De: "Christoph Dreis" <[email protected]> > > À: "hotspot-runtime-dev" <[email protected]> > > 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
