[vlc-devel] Application using libvlc crashes
mfmbusiness at earthlink.net
Sat Mar 15 11:45:53 CET 2008
Don't let Rafael scare you off of Cygwin -- There's nothing very arcane to
building VLC using it, people have been great about making sure that it
My Cygwin is vanilla, recent, works fine to build both Cygwin and
The one big negative is that the build (configure and make) is very slow on
older single core machines. It is much faster on a modern dual core.
From: vlc-devel-bounces at videolan.org [mailto:vlc-devel-bounces at videolan.org]
On Behalf Of Rafaël Carré
Sent: Friday, March 14, 2008 7:26 PM
To: Mailing list for VLC media player developers
Subject: Re: [vlc-devel] Application using libvlc crashes
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
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
to /home/buildslave/slave/nb-win32-trunk/build (in cygwin that may be C:
so in build/ directory you should have the vlc source folders, i.e. not the
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 ;)
Rafaël Carré <funman at videolan.org>
More information about the vlc-devel