From owner-freebsd-hackers@freebsd.org Thu Dec 24 18:37:24 2015 Return-Path: Delivered-To: freebsd-hackers@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 ECA89A50B37 for ; Thu, 24 Dec 2015 18:37:24 +0000 (UTC) (envelope-from jmaloney@pcbsd.org) Received: from barracuda.ixsystems.com (mail.ixsystems.com [69.198.165.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D184D110F for ; Thu, 24 Dec 2015 18:37:24 +0000 (UTC) (envelope-from jmaloney@pcbsd.org) X-ASG-Debug-ID: 1450982241-08ca042abc0bc60002-2efMSh Received: from [10.0.1.15] (ip72-209-175-134.ks.ks.cox.net [72.209.175.134]) by barracuda.ixsystems.com with ESMTP id 6nINXdVJe7tp5yP0 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 24 Dec 2015 10:37:22 -0800 (PST) X-Barracuda-Envelope-From: jmaloney@pcbsd.org X-Barracuda-AUTH-User: jmaloney@pcbsd.org X-Barracuda-Apparent-Source-IP: 72.209.175.134 From: Joe Maloney To: Andriy Gapon , CC: FreeBSD Hackers Date: Thu, 24 Dec 2015 12:37:21 -0600 Message-ID: <151d547f2e8.2710.65a736056516fedbe0e39048eb84e883@pcbsd.org> In-Reply-To: <567BF197.10908@FreeBSD.org> References: <567BF197.10908@FreeBSD.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.6.0.4 (build: 24000007) Subject: Re: firefox crashes during pkg upgrade MIME-Version: 1.0 X-ASG-Orig-Subj: Re: firefox crashes during pkg upgrade Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Barracuda-Connect: ip72-209-175-134.ks.ks.cox.net[72.209.175.134] X-Barracuda-Start-Time: 1450982242 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://10.2.0.41:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ixsystems.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=8.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.25542 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2015 18:37:25 -0000 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 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 > 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 > es > fs > gs > > 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 std::__1::less, std::__1::allocator >::destroy () > from /usr/local/lib/firefox/libxul.so > #7 0x0000000803de6c24 in std::__1::__tree std::__1::less, std::__1::allocator >::destroy () > from /usr/local/lib/firefox/libxul.so > #8 0x0000000803de6cdd in std::__1::__tree std::__1::less, std::__1::allocator >::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 std::__1::allocator >::__push_back_slow_path () > from /usr/local/lib/firefox/libxul.so > #11 0x000000080282436e in std::__1::vector, > std::__1::allocator > >>::__push_back_slow_path > () from > /usr/local/lib/firefox/libxul.so > #12 0x0000000802808c68 in std::__1::vector std::__1::char_traits, std::__1::allocator >, > std::__1::allocator, > std::__1::allocator > > >>::insert std::__1::char_traits, std::__1::allocator >*> > () from > /usr/local/lib/firefox/libxul.so > #13 0x0000000803de694b in std::__1::__tree std::__1::less, std::__1::allocator >::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 : push %rbp > 0x000000080ed69c41 : mov > %rsp,%rbp > 0x000000080ed69c44 : push %r15 > 0x000000080ed69c46 : push %r14 > 0x000000080ed69c48 : push %r13 > 0x000000080ed69c4a : push %r12 > 0x000000080ed69c4c : push %rbx > 0x000000080ed69c4d : sub > $0x48,%rsp > 0x000000080ed69c51 : mov > %rcx,-0x50(%rbp) > 0x000000080ed69c55 : 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"