FormatTools constructor does not call jutil.attach()

Hi folks,

I’m trying to get version 11418 now, in the same linux cluster environment as my previous posts http://forum.image.sc/t/11418-wx-python-related-crash/12913/1.

I’ve found that in the method make_format_tools_class() in CellProfiler.bioformats.formatreader.py, the first line in the format tools constructor is to CellProfiler.utilities.jutil.py function get_env(). However, jutil.attach() has not been called, despite the function comment saying that this is explicitly necessary.

Intercepted exception while running module Traceback (most recent call last): File "/usr/cp2/CellProfiler/cellprofiler/pipeline.py", line 328, in run self.module.run(self.workspace) File "/usr/cp2/CellProfiler/cellprofiler/modules/loadimages.py", line 2186, in run image = provider.provide_image(workspace.image_set) File "/usr/cp2/CellProfiler/cellprofiler/modules/loadimages.py", line 3075, in provide_image wants_max_intensity = True) File "/usr/cp2/CellProfiler/bioformats/formatreader.py", line 330, in load_using_bioformats FormatTools = make_format_tools_class() File "/usr/cp2/CellProfiler/bioformats/formatreader.py", line 46, in make_format_tools_class class FormatTools(object): File "/usr/cp2/CellProfiler/bioformats/formatreader.py", line 51, in FormatTools env = jutil.get_env() File "/usr/cp2/CellProfiler/cellprofiler/utilities/jutil.py", line 337, in get_env return __thread_local_env.env AttributeError: 'thread._local' object has no attribute 'env'

I could patch this myself, but am not sure of the best way to do so. Could jutil.get_env call attach directly? Is there a way to query the jutil module to see if the vm is attached? I can upload the pipeline that I use to generate this error if required.

Thanks,

Lee.

Looking at the code more closely, it seems to me that the call to jutil.get_env in the FormatTools constructor should in fact be a call to jutil.attach(). Both return the environment from the thread of the (now presumably attached) java vm:

[code] class FormatTools(object):
’’'A wrapper for loci.formats.FormatTools

    See http://hudson.openmicroscopy.org.uk/job/LOCI/javadoc/loci/formats/FormatTools.html
    '''
    env = jutil.get_env()
    klass = env.find_class('loci/formats/FormatTools')
    ...

[/code]

Could become instead

[code] class FormatTools(object):
’’'A wrapper for loci.formats.FormatTools

    See http://hudson.openmicroscopy.org.uk/job/LOCI/javadoc/loci/formats/FormatTools.html
    '''
    env = jutil.attach()
    klass = env.find_class('loci/formats/FormatTools')
    ...

[/code]

If init.py has been run in CellProfiler/bioformats then the VM should have been started, and waiting to be attached. What do you folks think?

Lee.

Hi Lee,
Sorry, it was a recently introduced bug that I’ve fixed in revision 11440. The main thread calls jutil.attach() shortly after starting the JVM and calls jutil.detach() before exiting. The call to open the image was happening in a worker thread. Ideally, you’d like to call jutil.attach() at the start of the worker thread and jutil.detach() at the end to keep from having to call the pair througout your code whenever a Java object was being used, but BioFormats and the JVM are optional, so I wanted to refrain from doing that. I’ve enclosed the file opening routine, bioformats.formatreader.load_using_bioformats() in calls to jutil.attach() and jutil.detach() and that should take care of the problem, even if it isn’t the most elegant solution.

Thanks for pointing it out, hope this makes everything work for you.

–Lee