vlc crashed with SIGSEGV in FcConfigFilename()

[astrogio84]

Binary package hint: vlc

I can't execute any video with vlc after I upgrade my system to Karmic 64 bit.

ProblemType: Crash
Architecture: amd64
Date: Mon Oct 5 12:54:40 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/bin/vlc
NonfreeKernelModules: nvidia
Package: vlc-nox 1.0.2-1ubuntu1
ProcCmdline: vlc
ProcEnviron:
 LANG=it_IT.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-11.38-generic
SegvAnalysis:
 Segfault happened at: 0x7f53df01d73a <FcConfigFilename+26>: movzbl (%rdi),%eax
 PC (0x7f53df01d73a) ok
 source "(%rdi)" (0x00000068) not located in a known VMA region (needed readable region)!
 destination "%eax" ok
SegvReason: reading NULL VMA
Signal: 11
SourcePackage: vlc
StacktraceTop:
 FcConfigFilename () from /usr/lib/libfontconfig.so.1
 FcConfigParseAndLoad ()
 ?? () from /usr/lib/libass.so.3
 ass_set_fonts () from /usr/lib/libass.so.3
 ?? () from /usr/lib/vlc/codec/liblibass_plugin.so
Title: vlc crashed with SIGSEGV in FcConfigFilename()
Uname: Linux 2.6.31-11-generic x86_64
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

[salva84 (salva-ms)]

same problem

[Aaron Mayse (eyeless1)]

Same here. I think it's an audio problem:

-it only happens when playing .mkv files; .avi works perfectly fine.
-it happens regardless of which video driver I'm using (fglrx or the open source ati driver), and I notice the above user is using an NVIDIA card
-it also affects mplayer, which crashes and specifically mentions audio problems.

[Aaron Mayse (eyeless1)]

Oh, right, and I'll note that, when I first updated my distribution (on 10/24) the same videos--the ones that crash vlc and mplayer--played just fine. They only crashed after I hit the update manager *after* the distribution upgrade.

[rusivi2 (rusivi2-deactivatedaccount)]

Thank you for reporting this bug.

Does this happen in Lucid?

[Vish (vish)]

Reading the upstream bug, this has been discussed and is a known bug.
Reverting status to triaged

[Rémi Denis-Courmont (rdenis)]

Unfortunately, this bug cannot be fixed at the VLC level: It seems Fontconfig is not re-entrant. QtGui uses it, the VLC FreeType plugin uses it, and I think libass uses it too. There is no way that all those three libraries can interlock their usage of Fontconfig.

That leaves only two possible solutions:

(1) Fontconfig could be linked statically in the VLC FreeType plugin, and in QtGui and/or libass. This would ensure that each component would use its own image of Fontconfig so that interlocking is not needed. This requires changes in Ubuntu packaging more so than in VLC upstream. I am not authoritative on the topic of Ubuntu packaging, but I would guess this would be a violation of the Ubuntu library policy.

(2) Modify Fontconfig itself so that it becomes reentrant/thread-safe.

Ubuntu maintainers, please advise.

[Reinhard Tartler (siretart)]

Remi,

I've now opened a fontconfig bugtask for this issue so that fontconfig experts can review this; I've found http://osdir.com/ml/fonts.fontconfig/2006-02/msg00135.html after short googling, which indicates that fontconfig indeed seems to be not thread safe.

However, in the presented backtrace here I see that only thread 1 is executing code from libfontconfig.so.1. Can you please elaborate what makes you think that this particular crash is a syncronization problem in libfontconfig?

[Rémi Denis-Courmont (rdenis)]

Note that the Qt4 thread is doing font manipulation. Too big coincidence...

[dino99 (9d9)]

This version is outdated and no more supported