Date: Mon, 30 Jan 2017 12:40:41 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Andriy Gapon <avg@FreeBSD.org> Cc: freebsd-gecko@FreeBSD.org, FreeBSD Hackers <freebsd-hackers@FreeBSD.org> Subject: Re: firefox crashes during pkg upgrade Message-ID: <20170130104041.GK3018@kib.kiev.ua> In-Reply-To: <2a4cad57-ddbf-6ef0-13e6-c2d24280fd24@FreeBSD.org> References: <567BF197.10908@FreeBSD.org> <2a4cad57-ddbf-6ef0-13e6-c2d24280fd24@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 30, 2017 at 12:13:34PM +0200, Andriy Gapon wrote: > On 24/12/2015 15:22, Andriy Gapon wrote: > > I've got a strange problem: sometime when I do pkg upgrade a firefox process > > crashes with SIGBUS. And that happens rather often. > > I am still seeing this problem. Sometimes it's firefox, sometimes thunderbird, > sometimes none, sometimes both. > > In all cases the crashes involve libgio. > > Here is the latest example. > Thunderbird aborted after hitting an assertion: > GLib-GIO:ERROR:glocalfilemonitor.c:344:g_file_monitor_source_handle_event: > assertion failed: (!child || is_basename (child)) > Redirecting call to abort() to mozalloc_abort > > (gdb) bt > #0 0x0000000802093d7a in thr_kill () from /lib/libc.so.7 > #1 0x0000000802093d4b in __raise (s=11) at /usr/src/lib/libc/gen/raise.c:52 > #2 0x0000000805e5ab13 in nsProfileLock::FatalSignalHandler(int, __siginfo*, > void*) () from /usr/local/lib/thunderbird/libxul.so > #3 0x0000000801db863a in handle_signal (actp=0x7fffffffd248, sig=11, > info=0x7fffffffd620, ucp=0x7fffffffd2b0) at /usr/src/lib/libthr/thread/thr_sig.c:244 > #4 0x0000000801db7d1f in thr_sighandler (sig=11, info=0x7fffffffd620, > _ucp=0x7fffffffd2b0) at /usr/src/lib/libthr/thread/thr_sig.c:189 > #5 <signal handler called> > #6 0x0000000001029a3d in mozalloc_abort(char const*) () > #7 0x0000000001029a5d in abort () > #8 0x000000080d22f08c in g_assertion_message () from > /usr/local/lib/libglib-2.0.so.0 > #9 0x000000080d22f0ee in g_assertion_message_expr () from > /usr/local/lib/libglib-2.0.so.0 > #10 0x000000080df5ea9b in g_file_monitor_source_handle_event () from > /usr/local/lib/libgio-2.0.so.0 > #11 0x000000080df65a3d in ?? () from /usr/local/lib/libgio-2.0.so.0 > #12 0x000000080df63c3e in ?? () from /usr/local/lib/libgio-2.0.so.0 > #13 0x000000080df644af in ?? () from /usr/local/lib/libgio-2.0.so.0 > #14 0x000000080d20ab75 in g_main_context_dispatch () from > /usr/local/lib/libglib-2.0.so.0 > #15 0x000000080d20aea4 in ?? () from /usr/local/lib/libglib-2.0.so.0 > #16 0x000000080d20af34 in g_main_context_iteration () from > /usr/local/lib/libglib-2.0.so.0 > #17 0x0000000805619ecc in nsAppShell::ProcessNextNativeEvent(bool) () from > /usr/local/lib/thunderbird/libxul.so > #18 0x00000008055eda96 in nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, > bool) () from /usr/local/lib/thunderbird/libxul.so > #19 0x00000008055edb5d in non-virtual thunk to > nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, bool) () from > /usr/local/lib/thunderbird/libxul.so > #20 0x0000000803ce7ec0 in nsThread::ProcessNextEvent(bool, bool*) () from > /usr/local/lib/thunderbird/libxul.so > #21 0x0000000803d0d143 in NS_ProcessNextEvent(nsIThread*, bool) () from > /usr/local/lib/thunderbird/libxul.so > #22 0x0000000803f930de in > mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) () from > /usr/local/lib/thunderbird/libxul.so > #23 0x0000000803f76618 in MessageLoop::Run() () from > /usr/local/lib/thunderbird/libxul.so > #24 0x00000008055ed7ab in nsBaseAppShell::Run() () from > /usr/local/lib/thunderbird/libxul.so > #25 0x0000000805e1f2ce in nsAppStartup::Run() () from > /usr/local/lib/thunderbird/libxul.so > #26 0x0000000805e64c22 in XREMain::XRE_mainRun() () from > /usr/local/lib/thunderbird/libxul.so > #27 0x0000000805e64f0d in XREMain::XRE_main(int, char**, nsXREAppData const*) () > from /usr/local/lib/thunderbird/libxul.so > #28 0x0000000805e652d1 in XRE_main () from /usr/local/lib/thunderbird/libxul.so > #29 0x00000000010294c0 in main () > > (gdb) fr 10 > #10 0x000000080df5ea9b in g_file_monitor_source_handle_event () from > /usr/local/lib/libgio-2.0.so.0 > (gdb) x/s $r15 > 0x82032ae40: 'Z' <repeats 11104 times>, "/usr/local/share/gnome" > > The above string is the value of 'child' parameter. > It seems like it points to some invalid memory. > Given that 'Z' is 0x5a it seems like freed memory. I am not sure that my issue is same as your issue, but I also see gtk applications sometimes faulting during the packages updates. If you take a look into firefox address map, there are the following interesting items: 1356 0x8023a1000 0x8023c1000 r-- 32 32 4 0 ---- vn /var/db/fontconfig/a2bfc4e431963a28dd6df8adc7776b96-le64.cache-7 1356 0x80797a000 0x8079b9000 r-- 39 44 2 0 CN-- vn /usr/sfw/local8/share/fonts/webfonts/tahoma.ttf 1356 0x80eeb0000 0x80eecf000 r-- 16 16 1 0 ---- vn /usr/sfw/local8/share/mime/mime.cache 1356 0x80eecf000 0x80eedd000 r-- 14 14 2 0 CN-- vn /usr/sfw/local8/share/icons/Adwaita/icon-theme.cache 1356 0x80ee1e000 0x80ee4a000 r-- 44 44 1 0 CN-- vn /usr/home/kostik/.mozilla/firefox/q3eu9l5y.default/extensions/compatibility@addons.mozilla.org.xpi 1356 0x815800000 0x817100000 r-- 256 260 1 0 ---- vn /usr/sfw/local8/share/icu/58.2/icudt58l.dat They are many different things I picked, e.g. the fontconfig cache files, ttf fonts, some icons pointers, xpi extentions, probably there are more things to list. The common between them is the fact that they are mapped into the target process, but they are not ELF shared objects. More, I know that at least fontconfig and icons caches are rebuilt at the package install or upgrade time. The problem with them is that the files are filled with the new data live. This means that the previous mapping potentially shrinked, and previously read data, in particular, internal pointers in the process inside the mapped data, also invalidated. For shared objects, pkg ensures that the existing mappings are not affected, by removing and then recreating the files. No such procedure exists or can be applied to the caches. I discussed this once with bapt, no good solution seems to exist.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170130104041.GK3018>