Bridj - Multithreading crashes the JVM

[dbuchhorn]

Hello Olivier,

the actuell bridj 0.7-SNAPSHOT version (bridj-0.7-20130922.224652-51) crashes the JVM. I use multiple threads to make some image manipulations over the ImageMagic C API. I use JDK 1.6 32bit and JDK 1.7 32bit on a Windows 8 64bit OS. My program is executed in a JBoss 5.1 application server.
The JVM often crashes after some minutes.

Here are some JVM reports:
Report 1:

Stack: [0x58790000,0x587e0000],  sp=0x587de2e8,  free space=312k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0x153489]
V  [jvm.dll+0x112640]
V  [jvm.dll+0x112ea1]
V  [jvm.dll+0x127e1c]
V  [jvm.dll+0x1283ab]
V  [jvm.dll+0x11e108]
J  java.lang.Throwable.fillInStackTrace()Ljava/lang/Throwable;
j  org.bridj.LastError.setLastError(II)Lorg/bridj/LastError;+17
v  ~StubRoutines::call_stub
V  [jvm.dll+0x10e4dd]
V  [jvm.dll+0x1a5981]
V  [jvm.dll+0x10e56d]
V  [jvm.dll+0xa0a86]
V  [jvm.dll+0xa74b3]
C  [bridj.dll+0x1c00]
C  [bridj.dll+0x1f67]  Java_org_bridj_LastError_getDescription+0x2e7
C  [bridj.dll+0xb920]  dcRawCallAdapterSkipTwoArgs+0x510
j  de.fup.magick.wand.MagickWandAPI.DestroyMagickWand(Lorg/bridj/Pointer;)Lorg/bridj/Pointer;+0
j  de.fup.magick.wand.MagickWand.dispose()Z+42

Report 2:

Stack: [0x5b5a0000,0x5b5f0000],  sp=0x5b5ee794,  free space=313k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0x5817]
V  [jvm.dll+0xa744b]
C  [bridj.dll+0x1c00]
C  [bridj.dll+0x1f67]  Java_org_bridj_LastError_getDescription+0x2e7
C  [bridj.dll+0xb920]  dcRawCallAdapterSkipTwoArgs+0x510
j  de.fup.magick.wand.MagickWandAPI.DestroyMagickWand(Lorg/bridj/Pointer;)Lorg/bridj/Pointer;+0
j  de.fup.magick.wand.MagickWand.dispose()Z+42

Report 3:

Stack: [0x5f220000,0x5f2a0000],  sp=0x5f29e3f0,  free space=504k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0x14865a]
V  [jvm.dll+0x14354c]
V  [jvm.dll+0x10dd6c]
V  [jvm.dll+0x10e4a4]
V  [jvm.dll+0x1a5981]
V  [jvm.dll+0x10e56d]
V  [jvm.dll+0xa0a86]
V  [jvm.dll+0xa74b3]
C  [bridj.dll+0x1c00]
C  [bridj.dll+0x1f67]  Java_org_bridj_LastError_getDescription+0x2e7
C  [bridj.dll+0xb920]  dcRawCallAdapterSkipTwoArgs+0x510
j  de.fup.magick.wand.MagickWandAPI.DestroyMagickWand(Lorg/bridj/Pointer;)Lorg/bridj/Pointer;+0
j  de.fup.magick.wand.MagickWand.dispose()Z+42

Sometimes in the log4j log files I found a java.lang.StackOverflowError like this one:
javax.ejb.EJBException: Unexpected Error
java.lang.StackOverflowError
at de.fup.magick.wand.MagickWandAPI.DestroyMagickWand(Native Method)
at de.fup.magick.wand.MagickWand.dispose(MagickWand.java:134)

It seems the error occurs during cleanup the native allocated memory.
A test with the latest 0.6.3-SNAPSHOT version works fine (no crash after a 16 hour test). I also test the JDK 1.7 64bit version and the JVM don't crashes too (12 hour test).

I use google to search for some reasons. Can it be the internal JVM runtime paraters like Xss (thread stack size) and so on? These parameters are different on each OS and JVM version. I also try to set the Xss parameter to a higher value the JVM still crashes. I tried these because my program runs inside the JBoss application server. All classes are executed with a deep stack. But maybe there is a bug in the 32bit bridj version. (it can be in the 64bit version too but currently not appeared)

Any help are welcome.

[ochafik]

Hi @dbuchhorn ,

Thanks a lot for your report, and sorry for the trouble! I've recently modified the "last error" code, it looks like I might have introduced some wrong pointer cast somewhere... Investigating this now :-)

Cheers

[ochafik]

If you have a chance, could you please try to run with -Dbridj.direct=false (or with the BRIDJ_DIRECT=0 environment variable)?

Likewise, a full dump of the logs with -Dbridj.debug=true (or BRIDJ_DEBUG=1) could be very helpful (or at least, the portion about DestroyMagickWand).
Finally, could you please copy the Java bindings signature for DestroyMagickWand?

Thanks

[ochafik]

(update: BRIDJ_VERY_VERBOSE=1 / -Dbridj.veryVerbose=true will provide more information than just debug :-))

[dbuchhorn]

For the first run I only use "-Dbridj.veryVerbose=true", for the second test I use "-Dbridj.direct=false" too.
The log files can be downloaded from here: https://www.dropbox.com/sh/8v5dujw9uxw3dta/NLsQHsEoYF

[ochafik]

Hi @dbuchhorn ,

Sorry for the delay, this should be fixed in the latest 0.7-SNAPSHOT.

Cheers