Bug 29393 - R600: libGL crashes using Lwjgl
Summary: R600: libGL crashes using Lwjgl
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: GLX (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-03 17:48 UTC by Casey Jones
Modified: 2012-09-13 11:42 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Full Java error log (32.67 KB, text/x-log)
2010-08-03 17:48 UTC, Casey Jones
Details

Description Casey Jones 2010-08-03 17:48:25 UTC
Created attachment 37560 [details]
Full Java error log

Lwjgl is a Java binding to OpenGL.  Any Lwjgl application or demo crashes libGL.so and forces the Java VM to abort.

This is the output from Java:

Could not locate symbol glXCreateContextAttribsARB
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xb00434a8, pid=19189, tid=2954230640
#
# JRE version: 6.0_21-b06
# Java VM: Java HotSpot(TM) Server VM (17.0-b16 mixed mode linux-x86 )
# Problematic frame:
# C  [libGL.so.1+0x424a8]
#
# An error report file with more information is saved as:
# /root/hs_err_pid19189.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

I'm attaching the mentioned hs_err_pid19189.log

I'm using the latest git version of Mesa with a Radeon 4850.  KMS is enabled.  I'm using the Sun/Oracle JDK, not OpenJDK or IcedTea.  I've confirmed that this works on Mesa 7.8.2.  It worked on earlier version of 7.9, but sometime in the last few weeks it stopped working.  I've been working on my own Lwjgl application, so when I ran into this error I downgraded Mesa to 7.8, but I still have 7.9 in a chroot which I can do further testing on.

There are demo applications here:
http://lwjgl.org/demos.php

I used GLGears.
To run a jnlp file from the command line:
javaws test.opengl.Gears

Thanks.
Comment 1 Casey Jones 2010-08-03 18:07:16 UTC
I also tried r600g in my chroot just for kicks, and it crashes as well.  Plain old glxgears worked, but the Lwjgl version does not.
Comment 2 Alex Deucher 2010-08-03 18:17:09 UTC
Can you bisect mesa to see what commit broke it?
Comment 3 Casey Jones 2010-08-03 19:26:51 UTC
This is what I got.

f8d81c31cee30821da3aab331a57f484f6a07a5d is the first bad commit
commit f8d81c31cee30821da3aab331a57f484f6a07a5d
Author: Nick Bowler <nbowler@draconx.ca>
Date:   Wed Jul 14 12:01:49 2010 -0400

    dri2: Track event mask in client code.
    
    When direct rendering is being used, DRI2 BufferSwapComplete events are
    sent unconditionally to clients, even if they haven't been requested.
    This causes error messages to be printed by every freeglut application
    of the form
    
      freeglut (./gears): Unknown X event type: 104
    
    and might confuse other clients.
    
    This is a fixed up version of the patch by Jesse Barnes, which drops
    BufferSwapComplete events if they are not requested by clients.
    
    Fixes fdo bug 27962.
    
    Signed-off-by: Nick Bowler <nbowler@draconx.ca>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Comment 4 Alex Deucher 2010-08-03 21:21:23 UTC
This looks like a glx bug rather than a driver bug.
Comment 5 Casey Jones 2010-09-11 21:31:11 UTC
This bug went away.  A while ago it only crashed when the application exited, but it ran fine before you closed the window.  Now it doesn't crash at all.

I'll leave this open though in case a developer has anything to say.
Comment 6 Andreas Boll 2012-09-13 11:42:04 UTC
(In reply to comment #5)
> This bug went away.  A while ago it only crashed when the application exited,
> but it ran fine before you closed the window.  Now it doesn't crash at all.
> 
> I'll leave this open though in case a developer has anything to say.

Closing.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.