Date: Sun, 26 Feb 2017 16:14:04 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-gecko@FreeBSD.org, FreeBSD Hackers <freebsd-hackers@FreeBSD.org> Subject: Re: firefox crashes during pkg upgrade Message-ID: <d971f579-4d92-196f-a91d-325f41fabcea@FreeBSD.org> In-Reply-To: <20170130104041.GK3018@kib.kiev.ua> References: <567BF197.10908@FreeBSD.org> <2a4cad57-ddbf-6ef0-13e6-c2d24280fd24@FreeBSD.org> <20170130104041.GK3018@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d971f579-4d92-196f-a91d-325f41fabcea>