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.
..Thomas
