Jon Fineman <[email protected]> wrote: > On 2020-01-31 15:00, Solene Rapenne wrote: > > On Fri, Jan 31, 2020 at 10:30:06AM -0600, joshua stein wrote: > >> > >> On Fri, 31 Jan 2020 at 12:11:14 +0100, Solene Rapenne wrote: > >>> On Thu, Jan 30, 2020 at 09:16:35PM -0500, Jon Fineman wrote: > >>>>> Synopsis: After updating Firefox on launch it core dumps > >>>>> Category: > >>>>> Environment: > >>>> System : OpenBSD 6.6 > >>>> Details : OpenBSD 6.6 (GENERIC.MP) #4: Wed Jan 15 10:55:43 MST 2020 > >>>> > >>>> [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP > >>>> > >>>> Architecture: OpenBSD.amd64 Machine : amd64 > >>>>> Description: > >>>> Ran pkg_add -u and syspatch. I didn't launch Firefox for a while so I > >>>> can't say > >>>> what introduced the issue. It had been working fine. > >>>> > >>>> After upgrading to Firefox 72.0.2 when launching from the shell prompt > >>>> it core > >>>> dumps. When launching from the X menu it never launches and a core file > >>>> exists > >>>> with an updated date/time. > >>>> > >>>> If run firefox --help from the command line it prints the help menu and > >>>> then > >>>> core dumps. Same with firefox --version. > >>>> > >>>>> How-To-Repeat: > >>>> From ksh run either of the below commands: > >>>> firefox > >>>> firefox --help > >>>> firefox --version > >>>> > >>>>> Fix: > >>>> > >>> > >>> can you try firefox --safe-mode > >>> > >>> what's the output of pkg_info | grep firefox? > >> > >> It's probably because of: > >> > >> amdgpu0 at pci0 dev 1 function 0 "ATI Stoney Ridge" rev 0xda > >> drm0 at amdgpu0 > >> > >> and it's getting killed by a pledge violation due to libGL doing different > >> ioctls on amdgpu than when on inteldrm, and they aren't allowed by the > >> "drm" > >> pledge. > >> > > > > if pledge is the issue, wouldn't it display a line in the dmesg output? > > (which was attached to the mail) > > > > safe mode gives me (which is the same behavior as the other tests): > Segmentation fault (core dumped) > > pkg_info output is: > firefox-72.0.2 Mozilla web browser
I ran firefox with gdb and the back trace is: Program received signal SIGSEGV, Segmentation fault. 0x00001b0b2e5b14c4 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> > > >::__push_back_slow_path<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > () from /usr/local/lib/firefox/libxul.so.87.0 (gdb) bt #0 0x00001b0b2e5b14c4 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> > > >::__push_back_slow_path<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > () from /usr/local/lib/firefox/libxul.so.87.0 #1 0x00001b0b323d290c in std::__1::operator>><char, std::__1::char_traits<char>, std::__1::allocator<char> > () from /usr/local/lib/firefox/libxul.so.87.0 #2 0x00001b0b323d2e92 in std::__1::operator>><char, std::__1::char_traits<char>, std::__1::allocator<char> > () from /usr/local/lib/firefox/libxul.so.87.0 #3 0x00001b083250e753 in __register_frame_info () from /usr/local/bin/firefox #4 0x00001b083250e13b in _start () from /usr/local/bin/firefox #5 0x0000000000000000 in ?? () (gdb)
