Date: Thu, 04 Jan 2018 22:04:19 +0000 From: bugzilla-noreply@freebsd.org To: gecko@FreeBSD.org Subject: maintainer-feedback requested: [Bug 224917] www/firefox: bus error on stable/10 with 57.0.3,1 Message-ID: <bug-224917-21738-8q2EyoTHnC@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-224917-21738@https.bugs.freebsd.org/bugzilla/> References: <bug-224917-21738@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
Jilles Tjoelker <jilles@FreeBSD.org> has reassigned Bugzilla Automation <bugzilla@FreeBSD.org>'s request for maintainer-feedback to gecko@FreeBSD.o= rg: Bug 224917: www/firefox: bus error on stable/10 with 57.0.3,1 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224917 --- Description --- Created attachment 189422 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D189422&action= =3Dedit gdb output After upgrading firefox from 57.0.2_1,1 to 57.0.3,1 it started crashing with bus error frequently (in particular on the about:sessionrestore page but al= so elsewhere). This is stable/10 amd64 with packages from pkg.freebsd.org. The machine also uses nvidia-driver 384.98. What happens is that clang has decided to combine two 64-bit stores in mozilla::ipc::MessageChannel::Clear() in libxul.so into one aligned 128-bit store (movaps). However, the object is actually not 128-bit aligned and a general protection fault occurs in the main firefox process. Some gdb outpu= t is in an attachment. As a result, various child processes crash in mozilla::ipc::MessageChannel::OnChannelErrorFromLink(). I think these crash= es are a direct result of the original crash, and not interesting by themselve= s. The insufficient alignment could be because of a disagreement between vario= us pieces of code about what the alignment should be or because the pointer is bogus. Assuming it is the former, I have modified one byte in /usr/local/lib/firefox/libxul.so to change the movaps instruction to movups= so it will work with any alignment. With this change, firefox runs stably again for me (note that, on this machine, I have many tabs open but I do not leave firefox running for more than a day). More details about the workaround: --- /tmp/zshXpplPs 2018-01-03 23:47:31.929337000 +0100 +++ /tmp/zshxVT4SU 2018-01-03 23:47:31.929702000 +0100 @@ -1,5 +1,5 @@ -/usr/local/lib/firefox/libxul.so: file format elf64-x86-64-freebsd +libxul.so.fixed: file format elf64-x86-64-freebsd Disassembly of section .init: @@ -1231701,7 +1231701,7 @@ cebf90: e8 8b bf 00 00 callq cf7f20 <_ZNSt3__16__treeINS_12__value_typeImN7mozilla3ipc14MessageChannel13Promise= Hold erEEENS_19__map_value_compareImS6_NS_4lessImEELb1EEENS_9allocatorIS6_EEE7de= stro yEPNS_11__tree_nodeIS6_PvEE> cebf95: 4d 89 be 08 01 00 00 mov %r15,0x108(%r14) cebf9c: 0f 57 c0 xorps %xmm0,%xmm0 - cebf9f: 41 0f 29 86 10 01 00 movaps %xmm0,0x110(%r14) + cebf9f: 41 0f 11 86 10 01 00 movups %xmm0,0x110(%r14) cebfa6: 00=20 cebfa7: 49 c7 46 38 00 00 00 movq $0x0,0x38(%r14) cebfae: 00=20 root@lion /home/jilles# cmp -l /root/libxul.so.orig /usr/local/lib/firefox/libxul.so 13549474 51 21
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-224917-21738-8q2EyoTHnC>