Issue2163

PySystemState initStaticFields and initBuildins initialize PyTypes before Py.False and Py.True are initialized. Intermittently this leads to ExceptionInInitializerError thrown due to a NullPointer exception in PyObject._cmpeq_unsafe.

Stack trace:

Exception in thread "main" java.lang.ExceptionInInitializerError	at org.python.core.PySystemState.initStaticFields(PySystemState.java:912)
	at org.python.core.PySystemState.doInitialize(PySystemState.java:882)
	at org.python.core.PySystemState.initialize(PySystemState.java:800)
	at org.python.core.PySystemState.initialize(PySystemState.java:750)
	at org.python.core.PySystemState.initialize(PySystemState.java:743)
	at org.python.util.jython.run(jython.java:150)
	at org.python.util.jython.main(jython.java:129)
Caused by: java.lang.NullPointerException
	at org.python.core.PyObject._cmpeq_unsafe(PyObject.java:1362)
	at org.python.core.PyObject._eq(PyObject.java:1456)
	at org.python.core.PyObject.equals(PyObject.java:244)
	at java.util.HashMap.put(HashMap.java:475)
	at java.util.HashSet.add(HashSet.java:217)
	at org.python.core.PyType.fromClass(PyType.java:1317)
	at org.python.core.PyType.fromClass(PyType.java:1275)
	at org.python.core.PyEllipsis.<clinit>(PyEllipsis.java:14)
	at java.lang.J9VMInternals.initializeImpl(Native Method)
	at java.lang.J9VMInternals.initialize(J9VMInternals.java:236)
	... 7 more

Root cause of the problem is that PyType.fromClass stores all types in a HashSet exposedTypes. If during initialization two PyTypes end up having the same hashCode, the HashSet uses the method equals. Some methods called by PyObject.equals return Py.True/Py.False (see PyObject._is) which aren't initialized as first PyTypes...

We have seen this error only on AIX systems and with an application that generated +10000 Jython runs per day.

One fix would be to ensure PyTrue and PyFalse get initialized right at the start of the PyType initialization. See the attached.

public static synchronized PyType fromClass(Class<?> c) {
    	
    	// HP Debug
    	if (Py.False == null) Py.False = new PyBoolean(false);
    	if (Py.True == null) Py.True = new PyBoolean(true);
    	
        return fromClass(c, true);
    }

This isn't elegant. There should be a better way to fix the issue.

Thanks, this is an important problem for us to fix.

Target beta 4

In general, PySystemState#initStaticFields is problematic code.

Also, it's not clear to me that most of these fields needs to be mutable vs final. Example: even if the Python semantics do allow True to be set to some other value, it's not really Py.True that's changing, it's instead changes in the entries in __builtin__.__dict__ (see __builtin__#fillWithBuiltins)

This is just the sort of refactoring we would like to do before the final beta, which should be beta 4

So the key piece will be to move the initialization to org.python.core.Py, without breaking the fact that PyType depends on some of the initialization there as well. Lazy initialization should suffice.

Should be fixed as of https://hg.python.org/jython/rev/1e8dd809df28

Note this will not change for 2.5 because it breaks the Java API, so updating tag