Packman's VLC Player v2.2.4-29.1 Seg-Faults

Packman’s VLC package hasn’t been changed since September though…

Anyway, try to uninstall vlc-codec-gstreamer, I do remember other people having problems with that months ago.

I’d still recommend you to uninstall it, if you want to use the nvidia driver.

As mentioned, it only really makes sense with intel, as it redirects nvidia’s hardware decoding to intel’s (simply put).
And VLC does support intel’s hardware decoding by itself, no need for such a “hack”.

Your problem may somehow be related to the problems mentioned in this thread though:
There seem to be common problems with nvidia when using suse-prime currently…

  • libvdpau_va_gl1 not installed.
  • vlc-codec-gstreamer already installed.- the problem persists, no matter if it’s opensource or proprietary nvidia driver.

Problem solved with the installation of VLC Beta. :slight_smile:

Even so, smplayer featuring superior performance!

Yeah, that was directed at danielbasel. And he also posted already that it didn’t help.

At least in your case it’s actually vlc-cache-gen that crashes (when it loads the plugins apparently) though, that’s completely unrelated to video playback (so I would not expect libvdpau_va_gl1 being the problem in the first place).

  • vlc-codec-gstreamer already installed.

I wrote that you should try to uninstall it.

I meanwhile remembered that somebody recently pinned down a crash to the notify plugin.
So deleting that, /usr/lib64/vlc/plugins/notify/, may help too.

But if vlc-beta works for you, stick to that (or mpv/smplayer) I’d say.

There are some similar crash reports on the Packman mailing list.
Nobody posted a crash backtrace so far though, so it is impossible to even guess what the cause may be… :\

Personally, I never had any problem with VLC here since years, not on 13.2 and not on 42.2 (with intel and radeon).
So it’s definitely not a general problem.

I would if I knew how to :slight_smile:
starting vlc from command line just gives “Speicherzugriffsfehler”, nothing else…

You said, vlc on packman hasn’t changed since a long time, but I definitively had updates - it’s since that update that it doesn’t work anymore:

2017-01-12 16:02:20 vlc-noX-2.2.4-34.1.x86_64.rpm installed ok

Additional rpm output:

/var/tmp/rpm-tmp.3gqnPm: line 2: 14132 Segmentation fault /usr/lib64/vlc/vlc-cache-gen -f /usr/lib64/vlc/plugins

warning: %post(vlc-noX-2.2.4-34.1.x86_64) scriptlet failed, exit status 139

2017-01-12 16:02:20|install|vlc-noX|2.2.4-34.1|x86_64|||642b9797feb161e5ed60fdb4313e71c83446b3b42c6b73633e163141de1ab0b9|

2017-01-12 16:02:20 vlc-codecs-2.2.4-34.1.x86_64.rpm installed ok

Additional rpm output:

/var/tmp/rpm-tmp.ZYlkFE: line 1: 14137 Segmentation fault /usr/lib64/vlc/vlc-cache-gen -f /usr/lib64/vlc/plugins

warning: %post(vlc-codecs-2.2.4-34.1.x86_64) scriptlet failed, exit status 139

2017-01-12 16:02:20|install|vlc-codecs|2.2.4-34.1|x86_64|||b5b7144354ea42a42a3021643f0cdf279fa104333e1696b7ecac7986268f0ae5|

2017-01-12 16:02:21 vlc-qt-2.2.4-34.1.x86_64.rpm installed ok

Additional rpm output:

/var/tmp/rpm-tmp.hi4PHZ: line 1: 14140 Segmentation fault /usr/lib64/vlc/vlc-cache-gen -f /usr/lib64/vlc/plugins

warning: %post(vlc-qt-2.2.4-34.1.x86_64) scriptlet failed, exit status 139

2017-01-12 16:02:21|install|vlc-qt|2.2.4-34.1|x86_64|||ee95e6536f63f8a4d52eeb078c0a3e146c838f87ef8ee1cf9ca3cf7e1f89dd93|

2017-01-12 16:02:21 vlc-2.2.4-34.1.x86_64.rpm installed ok

Additional rpm output:

/var/tmp/rpm-tmp.ehRnI6: line 1: 14143 Segmentation fault /usr/lib64/vlc/vlc-cache-gen -f /usr/lib64/vlc/plugins

warning: %post(vlc-2.2.4-34.1.x86_64) scriptlet failed, exit status 139

2017-01-12 16:02:21|install|vlc|2.2.4-34.1|x86_64|||13b7daf6443d45293a7f902bc475e9f1112459ec76abc819c927ea31cc4b9f26|
2017-01-12 16:02:22|install|flash-plugin||x86_64|||5d9015ed704c7630a5b2c5a0084487becaa089e5|

Run vlc-cache-gen in gdb and get the backtrace with “bt”… :wink:

Alternatively, the coredump should be saved automatically, when it crashes.
“coredumpctl” (run as root) should list it.

You said, vlc on packman hasn’t changed since a long time, but I definitively had updates - it’s since that update that it doesn’t work anymore:

If some package is updated on which vlc depends (like ffmpeg), vlc will get rebuilt too.
But the package itself hasn’t been changed since September, and that was only a manually added dependency on an unrestricted libavcodec and changes to the package description.
The last “real” change was in August.

As I don’t see the crash here, and you don’t see it with intel either IIRC, I’d suspect this is somehow caused by the nvidia driver though, wouldn’t be the first time that a bug there would cause strange crashes… :confused:
Or maybe related to suse-prime, which somehow needs to make nvidia’s OpenGL libs available when running on nvidia and hide them when running on intel.

Btw, Packman’s vlc package is just a link to the standard package in 42.2, only built with full codec support.

Huuu, after googling a bit I see that the gdb thing is for people with better skills than I have :slight_smile:

I tried to run /usr/lib64/vlc/vlc-cache-gen but there was no output at all.
I tried coredumpctl (systemd-coredumpctl) and it just told me “No coredumps found”…

Yes, it looks as if its an nvidia or suse-prime thing as obviously only few people are affected. So I guess I have to wait until a new nvidia update appears and cross fingers :slight_smile:

Well, yes, but just getting a backtrace is not really difficult:

  • Run “gdb command
  • type in “run” to start the application (or “run arg1 arg2 …” if you want to pass command line parameters)
  • reproduce the crash/wait for the crash to happen
  • type “bt” to get the backtrace that should show where it crashes

Ideally you should have the corresponding debuginfo packages installed (gdb tells you which ones are missing), but even if not it should at least give some hint already.

I tried to run /usr/lib64/vlc/vlc-cache-gen but there was no output at all.

You probably need to add the ‘-f’ parameter to force a regeneration of the cache, otherwise it will likely just do nothing (if the cache already exists).
And I think you need to specify the plugin directory too.

The exact command that crashed on your system is this according to your zypper log:

/usr/lib64/vlc/vlc-cache-gen -f /usr/lib64/vlc/plugins

(this is the command that the vlc packages run on installation to generate the cache in the first place)

So try if you can reproduce the crash with this.

I tried coredumpctl (systemd-coredumpctl) and it just told me “No coredumps found”…

This feature uses systemd’s journal.

If you use a “normal” syslog daemon (e.g. when you upgraded from 13.1 or earlier), the journal is runtime-only and gets “erased” when you reboot.
Maybe that’s the case here?

PS: If vlc works fine for you when using intel, try to generate the cache while using intel, i.e. run “sudo /usr/lib64/vlc/vlc-cache-gen -f /usr/lib64/vlc/plugins” after switching to intel.
This may fix vlc on nvidia too.

For explanation: it’s obviously some plugin that is crashing when it is being loaded. vlc-cache-gen loads every plugin it finds and adds the information to the cache.
VLC normally uses the cache to get all available plugins, but if it sees one on your hard disk that is not mentioned in the cache, it explicitly loads it on startup to find out more about that plugin.
But as vlc-cache-gen crashed, the affected plugins are likely not in the cache, so VLC tries to load them on startup and crashes too.

If it’s only one (or some) plugin that crashes, it may help therefore to make sure that one is in the cache, as VLC should not load it at all then (unless you explicitly activated it).

Good news first:

This did the trick. VLC now works perfect with nvidia, too.
Thanks a lot, you’re a genious!

(what I did: switched to intel graphics using suse-prime command, logged-out/in, run “/usr/lib64/vlc/vlc-cache-gen -f /usr/lib64/vlc/plugins”, switched back to nvidia, logged-out/in, started a video with vlc, smiled :slight_smile: )

I was not able to use the gdb thing.
First I installed all corresponding debug and devel packages for vlc using yast, but then gdb wanted lots more. It showed me two lines with each one zypper install command, which I tried, but zypper did not find those programs. I could also not find them using yast search (including “rpm provides”). I did not try the third zypper install command that gdb showed me because that one contained maybe a hundred things to install (didn’t count, but the command filled whole console window…). “bt” then said there’s no stack, or something like that…

So, for me, the problem is solved, thanks again!
If I can help testing something more (with my reduced skills…), just ask. I’ll be happy to give tries.

Ok, then it is not a simple crash, and not easy to debug anyway.
Apparently there’s some stack corruption or similar, so gdb cannot determine where it crashes.

But if it works for you now, that’s fine I suppose.
Just remember that you may have to rerun that command after a vlc update (unless the problem is fixed somehow already then) or install the updates using intel in the first place.

Follow-up with another solution.

Run as root:

strace /usr/lib64/vlc/vlc-cache-gen -f /usr/lib64/vlc/plugins

(After installing/updating vlc the script causes the segfault. Running it with strace obviously avoids the segfault)
(Found this solution here:,139831.30.html
because I installed a new leap 42.1 on an PC with only a nvidia card and could not use the “trick” that worked on my laptop)