Bug 1192

One test run emitted this interesting ArrayIndexOutOfBoundsException
with jogamp.nativewindow.jawt.JAWTUtil in the backtrace.

pi@raspberrypi ~ $ java -jamvm -jar libgdx-demo-pax-britannica-1.6.3-armhf.jar 
java.lang.ArrayIndexOutOfBoundsException: 692
	at sun.awt.XSettings$Update.getCARD8(XSettings.java:140)
	at sun.awt.XSettings$Update.updateOne(XSettings.java:249)
	at sun.awt.XSettings$Update.update(XSettings.java:229)
	at sun.awt.XSettings.update(XSettings.java:56)
	at sun.awt.X11.XAWTXSettings.getUpdatedSettings(XAWTXSettings.java:140)
	at sun.awt.X11.XAWTXSettings.initPerScreenXSettings(XAWTXSettings.java:96)
	at sun.awt.X11.XAWTXSettings.initXSettings(XAWTXSettings.java:61)
	at sun.awt.X11.XAWTXSettings.<init>(XAWTXSettings.java:53)
	at sun.awt.X11.XToolkit.loadXSettings(XToolkit.java:1504)
	at sun.awt.X11.XToolkit.initXSettingsIfNeeded(XToolkit.java:1475)
	at sun.awt.X11.XToolkit.lazilyLoadDesktopProperty(XToolkit.java:1445)
	at java.awt.Toolkit.getDesktopProperty(Toolkit.java:1826)
	at jogamp.nativewindow.jawt.JAWTUtil$3.run(JAWTUtil.java:433)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:302)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:745)
	at java.awt.EventQueue.access$300(EventQueue.java:103)
	at java.awt.EventQueue$3.run(EventQueue.java:706)
	at java.awt.EventQueue$3.run(EventQueue.java:704)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:715)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
glGetError 0x500
glGetError 0x500
glGetError 0x500
Segmentation fault

gdb java core
warning: Could not load shared library symbols for 7 libraries, e.g. /tmp/jogamp_0001/file_cache/jln6586747877065205123/jln1540222421010353978/libgluegen-rt.so.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `java -jamvm -jar libgdx-demo-pax-britannica-1.6.3-armhf.jar'.
Program terminated with signal 11, Segmentation fault.
#0  0x76d973b8 in executeJava () at interp.c:2416
2416	interp.c: No such file or directory.
(gdb) bt
#0  0x76d973b8 in executeJava () at interp.c:2416
#1  0x76d7e0a8 in executeMethodVaList (ob=ob@entry=0x68a3f878, 
    class=0x6877d2c8, mb=0x1718a58, jargs=...) at execute.c:129
#2  0x76d7f39c in Jam_CallVoidMethod (env=<optimized out>, 
    obj=<optimized out>, methodID=0x1718a58) at jni.c:1184
#3  0x5fa4ab20 in ?? ()
#4  0x5fa4ab20 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

(In reply to comment #0)
> However many of the JNI signatures in the comments of the
> src/newt/native/X11Display.c is wrong.

Yes .. that reminds me of a security critical code review,
where one said: don't you ever add comments!

> This find calls for a thorough investigation if all the arguments to the
> many JNI methods called from the DispatchMessages0 uses the right argument
> types. Using the wrong type may cause Java -> JNI or JNI -> Java truncation
> depending on the JVM implementation.

The JNI methods themselves are validated by the compiler,
since they are compared to the javah generated headers. Check.

The JNI -> Java method callbacks may be an issue here,
since they use anonymous var-args. 
We had an issue w/ those already, see Bug 1166.

I don't know how we can validate those automatically.

Further, I don't know why such mistakes won't break i586 machines,
which are being tested w/ our jenkins setup.

We shall consider adding an arm32 jenkins node
only using reliable drivers, i.e. software rendering and such
w/o binary blobs.

(all .. as discussed in IIRC)

> glGetError 0x500
> Segmentation fault
> 
> gdb java core
> warning: Could not load shared library symbols for 7 libraries, e.g.
> /tmp/jogamp_0001/file_cache/jln6586747877065205123/jln1540222421010353978/
> libgluegen-rt.so.
> Use the "info sharedlibrary" command to see the complete listing.
> Do you need "set solib-search-path" or "set sysroot"?
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
> Core was generated by `java -jamvm -jar
> libgdx-demo-pax-britannica-1.6.3-armhf.jar'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x76d973b8 in executeJava () at interp.c:2416
> 2416	interp.c: No such file or directory.
> (gdb) bt
> #0  0x76d973b8 in executeJava () at interp.c:2416
> #1  0x76d7e0a8 in executeMethodVaList (ob=ob@entry=0x68a3f878, 
>     class=0x6877d2c8, mb=0x1718a58, jargs=...) at execute.c:129
> #2  0x76d7f39c in Jam_CallVoidMethod (env=<optimized out>, 
>     obj=<optimized out>, methodID=0x1718a58) at jni.c:1184
> #3  0x5fa4ab20 in ?? ()
> #4  0x5fa4ab20 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)


-> methodID=0x1718a58

We may need to add DBG_PRINTF for all our method-ids ..

(In reply to comment #2)
> We shall consider adding an arm32 jenkins node
> only using reliable drivers, i.e. software rendering and such
> w/o binary blobs.

.. and a 'good known' JVM of course.

In short: testing w/ good known, working components
to validate our code base only.

(In reply to comment #3)
> > (gdb) bt
> > #0  0x76d973b8 in executeJava () at interp.c:2416
> > #1  0x76d7e0a8 in executeMethodVaList (ob=ob@entry=0x68a3f878, 
> >     class=0x6877d2c8, mb=0x1718a58, jargs=...) at execute.c:129
> > #2  0x76d7f39c in Jam_CallVoidMethod (env=<optimized out>, 
> >     obj=<optimized out>, methodID=0x1718a58) at jni.c:1184
> > #3  0x5fa4ab20 in ?? ()
> > #4  0x5fa4ab20 in ?? ()
> > Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> 
> 
> -> methodID=0x1718a58
> 
> We may need to add DBG_PRINTF for all our method-ids ..

Also .. you might want to use a debug build, i.e. not stripping symbols:
    -Dc.compiler.debug=true \
    -Djavacdebuglevel="source,lines,vars" \

This should disclose at least:
> > #3  0x5fa4ab20 in ?? ()

Created attachment 718 [details]
jamvm --enable-tracedll log

Recompiled and used javmvm with --enable-tracedll
trace log:
<DLL: Looking up dispatch_eglChooseConfig0 internally>
<DLL: Calling JNI method com/jogamp/opengl/egl/EGL.dispatch_eglChooseConfig0(JLjava/lang/Object;ILjava/lang/Object;IILjava/lang/Object;IJ)Z>
<DLL: Looking up dispatch_eglGetConfigAttributes internally>
<DLL: Calling JNI method com/jogamp/opengl/egl/EGL.dispatch_eglGetConfigAttributes(JJILjava/lang/Object;ILjava/lang/Object;IJ)V>
<DLL: Looking up dispatch_eglGetConfigAttrib0 internally>
<DLL: Calling JNI method

indicate that the crash can triggers early after EGL
dispatch_eglGetConfigAttrib0

it appears the the heap is corrupt
below shows that a invalid pointer crash in interp.c:2477
that happened after jamvm is returning from a
void run() method
the pointer to the old frame on the heap appears to have been overwritten.


Core was generated by `java -jam -jar ../libgdx-demo-pax-britannica-1.6.3-armhf.jar'.
Program terminated with signal 11, Segmentation fault.
#0  executeJava () at interp.c:2477
2477	    if(frame->mb == NULL) {
(gdb) list
2472	
2473	methodReturn:
2474	    /* Set interpreter state to previous frame */
2475	    frame = frame->prev;
2476	
2477	    if(frame->mb == NULL) {
2478	        /* The previous frame is a dummy frame - this indicates
2479	           top of this Java invocation. */
2480	        return ostack;
2481	    }
(gdb) p frame
$1 = (Frame *) 0x1

(gdb) frame 1
#1  0x76d3789c in executeMethodVaList (ob=0x68a32f98, class=0x67cc57c8, mb=0xc7ac78, jargs=...) at execute.c:129
129	        executeJava();

(gdb) p mb->name
$1 = 0x76d647ac "run"
(gdb) p mb->type 
$2 = 0x76d651e0 "()V"

(gdb) p class
$3 = (Class *) 0x67cc57c8
(gdb) p class->
class  lock   
(gdb) p class->lock 
$4 = 0
(gdb) p class->class 
$5 = (Class *) 0x67cc20e0

managed to capture the crash in gdb, this time we got the full method signature

<DLL: Looking up dispatch_eglGetConfigAttrib0 internally>
<DLL: Calling JNI method com/jogamp/opengl/egl/EGL.dispatch_eglGetConfigAttrib0(JJILjava/lang/Object;IJ)Z>

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x6287c470 (LWP 17709)]
0x630dd848 in ?? ()
(gdb) bt
#0  0x630dd848 in ?? ()
#1  0x76ec1e5c in __GI___libc_free (mem=<optimized out>) at malloc.c:3738
#2  0x67d76bc8 in ?? ()
#3  0x67d76bc8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) list
1	arena.c: No such file or directory.

arena.c is part of glibc malloc

Created attachment 719 [details]
not-us.log

when re-running the testcase several times in gdb
i managed to hit a classloader error using jamvm
even before loading any jogl classes.

thus something starts to malfunction before using any jogamp classes or natives.

closing the bug as invalid since we can observe malfunction before any jogamp classes or natives has been loaded.

branch to merge: https://github.com/xranby/jogl/tree/Bug1192

Bug 1192: NEWT native/X11Display.c Cleanup JNI signatures in comments

576ba0b8334dae8ab8b0b2686422d450c7f360da
 NEWT native/X11Display.c Cleanup JNI signatures in comments