firefox crashes during pkg upgrade
Joe Maloney
jmaloney at pcbsd.org
Thu Dec 24 18:37:25 UTC 2015
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 at 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 at 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 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
More information about the freebsd-gecko
mailing list