JDK-7152608 : [macosx] Crash in liblwawt.dylib in AccelGlyphCache_RemoveCellInfo
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 7u4
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: os_x
  • CPU: x86
  • Submitted: 2012-03-09
  • Updated: 2012-05-11
  • Resolved: 2012-04-05
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 JDK 8
7u4 b18Fixed 8Fixed
Related Reports
Duplicate :  
Duplicate :  
Description
http://netbeans.org/bugzilla/show_bug.cgi?id=209325

The user followed these steps in NetBeans before the crash:

- created maven NBM project (allow osgi deps)
- created action (default options)
- into performAction pasted some sample code (JOptionPane.showMessage
- clean and build
- run nbm project

JVM with the developing NB has crashed (while second instance of NB with NBM
started sucesfully) with this error in console:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000011210a861, pid=51432, tid=4658917376
#
# JRE version: 7.0_04-b13
# Java VM: Java HotSpot(TM) 64-Bit Server VM (23.0-b16 mixed mode bsd-amd64
compressed oops)
# Problematic frame:
# C  [liblwawt.dylib+0xc861]  AccelGlyphCache_RemoveCellInfo+0x12
#
# Failed to write core dump. Core dumps have been disabled. To enable core
dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /Users/tomas/space/core-main/hs_err_pid51432.log
Phoning home... 
Using server: 10.161.186.18, port 4711
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

See also the attachment.

Comments
SUGGESTED FIX Suggested fix: http://cr.openjdk.java.net/~bae/7152608/webrev/
15-03-2012

EVALUATION This problem is an example of 'use-after-free' crash: the crash itself happens when AccelGlyphCache meets invalid pointer to a cache cell info in cached glyph info structure. This pointer can have arbitrary value, because corresponding glyph info structure is already destroyed by CStrike cache machinery. The root of the problem is that this destruction is made without any notification to AccelGlyphCache, which keeps and uses invalid pointer to glyph info object. This crash can happen in any application which produces glyphs intensively. For example, Java2D transform demo crashes with the same symptoms.
14-03-2012

EVALUATION Stack: [0x0000000115917000,0x0000000115b17000], sp=0x0000000115b167d0, free space=2045k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [liblwawt.dylib+0xc861] AccelGlyphCache_RemoveCellInfo+0x12 C [liblwawt.dylib+0xcb3c] AccelGlyphCache_AddGlyph+0x1b9 C [liblwawt.dylib+0xabb1] OGLTR_AddToGlyphCache+0x4f C [liblwawt.dylib+0xb4ee] OGLTR_DrawGlyphList+0x2b3 C [liblwawt.dylib+0x7da6] Java_sun_java2d_opengl_OGLRenderQueue_flushBuffer+0x2a2 J sun.java2d.opengl.OGLRenderQueue.flushBuffer(JI)V Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) J sun.java2d.opengl.OGLRenderQueue.flushBuffer(JI)V J sun.java2d.opengl.OGLRenderQueue$QueueFlusher.run()V v ~StubRoutines::call_stu
11-03-2012

EVALUATION Seems like a 2D issue.
11-03-2012