Random crashes occur on the MacOS JVM

[GoogleCodeExporter]

Here's from Sal Scotto:

Also the crashlog i posted. i can only get this to happen if my disk is
under heavy load when it goes to start. I think the apple vm starts a timer
when it goes to load a lib and times out throwing a sigtrap and exiting the vm
when loading from disk. I did notice when i was burning a dvd today (and
making very heavy use of the disk during burn/verify process) it would
consta crash til the verify was complete.
so seems to me this is a JVM issue as it thinks its deadlocked trying to
load the logger in the ferry code (it was taking to long)

Thread 12 Crashed:
0   libclient.dylib               0x0067f5c4 JVM_RaiseSignal + 441604
1   libclient.dylib               0x0047f97b 0x3ba000 + 809339
2   libclient.dylib               0x005bfa1a JNI_CreateJavaVM_Impl + 60810
3   libxuggle-ferry.3.dylib       0x1acf58c3
com::xuggle::ferry::Logger::getLogger(char const*) + 147
4   libxuggle-ferry.3.dylib       0x1acf5edd
com::xuggle::ferry::Logger::getStaticLogger(char const*) + 29
5   libxuggle-xuggler.3.dylib     0x1c324e6c
__static_initialization_and_destruction_0(int, int) + 44

Would indicate to me, as the logger was trying to start up, the jvm thinks
it was hung doing a load library so exits the jvm as a 'crash' state. Not
sure what can be done there. only happens on os x

Original issue reported on code.google.com by art.cla...@gmail.com on 30 Jun 2009 at 5:55

[GoogleCodeExporter]

A potential workaround is to not use logging in the Global methods, which 
should stop
us from calling back into Java.  I'll try a patch for that later today.

Original comment by art.cla...@gmail.com on 30 Jun 2009 at 5:56

[GoogleCodeExporter]

also possibly as a thought, in Global.cpp setup a dummy callback stub for 
loading.
then after library load in XuggleJNI  static section, call back into native and 
set
the logger to a real function

Original comment by sal.sco...@gmail.com on 30 Jun 2009 at 6:06

[GoogleCodeExporter]

You run into a problem then with when can you safely do that -- the Global class
assumes it operates in a JNI library loader, and hence no other thread is 
accessing
it.  Once you defer, you need to worry about threading.

Instead, there really isn't much logging that happens in the Global method, so I
think it's easier to just remove the static logger in that file.

Original comment by art.cla...@gmail.com on 30 Jun 2009 at 6:36

[GoogleCodeExporter]

Try revision r723 (or later) and let me know if that works around the issue.

Original comment by art.cla...@gmail.com on 30 Jun 2009 at 7:12

[GoogleCodeExporter]

i built r723, and i can still get it to crash at that spot. Since it takes a 
lot of
load to get it to crash. Ive been running a handbrake encode while trying to 
start
the mediaviewer at the same time. it takes a few tries but eventually goes to 
start
and crashes with same issue as above.

Thread 12 Crashed:
0   libclient.dylib                 0x0067f5c4 JVM_RaiseSignal + 441604
1   libclient.dylib                 0x0047f97b 0x3ba000 + 809339
2   libclient.dylib                 0x005bfa1a JNI_CreateJavaVM_Impl + 60810
3   libxuggle-ferry.3.dylib         0x1ad40ae3
com::xuggle::ferry::Logger::getLogger(char const*) + 147 (Logger.cpp:158)
4   libxuggle-ferry.3.dylib         0x1ad410fd
com::xuggle::ferry::Logger::getStaticLogger(char const*) + 29 (Logger.cpp:182)
5   libxuggle-xuggler-io.3.dylib    0x0559ffbc
__static_initialization_and_destruction_0(int, int) + 44
6   dyld                            0x8fe12f36
ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 246
7   dyld                            0x8fe0e7e3
ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned 
int) + 307
8   dyld                            0x8fe0e8c9
ImageLoader::runInitializers(ImageLoader::LinkContext const&) + 57
9   dyld                            0x8fe02202 
dyld::runInitializers(ImageLoader*) + 34
10  dyld                            0x8fe0bbdd dlopen + 605
11  libSystem.B.dylib               0x916ac2c2 dlopen + 66
12  libclient.dylib                 0x0060d6f1 JVM_LoadLibrary + 193
13  libjava.jnilib                  0x00061d74
Java_java_lang_ClassLoader_00024NativeLibrary_load + 87

Atleast now you get a line number!

Original comment by sal.sco...@gmail.com on 30 Jun 2009 at 8:12

[GoogleCodeExporter]

though it looks like it might be that the returned string might now have 
alocated?

Original comment by sal.sco...@gmail.com on 30 Jun 2009 at 8:17

[GoogleCodeExporter]

probably something different actually.  I've had issues before with Mac's and 
order
of static C initialization.  My guess is that if I attempt to call a JVM method
inside on onload handler due to initializing a static variable, Apple gives up 
the ghost.

So, I'll try a different workaround where I no longer attempt to initialize in 
an
OnLoad handler.  It might not solve your issue but it's worth a shot.

Try r726

You'll need to uninstall any prior versions, then do:
ant clobber stage install

Original comment by art.cla...@gmail.com on 1 Jul 2009 at 2:48

[GoogleCodeExporter]

Sal, any word on whether this still occurs for you with tip of tree (which 
should be
stable enough to try now)?

Original comment by art.cla...@gmail.com on 2 Jul 2009 at 6:10

[GoogleCodeExporter]

sorry for late comment, google decided not to send me an email when the bug got
updated. im building now

Original comment by sal.sco...@gmail.com on 5 Jul 2009 at 1:27

[GoogleCodeExporter]

from tip of tree r726 i was able to get it to crash again

Thread 12 Crashed:
0   libclient.dylib                 0x0067f5c4 JVM_RaiseSignal + 441604
1   libclient.dylib                 0x0047f97b 0x3ba000 + 809339
2   libclient.dylib                 0x005bfa1a JNI_CreateJavaVM_Impl + 60810
3   libxuggle-ferry.3.dylib         0x1ad45a83
com::xuggle::ferry::Logger::getLogger(char const*) + 147 (Logger.cpp:158)
4   libxuggle-ferry.3.dylib         0x1ad4609d
com::xuggle::ferry::Logger::getStaticLogger(char const*) + 29 (Logger.cpp:182)
5   libxuggle-xuggler-io.3.dylib    0x0559ffbc
__static_initialization_and_destruction_0(int, int) + 44
6   dyld                            0x8fe12f36
ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 246
7   dyld                            0x8fe0e7e3
ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned 
int) + 307
8   dyld                            0x8fe0e8c9
ImageLoader::runInitializers(ImageLoader::LinkContext const&) + 57
9   dyld                            0x8fe02202 
dyld::runInitializers(ImageLoader*) + 34
10  dyld                            0x8fe0bbdd dlopen + 605
11  libSystem.B.dylib               0x916ac2c2 dlopen + 66
12  libclient.dylib                 0x0060d6f1 JVM_LoadLibrary + 193
13  libjava.jnilib                  0x00061d74
Java_java_lang_ClassLoader_00024NativeLibrary_load + 87

Original comment by sal.sco...@gmail.com on 5 Jul 2009 at 1:47

[GoogleCodeExporter]

Hi Sal,

Tip of tree is r783 -- between now and 726 I re-did initialization.  Can you 
try tip?

- Art

Original comment by art.cla...@gmail.com on 5 Jul 2009 at 7:37

[GoogleCodeExporter]

Also, can you ensure you have manually removed/deleted any old Xuggler 
libraries. 
r726 shouldn't be able to call into Java during the load JVM stuff, so I think 
you
might be getting an old version of the library somewhere on your path.

- Art

Original comment by art.cla...@gmail.com on 5 Jul 2009 at 7:43

[GoogleCodeExporter]

Thought i had re-installed ill try again. im in europe right now so i have a 
6hr diff
in timezone

Original comment by sal.sco...@gmail.com on 9 Jul 2009 at 6:25

[GoogleCodeExporter]

same error granted to took a lot of work to have it happen. im pretty sure i 
had a
clean build since i forgot to set the 64 bit flag and first pass and had to 
uninstall
then rebuild and reinstall. to get it to crash btw i had to get my machine to 
max out
both cpus to 100% and try launching over and over again.

Original comment by sal.sco...@gmail.com on 10 Jul 2009 at 5:35

[GoogleCodeExporter]

We're getting closer then.  Do you have a crash log from the latest crash and a 
java
heap crash log?

Original comment by art.cla...@gmail.com on 10 Jul 2009 at 2:21

[GoogleCodeExporter]

Hi Sal,

I'm marking this as WontFix for now because (a) we can't reproduce it in our 
setup
and (b) I'm awaiting a crashlog.

I'll re-open it if/when you can get us a crash log.

Thanks,

- Art

Original comment by art.cla...@gmail.com on 29 Jul 2009 at 5:40

• Changed state: WontFix