Sometimes when messing with libgdx, it appears
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f95727c8999, pid=6955, tid=140278980540160
#
# JRE version: 7.0_09-b05
# Java VM: Java HotSpot(TM) 64-Bit Server VM (23.5-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [libc.so.6+0x80999]
ADT Bundle 21, Linux Mint 14 Mate 64-bit, libgdx 0.9.8, Java 64 1.7.0_09 (compile target 1.6), vga driver amd 12.11.beta11.
That’s a crash in a native method. The libgdx people might be interested in seeing that. Going to need the full dump though, so stick it on the pastebin perhaps?
That’s full dump. Well since it’s about native, I guess I just sit here waiting.
For more info, the game windows in question will still stick there. It only shows title bar with transparent content. Eclipse’s terminate takes a while but won’t do so I have to pkill it.
EDIT: new throw up, now with red color (previous dump is normal-colored in eclipse)
*** glibc detected *** /usr/lib/jvm/jdk1.9.0/bin/java: corrupted double-linked list: 0x00007fbd1c6118f0 ***
Errrr libc.so.6 is the GNU C standard library implementation. Sounds like something is either calling it wrong or you have a corrupt installation of that :S
Dump on my 1st post always shows up on exiting while the next shorter dump appears randomly.
You should have a file named hs_err_pid*.log in the directory where you ran it (probably your project root in eclipse). That will have the full dump in it, and that’s what the GDX folks would need. My guess is it’s driver-related and there’s nothing they can do, but it’s always good to know.
Also, if you actually “messed with libgdx” in a way, that is: Gdx.gl.* or Gdx.gl2.* or anything like that in terms of GL calls, then it’s probably your fault 
@sproingie
nope, no where (checked on root of 3 projects).
@matheus23
Not really I just called Gdx.gl.[put the chaos here] but that’s only because I mixed up ShapeRenderer plus SpriteBatch. It’s not good. So I removed the ShapeRenderer and only messing GL with clear buffer and alpha bend.
Er, JDK1.9…?
Cas 
I get consistent segfaults when exiting on Linux (Ubuntu 12.04) with the AMD graphics drivers, though this is in libX11 (google LWJGL XQueryExtension). I wonder if your bug might have similar causes (I seem to recall reading it’s caused by a thread race on exit). Do other LWJGL-based applications work OK on your system?
What about home directory?
That is odd :DD
He’s from the future!! :o :o
Yes I am from future, where you can create class inside for/while/if blocks ;D and libgdx can port to PS4, 720, wiiU, etc
@nsigma
Nope. There is .java/ dir but not there too. Thread race? hmm it must not be my fault (yet), I haven’t even put audio.
java version "1.7.0_09"
Java(TM) SE Runtime Environment (build 1.7.0_09-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.5-b02, mixed mode)
My execution result of “java -version”. Is the 1.9.0 my built-in openjdk?!
Errr…
if(mySpecialVariable > 5) {
class SuperNestedClass {
private int num;
SuperNestedClass(int num) {
this.num = num;
}
}
SuperNestedClass snc = new SuperNestedClass(mySpecialVariable);
doSomethingWithObject(snc);
}
That is valid code…
Yeah I know, that why the ;D was there ;D
I solved this by myself. The evil is a non-safe thread, for example like changing Screen based on input events (not from render()).
After done with java4k judging I go back to this project and it happens again 
I have made it safer, by using boolean flag to change screen on render loop().
More info, it always happens on 3rd attempt to change screen. For example,
menu -> game -> score -> (hell broke) menu
menu -> game -> menu -> (world burn) game
I have tried to disable “compressed oops” with runtime flag although I don’t know WTH it is. Seriously, this thing can be googled easily but no one solution.