Created attachment 42093 [details]
Java error report
I don't know if this is related to the r600 driver or not but I thought there was a good chance. I recently bought the Minecraft beta, and once I get into a game I have between 15 seconds and 3 minutes before the game suddenly crashes. I see this in the terminal:
# A fatal error has been detected by the Java Runtime Environment:
# SIGSEGV (0xb) at pc=0xb76dba86, pid=7542, tid=1836055408
# JRE version: 6.0_23-b05
# Java VM: Java HotSpot(TM) Server VM (19.0-b09 mixed mode linux-x86 )
# Problematic frame:
# C [libc.so.6+0x75a86] memcpy+0x46
# An error report file with more information is saved as:
# If you would like to submit a bug report, please visit:
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
The specified file is attached. Looking at the stack trace:
C [libc.so.6+0x75a86] memcpy+0x46
C [liblwjgl.so+0x4556d] Java_org_lwjgl_opengl_GL11_nglDrawArrays+0x1d
It looks like r600_dri.so may be causing or at least helping the problem. My graphics card is an ATI Mobility Radeon 4100. I'm using Sabayon linux, fully updated as of today.
Please let me know how I can help figure out what is wrong.
Looks similar to bug 32654.
Unfortunately, these Java error reports don't contain much tangible information about where in *_dri.so the crashes are occurring. Something like a full gdb backtrace from the crash would be ideal, but not being a Java expert, I lack the knowledge how you could get that or if it's even possible. Alternatively, something like addr2line might be useful to get at least a little more information.
I'm not sure if Java could cause it to look like that, but at first sight I'd say the driver is simply missing debug symbols. Also, is that classic r600 or gallium, and which version?
(In reply to comment #2)
> I'm not sure if Java could cause it to look like that, but at first sight I'd
> say the driver is simply missing debug symbols. Also, is that classic r600 or
> gallium, and which version?
Classic. What's the difference? And how would I figure out what version?
I'm trying to figure out how to use addr2line to get some better line numbers, and I'll look into debugging java crashes.
(In reply to comment #3)
> Classic. What's the difference? And how would I figure out what version?
glxinfo, unless you're running 32-bit Java on 64-bit Linux. You'll probably want to try to reproduce it with the current git version of the driver though.
(In reply to comment #4)
> (In reply to comment #3)
> > Classic. What's the difference? And how would I figure out what version?
> glxinfo, unless you're running 32-bit Java on 64-bit Linux. You'll probably
> want to try to reproduce it with the current git version of the driver though.
Okay, I rebuilt xorg-drivers with the debug flag, and now I'm getting this:
java: vbo/vbo_save_api.c:221: map_vertex_store: Assertion
in the terminal when it crashes like it did before. A quick google search shows
that this error is actually a known bug of Minecraft, but it also shows up in
Oolite and probably elsewhere.
Oddly enough I seem to be unable to use ATI's opengl, I have to use mesa. I
don't know if that is any help.
Addr2line doesn't seem to be able to give useful information from the non-debug
drivers, and I haven't tried it on the new ones because I don't think the
addresses would be the same. I'm still not quite sure how to attach gdb to the
java process to attempt to debug this, but I'm looking.
I'll attach a dump of my glxinfo.
Created attachment 42136 [details]
glxinfo &> glxinfo.txt
Okay, I finally figured out how to attach gdb to java, and after installing the debug version of glibc and the latest mesa from git, I got this backtrace from Minecraft:
#0 0xffffe430 in __kernel_vsyscall ()
#1 0xb757e401 in raise () from /lib/libc.so.6
#2 0xb757fb42 in abort () from /lib/libc.so.6
#3 0xb6f1d8df in os::abort(bool) () from /opt/sun-jre-bin-220.127.116.11/lib/i386/server/libjvm.so
#4 0xb705dec1 in VMError::report_and_die() ()
#5 0xb6f2487c in JVM_handle_linux_signal ()
#6 0xb6f207c4 in signalHandler(int, siginfo*, void*) ()
#7 <signal handler called>
#8 0xb75c9936 in memcpy () from /lib/libc.so.6
#9 0x00000001 in ?? ()
#10 0x6ca68f89 in _save_wrap_filled_vertex (ctx=<value optimized out>)
#11 0x6c9cd6ca in _ae_ArrayElement (elt=2727) at main/api_arrayelt.c:1672
#12 0x6ca6c7a9 in _save_OBE_DrawArrays (mode=4, start=0, count=3942) at vbo/vbo_save_api.c:949
#13 0x6d69b56d in Java_org_lwjgl_opengl_GL11_nglDrawArrays ()
#14 0xb395d8fb in ?? ()
#15 0xb396f714 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Let me know what else I can do to help.
So, I've been digging around with DDD in the crash, and I've found something that looks pretty interesting to me. In _ae_ArrayElement(GLint) in main/api_arrayelt.c the debugger is showing that actx and aa->array are null, and that aa->offset is -1, yet the breakpoint is line 1672 inside a for loop where supposedly aa->offset != -1.
Backtrace seems to point to bug in java jvm or gl stuff or application, closing this bug as it's not ours