Spontaneous NullPointerExceptions when firing Events

Not an answer, only suggestion from troubleshooting a very similar problem - a Swing one.

To avoid any guessing, we should look at the source code - resolve the "unknown source" part.The stacktrace you provided is lacking line numbers.This is because, the standard JRE is compiled without any debug information.Once, I believe at Sun times, one could download a separate distribution aimed at developers with all debugging symbols in place.That allowed, besides having the exact line numbers, also to set up breakpoints inside the JDK's code.

We could start investigating issues right from there.

If there is no JRE with debug symbols, You can always try compiling your own!I've once successfully compiled the "src.zip" file, which accompanied the JDK distribution. It wasn't self contained though! There were several parts missing, some Linux specific classes etc. The javac from JDK itself had problems with the file - it ran out of memory all the time. Fortunately, the Eclipse's javac compiler can deal with big codebase and partially compile classes.

Then, I ran my program with the resulting jar (the src.zip compiled with debug symbols) at the bootstrap classpath. Normally, you aren't allowed to modify anything inside "java." and "sun." packages. With bootstrap classpath, you can.

Now, back to Your certain problem: both JavaFX and OpenGL solve multithreading issues, by so called "thread confinement". That means, that everything is forcefully single-threaded. Probably, Your issues arises from the fact, that both javaFx and OpenGL has their separate threads! I'm betting, you did some interaction outside of the JavaFX's EDT. But, it's only a far fetched hypothesis. Try getting the source lines, we could go on from there.

At the time I needed the debug info, I was following the answer from here: debug jdk source can't watch variable what it is

But, all the work might not be needed! I just learned, You could attach the source files itself to the boot classpath, as specified here: https://stackoverflow.com/a/10498425

Update,

So, it seems the "node" reference is null (I doubt that "this" is null).Next step would identifying the null node and find the exact time where it was added. I'd probably put some breakpoints (or printout statements) at all sensible "addNode" invocations - from your program.

From the source code (I quickly skimmed through http://grepcode.com/file/repo1.maven.org/maven2/net.java.openjfx.backport/openjfx-78-backport/1.8.0-ea-b96.1/javafx/scene/Scene.java#2263 ) it seems, the "null" reference comes from the "dirtyNodes" array".

My best bet normally would be, that you're indirectly calling invoking the addToDirtyNodes ( http://grepcode.com/file/repo1.maven.org/maven2/net.java.openjfx.backport/openjfx-78-backport/1.8.0-ea-b96.1/javafx/scene/Scene.java#503 ) from outside the proper Thread. To my surprise, there is a first line which checks if it's called from the proper one:

Toolkit.getToolkit().checkFxUserThread();

Do You happen to see the line "Not on FX application thread; currentThread = " in your program's output?

Let's just hope, it's not a bug in JavaFX itself.

Don't modify your GUI on a non-GUI thread.

As I don't see your code I'm not sure where exactly you do it, but I had the same issue and it turns out I had passed a GUI object to a class of mine that ran a method on a non-GUI thread that was updating a GUI object. So don't do that.

As said, we also had this problem. It seems to have been caused by updating the UI from within a javafx.concurrent.Service's Task's call() method, although the updates were performed from a lambda handed over to Platform.runLater().

So I moved the UI update code from there to the Service's On-Succeeded/Failed-Handlers where it should have been in the first place. That seems to have eliminated the issue for us.