OpenModelica FMUs fail to exit when the shared library is opened with JNA

[cxh@…]

The summary is that under Linux and Mac OS X, it seems like exiting a FMU hangs when the shared library is opened with JNA's NativeLibrary.getInstance().

We've also seen it hang when calling dlopen() via Swig. Reproducing the dlopen()/Swig failure is a little tricky, so below is the error using NativeLibrary.getInstance().

Below is the OpenModelica file:

bash-4.1$ cat Simple.mo
within ;
model Simple "just a simple model - Compilation etc."

parameter Real p = 0.1;
Real x(start = 0.5);
Real z;

equation

der(x) = p * x;
z = x * x;

annotation (uses(Modelica(version="3.2")));

end Simple;

Below is the file that we use to create the fmu:

bash-4.1$ cat Simple.mos
loadModel(Modelica);
loadFile("Simple.mo");
translateModelFMU(Simple);

Below is the test file:

bash-4.1$ cat OmcFmuExitBug.java
import com.sun.jna.NativeLibrary;
public class OmcFmuExitBug {

public static void main(String [] args) throws Throwable {

System.out.println("This class illustrates a bug where an FMU");
System.out.println("generated by OpenModelica fails to exit.");
System.out.println("When this file is run, it hangs on exiting.");
NativeLibrary.getInstance("Simple.so");

}

}

This is under RHEL with Java 1.7.0_25, but it also fails under Darwin.

bash-4.1$ uname -a
Linux sisyphus.eecs.berkeley.edu 2.6.32-358.14.1.el6.x86_64 #1 SMP Mon Jun 17 15:54:20 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux
bash-4.1$ java -version
java version "1.7.0_25"
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)

To create the shared library, I ran
omc Simple.mos

The version of OpenModelica was:
bash-4.1$ omc -log
OpenModelica Compiler 1.9.0 beta4+dev (r15622)
...

If we run the model, then it does not exit, I have to hit C-z. I'm running under emacs, so this shows up as C-c C-z:

bash-4.1$ java -classpath .:jna.jar OmcFmuExitBug
This class illustrates a bug where an FMU
generated by OpenModelica fails to exit.
When this file is run, it hangs on exiting.

C-c C-z

[1]+ Stopped java -classpath .:jna.jar OmcFmuExitBug
bash-4.1$ bg
[1]+ java -classpath .:jna.jar OmcFmuExitBug &
bash-4.1$ jobs
[1]+ Running java -classpath .:jna.jar OmcFmuExitBug &

Oddly, ps does not show the job?
bash-4.1$ ps auxgww | grep Omc
cxh 16881 0.0 0.0 103244 848 pts/3 S+ 16:14 0:00 grep Omc

Oddly, if I run strace, then I can see that the job is sleeping in ps.

cxh 16938 1.5 0.0 4400 816 pts/3 S 16:20 0:00 strace -f -o strace.out java -classpath .:jna.jar OmcFmuExitBug

The "S" means

S Interruptible sleep (waiting for an event to complete)

To run strace, I used:
strace -f -o strace.out java -classpath .:jna.jar OmcFmuExitBug

I can see that the Simple.so file was loaded in to process 16749
16749 open("x86_64/Simple.so", O_RDONLY <unfinished ...>

Wolfgan Muller, cc'd here wrote:
"If I strace that under linux, I see that one thread is waiting for a lock to be lifted, presumably by the thread that also loaded the shared library if I look at the earlier stuff."

Below is the tail end of my run of strace. I'm not sure if it shows the lock or not. I'll include the full version as an attachment.

16749 <... futex resumed> ) = 0
16765 _exit(0) = ?
16749 futex(0x7f2b422b9f00, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
16761 <... futex resumed> ) = 0
16749 <... futex resumed> ) = 1
16749 mmap(0x7f2b4230c000, 12288, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|M\
AP_NORESERVE, -1, 0) = 0x7f2b4230c000
16749 futex(0x7f2b3c09a254, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f2b3c09a250, {FUTEX_OP\
_SET, 0, FUTEX_OP_CMP_GT, 1} <unfinished ...>
16761 mmap(0x7f2b380c4000, 12288, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|M\
AP_NORESERVE, -1, 0 <unfinished ...>
16758 <... futex resumed> ) = 0
16749 <... futex resumed> ) = 1
16761 <... mmap resumed> ) = 0x7f2b380c4000
16758 futex(0x7f2b3c09a228, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
16749 futex(0x7f2b3c09a228, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
16761 rt_sigprocmask(SIG_SETMASK, [QUIT], <unfinished ...>
16758 <... futex resumed> ) = -1 EAGAIN (Resource temporarily unavaila\
ble)
16749 <... futex resumed> ) = 0
16761 <... rt_sigprocmask resumed> NULL, 8) = 0
16758 futex(0x7f2b3c09a228, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
16749 futex(0x7f2b3c008654, FUTEX_WAIT_PRIVATE, 3, NULL <unfinished ...>
16761 madvise(0x7f2b380c4000, 1028096, MADV_DONTNEED <unfinished ...>
16758 <... futex resumed> ) = 0
16761 <... madvise resumed> ) = 0
16758 mprotect(0x7f2b42309000, 4096, PROT_READ <unfinished ...>
16761 _exit(0) = ?
16758 <... mprotect resumed> ) = 0
16758 mprotect(0x7f2b42309000, 4096, PROT_READ|PROT_WRITE) = 0
16758 mprotect(0x7f2b4230a000, 4096, PROT_NONE) = 0
16758 futex(0x7f2b3c008654, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f2b3c008650, {FUTEX_OP\
_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
16749 <... futex resumed> ) = 0
16758 madvise(0x7f2b10192000, 1028096, MADV_DONTNEED <unfinished ...>
16749 futex(0x7f2b3c008628, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
16758 <... madvise resumed> ) = 0
16749 <... futex resumed> ) = 0
16758 _exit(0) = ?
16749 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
16749 unlink("/tmp/hsperfdata_cxh/16748") = 0
16749 madvise(0x7f2b4230c000, 1028096, MADV_DONTNEED) = 0
16749 _exit(0) = ?
16748 <... futex resumed> ) = 0
16748 close(0) = 0
16748 close(0) = -1 EBADF (Bad file descriptor)
16748 futex(0x3e6ca15a90, FUTEX_WAKE_PRIVATE, 2147483647) = 0
16748 _exit(0)

[cxh@…]

tar file that replicates FMU exit problem with JNA

[cxh@…]

Run of strace under linux

[Martin Sjölund]

Postponed until 1.9.1

[Martin Sjölund]

I suspect this has something to do with the runtime being linked with C++. For dynamic libraries you also have weird things like: ​http://stackoverflow.com/questions/8793099/unload-dynamic-library-needs-two-dlclose-calls

[Martin Sjölund]

This ticket was not closed for 1.9.1, which has now been released. It was batch modified for milestone 1.9.2 (but maybe an empty milestone was more appropriate; feel free to change it).

[Martin Sjölund]

Milestone changed to 1.9.3 since 1.9.2 was released.

[cxh@…]

I can no longer replicate this under darwin64 and linux64, so something must have changed. This bug could be closed.

On both platforms, a successful run looks like:

bash-3.2$ java -classpath .:jna-4.1.0.jar OmcFmuExitBug
This class illustrates a bug where an FMU
generated by OpenModelica fails to exit.
When this file is run, it hangs on exiting.
bash-3.2$

Note that the process exited.

jna-4.1.0.jar was obtained with:

wget ​https://maven.java.net/content/repositories/releases/net/java/dev/jna/jna/4.1.0/jna-4.1.0.jar

Below is the environment under darwin64

bash-3.2$ uname -a
Darwin ealmac23.local 13.4.0 Darwin Kernel Version 13.4.0: Wed Dec 17 19:05:52 PST 2014; root:xnu-2422.115.10~1/RELEASE_X86_64 x86_64
bash-3.2$ java -version
java version "1.8.0_31"
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
bash-3.2$ omc --version
1.9.3+dev (r25132)
bash-3.2$ 

Below is the linux64 environment

[cxh@terra simple]$ uname -a
Linux terra.EECS.Berkeley.EDU 2.6.32-504.8.1.el6.x86_64 #1 SMP Fri Dec 19 12:09:25 EST 2014 x86_64 x86_64 x86_64 GNU/Linux
[cxh@terra simple]$ java -version
java version "1.8.0_31"
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
[cxh@terra simple]$ omc --version
1.9.3+dev (r25132)
[cxh@terra simple]$