Segfault on unmount when running two file systems in same JVM

[gbigwood]

I mount two file systems (Filesystem3) inside a unit test.

When I unmount the first file system: Runtime.getRuntime().exec(new String[] { "bash", "-c", "umount " + mountPointOfFirstFs) });

I get a segfault:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000015e23acec, pid=18758, tid=35075
#
# JRE version: 7.0_15-b03
# Java VM: Java HotSpot(TM) 64-Bit Server VM (23.7-b01 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# C  [libjavafs.jnilib+0xfcec]  get_env+0x2c
....
....

This seems to be because of the code in native_impl.c after it returns from the fuse_main loop inside the function Java_fuse_FuseMount_mount. The function cleans up the threadgroup, fuseFS and associated classes from the java env.

If I edit native_impl.c so that I return immediately after the fuse_main function finishes I can avoid the segfault, and unmount both FileSystems. I assume, however, that this creates a memory leak.

(Note: I am assuming that was the suggested method for unmounting, judging by the other github issue https://github.com/dtrott/fuse4j/issues/5)

[dtrott]

My original intent was for each file system to be serviced by a separate JVM. Hence the heavy use of global state inside the native library (it didn't matter if there was only one filesystem).

I think the native code can be refactored to count the number of times mount is called such that it only cleans up after the last filesystem has been unmounted - probably a quicker refactor than getting rid of all the global state....

However I want to tackle issue 9 first as I think I will need to create a new posix thread in order to ensure I can destroy the JVM from the correct thread when using the native launcher.

My primary concern for this issue is that I need to ensure all native threads are attached to the same Java ThreadGroup (which is passed as a mount argument) - that may be as simple as making the ThreadGroup static but I need to give both issues some thought.

[gbigwood]

Thanks for getting back regarding this :)

The only reason I ended up with more than one file system inside a JVM was due to our unit tests. A count would work I think. For now I simply do not free for N-1 filesystems.