On Wed, Nov 28, 2018 at 4:19 PM <coleen.phillim...@oracle.com> wrote:
>
>
>
> On 11/28/18 10:08 AM, Thomas Stüfe wrote:
> > On Wed, Nov 28, 2018 at 4:03 PM <coleen.phillim...@oracle.com> wrote:
> >>
> >>
> >> On 11/28/18 10:00 AM, Thomas Stüfe wrote:
> >>> On Wed, Nov 28, 2018 at 3:59 PM Thomas Stüfe <thomas.stu...@gmail.com>
> >>> wrote:
> >>>> Hi Coleen,
> >>>>
> >>>> (moved to svc-dev since David did shoo us off discuss before :-)
> >>>>
> >>>> Just to be sure I understand:
> >>>>
> >>>>> If the class is unloaded, the jmethodID is cleared. Native code should
> >>>>> first test whether it's NULL. I think that is the predictable behavior
> >>>>> that the spec requires.
> >>>> Wait, really? So, As a JNI caller I should do this:
> >>>>
> >>>> jmethodID method;
> >>>> ..
> >>>> if (*method == NULL) { .. invalid method id .. } ?
> >>>>
> >>>> I thought jmethodid is opaque, and its value itself cannot be changed
> >>>> from the VM, no?
> >>>>
> >>> Oh you probably meant "native code in the VM", not "native JNI code".
> >>> Sorry for the confusion.
> >> I did mean native JNI code, but I actually don't know how native JNI
> >> code is supposed to deal with nulled out jmethodIDs.
> >>
> >> Maybe they predictably crash?
> >>
> >> Coleen
> > I always thought it would gracefully reject, e.g. on JVMTI with
> > JVMTI_ERROR_INVALID_METHODID.
> >
> > Save that JC wrote that there are some JNI function sequences where
> > the VM would still crashes:
> >
> > <quote jc>
> > - Get a jmethodID and remember it
> > - Wait until the class gets unloaded
> > - Get the class to get reloaded and try call the old jmethodID
> > (which now points to NULL), the code will segfault
> > </quote>
> >
> > which looks like just a bug to me.
>
> It may be misuse of JNI also. We don't guarantee a lot of things with
> JNI. Maybe instead of clearing, we could install a Method* that throws
> NSME.
>
> But I guess why leak the jmethodID memory if it's going to crash anyway
> when using it?
>
Precisely :) We pay for it, we may just as well use it.
..Thomas
> Coleen
>
> >
> > ..Thomas
>
