On some machines, creating a new Image and calling getGraphics() on it causes lwjgl to enter into some kind of faulty state that crashes when swapping buffers. Any idea what causes this and how to make Slick clean up after itself properly?

Reproduction code:

package crashrepro;

import org.newdawn.slick.*;

public class CrashRepro extends BasicGame {
    public static void main(String[] args) throws Exception {
        CrashRepro cr = new CrashRepro("CrashRepro");
        // Crash only happens in fullscreen mode.
        AppGameContainer agc = new AppGameContainer(cr, 800, 600, true);

    public CrashRepro(String title) { super(title); }

    public void init(GameContainer gc) throws SlickException {}

    public void update(GameContainer gc, int i) throws SlickException {}

    public void render(GameContainer gc, Graphics grphcs) throws SlickException {
        Image img = new Image(128, 128);
        img.getGraphics(); // This crashes the game.

Stack trace:

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.lwjgl.opengl.WindowsContextImplementation.nSwapBuffers(Ljava/nio/ByteBuffer;)V+0
j  org.lwjgl.opengl.WindowsContextImplementation.swapBuffers()V+35
j  org.lwjgl.opengl.ContextGL.swapBuffers()V+3
j  org.lwjgl.opengl.DrawableGL.swapBuffers()V+0
j  org.lwjgl.opengl.Display.swapBuffers()V+39
j  org.lwjgl.opengl.Display.update(Z)V+44
j  org.lwjgl.opengl.Display.update()V+1
j  org.newdawn.slick.AppGameContainer.gameLoop()V+78
j  org.newdawn.slick.AppGameContainer.start()V+17
j  crashrepro.CrashRepro.main([Ljava/lang/String;)V+27
v  ~StubRoutines::call_stub

1 Answer 1


Turns out to have been caused by a lwjgl bug I reported here.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .