RFR(M): 8221077: No NullPointerException message if top frame is hidden.
Lindenmaier, Goetz
goetz.lindenmaier at sap.com
Tue May 7 07:38:48 UTC 2019
Hi,
the implementation is charmingly simple:
http://cr.openjdk.java.net/~goetz/wr19/8221077-hidden_top_frame/03-dontHide/
But as you, Remi, point out, I had feared some further
implications of not hiding the frames.
So I will not pursue this implementation further.
... just curious ... what is happening if I use the StackWalker
in a method whose frames are hidden? Will it have a top
frame that is != the method in which I called it?
Best regards,
Goetz.
> -----Original Message-----
> From: Remi Forax <forax at univ-mlv.fr>
> Sent: Montag, 6. Mai 2019 16:39
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: David Holmes <david.holmes at oracle.com>; hotspot-runtime-dev <hotspot-
> runtime-dev at openjdk.java.net>; Coleen Phillimore
> (coleen.phillimore at oracle.com) <coleen.phillimore at oracle.com>
> Subject: Re: RFR(M): 8221077: No NullPointerException message if top frame is
> hidden.
>
> Hi Goetz,
> please don't !
>
> You have existing codes that behave differently depending on the caller class,
> part of the security model is based on that, but also other APIs like by example,
> many of the existing logging libraries.
>
> When a stack frame is hidden, it means that the stack frame is not visible for
> getCallerClass, the StackWalker API and the Throwable stacktrace,
> the VM/JDK offers one coherent view of the stack frames.
>
> If you suppress the hiding for one of these entry points, at best, applications
> will fail, at worst you have introduced a security issue.
>
> regards,
> Rémi
>
> ----- Mail original -----
> > De: "Goetz Lindenmaier" <goetz.lindenmaier at sap.com>
> > À: "David Holmes" <david.holmes at oracle.com>, "hotspot-runtime-dev"
> <hotspot-runtime-dev at openjdk.java.net>, "Coleen
> > Phillimore (coleen.phillimore at oracle.com)" <coleen.phillimore at oracle.com>
> > Envoyé: Lundi 6 Mai 2019 14:36:36
> > Objet: RE: RFR(M): 8221077: No NullPointerException message if top frame is
> hidden.
>
> > Hi David,
> >
> > I'm not really happy with the design of hiding the frames,
> > either.
> > For 'inner' frames this seems ok, but for the top frames
> > up to the first not-hidden frame it is questionable to
> > hide them. As you say, there might be exceptions where
> > this is desirable, for NPE it seems wrong.
> >
> > I’ll have a look how it could be implemented to
> > suppress the hiding in case of NPE.
> >
> > Best regards,
> > Goetz.
> >
> >
> >> -----Original Message-----
> >> From: David Holmes <david.holmes at oracle.com>
> >> Sent: Montag, 6. Mai 2019 13:50
> >> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
> >> dev at openjdk.java.net; Coleen Phillimore (coleen.phillimore at oracle.com)
> >> <coleen.phillimore at oracle.com>
> >> Subject: Re: RFR(M): 8221077: No NullPointerException message if top
> frame is
> >> hidden.
> >>
> >> Hi Goetz,
> >>
> >> Just commenting on the situation ...
> >>
> >> On 6/05/2019 8:22 pm, Lindenmaier, Goetz wrote:
> >> > Hi,
> >> >
> >> > Exceptions can print the stack trace of when the exception occurred.
> >> > There can be methods on the stack that have been generated by
> >> > the runtime. To not confuse the reader of the stackTrace,
> >> > these are omitted (if -XX:-ShowHiddenFrames, which is default.)
> >> >
> >> > If the top frame is omitted/hidden,
> >> > it is inconsistent to print a message telling where
> >> > exactly in the hidden method the error occurred.
> >> >
> >> > Further, if the top frame is hidden, the information
> >> > needed to compute the message is missing. A wrong
> >> > message will be printed.
> >> >
> >> > This change suppresses the NPE message if the NPE
> >> > occurred in a hidden top frame.
> >>
> >> This sounds to me like "hidden frames" are being applied too broadly.
> >> Frames should only be hidden with respect to throwing specific
> >> exceptions - those for which the frame is part of the "throwing
> >> mechanics". If that code hits a real exception then the frame should not
> >> be treated as hidden IMO. But I don't know whether we can clearly
> >> identify which kinds of exceptions should really lead to a frame being
> >> hidden.
> >>
> >> David
> >> -----
> >>
> >> > It adds a java.lang.Boolean(true) to the backtrace
> >> > in case the real top frame is a hidden one and is dropped.
> >> >
> >> > When the NullPointerException message text is generated, this is
> >> > checked and the message is skipped if the proper frame is not
> >> > available.
> >> >
> >> > I handle this in a bug itself to keep the discussion of
> >> > the basic feature separated from this technical issue.
> >> >
> >> > Please review:
> >> > https://bugs.openjdk.java.net/browse/JDK-8221077
> >> > http://cr.openjdk.java.net/~goetz/wr19/8221077-hidden_top_frame/02/
> >> > This change must be applied on top of
> >> > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/08/
> >> >
> >> > Best regards,
> >> > Goetz.
More information about the hotspot-runtime-dev
mailing list