Bug 1408 - GNU/Linux DRM Freezes when manipulating the PointerIcon (setting & visibility)
Summary: GNU/Linux DRM Freezes when manipulating the PointerIcon (setting & visibility)
Status: RESOLVED FIXED
Alias: None
Product: Jogl
Classification: JogAmp
Component: embedded (show other bugs)
Version: 2.4.0
Hardware: All linux
: P4 blocker
Assignee: Sven Gothel
URL:
Depends on: 1156
Blocks: 1405 1406
  Show dependency tree / graph
 
Reported: 2019-12-04 21:02 CET by Sven Gothel
Modified: 2019-12-05 07:52 CET (History)
1 user (show)

See Also:
Type: DEFECT
SCM Refs:
d5ba4cae824087879a4857e20961a95da04eaebb 66976571abed5f14db5de9975ce08d62cfecc2c8 c7778616ef7706461ee0b09e20591f5a6e4ea363 59fe721a926ff66e98b716a25a08bdfa584ca6fa eaa81d524e9be6af9867c8b6750505c8660a6651 bfc152be4203eeceebea919aff9513d33213c802 ea23776919eff10dee57519ce72354bbaea3544e 84a2e5a250148d600d48a0dd58e07286a375f616 033ee4cad3493038480b06f6caf3de015a3e8de7
Workaround: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Gothel 2019-12-04 21:02:09 CET 
Triaging instability of DRM/GBM on Raspberry Pi 3B+ and 4B,
disclosed stability issues (freeze) when changing the PointerIcon or making it visible/invisible.

Potentially we have missed using a device lock here.
Comment 1 Sven Gothel 2019-12-04 21:04:27 CET 
Reproduced this freeze on a GNU/Linux x86_64 Intel Broadwell device,
besides Raspberry Pi 3B+ and 4B.
Comment 2 Sven Gothel 2019-12-04 21:51:52 CET 
(In reply to Sven Gothel from comment #0)
> 
> Potentially we have missed using a device lock here.

We are using the ResourceToolkitLock, 
but did not put pointer manipulation within a locked block.

However, after adding lock/unlock decoration the freeze still appears.
Comment 3 Sven Gothel 2019-12-04 21:54:32 CET 
Test is run as follows on Raspberry Pi:

cd projects/JogAmp/jogl/make
bash scripts/test-demo-launcher0.sh `which java` ../build-linux-armv6hf
 -time 10000 -noanim -vsync 0


and on x86_64


cd projects/JogAmp/jogl/make
bash scripts/test-demo-launcher0.sh `which java` ../build-x86_64
 -time 10000 -noanim -vsync 0
Comment 4 Sven Gothel 2019-12-04 22:46:26 CET 
d5ba4cae824087879a4857e20961a95da04eaebb
NEWT: Align DisplayImpl.createPointerIcon(..) behavior; PointerIconImpl.validatedHandle() shall not create native resource.

66976571abed5f14db5de9975ce08d62cfecc2c8
Bug 1408: NEWT DRM/GBM DisplayDriver: Add device locking/unlocking decoration for PointerIcon operations

c7778616ef7706461ee0b09e20591f5a6e4ea363
Bug 1408: NEWT DisplayImpl PointerIcon: Property 'newt.disable.PointerIcon' disables PointerIcon usage in general.

59fe721a926ff66e98b716a25a08bdfa584ca6fa
Bug 1408: NEWT DRM/GBM WindowDriver: Adding glFinish() before eglSwapBuffers(..) just in case ..
Comment 5 Sven Gothel 2019-12-04 23:03:00 CET 
(In reply to Sven Gothel from comment #4)

Looks like we have finally a winner:
> c7778616ef7706461ee0b09e20591f5a6e4ea363
> Bug 1408: NEWT DisplayImpl PointerIcon: Property 'newt.disable.PointerIcon'
> disables PointerIcon usage in general.

Disabling the PointerIcon (and hence DRM Cursor manipulation)
makes _the_ difference. Enabling it (dropping the property from the commandline) reproduces the freezes.

This is regardless whether we use VSYNC or the animator thread.

Note: The generic device locking occurs throughout NEWT display and JOGL,
i.e. during DRM cursor manipulation or GL rendering and swapSurface.

The freeze even occurs at startup on Raspi-3b+

Needs a good investigation now.
Comment 6 Sven Gothel 2019-12-05 07:51:24 CET 
eaa81d524e9be6af9867c8b6750505c8660a6651
Bug 1406, Bug 1405: demos.Launcher0: Allow passing GLEventListener via '-demo classname'

bfc152be4203eeceebea919aff9513d33213c802
NEWTDemoListener: Fix NPE

ea23776919eff10dee57519ce72354bbaea3544e
Bug 1406, Bug 1405: demos.Launcher0: Defaults to use multiple PointerIcons again
    
    launch script test-demo-launcher0.sh: Tested with '-Xcheck:jni'

84a2e5a250148d600d48a0dd58e07286a375f616
LinuxKeyEventTracker: Factor out 'sendKeyEvent(..)' call with null check.
Comment 7 Sven Gothel 2019-12-05 07:52:02 CET 
The actual fix:

033ee4cad3493038480b06f6caf3de015a3e8de7

    Bug 1405, Bug 1406, Bug 1408: Resolution: Call ReleasePrimitiveArrayCritical(..) in GetPrimitiveArrayCritical(..) code path!
    
    Now that was quite a miss, causing the bugs in the first place!
    The freeze was caused in the JVM, as this open GetPrimitiveArrayCritical(..) disabled the GC.
    This was reported via '-Xcheck:jni'.
    Depending on the system/jvm, the freeze may happen early or only after a while.
    
    This code path was not executed with new property 'newt.disable.PointerIcon' set,
    but from there to finding the missing critical release - a journey:
    
    - jstack showed
    
      "main" #1 prio=5 os_prio=0 cpu=275.71ms elapsed=51.93s allocated=9710K defined_classes=472 tid=0x00007f7084015000 nid=0x1a39 waiting on condition  [0x00007f
70897c2000]
         java.lang.Thread.State: RUNNABLE
              at jogamp.opengl.es3.GLES3Impl.dispatch_glUniformMatrix4fv1(Native Method)
              at jogamp.opengl.es3.GLES3Impl.glUniformMatrix4fv(GLES3Impl.java:2585)
              at jogamp.opengl.es3.GLES3Impl.glUniform(GLES3Impl.java:10713)
    
    -- said that this thread was no more running, waiting on condition ..
    -- glUniformMatrix4fv1 was given an array!
    
    - '-Xcheck:jni' gave:
    
      Warning: Calling other JNI functions in the scope of Get/ReleasePrimitiveArrayCritical or Get/ReleaseStringCritical
    
    -- Now it is clear that the lack of releasing the critical array, returning to Java and then calling other JNI methods
       caused the Warning - and eventually the freeze.