VLC with skins2 interface crashes on start

[sgimeno]

Hello,

I'm experiencing a crash starting vlc with skins2 default interface.
I have debian squeeze in a KVM virtual machine and VLC 1.1.3-1 from the debian repositories. This crash does not happen if debian is installed as normal (no virtual machine).
I start vlc like this:

Code: Select all

vlc -I skins2

I have compiled the sources in debug mode and the backtrace shows this:

Code: Select all

#0 0xb7fe2416 in __kernel_vsyscall () #1 0xb7d88751 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xb7d8bb82 in *__GI_abort () at abort.c:92 #3 0xb7dbf18d in __libc_message (do_abort=2, fmt=0xb7e83758 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 #4 0xb7dc9281 in malloc_printerr (action=<value optimized out>, str=0x6 <Address 0x6 out of bounds>, ptr=0x84add40) at malloc.c:6267 #5 0xb7dcaad8 in _int_free (av=<value optimized out>, p=<value optimized out>) at malloc.c:4795 #6 0xb7dcdbbd in *__GI___libc_free (mem=0x84add40) at malloc.c:3739 #7 0xb5ad7559 in ?? () from /usr/lib/libX11.so.6 #8 0xb450761b in X11Graphics::drawBitmap (this=0x84ad940, rBitmap=..., xSrc=0, ySrc=0, xDest=0, yDest=0, width=17, height=19, blend=false) at x11/x11_graphics.cpp:270 #9 0xb44be617 in AnimBitmap (this=0x84ad6e4, pIntf=0x8183aa8, rBitmap=...) at src/anim_bitmap.cpp:39 #10 0xb4469ce1 in CtrlButton (this=0x84ad668, pIntf=0x8183aa8, rBmpUp=..., rBmpOver=..., rBmpDown=..., rCommand=..., rTooltip=..., rHelp=..., pVisible=0x8218770) at controls/ctrl_button.cpp:45 #11 0xb4495081 in Builder::addButton (this=0xb2df1178, rData=...) at parser/builder.cpp:465 #12 0xb448fb93 in add_objects<BuilderData::Button> (this=0xb2df1178) at parser/builder.cpp:86 #13 Builder::build (this=0xb2df1178) at parser/builder.cpp:112 #14 0xb44cbe97 in ThemeLoader::parse (this=0x823f738, path=..., xmlFile=...) at src/theme_loader.cpp:365 #15 0xb44ccea5 in ThemeLoader::extract (this=0x823f738, fileName=...) at src/theme_loader.cpp:328 #16 0xb44cd696 in ThemeLoader::load (this=0x823f738, fileName=...) at src/theme_loader.cpp:87 #17 0xb44c8942 in Run (p_obj=0x8183aa8) at src/skin_main.cpp:262 #18 0xb7ead955 in start_thread (arg=0xb2df1b70) at pthread_create.c:300 #19 0xb7e29e7e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

And running it with valgrind shows this (I just copy a part of it):

Code: Select all

==10573== Invalid write of size 1 ==10573== at 0x5FB5F1D: X11Display::putPixel32LSB(unsigned char*, unsigned char, unsigned char, unsigned char, unsigned char) const (x11_display.cpp:449) ==10573== by 0x5FBB2D4: X11Graphics::drawBitmap(GenericBitmap const&, int, int, int, int, int, int, bool) (x11_graphics.cpp:231) ==10573== by 0x5F725F6: AnimBitmap::AnimBitmap(intf_thread_t*, GenericBitmap const&) (anim_bitmap.cpp:39) ==10573== by 0x5F1DCC0: CtrlButton::CtrlButton(intf_thread_t*, GenericBitmap const&, GenericBitmap const&, GenericBitmap const&, CmdGeneric&, UString const&, UString const&, VarBool*) (ctrl_button.cpp:45) ==10573== by 0x5F49060: Builder::addButton(BuilderData::Button const&) (builder.cpp:465) ==10573== by 0x5F43B72: Builder::build() (builder.cpp:86) ==10573== by 0x5F7FE76: ThemeLoader::parse(std::string const&, std::string const&) (theme_loader.cpp:365) ==10573== by 0x5F80E84: ThemeLoader::extract(std::string const&) (theme_loader.cpp:328) ==10573== by 0x5F81675: ThemeLoader::load(std::string const&) (theme_loader.cpp:87) ==10573== by 0x5F7C921: Run(void*) (skin_main.cpp:262) ==10573== by 0x414C954: start_thread (pthread_create.c:300) ==10573== by 0x422FE7D: clone (clone.S:130) ==10573== Address 0x4aa1264 is 0 bytes after a block of size 988 alloc'd ==10573== at 0x4023F50: malloc (vg_replace_malloc.c:236) ==10573== by 0x60185F3: XGetImage (in /usr/lib/libX11.so.6.3.0) ==10573== by 0x5FBB037: X11Graphics::drawBitmap(GenericBitmap const&, int, int, int, int, int, int, bool) (x11_graphics.cpp:193) ==10573== by 0x5F725F6: AnimBitmap::AnimBitmap(intf_thread_t*, GenericBitmap const&) (anim_bitmap.cpp:39) ==10573== by 0x5F1DCC0: CtrlButton::CtrlButton(intf_thread_t*, GenericBitmap const&, GenericBitmap const&, GenericBitmap const&, CmdGeneric&, UString const&, UString const&, VarBool*) (ctrl_button.cpp:45) ==10573== by 0x5F49060: Builder::addButton(BuilderData::Button const&) (builder.cpp:465) ==10573== by 0x5F43B72: Builder::build() (builder.cpp:86) ==10573== by 0x5F7FE76: ThemeLoader::parse(std::string const&, std::string const&) (theme_loader.cpp:365) ==10573== by 0x5F80E84: ThemeLoader::extract(std::string const&) (theme_loader.cpp:328) ==10573== by 0x5F81675: ThemeLoader::load(std::string const&) (theme_loader.cpp:87) ==10573== by 0x5F7C921: Run(void*) (skin_main.cpp:262) ==10573== by 0x414C954: start_thread (pthread_create.c:300)

Any idea of what mught be happening?

Thanks in advance,

Santi

[erwan10]

The area at stake (where invalid write occurs) is provided by a XGetImage X11 call for retrieving a stored pixmap. (modules/gui/skins2/x11/x11_graphics.cpp:192)

For an unknown reason, this call doesn't provide what is expected if a KVM is used. On the vlc side, code could probably be strengthened (more checks) before addressing this memory area. As for what caused this issue, I have no clue just now. It can be a vlc bug or a kvm bug ?

A few more questions :

- does that crash for _any_ skins or just the default one ? (other skins available at http://www.videolan.org/vlc/skins.php)
- What is the KVM you use (brand, version, ...) ?

[sgimeno]

First of all thanks for the answer

Regarding your questions:

1) I just tried a new skin and the crash still happens. This time the error raised by glib is a bit different:

Code: Select all

*** glibc detected *** vlc: double free or corruption (out) ***

instead of the:

Code: Select all

*** glibc detected *** vlc: free(): invalid next size (normal)

that was raised with the default skin.
The backtrace and the valgrind output is basically the same as the default though.

2) The KVM package I'm using is this:

Code: Select all

dpkg -l | grep kvm ii qemu-kvm 0.12.5+dfsg-3 Full virtualization on x86 hardware

Thanks!

[Rémi Denis-Courmont]

That's the same error. Either way, the heap gets corrupted. It might take a 'while' for glibc to detect heap corruption. Consequently, the crash may occur in a code path completely unrelated to the bug, that happens to allocate or free heap memory.

Only valgrind can be trusted for that kind of bugs.

[sgimeno]

Just in case is useful, find the complete valgrind output in:

http://pastebin.com/BSn53bv4

Thanks!