Date: Thu, 24 Dec 2015 12:37:21 -0600 From: Joe Maloney <jmaloney@pcbsd.org> To: Andriy Gapon <avg@FreeBSD.org>, <freebsd-gecko@FreeBSD.org> Cc: FreeBSD Hackers <freebsd-hackers@FreeBSD.org> Subject: Re: firefox crashes during pkg upgrade Message-ID: <151d547f2e8.2710.65a736056516fedbe0e39048eb84e883@pcbsd.org> In-Reply-To: <567BF197.10908@FreeBSD.org> References: <567BF197.10908@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I can confirm this happens to me as well. I believe it is a long standing problem. Joe Maloney On December 24, 2015 7:23:47 AM Andriy Gapon <avg@FreeBSD.org> wrote: > > Greetings! > > I've got a strange problem: sometime when I do pkg upgrade a firefox process > crashes with SIGBUS. And that happens rather often. > > For example, the last upgrade did the following package upgrades: > Installed packages to be UPGRADED: > rubygem-bundler: 1.10.6 -> 1.11.2 [FreeBSD] > pylint-py27: 1.4.3_1 -> 1.5.1 [FreeBSD] > py27-logilab-common: 0.63.2 -> 1.1.0 [FreeBSD] > py27-astroid: 1.3.6 -> 1.4.1 [FreeBSD] > php5-libphutil: 20150626 -> 20151220 [FreeBSD] > php5-arcanist: 20150626_2 -> 20151220 [FreeBSD] > m17n-db: 1.6.5 -> 1.7.0 [FreeBSD] > libvterm: git20150527 -> git20150828 [FreeBSD] > fribidi: 0.19.2_3 -> 0.19.7 [FreeBSD] > dmidecode: 2.12_2 -> 3.0 [FreeBSD] > chromium: 47.0.2526.80 -> 47.0.2526.106 [FreeBSD] > > The process will require 2 MiB more space. > 43 MiB to be downloaded. > > At the first glance none of those packages seem to be related to firefox. > > Also, I would guess that even if a shared library used by firefox would be > upgraded, then either the old version would be unlinked first and firefox would > keep using it, or there would be an error (ETXTBSY) if there would be an > attempt > to write to the shared library while it's being used. > > The core dump seems to be useless: > > Core was generated by `firefox'. > Program terminated with signal SIGBUS, Bus error. > #0 0x000000080ed69c90 in ?? () from /usr/local/lib/libgio-2.0.so.0 > [Current thread is 60 (Thread 801a0d000 (LWP 101727))] > (gdb) bt > #0 0x000000080ed69c90 in ?? () from /usr/local/lib/libgio-2.0.so.0 > #1 0x000000080ed6815e in ?? () from /usr/local/lib/libgio-2.0.so.0 > #2 0x000000080ed68af8 in ?? () from /usr/local/lib/libgio-2.0.so.0 > #3 0x000000080ddde7b5 in g_main_context_dispatch () from > /usr/local/lib/libglib-2.0.so.0 > #4 0x000000080dddeacb in ?? () from /usr/local/lib/libglib-2.0.so.0 > #5 0x000000080dddeb54 in g_main_context_iteration () from > /usr/local/lib/libglib-2.0.so.0 > #6 0x0000000803e134cc in ?? () from /usr/local/lib/firefox/libxul.so > #7 0x0000000803de6c24 in ?? () from /usr/local/lib/firefox/libxul.so > #8 0x0000000803de6cdd in ?? () from /usr/local/lib/firefox/libxul.so > #9 0x000000080259945f in ?? () from /usr/local/lib/firefox/libxul.so > #10 0x00000008025be1f3 in ?? () from /usr/local/lib/firefox/libxul.so > #11 0x000000080282436e in ?? () from /usr/local/lib/firefox/libxul.so > #12 0x0000000802808c68 in ?? () from /usr/local/lib/firefox/libxul.so > #13 0x0000000803de694b in ?? () from /usr/local/lib/firefox/libxul.so > #14 0x00000008045d47be in ?? () from /usr/local/lib/firefox/libxul.so > #15 0x00000008046243be in ?? () from /usr/local/lib/firefox/libxul.so > #16 0x0000000804624655 in ?? () from /usr/local/lib/firefox/libxul.so > #17 0x0000000804624a56 in XRE_main () from /usr/local/lib/firefox/libxul.so > #18 0x0000000000405abf in ?? () > #19 0x00000000004054df in _start () > > Although, hmm: > (gdb) disassemble 0x000000080ed69c70,+48 > Dump of assembler code from 0x80ed69c70 to 0x80ed69ca0: > 0x000000080ed69c70: add %al,(%rax) > 0x000000080ed69c72: mov $0x18,%esi > 0x000000080ed69c77: callq 0x80ec98ff4 <calloc@plt> > 0x000000080ed69c7c: mov %rax,%r13 > 0x000000080ed69c7f: xor %r15d,%r15d > 0x000000080ed69c82: test %r13,%r13 > 0x000000080ed69c85: je 0x80ed69cf0 > 0x000000080ed69c87: mov %r13,%r15 > 0x000000080ed69c8a: mov %r14,%rbx > 0x000000080ed69c8d: nopl (%rax) > => 0x000000080ed69c90: mov 0x8(%rbx),%rax > 0x000000080ed69c94: mov %rax,0x8(%r13) > 0x000000080ed69c98: mov 0x10(%rbx),%eax > 0x000000080ed69c9b: mov %eax,0x10(%r13) > 0x000000080ed69c9f: cmpq $0x0,(%rbx) > End of assembler dump. > (gdb) i reg > rax 0x81f542d60 34885348704 > rbx 0x5a5a5a5a5a5a5a5a 6510615555426900570 > rcx 0x20 32 > rdx 0x0 0 > rsi 0x0 0 > rdi 0x81f542d80 34885348736 > rbp 0x7fffffffd850 0x7fffffffd850 > rsp 0x7fffffffd7e0 0x7fffffffd7e0 > r8 0x20 32 > r9 0xfffff80000000000 -8796093022208 > r10 0x1 1 > r11 0x81f542d60 34885348704 > r12 0x81ccb0300 34842804992 > r13 0x81f542d60 34885348704 > r14 0x81f5540a0 34885419168 > r15 0x81f542d40 34885348672 > rip 0x80ed69c90 0x80ed69c90 > eflags 0x10206 [ PF IF RF ] > cs 0x43 67 > ss 0x3b 59 > ds <unavailable> > es <unavailable> > fs <unavailable> > gs <unavailable> > > Seems like %rbx has a value characteristic of free-d memory. > But I am not sure at all how this fact could be connected to pkg upgrade... > Perhaps a change in the file system triggers a bug in libgio somewhere. > > Update. > > Surprisingly[?], the old base gdb produces a better[?] stack trace: > > (kgdb) bt > #0 0x000000080ed69c90 in g_local_file_monitor_get_type () from > /usr/local/lib/libgio-2.0.so.0 > #1 0x000000080ed6815e in g_local_file_monitor_get_type () from > /usr/local/lib/libgio-2.0.so.0 > #2 0x000000080ed68af8 in g_local_file_monitor_get_type () from > /usr/local/lib/libgio-2.0.so.0 > #3 0x000000080ddde7b5 in g_main_context_dispatch () from > /usr/local/lib/libglib-2.0.so.0 > #4 0x000000080dddeacb in g_main_context_pending () from > /usr/local/lib/libglib-2.0.so.0 > #5 0x000000080dddeb54 in g_main_context_iteration () from > /usr/local/lib/libglib-2.0.so.0 > #6 0x0000000803e134cc in std::__1::__tree<unsigned long, > std::__1::less<unsigned long>, std::__1::allocator<unsigned long> >::destroy () > from /usr/local/lib/firefox/libxul.so > #7 0x0000000803de6c24 in std::__1::__tree<unsigned long, > std::__1::less<unsigned long>, std::__1::allocator<unsigned long> >::destroy () > from /usr/local/lib/firefox/libxul.so > #8 0x0000000803de6cdd in std::__1::__tree<unsigned long, > std::__1::less<unsigned long>, std::__1::allocator<unsigned long> >::destroy () > from /usr/local/lib/firefox/libxul.so > #9 0x000000080259945f in XRE_AddJarManifestLocation () from > /usr/local/lib/firefox/libxul.so > #10 0x00000008025be1f3 in std::__1::vector<unsigned long, > std::__1::allocator<unsigned long> >::__push_back_slow_path<unsigned long> () > from /usr/local/lib/firefox/libxul.so > #11 0x000000080282436e in std::__1::vector<std::__1::pair<int, int>, > std::__1::allocator<std::__1::pair<int, int> > >>::__push_back_slow_path<std::__1::pair<int, int> > () from > /usr/local/lib/firefox/libxul.so > #12 0x0000000802808c68 in std::__1::vector<std::__1::basic_string<char, > std::__1::char_traits<char>, std::__1::allocator<char> >, > std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, > std::__1::allocator<char> > > >>::insert<std::__1::__wrap_iter<std::__1::basic_string<char, > std::__1::char_traits<char>, std::__1::allocator<char> >*> > () from > /usr/local/lib/firefox/libxul.so > #13 0x0000000803de694b in std::__1::__tree<unsigned long, > std::__1::less<unsigned long>, std::__1::allocator<unsigned long> >::destroy () > from /usr/local/lib/firefox/libxul.so > #14 0x00000008045d47be in XRE_StartupTimelineRecord () from > /usr/local/lib/firefox/libxul.so > #15 0x00000008046243be in XRE_InitCommandLine () from > /usr/local/lib/firefox/libxul.so > #16 0x0000000804624655 in XRE_GlibInit () from /usr/local/lib/firefox/libxul.so > #17 0x0000000804624a56 in XRE_main () from /usr/local/lib/firefox/libxul.so > #18 0x0000000000405abf in _start () > #19 0x00000000004054df in _start () > #20 0x0000000800640000 in ?? () > #21 0x0000000000000000 in ?? () > > From the disassembly, though, I can see that several different functions are > reported as g_local_file_monitor_get_type(), e.g.: > 0x000000080ed69c40 <g_local_file_monitor_get_type+25776>: push %rbp > 0x000000080ed69c41 <g_local_file_monitor_get_type+25777>: mov > %rsp,%rbp > 0x000000080ed69c44 <g_local_file_monitor_get_type+25780>: push %r15 > 0x000000080ed69c46 <g_local_file_monitor_get_type+25782>: push %r14 > 0x000000080ed69c48 <g_local_file_monitor_get_type+25784>: push %r13 > 0x000000080ed69c4a <g_local_file_monitor_get_type+25786>: push %r12 > 0x000000080ed69c4c <g_local_file_monitor_get_type+25788>: push %rbx > 0x000000080ed69c4d <g_local_file_monitor_get_type+25789>: sub > $0x48,%rsp > 0x000000080ed69c51 <g_local_file_monitor_get_type+25793>: mov > %rcx,-0x50(%rbp) > 0x000000080ed69c55 <g_local_file_monitor_get_type+25797>: mov > %rdx,-0x48(%rbp) > ... > > I've found a report that seems to be related: > https://forums.freebsd.org/threads/gtk-programs-core-dump.54462/ > > -- > Andriy Gapon > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?151d547f2e8.2710.65a736056516fedbe0e39048eb84e883>