Excelsior JET + Xuggle = crash

[Mike Walczak]

I'm using Excelsior JET to create a .exe out of my java app (not my idea, but I have to run with it).  I'm using Xuggle 5.4 (win7, 64-bit, but 32-bit Xuggle version) to decode a network video stream (h264).   When my app runs as a normal java app (using jdk6), things work well.  When I run in the JET .exe (it uses its own jvm) it crashes when I close my video player window.

More details
* I'm using the MediaTool API (ToolFactory.makeReader(URL), then I create a separate thread to tell the reader to read more packets
* Crash occurs right after I close the MediaReader, and exit from the player thread
* The error has to do with not being able to suspend the native thread

JET's answer is that this is
"misuse in code of Xuggle native methods. Specifically, a native thread attaches itself to the JVM using the AttachCurrentThread() function but when it terminates it does not call DetachCurrentThread()."

I'm not sure I agree, since this only happens using their JVM - but let's say they are correct -- is there a way to force the native thread to detach itself? 
When does the native thread get created and how do I tell it to go away?



The error looks like this (for the sake of completeness).  

AJ-runtime trap: kind = 1, source = Z:\users\giguz\buildsystem\build\aj-runtime\rt-normal\core\runtime\windows\java\com\excelsior\jet\runtime\os\OSThread.java, line = 181
Unexpected OS failure: SuspendThread() failed (error code 5)

JET RUNTIME HAS DETECTED UNRECOVERABLE ERROR #44 (runtime trap).
Please, contact the vendor of the application.
Extra information about error is saved in the "jet_err_5768.txt" file.

Any clues would be appreciated - thanks.
-Mike

[Mike Walczak]

Poking around the Xuggle source, I see an auto attach code in JNIHelper::getEnv  (which calls vm->AttachCurrentThread(...))  but no calls to  vm->DetachCurrentThread()
Unless I'm missing something... it does not seem like the native threads detach themselves.
Anyone with the intimate knowledge of the Xuggle source code know why?  At this point (I've been stuck on this issue for a long time) I will make offerings to your favorite god in your name, if you help me with
this issue.   I need to make the native threads detach themselves before dying.

Thanks.
-Mike

[Art Clarke]

I don't think detach current thread was in Jdk 5 so I never thought to call it.  Unfortunately there is no automatic way I can think of for xuggler to know it will never be called again on a thread without a new API call.  The com/xuggle/ferry code would be the place to add it.

--
You received this message because you are subscribed to the Google Groups "xuggler-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/xuggler-users/-/jp3KC6TkcDoJ.
To post to this group, send email to xuggle...@googlegroups.com.
To unsubscribe from this group, send email to xuggler-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/xuggler-users?hl=en.

--
http://www.xuggle.com/
xu‧ggle (zŭ' gl) v. To freely encode, decode, and experience audio and video.

Use Xuggle to get the power of FFmpeg in Java.