JNI - question about jmethodid values.

Thomas Stüfe thomas.stuefe at gmail.com
Wed Nov 28 15:08:49 UTC 2018


On Wed, Nov 28, 2018 at 4:03 PM <coleen.phillimore at 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.stuefe at 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.

..Thomas


More information about the serviceability-dev mailing list