From owner-freebsd-gecko@freebsd.org Sun Feb 26 14:15:09 2017 Return-Path: Delivered-To: freebsd-gecko@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 AA3AACEEBC2; Sun, 26 Feb 2017 14:15:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B6A1CFB3; Sun, 26 Feb 2017 14:15:08 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA10301; Sun, 26 Feb 2017 16:15:01 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1chzbJ-0003XF-3f; Sun, 26 Feb 2017 16:15:01 +0200 Subject: Re: firefox crashes during pkg upgrade To: Konstantin Belousov References: <567BF197.10908@FreeBSD.org> <2a4cad57-ddbf-6ef0-13e6-c2d24280fd24@FreeBSD.org> <20170130104041.GK3018@kib.kiev.ua> Cc: freebsd-gecko@FreeBSD.org, FreeBSD Hackers From: Andriy Gapon Message-ID: Date: Sun, 26 Feb 2017 16:14:04 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170130104041.GK3018@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-gecko@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gecko Rendering Engine issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 14:15:09 -0000 On 30/01/2017 12:40, Konstantin Belousov wrote: > 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 [snip] >> 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. There is probably more than issue then. I managed to reproduce my issue with more debugging information: https://bugzilla.gnome.org/show_bug.cgi?id=779060 > 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. -- Andriy Gapon