JVM crash when writing packet

[GoogleCodeExporter]

I encountered a crash when writing files, and strongly think its Xuggler
related:

Jstack:

Thread 29006: (state = IN_NATIVE)
 - com.xuggle.xuggler.XugglerJNI.IPacket_make__SWIG_2(long,
com.xuggle.xuggler.IPacket, boolean) @bci=0 (Compiled frame; information
may be imprecise)
 - com.xuggle.xuggler.IPacket.make(com.xuggle.xuggler.IPacket, boolean)
@bci=6, line=460 (Compiled frame)

GDB:

#11 <signal handler called>
#12 0x00002aaaae6feed9 in ?? ()
#13 0x00002aaac7c6c061 in __dynamic_cast () from /usr/lib64/libstdc++.so.6
#14 0x00002aaace61c9e7 in com::xuggle::xuggler::IPacket::make ()

Any idea what can cause it in dynamic cast there?

Original issue reported on code.google.com by Stas.Os...@gmail.com on 8 Sep 2009 at 2:00

[GoogleCodeExporter]

This crash happens only when:

* A large concurrent amount of threads (200+) is writing to disk

* The CPU waiting time (disk access) climbs to 30% - 40%

Might be some missing mutex?

Original comment by Stas.Os...@gmail.com on 8 Sep 2009 at 2:28

[GoogleCodeExporter]

Can you provide some sample code/  This really LOOKS like a thread corruption 
issue
has occurred earlier, and then a lib-c dynamic cast is failing.  I'm asking for 
a non
RTP-based test case because I suspect it's actually in the RTP reading/writing 
code.

Original comment by art.cla...@gmail.com on 9 Sep 2009 at 3:37

[GoogleCodeExporter]

Hi Art.

I see what you mean. I'm not quite sure about this, as the packet not written 
to disk
but being processed before, so if there was some corruption / thread entangling
before, it probably would become visible then.

I will try to repro it, but again it needs a specific situation to have, and 
only
becomes visible on high amount of loads.

Original comment by Stas.Os...@gmail.com on 9 Sep 2009 at 7:35

[GoogleCodeExporter]

I forgot to update that it happens even earlier then dynamic_cast. Here is a 
sample dump:

GDB:
#6  <signal handler called>
#7  0x00002aaace4df8b5 in com::xuggle::xuggler::Packet::make () from
/JavaCore/xuggler/lib/libxuggle-xuggler.so.3.2.879
#8  0x00002aaace4f83a5 in 
Java_com_xuggle_xuggler_XugglerJNI_IPacket_1make_1_1SWIG_12 ()
   from /JavaCore/xuggler/lib/libxuggle-xuggler.so.3.2.879

JCrash:
Thread 2696: (state = IN_NATIVE)
 - com.xuggle.xuggler.XugglerJNI.IPacket_make__SWIG_2(long,
com.xuggle.xuggler.IPacket, boolean) @bci=0 (Compiled frame; information
 may be imprecise)
 - com.xuggle.xuggler.IPacket.make(com.xuggle.xuggler.IPacket, boolean) @bci=6,
line=460 (Compiled frame)

So here the crash point happens on stage that is even earlier then dynamic_cast.

Original comment by Stas.Os...@gmail.com on 9 Sep 2009 at 7:38

[GoogleCodeExporter]

Yeah; if it's a thread corruption issue the stack traces are next to useful.  
That's
why the repro case matters so much.

Original comment by art.cla...@gmail.com on 9 Sep 2009 at 8:44

[GoogleCodeExporter]

Closing with a repro case.  Provide one and I'll reopen.

Original comment by art.cla...@gmail.com on 16 Jan 2010 at 2:57

• Changed state: Invalid

[GoogleCodeExporter]

I think it got solved by some work-around - need to check.

Original comment by Stas.Os...@gmail.com on 17 Jan 2010 at 2:00