-
Bug
-
Resolution: Fixed
-
P4
-
1.2.0
-
1.2beta4
-
x86
-
windows_nt
-
Not verified
In JAE1_2beta3_N - getting error, panic at executeJava.c 269.
Analysis:
This happens when a JNI method invokes a Java method and the method call
triggers stack expansion. jni_Invoke contains the following logic to expand
the Java stack when setting up a method call (see jni.c 843 ff.):
if (!ExpandJavaStackForJNI (ee, &tmp_stack, &tmp_frame,
args_size) {
...
}
frame->javastack = tmp_stack;
frame->optop = (stack_item*)tmp_frame;
In other words, the arguments and the stack frame itself are left where they
were and only the optop pointer is adjusted to point into the new stack.
This is an invalid set-up for executing Java code, as detected at
executeJava.c 269:
sysAssert (REAL_OPTOP() >= frame->ostack);
The bug would not be detected very often because CreateNewJavaStack would
tend to allocate memory at higher addresses than the existing java stack.
Analysis:
This happens when a JNI method invokes a Java method and the method call
triggers stack expansion. jni_Invoke contains the following logic to expand
the Java stack when setting up a method call (see jni.c 843 ff.):
if (!ExpandJavaStackForJNI (ee, &tmp_stack, &tmp_frame,
args_size) {
...
}
frame->javastack = tmp_stack;
frame->optop = (stack_item*)tmp_frame;
In other words, the arguments and the stack frame itself are left where they
were and only the optop pointer is adjusted to point into the new stack.
This is an invalid set-up for executing Java code, as detected at
executeJava.c 269:
sysAssert (REAL_OPTOP() >= frame->ostack);
The bug would not be detected very often because CreateNewJavaStack would
tend to allocate memory at higher addresses than the existing java stack.