JDK-6353478 : Linux ATI proprietary driver related native crash OpenGL
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: linux
  • CPU: x86
  • Submitted: 2005-11-21
  • Updated: 2011-02-16
  • Resolved: 2005-12-16
Related Reports
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.6.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-rc-b61)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b61, mixed mode, sharing)


FULL OS VERSION :
Linux ip173 2.6.13-15-default #1 Tue Sep 13 14:56:15 UTC 2005 i686 i686 i386 GNU/Linux


EXTRA RELEVANT SYSTEM CONFIGURATION :
SUSE 10.0
ATI radeon 9700 mobility
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: MOBILITY RADEON 9700 Generic
OpenGL version string: 1.3.5461 (X4.3.0-8.19.10)


A DESCRIPTION OF THE PROBLEM :
There seem to be a problem with using GLX from native code on linux when running with the ATI proprietary X drivers and mustang. I've attached a small sample that show that even calling a simple function like glXGetProcAddress crashes with a SIGSEGV. These crashes occur when running LWJGL applications with mustang. Some observations:

1. It works with 1.5.0_0x releases
2. Using the built in, open source ati driver "radeon" instead of the proprietary one, "fglrx", the crashes disappear.
3. I've tried not to link directly with libGL, but instead dlopen() it, acquire the glXGetProcAddress address with dlsym and calling that, with the same result.

Unfortunately, I'm unable to simplify the test case even more, so I can't tell if this is a problem with mustang or a problem with the ati drivers. For what it's worth, I've seen this exact crash while using several builds of both the ati drivers and mustang. I've marked the bug "Can not make any progress until this bug is resolved." since that's literally true, should the current mustang builds turn into production builds.

THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Yes

THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Compile and run the test case with this script:
$JAVA_HOME/bin/javac test.java
$JAVA_HOME/bin/javah test
gcc -I$JAVA_HOME/include -I$JAVA_HOME/include/linux -Wall -shared -o libtest.so -fPIC -lGL test.c
$JAVA_HOME/bin/java -Djava.library.path=. test


EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected result:
The problem should simply print out an address, like

Address: 0x4274c890

and then exit normally.

Actual results:
A SIGSEGV occurs.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
#
# An unexpected error has been detected by Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00001eae, pid=7099, tid=1075222208
#
# Java VM: Java HotSpot(TM) Client VM (1.6.0-rc-b61 mixed mode, sharing)
# Problematic frame:
# C  0x00001eae
#
# 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.

---------- BEGIN SOURCE ----------
test.java:
----------------

public class test {
    public static void main(String[] args) {
        System.loadLibrary("test");
        doStuff();
    }

    private static native void doStuff();
}

test.c:
----------

#include <jni.h>
#include <GL/glx.h>
#include "test.h"

JNIEXPORT void JNICALL Java_test_doStuff(JNIEnv * env, jclass clazz) {
    void *address = glXGetProcAddress((GLubyte*)"glMultiTexCoord1f");
printf("Address: %p\n", address);
}

run script:
-----------------
$JAVA_HOME/bin/javac test.java
$JAVA_HOME/bin/javah test
gcc -I$JAVA_HOME/include -I$JAVA_HOME/include/linux -Wall -shared -o libtest.so -fPIC -lGL test.c
$JAVA_HOME/bin/java -Djava.library.path=. test

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Use java 1.5 or earlier.

Comments
EVALUATION Customer reported that using this flag worked around the issue. use LD_ASSUME_KERNEL 2.4.1. I beleive this is a duplicate of a recent bug that was put back.. Customer is testing 1.6.0-b61. If customer does not use flag crash occurs.. I beleive this is related to NPTL and correctness of libraries being loaded.. non tls being loaded with tls libraries. See stack traces attached.
23-11-2005

WORK AROUND use LD_ASSUME_KERNEL 2.4.1 fixed the issue
23-11-2005