From owner-freebsd-hackers@freebsd.org Mon Jan 30 10:40:49 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D2D8CC7E5F; Mon, 30 Jan 2017 10:40:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E12588F0; Mon, 30 Jan 2017 10:40:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v0UAefUl068674 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Jan 2017 12:40:41 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v0UAefUl068674 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v0UAefS7068673; Mon, 30 Jan 2017 12:40:41 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 30 Jan 2017 12:40:41 +0200 From: Konstantin Belousov To: Andriy Gapon Cc: freebsd-gecko@FreeBSD.org, FreeBSD Hackers Subject: Re: firefox crashes during pkg upgrade Message-ID: <20170130104041.GK3018@kib.kiev.ua> References: <567BF197.10908@FreeBSD.org> <2a4cad57-ddbf-6ef0-13e6-c2d24280fd24@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a4cad57-ddbf-6ef0-13e6-c2d24280fd24@FreeBSD.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 10:40:49 -0000 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 > #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' , "/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.