Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Dec 2015 15:22:31 +0200
From:      Andriy Gapon <avg@FreeBSD.org>
To:        freebsd-gecko@FreeBSD.org
Cc:        FreeBSD Hackers <freebsd-hackers@FreeBSD.org>
Subject:   firefox crashes during pkg upgrade
Message-ID:  <567BF197.10908@FreeBSD.org>

next in thread | raw e-mail | index | archive | help

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?567BF197.10908>