JDK-8118470 : Mac: Invalid memory access error
  • Type: Bug
  • Component: javafx
  • Sub-Component: window-toolkit
  • Affected Version: fx2.0.2
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2011-10-12
  • Updated: 2015-06-17
  • Resolved: 2011-10-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7-poolFixed
Related Reports
Duplicate :  
JDK-8112976 - Mac: Assertion failed: ([NSOpenGLContext currentContext] == [self openGLContext]), function -[GlassView3D begin]
Relates :  
JDK-8128178 - Mac: GlassView2D/3D.lockedFocus boolean field isn't thread-safe
Relates :  
JDK-8101513 - CLONE - Glass should not be the owner of graphics context (Glass client should be the owner)
Relates :  
JDK-8098102 - Glass should not be the owner of graphics context (Glass client should be the owner)
Relates :  
JDK-8127874 - SceneBuilder is out of sync with the native OS window size while resizing.
Description
FX fails with:
 java[90076:1707] *** Assertion failure in -[GlassView3D lockFocus], /SourceCache/AppKit/AppKit-1038.36/AppKit.subproj/NSView.m:5237
 java[90076:1707] lockFocus caught exception: -[GlassView3D(0x1085949b0) lockFocus] failed with window=0x0, windowNumber=0, [self isHiddenOrHasHiddenAncestor]=0
 java[90076:1707] unlockFocus called too many time.
 Invalid memory access of location 0x4e53 rip=0x11a7969c3

on MacOS starting from 2.0.2-graphics-scrum build #73.
#73 contains only following change:
 1. Follow-up fix for RT-17213: com.sun.glass.ui.mac.MacView are not garbage collected (detail)

At least the following FX performance benchmarks fails with this error:
 WebNode.ColorfulShapes-Blur2Circle
 WebNode.GUIMark2-Vector
 Controls.TreeView-Keyboard

The bug is easy to reproduce. Do run WebNode.GUIMark2-Vector for example:
> cd JFX_WS/jfx/tests/performance/WebNodeTestSuite/
> ant
> ant run-vector-bm
Comments
We provide a workaround until we change the graphics context ownership - we use the shared context whenever the View is not locked.
24-10-2011
Btw, RT-13914 fix also lead to many performance regressions. See all FPS regressions here: http://aurora.russia.sun.com/performance/faces/ChessBoard.xhtml?reportName=FX2-graphics-scrum&parameters=%5Bshownbenchmarks%5D%281%3D1%29%5Brefrelease%5D2.0.2%5Brefbuild%5D%3D+%2710085%27%5Brefjdkrelease%5D1.6.0_26%5Brelease%5D%28pr.product.productRelease+%3D+%272.0.2%27%29%5Bbuild%5D%28pr.product.build+%3D+%2710085%27%29OR%28pr.product.build+%3D+%2710086%27%29%5Bjdkrelease%5D%28jdk.product.productRelease+%3D+%271.6.0_26%27%29%5Bhwclass%5Dhost.machine.additionalInfo+%3D+%27Mac-Mid-Range%27&splitting=%5BX+axis%5DfxConf%2C+metricName%5BComplement%5Dbenchmark%2C+jdkBuild%2C+jdk%5BY+axis%5DbenchmarkName%2C+benchmarkConf%2C+fxRelease%2C+fxBuild%5BZ+axis%5Dos%2C+hwclass%2C+jdkRelease%2C+benchmarkSuite&reference=%5BOthers%5DfxRelease%2C+fxBuild%2C+jdkRelease%2C+jdkBuild%2C+jdk%2C+benchmarkSuite%2C+benchmarkName%2C+metricName%5BReference+Set%5Dbenchmark%2C+os%2C+benchmarkConf%2C+fxConf%2C+hwclass&mixReference=false&flags=&significance=empty&hideDataConfiguration=false&calculateSummary=false&showSummaryExpanded=false&showSummaryContents=true&showComplementAttributes=false&compactTables=true&viewStyle=chessboard&filter= I am not sure this is real regression as it could be because FX started to work more properly. But want to let you know about this so you may have a look at this as well.
14-10-2011
Regarding #A: Actually, the View.begin() method provides a boolean return value that indicates whether the operation succeeded. Prism code could check the return value, and if it's false, assume that the operation failed.
13-10-2011
Verified that this happens because we can not obtain the lock on the view. The issue at the core is caused by Glass "breaking" its semantics behind View.lock API, which assumes that it always succeeds. It is complicated by the unclearly defined shutdown life-cycle phase. Currently the shutdown process should be: 1. release any resources associated with the current View (requires the View to be visible for GL context to be available) 2. make View invisible 3. release the View itself It looks like at the moment that phase is 2,1,3 There are several ways to address this issue: A. Glass should inform the clients if the lock fails, so that the client (Quantum) knows it can not perform any GL commands if View.lock fails (not ideal, since we will leak GL resources, unless Quantum is also modified in such a way as to make sure it releases the GL resources, like textures, before making the View invisible and disposing it - which would be a good idea anyhow) B. Modify Glass, so that View.lock always succeed (using offscreen object, such as IOSurface to provide a valid GL context)
13-10-2011
The crash takes place in: Thread 24 Crashed:: Java: QuantumRenderer-0 0 GLEngine 0x0000000116f3c24e glDeleteTextures_Exec + 23 1 libprism_jogl_gl2.jnilib 0x0000000116e0cefb Java_com_sun_prism_opengl_impl_gl2_GL2Impl_glDeleteTextures1__ILjava_lang_Object_2I + 123 2 ??? 0x000000010e4f5d6e 0 + 4535049582 3 ??? 0x000000010e4ea85a 0 + 4535003226 4 ??? 0x000000010e4ead34 0 + 4535004468 5 ??? 0x000000010e4ea85a 0 + 4535003226 6 ??? 0x000000010e4ea85a 0 + 4535003226 7 ??? 0x000000010e4ead34 0 + 4535004468 8 ??? 0x000000010e4ead34 0 + 4535004468 9 ??? 0x000000010e4ead34 0 + 4535004468 10 ??? 0x000000010e4eae8d 0 + 4535004813 11 ??? 0x000000010e4eaa82 0 + 4535003778 12 ??? 0x000000010e4eaa82 0 + 4535003778 13 ??? 0x000000010e4ead34 0 + 4535004468 14 ??? 0x000000010e4ea85a 0 + 4535003226 15 ??? 0x000000010e4ead34 0 + 4535004468 16 ??? 0x000000010e4ead34 0 + 4535004468 17 ??? 0x000000010e4e5438 0 + 4534981688 18 libclient64.dylib 0x000000010dbdd6ca 0x10db32000 + 702154 19 libclient64.dylib 0x000000010dbe975c 0x10db32000 + 751452 20 libclient64.dylib 0x000000010dbe9652 0x10db32000 + 751186 21 libclient64.dylib 0x000000010dbe95f2 0x10db32000 + 751090 22 libclient64.dylib 0x000000010dbe9494 0x10db32000 + 750740 23 libclient64.dylib 0x000000010dbe92a9 0x10db32000 + 750249 24 libclient64.dylib 0x000000010db457d0 0x10db32000 + 79824 25 libsystem_c.dylib 0x00007fff8bbb98bf _pthread_start + 335 26 libsystem_c.dylib 0x00007fff8bbbcb75 thread_start + 13 Based on the recent changes my initial guess is that at the tear down phase we fail to lock on the view, and so are left with no valid GL context, which is what causes glDeleteTextures (since it requires a GL context to be set) to crash.
13-10-2011
Raise priority to Major.
13-10-2011
There are no assertion thrown anymore but the benchmarks still crash with "Invalid memory access of location" The issue is reproduced with latest graphics scrum builds which contain fix for RT-13914
13-10-2011
Chien and I also found RT-13914 yesterday when he discovered this bug. The assertion message is the same, but something has changed in glass recently to trigger this assertion. RT-13914 was originally filed as a corner-case bug that the SceneBuilder ran into, but has now become a serious regression from 2.0 that affects all programs on exit.
12-10-2011
Duplicate of RT-13914.
12-10-2011
This regression is pretty serious. It happens on practically every JavaFX program I have tried, including HelloRectangle.
12-10-2011
Actually almost all performance benchmarks have such assertion but not all fails/crashes due ti this reason.
12-10-2011
FX BUILD: 2.0.2-b73-graphics-scrum FX CONFIG: Prism/hw PLATFORMS: macos (at least macos 10.6.8) BENCHMARKS: WebNode.ColorfulShapes-Blur2Circle WebNode.GUIMark2-Vector Controls.TreeView-Keyboard AURORA RESULTS: http://aurora-ds.ru.oracle.com:9500/runs/15738.FX2-graphics-scrum.7b148.mac-mid.WebNode.GUIMark2-Vector.app-adhoc.prism-hw.install-jdk-fx2_resubmit0/.workload.log.4549
12-10-2011
The issue could be related to one of following open issues: 1. RT-16369 "Mac crash" 2. RT-17313 "WebView crash in WebEngine load method - Win + Mac" Filed new bug as the issue started to appear only in #73 where RT-17213 has been integrated.
12-10-2011