vlc crashes with SIGABRT at startup or when "Show Playlist" is clicked

[petski]

Binary package hint: vlc

Package-version: 0.9.8a-1ubuntu4
Release: jaunty
Architecture: x86_64

gdb info is attached.

libaa1 (1.4p5-37build1)
libc6 (2.9-4ubuntu2)
libcaca0 (0.99.beta16-1)
libdbus-1-3 (1.2.12-0ubuntu2)
libfreetype6 (2.3.7-2ubuntu1)
libfribidi0 (0.10.9-1)
libgcc1 (1:4.3.3-5ubuntu3)
libgl1-mesa-glx (7.3-1ubuntu3)
libglib2.0-0 (2.19.10-1)
libglu1-mesa (7.3-1ubuntu3)
libgtk2.0-0 (2.15.5-0ubuntu1)
libnotify1 (0.4.5-0ubuntu1)
libqtcore4 (4.5.0-0ubuntu1)
libqtgui4 (4.5.0-0ubuntu1)
libsdl-image1.2 (1.2.6-3)
libsdl1.2debian (1.2.13-4ubuntu3)
libstdc++6 (4.3.3-5ubuntu3)
libtar (1.2.11-5ubuntu1)
libvlccore0 (0.9.8a-1ubuntu4)
libx11-6 (2:1.1.99.2-1ubuntu2)
libx264-65 (1:0.svn20081230-0.0ubuntu1)
libxext6 (2:1.0.99.1-0ubuntu2)
libxinerama1 (2:1.0.3-2)
libxv1 (2:1.0.4-1)
libxxf86vm1 (1:1.0.2-1)
ttf-dejavu-core (2.28-1)
vlc-nox (0.9.8a-1ubuntu4)
zlib1g (1:1.2.3.3.dfsg-12ubuntu1)

(Wonder why vlc depends on both libgtk2 and libqtgui4)

[petski (petski)]

Just noticed there's a vlc-dbg package as well. Recaptured the backtrace.

[petski (petski)]

The cause of the issue is that modules/gui/qt4/components/playlist/sorting.h::i_column_sorting is being called with i_column = 0 from PLModel::sort. This case isn't catched in the switch, so the default is taken: abort().

I've made a small patch (find it attached) with which vlc will sort by COLUMN_NUMBER by default, instead of aborting. Probably not the best solution... I recompiled the vlc package in my PPA and finally I can startup vlc :).

Follow the instructions at https://launchpad.net/~petski to enable my PPA in case you want to test the package.

[petski (petski)]

Someone provided a package for vlc 0.9.9a (See LP #356310). I've tried to see if the new vlc version would resolve this bug, but unfortunately it didn't. When I go to "Playlist -> Show Playlist", the program still crashes with SIGABRT.

Attached it the dpatch I've used to patch the package provided in LP #356310. The patch resolves this bug.

[petski (petski)]

One of the Videolan developers, Jean-Baptiste Kempf, created a patch which resolves this issue. The contents of the patch can be found at [1]. I've attached a debdiff against Jaunty's current 0.9.9a-2ubuntu1. Again, all credits to Jean-Baptiste Kempf.

[1] http://trac.videolan.org/vlc/changeset/f9f2d307e707a510cb93d2ac20f0a87ba5895ace

[Morten Kjeldgaard (mok0)]

As the fix only applies to jaunty, we need an SRU for it. Please see here what is required: https://wiki.ubuntu.com/StableReleaseUpdates

First off, I can't reproduce this bug on jaunty/amd54 vlc_0.9.9a-2ubuntu1 -- and as you can see from the SRU writeup, we ned "detailed instructions how to reproduce the bug". Can you give some more information?

I've checked the patch, it looks like it's a sane "one-liner".

[petski (petski)]

The patch wasn't in Karmic at the time this bug was created. I can confirm the patch is Karmic.

The patch isn't in Jaunty, but it would be nice if it can be included. Don't know how to reproduce the bug and why I was suffering from it, while others did not (just a guess, but I would expect more simular bugs if it were the case). Unfortunately, the vlc-developer who created the patch didn't had the time to explain the root cause to me.

[Antony Riley (antony-cyberiantiger)]

Suffered this bug in jaunty, I don't know how to reproduce it, though I'll spend some more time working out how I did it.

I had to delete all the config files to make vlc work again, I don't know which one finally fixed it as I did them all at once.

rm ~/.cache/vlc/plugins-04041e.dat
rm ~/.local/share/vlc/ml.xspf
rm -rf ~/.config/vlc/

I'll try to reproduce it again but I can't promise anything. I'll also try to provide a better work around which does not involve deleting the entire configuration file.

[femtoRgon (femtorgon)]

Had this problem recently, in jaunty.
Experimented a bit, and problem seems to be caused in:
~/.config/vlc/vlc-qt-interface.conf
Seemed to be caused by:
[Playlist] -> headerState
Changing the 20th (numbering from 1) byte from \x4 to \0 fixed it.
This is probably already known, but there is what I've noticed.