The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent.
---------------------------------------------------------------------- Hi, I‘ll have a look on Monday. Thanks for reporting any analyzing it so far! Best regards, Götz > Am 27.06.2020 um 14:44 schrieb Remi Forax <[email protected]>: > > ----- 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
