[Info-vax] JNI problem on I64

[Simon Clubley]

On 2022-01-25, Arne Vajhøj <arne at vajhoej.dk> wrote:
> Code outline:
>
> ... (JNIEnv *cntx, jobject baobj)
> ...
> signed char *buf;
> ...
> buf = (*cntx)->GetByteArrayElements(cntx, baobj, NULL);
> ...
> ...
> ...
> (*cntx)->ReleaseByteArrayElements(cntx, baobj, buf, 0);
>
> VMS Alpha 8.4 with Java 1.5 : works fine
>

_Appears_ to work fine. :-)

> VMS I64 8.4 with Java 8 : crashes (the output is attached below)
>
> ReleaseByteArrayElements calls memcpy and memcpy calls something
> in LIBOTS that does an access violation.
>
> I understand the memcpy - if GetByteArrayElements returned a copy
> of the JVM data then ReleaseByteArrayElements has to copy the modified
> data back.
>
> But neither baobj nor buf has changed. So I am totally baffled
> over why I can get  an access violation.
>
> Does anyone have an idea about what I should be looking for?
>

Any behaviour change if you compile in debug mode or change optimisation
levels (including turning off all optimisation) ?

If you compile in debug mode, does looking at your variables reveal
anything interesting ? For example, can you look at the expected end
of the returned buffer in the debugger without getting an access violation ?

Is there just the one thread running in your code ?

You could also return the isCopy field in your call to see if a copy
is actually being made instead of just assuming it is.

Also, is "signed char *buf" the same as declaring it using the correct
JNI supplied data type ?

Simon.

PS: BTW, some would say that the JNI design _is_ the problem. :-)

PPS: Spoken as someone who has now played with this stuff on Android. :-)

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.