Debugging ffmpeg libs in Eclipse

[davidk]

Hi all

I'm trying to track down the cause of the MPEG buffer underflow
messages.

Has anyone (especially Art or Robert) advice on debugging the C++ code
once it's called from Java?

I know Eclipse will work on C++, but will it work on native method
calls?

Or will it be a matter of planting debug output?

I somehow suspect the problem in mpeg is that the packet output is
somehow occurring simultaneously with packet construction, as the
buffer size is growing while the packet declared size is static. But
that's just a hunch looking at the current error report.

best

David K

[Art Clarke]

Right, here's a series of steps that might help:

1) I find it easier to debug with GDB outside of Eclipse, but I have gotten CDT to work before.
2) Create a debug build of Xuggler (see the build instructions, and configure with --disable-optimizations).  This will ensure your object files to have source line information and will aid in debugging.  It will also build a DEBUG version of FFmpeg so you can step through line-by-line there.
3) Make sure your Eclipse set-up has the right environment variables set up in the process it launched in.
4) Install your debug build into your standard place (ant installer) to make sure it's picked up when you run Eclipse.
5) Restart Eclipse.

Now, this next step is tricky.  How do you attach GDB to your running program.  I'm going to show you all the steps assuming Linux (or MacOS).  Windows debugging is an order of magnitude harder.

The first way is to create a Java program that has some sort of pausing BEFORE loading a Xuggler method.  Make a stub program that doesn't actually begin running until you hit Enter on a console for example.  Run that Java program, and then when it is paused waiting for enter, open a new shell and attach with gdb (or use CDT's "Attach to Running C/C++ Process" debug profile):

# find the Process ID for the java process
> ps -ef | grep java
# attach GDB to the java process.  I assume the Process ID is 1234
> gdb `which java` 1234
# now you should be in GDB, set any breakpoints.  GDB will complain
# about libraries not being loaded and ask if you want to break on
# load; say yes
#
# finally tell GDB to continue (but remaining attached)
> continue

Now, return to your Java window and hit Enter.  Your breakpoints should hit.

Method two is if that approach doesn't work.  Xuggler has a mechanism built in where it will wait in an infinite loop for a debugger to attach on the first library load if needed.  To use that:

1) Run Java with the "com.xuggle.ferry.WaitForDebugger" property set to 1.
> java -Dcom.xuggle.ferry.WaitForDebugger=1 com.yourcompany.YourClass

2) Once the first Xuggler Jar is loaded, the following message will show up on your console:
> Waiting for debugger.  Please attach...

3) The message will tell you the file (JNIHelper.cpp) and line number where the message appears in Xuggler's source.  In a terminal, or using Eclipse's CDT "attach to process" find the Java process that is now stalled and attach

4) Using the GDB command "info threads", find the thread that is blocked in the JNIHelper::waitForDebugger method.  In this example I'll assume it's thread 12
> info threads
> thread 12

5) Now, set any breakpoints you want in your code

6) Finally, tell Xuggler to stop waiting by setting the following variable to a non-zero value
> set sDebuggerAttached = 1
> continue

Now, your breakpoints should be hit, and you should be able to step through C/C++ code in Eclipse.

Hope that helps,

- Art

--
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.

[Dave Peterson]

This seems to work pretty well although the instructions are a bit old and require some interpolation.  However, I cannot seem to get symbols loaded which is quite frustrating.
I can attach the process
I can find the thread
I can maneuver up the stack frames where I want to be to set the breakpoint, but once there....
l (for list)

No symbol table is loaded.  Use the "file" command.

[Dave Peterson]

Okay in case anyone else runs into similar issues.  Here are the steps that I took to get this working.  As Art says:  Mileage may vary... So tune these to your own desires, but definitely consider them:

# Xuggler Stuff
export clang=gcc
export CC=gcc
export CPP="cpp"
export export CXX="g++"
export LIBRARY_PATH=/opt/local/lib
export BINDIR=/opt/local/bin
export OPENSSLDIR=/opt/local/bin
export XUGGLE_NATIVE_CONFIGURE="--disable-optimizations --disable-stripping --enable-optimizations=no --x86_64-xuggle-darwin11-strip=no"
export XUGGLER_DEBUG=1
export CFLAGS="-g -gstabs"
export CPPFLAGS="-g -gstabs"
export CXXFLAGS="-g -gstabs"
export PKG_CONFIG_PATH=/usr/lib/pkgconfig
export SWIG=/opt/local/bin/swig
export PERL=/opt/local/bin/perl

The above should get you symbols into your .o, .dylib, .so, etc files.  However, that's not going to get symbols into the jar file in your maven repository since the build process strips the symbols out regardless of your export variables.  When I finally had my Doh! moment, I then proceeded to:

1.  cd $HOME/.m2/repository/xuggle/xuggle-xuggler/5.5
2.  Unpack my xuggler jar in the maven repo. (jar -xvf xuggle-xuggler-5.5.jar)
3. Replace the stripped version of your native code with the one with debug symbols in it (you can usually tell by the larger size or look for the ln -s command in your build output).
cp /projects/xuggle-xuggler/build/native/x86_64-xuggle-darwin11/csrc/com/xuggle/.libs/libxuggle.5.dylib com/xuggle/ferry/x86_64-xuggle-darwin11/libxuggle.dylib
4.  Repackage your jar again.  jar -cvf xuggle-xuggler-5.5.jar META-INF com

Now a
gdb `which java` <pid>

should show symbols and line numbers for debugging.

Good luck.
D