Author Hardy
Recipients Hardy
Date 2018-08-09.22:09:43
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>

We have an application which hosts plugins ( A plugin is a mixture of Jython scripts and some jars containing java classes). Since plugin code can potentially bring in java types with same names but of different versions and since PythonInterpreter instances even with different PySystemState objects are not 100 % independent of each other. We load each plugin along with Jython.jar under a dedicated URLClassLoader derived custom Child first class loader instance, which delegates type resolution to be routed to these jars or other child first class loader instances associated with this plugin before routing to class loaders higher up the food chain.

Once the child class loaders for the plugins have been constructed on lets call it Thread A.

We load a java class using one of these child first class loader (non Jython one), which creates preset type and which creates a dedicated worker thread for jython interpretation (lets call this the worker thread).

we call PySystemState.initialize (with some of the java jars on the syspath) and create a PythonInterpreter instance on the worker thread. Then start executing our scripts.

In order to unload a plugin.
I close the interpreter.
set interpreter locals to Py.newStringMap()
close all SyspathArchive found at systemState.path
Followed by Py.getSystemState().close()
wait for the worker thread to exit.

Once the worker thread has exited we then call close on the ChildFirstClassLoader (just invokes URLClassLoader's implementation) or let it get garbage collected, i have experimented with both.

We run an instance of the classloader leak prevention library to host the childfirstclassloader so various cleanups are performed which may otherwise leak the classloader instances.

For most part this works quite well but every now and then i am finding though that the process seg faults due to what appears to be something related to jnr-ffi library's usage in Jython.
It appears Jruby also suffered from the same problem due to this library.

I am attaching along the JVM crash dumps from our experiments. I am using Jython 2.7.0.

Any suggestions how to address this issue or what is causing this ? 

PS : Even any information/explanation on how the native library life cycles are expected to work in Jython's implementation will be a great help.
Date User Action Args
2018-08-09 22:09:43Hardysetmessageid: <>
2018-08-09 22:09:43Hardysetrecipients: + Hardy
2018-08-09 22:09:43Hardylinkissue2701 messages
2018-08-09 22:09:43Hardycreate