JVM Crash with Xuggle

668 views
Skip to first unread message

Wim Deblauwe

unread,
Mar 1, 2010, 3:05:02 AM3/1/10
to xuggler-users
Hi,

I have a red5 application but it is giving a JVM crash. I have tried
Xuggle 3.3 and 3.4. I am using red5 0.9.

The crash always shows the same problematic frame:

#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x745e27bc, pid=31883, tid=1996540784
#
# JRE version: 6.0_16-b01
# Java VM: Java HotSpot(TM) Server VM (14.2-b01 mixed mode linux-x86 )
# Problematic frame:
# C [libstdc++.so.6+0xb87bc] __dynamic_cast+0x2c
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

It also always happens in the same 'decodeVideo' method.

Stack: [0x76fbc000,0x7700d000], sp=0x7700ba90, free space=318k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
C=native code)
C [libstdc++.so.6+0xb87bc] __dynamic_cast+0x2c
C [libxuggle-xuggler.so.3.3.940+0x3ee4f]
_ZN3com6xuggle7xuggler11StreamCoder11decodeVideoEPNS1_13IVideoPictureEPNS1_7IPacketEi
+0x4f
C [libxuggle-xuggler.so.3.3.940+0x6b69c]
Java_com_xuggle_xuggler_XugglerJNI_IStreamCoder_1decodeVideo+0x5c
j com.xuggle.xuggler.XugglerJNI.IStreamCoder_decodeVideo(JLcom/xuggle/
xuggler/IStreamCoder;JLcom/xuggle/xuggler/IVideoPicture;JLcom/xuggle/
xuggler/IPacket;I)I+0

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j com.xuggle.xuggler.XugglerJNI.IStreamCoder_decodeVideo(JLcom/xuggle/
xuggler/IStreamCoder;JLcom/xuggle/xuggler/IVideoPicture;JLcom/xuggle/
xuggler/IPacket;I)I+0
J com.mycomp.imux.feed.RTSPFeed.run()V
j java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Ljava/lang/
Runnable;)V+59
j java.util.concurrent.ThreadPoolExecutor$Worker.run()V+28
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub

Any idea what might cause this? Anything I can do to debug?

regards,

Wim

Art Clarke

unread,
Mar 1, 2010, 9:46:51 AM3/1/10
to xuggle...@googlegroups.com
Hi there,

Not sure what is causing this, but check if it still happens on Xuggler tip-of-tree.

Since you appear to be running on Linux, can you check if a core file was created?  If not, do this from a shell:

# tell Unix to create core files and not restrict size.
ulimit -c unlimited
# run your Xuggler program
java -cp $XUGGLE_HOME/share/java/jars/xuggle-xuggler.jar:. yourclass
# check for core
ls -l core
# debug in gdb
gdb `which java` core
# get a stack trace in gdb
gdb> bt

Once you have the stack trace, reply to this e-mail and I might have some clue. 

- Art

--
You received this message because you are subscribed to the Google Groups "xuggler-users" group.
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.

Wim Deblauwe

unread,
Mar 2, 2010, 11:24:06 AM3/2/10
to xuggler-users
Hi,

I do not get this core file or directory. I start my application using
the red5.sh script. The hs_err_... log file is generated in this
directory, but no core file. Any idea where it should be located?

regards,

Wim

On 1 mrt, 15:46, Art Clarke <acla...@xuggle.com> wrote:
> Hi there,
>
> Not sure what is causing this, but check if it still happens on Xuggler
> tip-of-tree.
>
> Since you appear to be running on Linux, can you check if a core file was
> created?  If not, do this from a shell:
>
> # tell Unix to create core files and not restrict size.
> ulimit -c unlimited
> # run your Xuggler program
> java -cp $XUGGLE_HOME/share/java/jars/xuggle-xuggler.jar:. yourclass
> # check for core
> ls -l core
> # debug in gdb
> gdb `which java` core
> # get a stack trace in gdb
> gdb> bt
>
> Once you have the stack trace, reply to this e-mail and I might have some
> clue.
>
> - Art

> > xuggler-user...@googlegroups.com<xuggler-users%2Bunsu...@googlegroups.com>


> > .
> > For more options, visit this group at
> >http://groups.google.com/group/xuggler-users?hl=en.
>

> --http://www.xuggle.com/

Wim Deblauwe

unread,
Mar 3, 2010, 5:53:40 AM3/3/10
to xuggler-users
Managed to get it working now. This is the output using Xuggler 3.4:

GNU gdb (GDB) 7.0-ubuntu
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/
gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/java...(no debugging symbols
found)...done.
[New Thread 24169]
[New Thread 24171]
[New Thread 24166]
[New Thread 24159]
[New Thread 24164]
[New Thread 24170]
[New Thread 24173]
[New Thread 24161]
[New Thread 24162]
[New Thread 24185]
[New Thread 24177]
[New Thread 24057]
[New Thread 24065]
[New Thread 24060]
[New Thread 24178]
[New Thread 24066]
[New Thread 24097]
[New Thread 24061]
[New Thread 24062]
[New Thread 24067]
[New Thread 24100]
[New Thread 24071]
[New Thread 24063]
[New Thread 24103]
[New Thread 24118]
[New Thread 24104]
[New Thread 24064]
[New Thread 24084]
[New Thread 24115]
[New Thread 24130]
[New Thread 24133]
[New Thread 24068]
[New Thread 24086]
[New Thread 24131]
[New Thread 24139]
[New Thread 24069]
[New Thread 24145]
[New Thread 24098]
[New Thread 24141]
[New Thread 24070]
[New Thread 24101]
[New Thread 24143]
[New Thread 24160]
[New Thread 24102]
[New Thread 24072]
[New Thread 24148]
[New Thread 24105]
[New Thread 24077]
[New Thread 24106]
[New Thread 24108]
[New Thread 24085]
[New Thread 24109]
[New Thread 24119]
[New Thread 24110]
[New Thread 24120]
[New Thread 24111]
[New Thread 24112]
[New Thread 24123]
[New Thread 24113]
[New Thread 24128]
[New Thread 24132]
[New Thread 24129]
[New Thread 24134]
[New Thread 24135]
[New Thread 24136]
[New Thread 24144]
[New Thread 24151]

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/tls/i686/cmov/libpthread.so.0...(no
debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0
Reading symbols from /usr/lib/jvm/java-6-sun-1.6.0.16/jre/bin/../lib/
i386/jli/libjli.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/jvm/java-6-sun-1.6.0.16/jre/bin/../lib/
i386/jli/libjli.so
Reading symbols from /lib/tls/i686/cmov/libdl.so.2...(no debugging
symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libdl.so.2
Reading symbols from /lib/tls/i686/cmov/libc.so.6...(no debugging
symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/
server/libjvm.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/
server/libjvm.so
Reading symbols from /lib/tls/i686/cmov/libm.so.6...(no debugging
symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libm.so.6
Reading symbols from /lib/tls/i686/cmov/librt.so.1...(no debugging
symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/librt.so.1
Reading symbols from /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/
libverify.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/
libverify.so
Reading symbols from /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/
libjava.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/
libjava.so
Reading symbols from /lib/tls/i686/cmov/libnsl.so.1...(no debugging
symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libnsl.so.1
Reading symbols from /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/
native_threads/libhpi.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/
native_threads/libhpi.so
Reading symbols from /lib/tls/i686/cmov/libnss_compat.so.2...(no
debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libnss_compat.so.2
Reading symbols from /lib/tls/i686/cmov/libnss_nis.so.2...(no
debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libnss_nis.so.2
Reading symbols from /lib/tls/i686/cmov/libnss_files.so.2...(no
debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libnss_files.so.2
Reading symbols from /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/
libzip.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/
libzip.so
Reading symbols from /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/
libmanagement.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/
libmanagement.so
Reading symbols from /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/
libnet.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/
libnet.so
Reading symbols from /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/
librmi.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/
librmi.so
Reading symbols from /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/
libnio.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/i386/
libnio.so
Reading symbols from /usr/local/xuggler/lib/libxuggle-xuggler.so.
3.4.1012...(no debugging symbols found)...done.
Loaded symbols for /usr/local/xuggler/lib/libxuggle-xuggler.so.
3.4.1012
Reading symbols from /usr/local/xuggler/lib/libavdevice.so.52...(no
debugging symbols found)...done.
Loaded symbols for /usr/local/xuggler/lib/libavdevice.so.52
Reading symbols from /usr/local/xuggler/lib/libavformat.so.52...(no
debugging symbols found)...done.
Loaded symbols for /usr/local/xuggler/lib/libavformat.so.52
Reading symbols from /usr/local/xuggler/lib/libavcodec.so.52...(no
debugging symbols found)...done.
Loaded symbols for /usr/local/xuggler/lib/libavcodec.so.52
Reading symbols from /usr/local/xuggler/lib/libavutil.so.50...(no
debugging symbols found)...done.
Loaded symbols for /usr/local/xuggler/lib/libavutil.so.50
Reading symbols from /usr/local/xuggler/lib/libswscale.so.0...(no
debugging symbols found)...done.
Loaded symbols for /usr/local/xuggler/lib/libswscale.so.0
Reading symbols from /usr/local/xuggler/lib/libxuggle-ferry.so.3...(no
debugging symbols found)...done.
Loaded symbols for /usr/local/xuggler/lib/libxuggle-ferry.so.3
Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /usr/local/xuggler/lib/libfaac.so.0...(no
debugging symbols found)...done.
Loaded symbols for /usr/local/xuggler/lib/libfaac.so.0
Reading symbols from /usr/local/xuggler/lib/libmp3lame.so.0...(no
debugging symbols found)...done.
Loaded symbols for /usr/local/xuggler/lib/libmp3lame.so.0
Reading symbols from /usr/local/xuggler/lib/libopencore-amrnb.so.0...
(no debugging symbols found)...done.
Loaded symbols for /usr/local/xuggler/lib/libopencore-amrnb.so.0
Reading symbols from /usr/local/xuggler/lib/libopencore-amrwb.so.0...
(no debugging symbols found)...done.
Loaded symbols for /usr/local/xuggler/lib/libopencore-amrwb.so.0
Reading symbols from /usr/local/xuggler/lib/libspeex.so.1...(no
debugging symbols found)...done.
Loaded symbols for /usr/local/xuggler/lib/libspeex.so.1
Reading symbols from /usr/local/xuggler/lib/libtheoraenc.so.1...(no
debugging symbols found)...done.
Loaded symbols for /usr/local/xuggler/lib/libtheoraenc.so.1
Reading symbols from /usr/local/xuggler/lib/libtheoradec.so.1...(no
debugging symbols found)...done.
Loaded symbols for /usr/local/xuggler/lib/libtheoradec.so.1
Reading symbols from /usr/local/xuggler/lib/libvorbisenc.so.2...(no
debugging symbols found)...done.
Loaded symbols for /usr/local/xuggler/lib/libvorbisenc.so.2
Reading symbols from /usr/local/xuggler/lib/libvorbis.so.0...(no
debugging symbols found)...done.
Loaded symbols for /usr/local/xuggler/lib/libvorbis.so.0
Reading symbols from /usr/local/xuggler/lib/libx264.so.83...(no
debugging symbols found)...done.
Loaded symbols for /usr/local/xuggler/lib/libx264.so.83
Reading symbols from /usr/local/xuggler/lib/libogg.so.0...(no
debugging symbols found)...done.
Loaded symbols for /usr/local/xuggler/lib/libogg.so.0
Reading symbols from /usr/local/xuggler/lib/libxuggle-xuggler-io.so.
3.4.1012...(no debugging symbols found)...done.
Loaded symbols for /usr/local/xuggler/lib/libxuggle-xuggler-io.so.
3.4.1012
Core was generated by `/usr/lib/jvm/java-6-sun/bin/java -
Dpython.home=lib -Dred5.root=/home/wdb/Work/t'.
Program terminated with signal 6, Aborted.
#0 0xb7775422 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7775422 in __kernel_vsyscall ()
#1 0xb761f4d1 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7622932 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0xb6fe3b9f in os::abort(bool) () from /usr/lib/jvm/java-6-
sun-1.6.0.16/jre/lib/i386/server/libjvm.so
#4 0xb7106b81 in VMError::report_and_die() () from /usr/lib/jvm/
java-6-sun-1.6.0.16/jre/lib/i386/server/libjvm.so
#5 0xb7107771 in crash_handler(int, siginfo*, void*) () from /usr/lib/
jvm/java-6-sun-1.6.0.16/jre/lib/i386/server/libjvm.so
#6 <signal handler called>
#7 0xb6fe0f22 in os::is_first_C_frame(frame*) () from /usr/lib/jvm/
java-6-sun-1.6.0.16/jre/lib/i386/server/libjvm.so
#8 0xb71059af in VMError::report(outputStream*) () from /usr/lib/jvm/
java-6-sun-1.6.0.16/jre/lib/i386/server/libjvm.so
#9 0xb7106aba in VMError::report_and_die() () from /usr/lib/jvm/
java-6-sun-1.6.0.16/jre/lib/i386/server/libjvm.so
#10 0xb6fea3ac in JVM_handle_linux_signal () from /usr/lib/jvm/java-6-
sun-1.6.0.16/jre/lib/i386/server/libjvm.so
#11 0xb6fe6624 in signalHandler(int, siginfo*, void*) () from /usr/lib/
jvm/java-6-sun-1.6.0.16/jre/lib/i386/server/libjvm.so
#12 <signal handler called>
#13 0x751597d0 in ?? () from /usr/local/xuggler/lib/libavcodec.so.52
(gdb)

Wim Deblauwe

unread,
Mar 3, 2010, 5:56:37 AM3/3/10
to xuggler-users

On Mar 1, 3:46 pm, Art Clarke <acla...@xuggle.com> wrote:
> Hi there,
>
> Not sure what is causing this, but check if it still happens on Xuggler
> tip-of-tree.

Are these still compatible with red5 ?

Art Clarke

unread,
Mar 3, 2010, 9:01:54 AM3/3/10
to xuggle...@googlegroups.com
This is missing all the other threads :(  Can you:
a) post results in pastebin (my e-mail reader can cut stuff off)
b) Run this set of GDB commands (assuming you're running from a Xuggler source directory) to get a full stack trace of all threads:
  gdb -x mk/buildtools/stacktrace.gdb `which java` core > gdboutput.txt

And paste the contents of gdboutput.txt.
 
- Art

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.

Art Clarke

unread,
Mar 3, 2010, 9:02:21 AM3/3/10
to xuggle...@googlegroups.com

Should be compatible with the latest (tip of tree) Red5.

- Art

Wim Deblauwe

unread,
Mar 3, 2010, 10:19:38 AM3/3/10
to xuggler-users
See http://pastebin.com/0FMvue2P


On Mar 3, 3:01 pm, Art Clarke <acla...@xuggle.com> wrote:
> This is missing all the other threads :(  Can you:
> a) post results in pastebin (my e-mail reader can cut stuff off)
> b) Run this set of GDB commands (assuming you're running from a Xuggler
> source directory) to get a full stack trace of all threads:
>   gdb -x mk/buildtools/stacktrace.gdb `which java` core > gdboutput.txt
>
> And paste the contents of gdboutput.txt.
>
> - Art
>

> On Wed, Mar 3, 2010 at 2:53 AM, Wim Deblauwe <wim.debla...@gmail.com> wrote:
> > Managed to get it working now. This is the output using Xuggler 3.4:
>
> > GNU gdb (GDB) 7.0-ubuntu
> > Copyright (C) 2009 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/

> > gpl.html <http://gnu.org/licenses/%0Agpl.html>>

> ...
>
> read more »

Art Clarke

unread,
Mar 3, 2010, 10:45:10 AM3/3/10
to xuggle...@googlegroups.com
Hi there,

I can see a corrupt stack frame in FFmpeg but I don't have much idea what else is causing that.  Can you try upgrading to tip of Xuggler tree to see if the problem is fixed there.

- Art


--
You received this message because you are subscribed to the Google Groups "xuggler-users" group.
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.

Wim Deblauwe

unread,
Mar 3, 2010, 2:20:29 PM3/3/10
to xuggler-users
I tried latest tip of tree installers from hudson of both Xuggle and
Red5. I still have the JVM crash.

gdb output: http://pastebin.com/5jAhqWDa
pid log file: http://pastebin.com/HmU6GaH7

Note that I also have the same crash on CentOS 5 (64-bit) and Windows
2008 64-bit (on 32-bit JVM there). The tests with the tip of tree
installers are run on my Ubuntu dev machine.

regards,

Wim

On 3 mrt, 16:45, Art Clarke <acla...@xuggle.com> wrote:
> Hi there,
>
> I can see a corrupt stack frame in FFmpeg but I don't have much idea what
> else is causing that.  Can you try upgrading to tip of Xuggler tree to see
> if the problem is fixed there.
>
> - Art
>

> On Wed, Mar 3, 2010 at 7:19 AM, Wim Deblauwe <wim.debla...@gmail.com> wrote:
> > Seehttp://pastebin.com/0FMvue2P

> ...
>
> meer lezen »

Wim Deblauwe

unread,
Mar 4, 2010, 8:47:53 AM3/4/10
to xuggler-users
I also updated to the latest JDK (sun jdk 1.6.0_18), but still the
same.

> ...
>
> meer lezen »

Art Clarke

unread,
Mar 4, 2010, 10:23:19 AM3/4/10
to xuggle...@googlegroups.com
Alright, looks like this qualifies for my "reliabily crashes a JVM" qualifier for a P0 bug.  Do you have source code you could send me (preferably as simple as possible including only Xuggler dependencies) that can reliably reproduce the problem for you?

- Art

> ...
>
> meer lezen »

--
You received this message because you are subscribed to the Google Groups "xuggler-users" group.
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.

Wim Deblauwe

unread,
Mar 4, 2010, 10:30:14 AM3/4/10
to xuggle...@googlegroups.com
Hi,

I don't have a simple program that only uses Xuggle I am afraid. This is a red5 application. You can ask any of the red5 team, they have the source code or I can send it in a private email?

regards,

Wim

2010/3/4 Art Clarke <acl...@xuggle.com>

Art Clarke

unread,
Mar 4, 2010, 11:13:26 AM3/4/10
to xuggle...@googlegroups.com
Hi Wim,

There is no Xuggler code in Red5 (I'm on that Red5 team) so you're using some other piece of software.  Sorry, but without a repro case, I can't do anything -- and frankly this is a free open-source product, so I need you to spend the time to make a reproduction case because this isn't my day job :)

- Art

Wim Deblauwe

unread,
Mar 5, 2010, 2:19:56 PM3/5/10
to xuggler-users
Are there any guidelines about what you should take into account when
using Xuggle with multiple threads? Are there calls that are not
thread safe?

I have a strong feeling that maybe we are doing things from different
threads, that we should not do?

regards,

Wim

On 4 mrt, 17:13, Art Clarke <acla...@xuggle.com> wrote:
> Hi Wim,
>
> There is no Xuggler code in Red5 (I'm on that Red5 team) so you're using
> some other piece of software.  Sorry, but without a repro case, I can't do
> anything -- and frankly this is a free open-source product, so I need you to
> spend the time to make a reproduction case because this isn't my day job :)
>
> - Art
>

> On Thu, Mar 4, 2010 at 7:30 AM, Wim Deblauwe <wim.debla...@gmail.com> wrote:
> > Hi,
>
> > I don't have a simple program that only uses Xuggle I am afraid. This is a
> > red5 application. You can ask any of the red5 team, they have the source
> > code or I can send it in a private email?
>
> > regards,
>
> > Wim
>

> > 2010/3/4 Art Clarke <acla...@xuggle.com>


>
> >> Alright, looks like this qualifies for my "reliabily crashes a JVM"
> >> qualifier for a P0 bug.  Do you have source code you could send me
> >> (preferably as simple as possible including only Xuggler dependencies) that
> >> can reliably reproduce the problem for you?
>
> >> - Art
>

> ...
>
> meer lezen »

Art Clarke

unread,
Mar 5, 2010, 2:42:22 PM3/5/10
to xuggle...@googlegroups.com
Make sure each object you use (e.g. IStreamCoder or IContainer) is only accessed from one container at a time.

- Art

> ...
>
> meer lezen »

--
You received this message because you are subscribed to the Google Groups "xuggler-users" group.
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.

Wim Deblauwe

unread,
Mar 5, 2010, 2:51:49 PM3/5/10
to xuggle...@googlegroups.com
Do you mean " ... from one thread at a time." ? Or what do you mean with container?

Wim

2010/3/5 Art Clarke <acl...@xuggle.com>

Andy Shaules

unread,
Mar 5, 2010, 3:07:34 PM3/5/10
to xuggle...@googlegroups.com
Yup, that works great here, can you deploy it? or was that the huge time taker you mentioned?
 
Slow BW?
 
np. We Got it Made!!
 
Thank you Zard, you rocked it!

Andy Shaules

unread,
Mar 5, 2010, 3:08:02 PM3/5/10
to xuggle...@googlegroups.com
oops, disregard lol
 
sorry
----- Original Message -----
Sent: Friday, March 05, 2010 11:51 AM
Subject: Re: [xuggler-users] Re: JVM Crash with Xuggle

Wim Deblauwe

unread,
Mar 8, 2010, 8:56:53 AM3/8/10
to xuggle...@googlegroups.com
I have attached the sources of my red5 application. The main entry point is the SourceService. From our (flash/flex) application, we call SourceService#addSource() when we want to view a source and SourceService#stopSource() when we are done with it. The JVM crash happens most of the time when we stop viewing on a stream. As it is always in a call to encode or decodeVideo, I think maybe that the pointers that are passed to this method are invalid somehow. I would be most grateful if you could have a look at the code and see if there is anything done wrong there?
sources.zip

Wim Deblauwe

unread,
Mar 9, 2010, 3:26:10 AM3/9/10
to xuggler-users
Some extra info:

There are 2 types of crashes:

In decodeVideo:
------------------------

Is always in a FeedService thread:

Current thread (0x084a9c00): JavaThread
"FeedService-2" [_thread_in_native, id=1263,
stack(0x7421f000,0x74270000)]

Stack: [0x7421f000,0x74270000], sp=0x7426ed10, free
space=13f7426e6a0k


Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
C=native code)
C [libstdc++.so.6+0xb87bc] __dynamic_cast+0x2c

C [libxuggle-xuggler.so.3.4.1012+0x40a52]
_ZN3com6xuggle7xuggler11StreamCoder11decodeVideoEPNS1_13IVideoPictureEPNS1_7IPacketEi
+0x52
C [libxuggle-xuggler.so.3.4.1012+0x6d3fc]


Java_com_xuggle_xuggler_XugglerJNI_IStreamCoder_1decodeVideo+0x5c
j com.xuggle.xuggler.XugglerJNI.IStreamCoder_decodeVideo(JLcom/xuggle/
xuggler/IStreamCoder;JLcom/xuggle/xuggler/IVideoPicture;JLcom/xuggle/
xuggler/IPacket;I)I+0

j com.xuggle.xuggler.IStreamCoder.decodeVideo(Lcom/xuggle/xuggler/
IVideoPicture;Lcom/xuggle/xuggler/IPacket;I)I+16
j com.mycomp.imux.feed.RTSPFeed.run()V+397


j java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Ljava/lang/
Runnable;)V+59
j java.util.concurrent.ThreadPoolExecutor$Worker.run()V+28
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub

V [libjvm.so+0x384f40]
V [libjvm.so+0x55c9a8]
V [libjvm.so+0x384747]
V [libjvm.so+0x3847fa]
V [libjvm.so+0x405225]
V [libjvm.so+0x64bb0e]
V [libjvm.so+0x55de9e]
C [libpthread.so.0+0x580e]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j com.xuggle.xuggler.XugglerJNI.IStreamCoder_decodeVideo(JLcom/xuggle/
xuggler/IStreamCoder;JLcom/xuggle/xuggler/IVideoPicture;JLcom/xuggle/
xuggler/IPacket;I)I+0

j com.xuggle.xuggler.IStreamCoder.decodeVideo(Lcom/xuggle/xuggler/
IVideoPicture;Lcom/xuggle/xuggler/IPacket;I)I+16
j com.mycomp.imux.feed.RTSPFeed.run()V+397


j java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Ljava/lang/
Runnable;)V+59
j java.util.concurrent.ThreadPoolExecutor$Worker.run()V+28
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub


In encodeVideo:
-----------------------

Is always in ProcessorService thread:

Current thread (0x773ec000): JavaThread
"ProcessorService-2" [_thread_in_native, id=27808,
stack(0x7395e000,0x739af000)]

Stack: [0x7395e000,0x739af000], sp=0x739a2224, free
space=110739a1bb0k


Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
C=native code)

C [libavcodec.so.52+0x431ade]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)

j com.xuggle.xuggler.XugglerJNI.IStreamCoder_encodeVideo(JLcom/xuggle/
xuggler/IStreamCoder;JLcom/xuggle/xuggler/IPacket;JLcom/xuggle/xuggler/
IVideoPicture;I)I+0
j com.xuggle.xuggler.IStreamCoder.encodeVideo(Lcom/xuggle/xuggler/
IPacket;Lcom/xuggle/xuggler/IVideoPicture;I)I+16
j com.mycomp.imux.process.Processor.encodeAndWrite(Lcom/xuggle/
xuggler/IPacket;Lcom/xuggle/xuggler/IVideoPicture;)V+59
j com.mycomp.imux.process.Processor.encodeAndWrite(Lcom/xuggle/
xuggler/IVideoPicture;)V+64
j com.mycomp.imux.process.RTSPProcessor.run()V+143


j java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Ljava/lang/
Runnable;)V+59
j java.util.concurrent.ThreadPoolExecutor$Worker.run()V+28
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub

On Mar 8, 2:56 pm, Wim Deblauwe <wim.debla...@gmail.com> wrote:
> I have attached the sources of my red5 application. The main entry point is
> the SourceService. From our (flash/flex) application, we call
> SourceService#addSource() when we want to view a source and
> SourceService#stopSource() when we are done with it. The JVM crash happens
> most of the time when we stop viewing on a stream. As it is always in a call
> to encode or decodeVideo, I think maybe that the pointers that are passed to
> this method are invalid somehow. I would be most grateful if you could have
> a look at the code and see if there is anything done wrong there?
>
> regards,
>
> Wim
>

> 2010/3/4 Art Clarke <acla...@xuggle.com>


>
> > Hi Wim,
>
> > There is no Xuggler code in Red5 (I'm on that Red5 team) so you're using
> > some other piece of software.  Sorry, but without a repro case, I can't do
> > anything -- and frankly this is a free open-source product, so I need you to
> > spend the time to make a reproduction case because this isn't my day job :)
>
> > - Art
>

> > On Thu, Mar 4, 2010 at 7:30 AM, Wim Deblauwe <wim.debla...@gmail.com>wrote:
>
> >> Hi,
>
> >> I don't have a simple program that only uses Xuggle I am afraid. This is a
> >> red5 application. You can ask any of the red5 team, they have the source
> >> code or I can send it in a private email?
>
> >> regards,
>
> >> Wim
>

> >> 2010/3/4 Art Clarke <acla...@xuggle.com>


>
> >>>  Alright, looks like this qualifies for my "reliabily crashes a JVM"
> >>> qualifier for a P0 bug.  Do you have source code you could send me
> >>> (preferably as simple as possible including only Xuggler dependencies) that
> >>> can reliably reproduce the problem for you?
>
> >>> - Art
>

> ...
>
> read more »
>
>  sources.zip
> 128KViewDownload

Wim Deblauwe

unread,
Mar 9, 2010, 11:48:40 AM3/9/10
to xuggler-users
Another day xuggling/struggling:

Because the crash usually happens when switching streams (we call
stopSource() and then addSource() ), I thought I might have something
to do with memory being released too soon or something. I move all the
delete() calls on IVideoPicture and IPacket into a separate thread
with a delay of 1 second. I see already a big improvement (a lot
harder to crash the system), but still not perfect. The crash is also
no longer in the encodeVideo() or decodeVideo() methods like before,
but in the IContainer#readNextPacket() method now.

If this might make anybody think of something I can try extra, let me
know!

regards,

Wim

> ...
>
> meer lezen »

Art Clarke

unread,
Mar 9, 2010, 11:54:52 AM3/9/10
to xuggle...@googlegroups.com
Hi,

Sorry Wim, but I've had zero time to look at this, and probably won't for at least one to two more weeks.

- Art

--
You received this message because you are subscribed to the Google Groups "xuggler-users" group.
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.

Wim Deblauwe

unread,
Mar 11, 2010, 1:44:23 PM3/11/10
to xuggler-users
Hi,

good news. I found the source of the jvm crash. There was an error in
the shutdown of both the Processor and the Feed classes. It could
happen that the run() methods are still being executed (containing
calls to encodeVideo/decodeVideo/readNextPacket) and the shutdown was
happening from another thread and already closing the IContainer and
related classes. There was code in place to wait for run() to exit,
but it had a bug.

I added a bit of dirty hack for now to test and have seen no crashes
anymore. I will test some more and then try to refactor the code to
get a decent solution.

regards,

Wim


On 9 mrt, 17:54, Art Clarke <acla...@xuggle.com> wrote:
> Hi,
>
> Sorry Wim, but I've had zero time to look at this, and probably won't for at
> least one to two more weeks.
>
> - Art
>

> ...
>
> meer lezen »

Manol Avramov

unread,
Jun 12, 2017, 1:40:50 PM6/12/17
to xuggler-users
Hi, Im have the same problem. Can you tell what was the solution.
Reply all
Reply to author
Forward
0 new messages