JDK-5066318 : OGL: Enabling OGL pipeline on Windows with ATI board crashes VM at exit/shutdown
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 5.0,6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2004-06-22
  • Updated: 2010-07-09
  • Resolved: 2011-03-08
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 6 JDK 7
6u4Fixed 7 b08Fixed
Related Reports
Duplicate :  
JDK-6440273 - Java HotSpot(TM) Client VM (1.6.0-rc-b87) crashes with -Dsun.java2d.opengl=true
Duplicate :  
JDK-6357499 - OGL crashed with resizing Java2Demo Frame on Radeon 9800XT with driver 5.11
Relates :  
JDK-6525997 - OGL: VM crash when drawing a general path on screen and repainting it a few times, Win32
Relates :  
JDK-5033205 - PIT: OGL with Java2Demo and Radeon not displaying application demos properly
Relates :  
JDK-6439320 - OGL: enable sun.java2d.opengl.fbobject by default
Description
Name: rl43681			Date: 06/21/2004


FULL PRODUCT VERSION :
java version "1.5.0-beta3"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta3-b56)
Java HotSpot(TM) Client VM (build 1.5.0-beta3-b56, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

EXTRA RELEVANT SYSTEM CONFIGURATION :
ATI 9700 Pro
Driver version: 6.14.10.6444 (CATALYST Windows XP 4.6)


A DESCRIPTION OF THE PROBLEM :
Invocation:
..\..\..\bin\java.exe -Dsun.java2d.opengl=true -jar SwingSet2.jar

produces a blank application. Exiting the application produces the following:

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x693e9440, pid=3984, tid=1452
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0-beta3-b56 mixed mode, sharing)
# Problematic frame:
# C  [atioglxx.dll+0x3e9440]
#
# An error report file with more information is saved as hs_err_pid3984.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Change directory to SwingSet2.
Execute ..\..\..\bin\java.exe -Dsun.java2d.opengl=true -jar SwingSet2.jar


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Accelerated OpenGL performance as commented about in article  http://java.sun.com/developer/technicalArticles/releases/j2se15
ACTUAL -
Did not work.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x693e9440, pid=3984, tid=1452
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0-beta3-b56 mixed mode, sharing)
# Problematic frame:
# C  [atioglxx.dll+0x3e9440]
#
# An error report file with more information is saved as hs_err_pid3984.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Don't invoke OpenGL hardware acceleration.
(Incident Review ID: 280633) 
======================================================================
Comments
EVALUATION Add to the list of benefits: - no more crash on resizing on pre-FBO ATI boards (see 6357499)
12-01-2007
EVALUATION Well, still no driver fix from ATI. However, I have discovered that the driver bug is not completely specific to the use of pbuffers, but rather is caused by an interaction with the WGL_ARB_render_texture extension. First, a history lesson. When the OGL-based Java 2D pipeline was first developed in 2001/02, there were two WGL extensions proposed that went hand-in-hand with WGL_ARB_pbuffer: - WGL_ARB_render_texture - WGL_ARB_make_current_read Both were designed as a way to copy a pbuffer to another OpenGL destination. The former had a somewhat complicated spec (kind of an early precursor to the GL_EXT_framebuffer_object extension), but it allowed developers to use a pbuffer as a destination or as a texture object source. This meant it was possible to render into a pbuffer, and then transform it just like any other texture. The latter had a much simpler spec (almost identical to the way things are done in GLX 1.3), but it didn't have all the render-to-texture business, so it was fast for simple pbuffer->screen copies, but not great for transforming/scaling (just like on the GLX side of things). To make matters worse, at the time Nvidia supported one but not the other, while ATI supported the other but not the one (can't remember the specifics). Anyway, when it came time to port our OGL pipeline to Windows, the only extension at that time to be supported by both Nvidia and ATI was WGL_ARB_render_texture. I would liked to have gone with the much simpler WGL_ARB_make_current_read extension, since it was so similar to what I dealt with on the GLX side of things, but to support as many modern boards as possible, I had to go with WGL_ARB_render_texture. It was a pain to work through the driver issues with that spec (some of which remain today, e.g. the issue in this bug report), but it worked reasonably well. A few years have passed, and the landscape has changed a bit. Both ATI and Nvidia now support both the WGL_ARB_render_texture and WGL_ARB_make_current_read extensions. Unfortunately, Intel still does not support WGL_ARB_render_texture, which means that our OGL pipeline has not been available to approximately 50% of the market. There are other smaller players (SiS, S3, XGI) that do support WGL_ARB_render_texture, but not WGL_ARB_make_current_read, but even so, I've never had any luck getting our OGL pipeline working on those boards; the drivers are simply too buggy. The Delphi3D hardware registry has a good survey of which boards support each extension: http://www.delphi3d.net/hardware/extsupport.php?extension=WGL_ARB_render_texture http://www.delphi3d.net/hardware/extsupport.php?extension=WGL_ARB_make_current_read In JDK 6 we added support for the GL_EXT_framebuffer_object extension. We made that the default codepath (where supported), and we would like to make that our preferred approach going forward (as the rest of the industry is doing); it's fast, reliable, and cross-platform. But the fact of the matter is that we still want to support as many older boards as possible that do not support GL_EXT_framebuffer_object: - Nvidia boards earlier than the GeForce FX 5xxx series - ATI boards earlier than the Radeon 95xx series - All Intel chips Anyway, getting back to the bug at hand... In an effort to add support for Intel boards, I added a codepath that uses the WGL_ARB_make_current_read extension in place of the existing WGL_ARB_render_texture codepath. This got us mostly working on Intel GPUs (modulo a few Intel driver bugs that need to be worked out). But perhaps more interesting is that this ATI crash-on-exit bug is no longer reproducible with the WGL_ARB_make_current_read codepath, which suggests that the problem was not with pbuffers as originally hypothesized, but rather with their interaction with the WGL_ARB_render_texture extension. So this is actually a win-win situation. I also tried this codepath on an Nvidia GeForce FX 5600 and found (using SwingMark) that performance of WGL_ARB_make_current_read was a fair amount better than with the existing WGL_ARB_render_texture codepath. On a couple ATI Radeon boards, performance was just slightly better with WGL_ARB_make_current_read. So it seems that there are lots of obvious wins with using the WGL_ARB_make_current_read extension, but the question becomes: should we do a one-for-one replacement, or should we try to support both extensions going forward? While it is possible to support both extensions, the code becomes even more complicated (it was bad enough already with WGL_ARB_render_texture and GL_EXT_framebuffer_object). Also, we try as much as possible to avoid adding new system properties, and we'd probably have to add a new flag if we were to support both, which is less than ideal. In my opinion, it would be much cleaner if instead we ripped out the old WGL_ARB_render_texture code and replaced it with WGL_ARB_make_current_read. This is something we could even backport to a JDK 6 update release, since it should have minimal impact. The downsides of this approach are fairly minimal. It means that there's no hope for getting the OGL pipeline working on SiS boards (for example), until such a time comes that they support either GL_EXT_framebuffer_object or WGL_ARB_make_current_read; but from what I've seen there are too many other problems with SiS drivers to make me concerned about this. Also, it means that developers using older (pre-FBO) boards may see lower performance when trying to do bilinear scaling/transforming of VolatileImages. Performance of this case was already not much better with WGL_ARB_render_texture, so now all we would be doing is making performance of this case on Windows much more similar to what is seen on Linux/Solaris. Overall it should be a much more consistent experience when running apps on different platforms. For all of the above reasons, I'm planning to fully replace our WGL_ARB_render_texture codepath with a simpler one based on WGL_ARB_make_current_read. This means: - no extra system properties - much more straightforward code - no more crash-on-exit on pre-FBO ATI boards (solves the bug at hand) - preliminary support for Intel GPUs (additional changes may be needed in a follow-on bug fix, TBD)
09-01-2007
WORK AROUND Enable the FBO codepath using the system property: -Dsun.java2d.opengl=[T,t]rue -Dsun.java2d.opengl.fbobject=true Once 6439320 is fixed, this workaround should no longer be necessary.
19-06-2006
EVALUATION Still no fix for this issue from ATI, despite repeated attempts to have them investigate it. Fortunately, it appears that this problem is caused by a bug in their pbuffer code, so if you enable our codepath that uses FBOs instead of pbuffers, then this bug is no longer reproducible. In fact, using the FBO codepath is much more reliable overall on ATI's drivers, which is why we are planning to make the FBO codepath the default in Mustang (see 6439320 for more details). See workaround section for what you can do in the meantime...
19-06-2006
EVALUATION Not for tiger. ###@###.### 2004-06-24 I can still reproduce this on my ATI Radeon 9500 Pro with Catalyst WinXP 5.1 drivers installed. The crash seems to be originating from the VM thread as it is shutting down, so perhaps the crash happens as the driver DLLs are being unloaded when the process exits. The problem is reproducible on Tiger, Mustang, and in my single-threaded rendering workspace as well. I'll have send this to ATI for further review. ###@###.### 2005-1-22 00:30:56 GMT I've submitted a bug report to ATI (Ticket# 737-767959) regarding this issue. I'm not aware of anything that can be done in the JDK to workaround this problem. The crash only happens upon exit, so it should be harmless (other than the fact that a nasty error message is printed to the console). Note that as of Mustang-b27, the OGL pipeline is much more stable due to the single-threaded rendering changes (see 6219284), so if you've had trouble in the past with the OGL pipeline on ATI boards, things should be getting better soon. ###@###.### 2005-03-09 23:30:36 GMT
09-03-2005