GNOME Bugzilla – Bug 608751
[assrender] Random crashes because libass is not threadsafe
Last modified: 2010-02-23 17:19:19 UTC
I'll fill this later. ProblemType: Crash Architecture: i386 CheckboxSubmission: b8398b21075a3a8723b2ba20478c4f9e CheckboxSystem: 703a6ca1eefae989daaf40c6bb6aa94a CrashCounter: 1 Date: Mon Feb 1 13:09:22 2010 DistroRelease: Ubuntu 10.04 ExecutablePath: /usr/bin/totem InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha i386 (20091209) Package: libgstreamer0.10-0 0.10.25.2-2ubuntu1 ProcCmdline: totem ProcEnviron: LANG=en_US.utf8 SHELL=/bin/bash ProcVersionSignature: Ubuntu 2.6.32-12.16-genusername SegvAnalysis: Segfault happened at: 0x66d5ec1 <*__GI___libc_free+49>: mov 0x4(%edx),%eax PC (0x066d5ec1) ok source "0x4(%edx)" (0x00000808) not located in a known VMA region (needed readable region)! destination "%eax" ok SegvReason: reading NULL VMA Signal: 11 SourcePackage: gstreamer0.10 StacktraceTop: *__GI___libc_free (mem=0x80c) at malloc.c:3709 ass_clear_fonts (priv=0x9ae8b78) at ass_library.c:123 ass_library_done (priv=0x9ae8b78) at ass_library.c:53 gst_ass_render_finalize (object=0x9ae60c0) IA__g_object_unref (_object=0x9ae60c0) Title: totem crashed with SIGSEGV in *__GI___libc_free() Uname: Linux 2.6.32-12-generic i686 UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
Created attachment 152793 [details] Dependencies
Created attachment 152794 [details] Disassembly
Created attachment 152795 [details] ProcMaps
Created attachment 152796 [details] ProcStatus
Created attachment 152797 [details] Registers
Created attachment 152798 [details] Stacktrace
Created attachment 152799 [details] ThreadStacktrace
Created attachment 152800 [details] XsessionErrors
Do you have a way to reproduce this? Would be good to get a complete backtrace without optimizations or even a valgrind log... this looks like a libass issue IMHO.
Reproducing is as simple as opening an MKV file that contains an ASS track in Totem. I believe it is a regression brought on by a commit to -base in November since I recall from a few weeks ago that bad git + base 0.10.25.0 doesn't trigger the issue. Of course, that combination doesn't allow styled subtitles to work in Totem. I'll try narrow down the offending commit again since I have forgot. Also, this bug doesn't occur when running an MKV file with ASS through playbin2.
BTW, here's a valgrind log. http://www.mediafire.com/?zzjlmywnz3z
(In reply to comment #10) > Reproducing is as simple as opening an MKV file that contains an ASS track in > Totem. I believe it is a regression brought on by a commit to -base in November > since I recall from a few weeks ago that bad git + base 0.10.25.0 doesn't > trigger the issue. Of course, that combination doesn't allow styled subtitles > to work in Totem. I'll try narrow down the offending commit again since I have > forgot. Do you have this with every MKV file containing ASS tracks? I can't reproduce this here with GIT and totem 2.29.6... also the valgrind log is not very useful, it doesn't contain any segfaults :(
Ever since last night's removal of ass_set_fonts_dir, I'm noticing that Totem no longer hangs or crashes every single time I load a MKV file. Instead now, it will sometimes load the file properly on the first attempt when using "Open", but if doesn't succeed for whatever reason, it may load on the second attempt when using "Open" again. If Totem again fails to load the file, I get the output below.
Created attachment 152848 [details] gdb segfault
(In reply to comment #14) > Created an attachment (id=152848) [details] > gdb segfault Could you also get a backtrace? :)
Backtrace attached (hope I logged it properly). BTW, I'll try to get a valgrind that contains a segfault. It's harder to trigger through valgrind than through gdb.
Created attachment 152852 [details] gdb backtrace
And I did do it wrong... Proper backtrace attached.
Created attachment 152853 [details] gdb backtrace (proper)
This looks very much like a libass, freetype or configuration problem. The same file works fine with other players that use the same libass version?
mplayer git, libass tests, and vlc git all handle the files properly. playbin2, as of the latest commits to bad, is doing quite well too. This problem is restricted to Totem's handling of the aforementioned files.
Ok, no idea then... hm, would really help if I could reproduce it here or if you could get a valgrind log of the crash.
I'm unable to reproduce this with current -base, -good, -bad and -ffmpeg plus Ubuntu 9.10's Totem. Still, maybe there is a problem... I'm not sure how threads are used in gstreamer, please make sure that only one thread at a time uses a ass_renderer or ass_track. libass is reentrant but doesn't do any locking on its objects by itself.
I'm getting a multitude of distinct, yet related segfault errors all triggered by the file loading.
Created attachment 153744 [details] Another backtrace with multiple segfaults
Here's a Valgrind with FreeType marking the start of the crash.
http://www.mediafire.com/?xz3lmnhgzxe
Is there anything else I can provide that would help get this bug a closer look before the next bad release?
(In reply to comment #25) > Created an attachment (id=153744) [details] > Another backtrace with multiple segfaults A single 'thread apply all bt' stack trace might be more useful.
Let each instance of a file being loaded represent a separate trace.
Created attachment 154512 [details] thread apply all bt
Created attachment 154519 [details] [review] assrender: Protect libass structures from concurrent access from multiple threads Fixes bug #608751.
commit 0dbe95a97d553635c21b476f7206da4bf2bee652 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Tue Feb 23 18:16:48 2010 +0100 assrender: Protect libass structures from concurrent access from multiple th Fixes bug #608751.