1

I'm experiencing something really strange, and I don't know what's causing it at all. This is the problematic line of code:

BufferedImage out = new BufferedImage(256, 256, BufferedImage.TYPE_INT_RGB);

Upon calling this, all threads freeze and everything stops. I've tried putting this in its own thread and the main thread, the same thing occurs. I am using LWJGL3, so that might be an issue, but I don't see how it could be.

Edit: Does not occur in a blank project without LWJGL in or out of -XstartOnFirstThread

CJ Burkey
  • 385
  • 1
  • 14
  • 1
    How do you know that's where the program halts? Have you checked the call stack of each thread with a debugger? – Radiodef Jun 06 '17 at 01:04
  • @Radiodef I have not checked any call stacks, but I have this code to debug: `System.out.println("Before");` `BufferedImage out = new BufferedImage(256, 256, BufferedImage.TYPE_INT_RGB);` `System.out.println("After");` I only see "Before" in the console. – CJ Burkey Jun 06 '17 at 01:06
  • 1
    Well, the next thing I would do is inspect the call stacks of each thread with a debugger to verify they have indeed frozen and where they all are. – Radiodef Jun 06 '17 at 01:10
  • 1
    @Radiodef It seems that `ColorModel.loadLibraries` is where the thread just stops. Inside of that method, `java.security.AccessController.doPrivileged` is called. Edit: I even tried created another thread to print memory usage into the console repeatedly, but even that thread locks up. – CJ Burkey Jun 06 '17 at 01:21
  • 1
    instantiate BufferedImage inside a simple main method, without adding lwjgl and other libraries to build path. does it work on its own? – yılmaz Jun 06 '17 at 01:24
  • @yılmaz Yes, that works fine. I'll try calling the method earlier, see if that allows it to work. – CJ Burkey Jun 06 '17 at 01:26
  • This just gets weirder and weirder. Moving the method to the beginning of the program induces a native crash, specifically, this one: `SIGSEGV (0xb) at pc=0x000000012741f55b, pid=7452, tid=0x0000000000000307` – CJ Burkey Jun 06 '17 at 01:38
  • Please provide a minial example which reproduces your problem and post it here so we can try. – eldo Jun 06 '17 at 11:42
  • @eldo All I need to do is call `new BufferedImage()` from _anywhere_ in my program to lock all threads. I'm using the "everything" package from LWJGL, version 3.1.3-SNAPSHOT. The only exception is if the call put before the GLFW initialization, at that point, I get a native crash. It makes me feel as if it's a Java problem. I just tried moving it to the front again, same version and everything, but this time, GLFW just never initialized. No threads froze and all methods are called, but GLFW just never opened. – CJ Burkey Jun 06 '17 at 16:39
  • According to [THIS](https://stackoverflow.com/questions/39809275/creating-a-bufferedimage-causes-glfw-in-the-lwjgl-to-lock-up-java) post, it's not just me. It's something with GLFW, Mac, and the fact GLFW has to run on the main thread. One user suggested using `-Djava.awt.headless=true` to prevent the native calls of ColorModel to freeze AWT, but it still occurs. I tried keeping the argument there, but setting it to false, and _sometimes_ it works, but only partially. The window that opens renders and everything, but it doesn't accept any input. No keyboard or mouse input. – CJ Burkey Jun 06 '17 at 16:44

1 Answers1

2

Ok! I found the solution. Turns out, all it takes is the following JVM argument: -Djava.awt.headless=true You also have to make sure that you aren't running it in the main thread, you have to do it outside of the thread where GLFW is initialized.

All of this only applies if you are running LWJGL on Mac, Linux and Windows don't have this issue.

CJ Burkey
  • 385
  • 1
  • 14