JDK-8095034 : NullPointerException at javafx.scene.Scene$ScenePulseListener.synchronizeSceneNodes
  • Type: Bug
  • Component: javafx
  • Sub-Component: scenegraph
  • Affected Version: 8
  • Priority: P4
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2014-02-17
  • Updated: 2022-12-05
  • Resolved: 2014-02-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8u20Resolved
Related Reports
Blocks :  
JDK-8098064 - Exceptions by Invalidation- or ChangeListeners are not caught
Relates :  
JDK-8298104 - NPE on synchronizeSceneNodes()
Description
Investigation of RT-35400 highlighted this NullPointerException:

Exception in thread "JavaFX Application Thread" java.lang.NullPointerException
at javafx.scene.Scene$ScenePulseListener.synchronizeSceneNodes(Scene.java:2282)
at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2405)
at com.sun.javafx.tk.Toolkit$3.run(Toolkit.java:322)
at com.sun.javafx.tk.Toolkit$3.run(Toolkit.java:320)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:320)
at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:349)
at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:479)
at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:460)
at com.sun.javafx.tk.quantum.QuantumToolkit$13.run(QuantumToolkit.java:327)
at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95)
at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at com.sun.glass.ui.win.WinApplication.access$300(WinApplication.java:39)
at com.sun.glass.ui.win.WinApplication$4$1.run(WinApplication.java:112)
at java.lang.Thread.run(Thread.java:744) 


Quoting Anthony Petrov:
"Note that the corresponding code in Scene.java that throws the exception is now located at another lines due to other changes to that file. Nevertheless, the piece of code that actually throws it looks like this:

                for (int i = 0 ; i < dirtyNodesSize; ++i) {
                    Node node = dirtyNodes[i];
                    dirtyNodes[i] = null;
                    if (node.getScene() == Scene.this) {
                            node.impl_syncPeer();
                        }
                    }

There's a missing null check before using the node variable in the if() condition."
Comments
RT-33633 is fixed. Yves, can you please verify if this is still an issue?
25-02-2014
The real cause of this is an Exception thrown from the scenebuilder code. It is propagated up to the Parent.children.onChange() method (from Node.sceneProperty() change listener) where it's not caught which leads to broken invariance of the Parent. This later leads to exception being thrown during the synchronization which in turn fails to reset the dirty node counter (and there are already null values in the list). Therefore, the next pulse will throw a NPE. Anyhow, user exceptions should not break internal FX code, so we need to make FX properties/collections more robust and do not throw exceptions on property.set() or collection modifications. Also in case of Exception in a listener, no listeners should be skipped. Such exceptions should be logged, but never propagated anywhere IMO. This is covered by RT-33633. I think this is a major flaw and should be considered for 8u20, so I'm going to retarget RT-33633 to that release.
18-02-2014
I would worry that adding a null check would be fixing a symptom and not the real cause. Checking for null should only be necessary if either: A) null nodes are added to the list (which they should not be); or B) the synchronizeSceneNodes method was ever called reentrantly (which would probably cause other problems, and doesn't seem to be the case here). Null values are transiently added by the loop while they are being processed, but then the count is set to 0 at the end of the loop. And there is no valid reason I know of for adding a null otherwise.
17-02-2014