1076 2014-09-22 23:36:10 +0200 Fix race conditions in GLDrawableHelper glRunnable and Animator* for unhandled exceptions 2019-03-29 17:54:47 +0100 1 1 3 JogAmp Jogl core 2.3.0 All all RESOLVED FIXED --- major --- 0 sgothel sgothel sgothel DEFECT c298b4317a30cc453a2350ebeb5ab3570a4c107d cef7ba607ad7e8eb1ff2a438d77710a29aa0bda6 66ecb6c386d5c3d87d8be2600a0c7dd7d71a4329 --- oldest_to_newest 4261 0 sgothel 2014-09-22 23:36:10 +0200 commit c298b4317a30cc453a2350ebeb5ab3570a4c107d: GLDrawable.invoke(..) regression of commit c77b8f586cb2553582a42f5b90aeee5ef85f1efe: 'wait' was not set to false, if 'deferredHere' was forced to 'false'. This could lead to the situation where GLRunnableTask will catch the exception and supresses it. Animator/FPSAnimator post exception propagation code animThread = null; notifyAll(); must be complete to finalize animator state in case of an exception. Decorate 'handleUncaughtException(..)' w/ try { } finally { } where the latter ensures the mentioned 'closure'. +++ commit cef7ba607ad7e8eb1ff2a438d77710a29aa0bda6: Fix synchronization issues in GLDrawableHelper.flushGLRunnables(): - Querying 'glRunnables.size()' is not synchronized, only its reference is volatile, not the instance's own states. - 'flushGLRunnable()' must operates while acquired the 'glRunnable' lock. - 'glRunnables' are no more volatile - introduced volatile 'glRunnableCount', allowing 'display(..)' method to pre-query whether blocking 'execGLRunnables(..)' must be called. This is risk (deadlock) free. Also fixes rare deadlock in animator display-exception / GLAD.invoke(wait=true, ..) case: - 'GLDrawableHelper.invoke(.., GLRunnable)' acquires the 'glRunnable' lock. - Then it queries animator state, which is blocking. - Hence animator's 'flushGLRunnable()' call must happen outside the animator lock 4264 1 sgothel 2014-09-23 04:00:17 +0200 commit 66ecb6c386d5c3d87d8be2600a0c7dd7d71a4329: Fix synchronization issues in Animator* Exception case Refines commit cef7ba607ad7e8eb1ff2a438d77710a29aa0bda6 - The animator monitor-lock was still hold in the post finally block issuing flushGLRunnables(), due to intrinsic monitor release (in finally): - <http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.html#jvms-2.11.10> - <http://stackoverflow.com/questions/10743285/behavior-of-a-synchronized-method-with-try-and-finally> - Further: AnimatorBase.flushGLRunnables() acquired the lock itself (duh!) This commit removes the requirement for finally altogether by simply return a boolean from handleUncaughtException(caughtException), where false denotes the caller to propagate the exception itself (no handler). Post synchronized block then issues flushGLRunnables() and exceptation propagation as required. AnimatorBase.flushGLRunnables() 'synchronized' modifier is removed. Further, ThreadDeath is being propagated if caught. Here the finally block is also removed - redundant.