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

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?

Arne

#
# A fatal error has been detected by the Java Runtime Environment:
# # %SYSTEM-F-ACCVIO (0xc) at pc=84234440, pid=1064, tid=0x000000007b6ecec0
# # JRE version: OpenJDK Runtime Environment (8.0_222-b05) (build
1.8.0_222-b05)
# Java VM: OpenJDK 64-Bit Server VM (25.222-b05 mixed mode OpenVMS-ia64 )
# Problematic frame:
# C [LIBOTS+0x2c0] +0x84234440
# #
# # Can not save log file, dump to screen..
# # A fatal error has been detected by the Java Runtime Environment:
# # %SYSTEM-F-ACCVIO (0xc) at pc=84234440, pid=1064, tid=0x000000007b6ecec0
# # JRE version: OpenJDK Runtime Environment (8.0_222-b05) (build
1.8.0_222-b05)
# Java VM: OpenJDK 64-Bit Server VM (25.222-b05 mixed mode OpenVMS-ia64 )
# Problematic frame:
# C [LIBOTS+0x2c0] +0x84234440
# #
# # Please report this error to VSI customer support.
#

--------------- T H R E A D ---------------

Current thread (31C000): JavaThread "main" [_thread_in_vm,
id=2070859456, stack(7AB16000,7AD16000)]

siginfo:si_signo=(null): si_errno=error 9732, si_code=12

Top of Stack: (sp=7AD0FAF0)
7AD0FAF0: 0000000000000000 0000000000000000
7AD0FB00: 0000000000000000 0000000000000000
7AD0FB10: 0000030000030380 0000000843790022
7AD0FB20: ffffffff84234440 000000000000000c
7AD0FB30: 000007fdbffd6a00 000007fdbffd6a00
7AD0FB40: 0000000000000000 0000000000000000
7AD0FB50: c00000000000030b 0000000000000000
7AD0FB60: 0000000000000000 0000000000000000
7AD0FB70: 0000000000000000 0000000000000000
7AD0FB80: 0000000000000000 0000000000000000
7AD0FB90: 0000000000000000 0000000000000000
7AD0FBA0: 0209804c0274433f 0000000000000000
7AD0FBB0: ffffffffffff9ed7 00001013084ae030
7AD0FBC0: 0000080400000000 0000000000000000
7AD0FBD0: 0000000009b92000 00000000ffedbd34
7AD0FBE0: ffffffff84234430 8000000b766d1020
7AD0FBF0: 0000000000000000 ffffffff7ff78e80
7AD0FC00: 0000000000000000 0f6c000009b7cbf0
7AD0FC10: 0000000000007f00 0000000000000000
7AD0FC20: 0000000000000003 0000000000000000
7AD0FC30: 000007fd00000002 000000007b562000
7AD0FC40: 0000000000000000 0000000000000000
7AD0FC50: 000000000031c000 000000007ad0fe68
7AD0FC60: 000000007ab16000 000007fdc0fd4000
7AD0FC70: 000007fe2e80ba18 0000000000000018
7AD0FC80: 000000000000001b 0000000000000000
7AD0FC90: 000000007ad0ec40 000000007b6ecec0
7AD0FCA0: 00000000a0f80bb0 000000007b8b1f48
7AD0FCB0: ffffffff84234180 000007fd97405d00
7AD0FCC0: 0000000009b7aea0 0000000000000000
7AD0FCD0: 00000000004453a0 0000000009b7cbf0
7AD0FCE0: 00000000000097d7 00000000025d0173
7AD0FCF0: 000007fd9741d088 0000000009b92260
7AD0FD00: 000007fd9741cde8 000007fd9741cdf8
7AD0FD10: 0000000009b92010 0000000009b92000
7AD0FD20: 0000000000000018 00000000973eeb90
7AD0FD30: ffffffff8484b5f0 0000000000000000
7AD0FD40: 0000000000000000 0000000000000000
7AD0FD50: 0000000000000000 0000000000000000
7AD0FD60: ffffffff84234180 ffffffff844be1a0
7AD0FD70: 0000000000000800 0000000000000000
7AD0FD80: c000000000000000 000000000000ffcb
7AD0FD90: 00000000000004b6 000000000001003e
7AD0FDA0: 8400000000000000 000000000001000c
7AD0FDB0: e000000000000000 0000000000010001
7AD0FDC0: 96db6db6db6db6db 0000000000010009
7AD0FDD0: 9249249249249249 000000000000fffc
7AD0FDE0: 432414183a217a08 c428f87005283070
7AD0FDF0: 0000000000000000 0000000000000000
7AD0FE00: 0000000000000000 0000000000000000
7AD0FE10: 0000000009b7aea0 000000000031c000
7AD0FE20: 000000000031c000 000000000031c000
7AD0FE30: 000007fd60fc2100 000007fd60fc21d8
7AD0FE40: 000007fd60fc21d8 09b7ad80010e00ff
7AD0FE50: 09b7ad80010e00ff 000007fd60fc21d8
7AD0FE60: 0000000000000000 0000000000000000
7AD0FE70: 000007fd97412728 000007fd9742e920
7AD0FE80: 000007fd9742e858 000007fd9742e830
7AD0FE90: 000000007b35e5c0 000000007b35e5c0
7AD0FEA0: 0000000000000000 000007fd9742e588
7AD0FEB0: 0000000000000003 000007fd9742e920
7AD0FEC0: 000007fd9742e858 000007fd9742e830
7AD0FED0: 0000000000000003 000007fd9742e750
7AD0FEE0: 000007fd9742e660 000007fd9740be80
7AD0FEF0: 000007fd974081e0 000007fd97408198
7AD0FF00: 0000000000000000 0000000000000000
7AD0FF10: 000007fd97405e28 000007fd97405cf0
7AD0FF20: 000007fd973ff1b0 000000000031c000
7AD0FF30: 0000000000000000 0000000000000000
7AD0FF40: 0000000000000000 0000000000000000
7AD0FF50: 0000000000000000 0000000000000000
7AD0FF60: 0000000000000000 0000000000000000
7AD0FF70: 0000000000000000 0000000000000000
7AD0FF80: 0000000000000000 0000000000000000
7AD0FF90: 0000000000000000 0000000000000000
7AD0FFA0: 0000000000000000 0000000000000000
7AD0FFB0: 0000000000000000 0000000000000000
7AD0FFC0: 0000000000000000 0000000000000000
7AD0FFD0: 0000000000000000 0000000000000000
7AD0FFE0: 0000000000000000 0000000000000000
7AD0FFF0: 0000000000000000 0000000000000000
7AD10000: 0000000000000000 0000000000000000
7AD10010: 0000000000000000 0000000000000000
7AD10020: 0000000000000000 0000000000000000
7AD10030: 0000000000000000 0000000000000000
7AD10040: 0000000000000000 0000000000000000
7AD10050: 0000000000000000 0000000000000000
7AD10060: 0000000000000000 0000000000000000
7AD10070: 000007fdafc9f880 0000000000000000
7AD10080: 0000000000000000 0000000000000000
7AD10090: 0000000000000000 000000000031c000
7AD100A0: 0000000000000001 000007fd00000000
7AD100B0: 000007fd60f88a58 000000000031c000
7AD100C0: 0000000000000004 000007fd60bcdc50
7AD100D0: 000007fd60f88a58 000000000031c000
7AD100E0: 0000000003ebaa48 000007fd000000d8
7AD100F0: 000000007ad10530 000007fd60fabb28
7AD10100: 0000000000000001 0000000000000000
7AD10110: 0000000003ebaa08 0000000003eba620
7AD10120: 000007fd60f88a58 000000000031c000
7AD10130: 000007fd60f88a58 000000000031c000
7AD10140: 000007fd60bcdc50 000000000031c000
7AD10150: 000000000031c000 0000000008e30c90
7AD10160: 000007fd60f88a58 000007fd973ff1b0
7AD10170: 000000007ad107f0 000007fdafc8c2d0
7AD10180: 000007fdbffd5fb0 000007fd00000001
7AD10190: 000000007ad105c0 000000000031c000
7AD101A0: 000000000031c000 000000000031fd30
7AD101B0: 0000000003eba9f0 0000000003ebaa20
7AD101C0: 0000000003ebaad8 000007fd000000d8
7AD101D0: 000000007ad10d50 0000000000000003
7AD101E0: 0000000003ebaa08 0000000000000002
7AD101F0: 000007fd60f88a58 000007fd60f88a58
7AD10200: 0000000000000000 000007fd60fab270
7AD10210: 000000007ad10520 000007fd60f88a58
7AD10220: 000007fd60f88a58 000007fd00000003
7AD10230: 0000000000000081 0000000003ebaa08
7AD10240: 0000000100000001 000007fd00000001
7AD10250: 0000000000000200 000007fd60cb9d70
7AD10260: 00000000039b2960 000007fd60f88a58
7AD10270: 0000000003eadd70 0000000003eba5f0
7AD10280: 0000000003eba600 0000000003eba9d8
7AD10290: 00000000000003d8 000007fd60cbaba0
7AD102A0: 000007fd60f88a58 000000000031c000
7AD102B0: 000007fd60f8a298 0000000003ebaa64
7AD102C0: 0000000000000001 0000000005123a61
7AD102D0: 0000000000000001 000000000031c000
7AD102E0: 000007fd60cb9d70 000000000031c000

Instructions: (pc=84234440)
84234420: 08 4a 61 3a 18 14 c4 c2 70 30 28 20 71 f8 00 c4
84234430: 49 c2 ac 34 98 95 84 71 6d 30 2b 40 01 f8 00 c4
84234440: 08 7a 21 3a 18 14 24 43 70 30 28 05 70 f8 28 c4
84234450: 49 42 c4 34 98 95 84 a0 6d 30 2b 00 00 f8 2c e4

Stack: [7AB16000,7AD16000], sp=7AD0FE10, free space=2023k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
C=native code)
C [LIBOTS+0x2c0] +0x84234440
C [DECC$SHR+0x30] C$$MEMFUNC/_memcpy64+0x8484b5f0
C [java$jvm_shr+0x320] jni/jni_ReleaseByteArrayElements+0xce6de0
C [VMScall_shr+0x5300]
dk_vajhoej_vms_call_vms/Java_dk_vajhoej_vms_call_VMS_callFunction+0x9b88e10
v ~StubRoutines::native_call_stub
j
dk.vajhoej.vms.call.VMS.callFunction(J[I[I[Ldk/vajhoej/vms/call/VMS$TypeWrapper;)I+0
j
dk.vajhoej.vms.call.VMS.call(Ljava/lang/String;Ljava/lang/String;[Ldk/vajhoej/vms/call/VMS$Pass;)I+674
j
dk.vajhoej.vms.call.test.TestBasic.testDefaultAccessTraditionalStyle()V+56
v ~StubRoutines::call_stub
C [java$jvm_shr+0x15b0] javaCalls/call_helper+0x169ff30
C [java$jvm_shr+0xe0] os_vms/os_exception_wrapper+0xe9e4a0
C [java$jvm_shr+0x60] javaCalls/call+0x16a6ea0
C [java$jvm_shr+0x1090] reflection/invoke+0x10a3310
C [java$jvm_shr+0x480]
Interrupt

On 1/26/22 01:39, Arne Vajhøj 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
>
> VMS I64 8.4 with Java 8 : crashes (the output is attached below)
> ...

Just to make sure it isn't a 32-/64-bit problem: how do you compile?
Java 8 on VMS requires JNIs to use 64-bit pointers.

On 1/26/2022 4:50 AM, hb wrote:
> On 1/26/22 01:39, Arne Vajhøj 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
>>
>> VMS I64 8.4 with Java 8 : crashes (the output is attached below)
>> ...
>
> Just to make sure it isn't a 32-/64-bit problem: how do you compile?
> Java 8 on VMS requires JNIs to use 64-bit pointers.

I do use /pointer=64.

Arne

On 2022-01-25, Arne Vajhøj <arne@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@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 1/26/22 14:24, Arne Vajhøj wrote:
> On 1/26/2022 4:50 AM, hb wrote:
>> On 1/26/22 01:39, Arne Vajhøj 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
>>>
>>> VMS I64 8.4 with Java 8 : crashes (the output is attached below)
>>> ...
>>
>> Just to make sure it isn't a 32-/64-bit problem: how do you compile?
>> Java 8 on VMS requires JNIs to use 64-bit pointers.
>
> I do use /pointer=64.

Although I never tried it from an JNI, I would add a
lib$signal(ss$_debug); and try to debug the JNI code.

The other option to debug a JNI is to find where and when Java "loads"
it. In Java 6 there was a Java$dlopen routine. In the debugger you could
set a break point at that routine and then watch for your JNI to be
"loaded". Once it is "loaded", you can do a "set image <your-jni>" and
set break points in your code.

On 1/26/2022 11:53 AM, hb wrote:
> On 1/26/22 14:24, Arne Vajhøj wrote:
>> On 1/26/2022 4:50 AM, hb wrote:
>>> On 1/26/22 01:39, Arne Vajhøj 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
>>>>
>>>> VMS I64 8.4 with Java 8 : crashes (the output is attached below)
>>>> ...
>>>
>>> Just to make sure it isn't a 32-/64-bit problem: how do you compile?
>>> Java 8 on VMS requires JNIs to use 64-bit pointers.
>>
>> I do use /pointer=64.
>
> Although I never tried it from an JNI, I would add a
> lib$signal(ss$_debug); and try to debug the JNI code.
>
> The other option to debug a JNI is to find where and when Java "loads"
> it. In Java 6 there was a Java$dlopen routine. In the debugger you could
> set a break point at that routine and then watch for your JNI to be
> "loaded". Once it is "loaded", you can do a "set image <your-jni>" and
> set break points in your code.

Using the debugger is a lot more flexible than printf's.

But I am already printf'ing all the variable that I would
like to examine.

But cool trick.

Arne

On 1/26/2022 8:50 AM, Simon Clubley wrote:
> On 2022-01-25, Arne Vajhøj <arne@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. :-)

It passes an extensive test suite.

But producing the desired results with no visible side
effects does not mean that the code is correct on that
platform, just that it can't be debugged there.

There is a 99.9% probability that there is a bug in my
code. I just need to find it.

>> 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) ?

I have not tried.

It is typical not something that matters on VMS.

But easy to try.

> 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 ?

Pointers are valid.

I can printf both pointers and what they point at.

> Is there just the one thread running in your code ?

In my code both Java and C: yes.

But JVM probably has a few housekeeping threads around. The JVM
could easily run GC, but it should not be able to GC or move
the variables the C Code is using.

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

I could.

But I really don't care why ReleaseByteArrayElements does
a memcpy. I am pretty sure that it is because I got a copy,
but if that is not a case in it does memcpy for some other
reason, then I am not really the wiser.

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

typedef signed char jbyte;

> 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. :-)

The JNI API is very low level and rather cumbersome.

It was designed in the context of mid 90's with strong efficiency
requirements and lots of available C skill and for obvious reasons
little Java skill available.

The replacement is getting ready.

The foreign function API was made preview in Java 16 and I *hope*
that it will become standard in 19 or 20.

Arne

On 1/25/2022 7:39 PM, Arne Vajhøj 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
>
> 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?

> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  %SYSTEM-F-ACCVIO (0xc) at pc=84234440, pid=1064, tid=0x000000007b6ecec0

> Stack: [7AB16000,7AD16000],  sp=7AD0FE10,  free space=2023k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
> C=native code)
> C  [LIBOTS+0x2c0]  +0x84234440
> C  [DECC$SHR+0x30]  C$$MEMFUNC/_memcpy64+0x8484b5f0
> C  [java$jvm_shr+0x320]  jni/jni_ReleaseByteArrayElements+0xce6de0
> C  [VMScall_shr+0x5300]
> dk_vajhoej_vms_call_vms/Java_dk_vajhoej_vms_call_VMS_callFunction+0x9b88e10

A followup.

Problems solved.

A gazillion printf statements printing out everything everywhere
revealed what was going on.

And as usual the problem was of course in my code.

I wrote that "neither baobj nor buf has changed" - and that is
true as none of the 4 (!!) pointers changed.

It turned out that GetByteArrayElements was called twice.

And there was a baobj pointing to the object containing
the byte array and a baobj pointing to the actual byte array.

typedef jobject jarray;
typedef jarray jbyteArray;

does that the compiler cannot see the difference between
jobject and jbyteArray.

But everything worked fine on Java 5 on VMS Alpha.

GetByteArrayElements returns a pointer to the original
so two calls to GetByteArrayElements is not a problem
as they return the same pointer.

ReleaseByteArrayElements does not need to copy anything,
back so it does not need the argument.

Just for fun I tried:

(*cntx)->ReleaseByteArrayElements(cntx, NULL, NULL, 0);

no exceptions!

But Java 8 on VMS I64 is a different story. GetByteArrayElements
return a copy.

The two calls to GetByteArrayElements returned different
pointers.

ReleaseByteArrayElements actually need to copy back so
it took the pointer to the wrong type and just used
it as if the right type. And the memcpy bombed.

So time to clean up the code.

Only call GetByteArrayElements once.

And call ReleaseByteArrayElements with the right pointer
everywhere.

Now it woks.

Arne