[vlc-devel] Application using libvlc crashes

[Rafaël Carré]

On Fri, 2008-03-14 at 18:33 -0400, jboileau wrote:
> Hi Rafael,
> 
> Thanks for responding I agree that my stack trace is not very
> valuable, but since I only use libvlc and do not compile libvlc its
> the best I could do. Someone tried to build it here using cygwin but
> was never successful.

Building from cygwin is crazy ;)
Building from Linux is very easy however, and there is detailed
instructions out there, on jbkempf.com/blog or on the wiki.

>  Since we are users of libvlc we never persevered
> in building it. I use the libvlc from the nightly build. I debug using
> the Visual Studio environment.

I think Visual Studio doesn't integrate well with binaries built with
mingw32, but i don't know Windows so I can not guarantee.

> Apart from building them myself is there a way to get libvlc and
> libvlc-control with debug information so that the satck trace can be
> easier to read?

The nightly builds already contain the debug symbols, the problem is how
to read them ^^
A windows developer (Quovidis who unfortunately left us ..) was able to
use cygwin's gdb.

If you're not comfortable with gdb, there is some good tutorials online,
and the simplest use case is:

$ gdb my_app
....
(gdb) run my multiple arguments
..... your app run a bit slower but it runs
CRASH
XXX segfault blablablabla
(gdb) bt full
VERY USEFUL INFO ON THE CRASH WITH LINE NUMBERS
(gdb) thread apply all bt full
VERY USEFUL INFO ON WHAT THE OTHER THREADS WERE DOING
(gdb) print my_variable
VERY USEFUL INFO ON WHAT WAS GOING ON

unfortunately, sometime you can not access the variables, for example if
the crash was an assert() or an abort() because the variables are out of
the scope of gdb (it's now in the libc code or whatever.dll).

To print the functions, files, and line numbers; gdb needs access to the
full source at the EXACT location where it was compiled, so you'll need
to unpack the source code used to build the nightly, from
http://nightlies.videolan.org/build/source/?C=M;O=D
to /home/buildslave/slave/nb-win32-trunk/build (in cygwin that may be C:
\cygwin\home\buildslave....

so in build/ directory you should have the vlc source folders, i.e. not
the vlc-124534245543/ folder

That should be enough to have proper backtraces ;)

>  One thing I have done in the past is use a tool that
> gives me the address of all the entry points in these DLLs and compare
> the address in the stack trace. That way I am usally able to give
> function names for the stack entries, but I am unsure of its validity.
> For example the last libvlc call in the trace I provided would be in
> __vlc_object_find which is at address 0x6a388ee0 since the trace is at
> address libvlc.dll!6a38978e(). The next function in libvlc is
> __var_Create at 0x6a389ee0	. I can always provide that information
> with my traces if it helps?

No, because I don't know how to assemble C code, and translate C code
from and to memory dumps ;)

> Jacques

-- 
Rafaël Carré <funman at videolan.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20080315/233da6ff/attachment.sig>