Bug 244978 - www/firefox: 74.0_5,1 coredumps on webgl content
Summary: www/firefox: 74.0_5,1 coredumps on webgl content
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-gecko (Nobody)
URL:
Keywords: crash, needs-qa, regression
Depends on:
Blocks:
 
Reported: 2020-03-22 14:48 UTC by Remy Nonnenmacher
Modified: 2020-03-29 17:19 UTC (History)
1 user (show)

See Also:
koobs: maintainer-feedback? (gecko)


Attachments
about:support for crashing FF (20.93 KB, text/plain)
2020-03-29 17:14 UTC, Remy Nonnenmacher
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Remy Nonnenmacher 2020-03-22 14:48:47 UTC
After upgrade from 73.0.1,1 to 74.0_5,1, firefox dumps core each time a webgl content is invoked.

Reinstalling 73.0.1,1 from saved pkg makes webgl content works again.
Iridium and Chrome works (so not an X11/OpenGL issue).

Same problem have been raised on Linux but have "mysteriously disapeared" (very helpfull).

I compiled the version from ports and crash happens as well.

Note: the message about a missing transform_feedback2" GL extension is displayed by working 73 version and by non working 74 so my guess is that it's not relevant.

Thanks for your attention. Let me know if I can help.
Comment 1 Jan Beich freebsd_committer 2020-03-29 12:14:07 UTC
Can you show backtrace from lldb/gdb? If it's incomplete rebuild firefox and library dependencies WITH_DEBUG=1.

Can you dump about:support[1]? What version of drm-*-kmod is installed? If the crash is indeed in WebGL then the issue maybe in gfx drivers.

In case it's an upstream issue does bug 244793 help?

Are you using binary packages or build yourself? If the latter back up then try reproducing only packages.

[1] Click on "Copy raw data to clipboard" then attach the output as a file here. For privacy use a new profile but make sure the crash still occurs.
Comment 2 Remy Nonnenmacher 2020-03-29 17:14:22 UTC
Created attachment 212839 [details]
about:support for crashing FF
Comment 3 Remy Nonnenmacher 2020-03-29 17:19:29 UTC
Recompiled with WITH_DEBUG=1 from port www/firefox. Got a very slow firefox but everything still stripped:

[root-rn:~]# l firefox.core 
1481792 -rw-------  1 root  wheel  1516904448 Mar 29 17:28 firefox.core
[root-rn:~]# lldb -c firefox.core /usr/local/lib/firefox/firefox
(lldb) target create "/usr/local/lib/firefox/firefox" --core "firefox.core"
Core file '/root/firefox.core' (x86_64) was loaded.
(lldb) bt
* thread #1, name = 'firefox', stop reason = signal SIGSEGV
  * frame #0: 0x000000080143f16a libc.so.7`_thr_kill + 10
    frame #1: 0x000000080143d5a4 libc.so.7`raise + 52
    frame #2: 0x0000000811269391 libxul.so`___lldb_unnamed_symbol823841$$libxul.so + 305
    frame #3: 0x0000000812458b96 libxul.so`___lldb_unnamed_symbol929943$$libxul.so + 486
    frame #4: 0x000000080126f3be libthr.so.3`___lldb_unnamed_symbol101$$libthr.so.3 + 222
    frame #5: 0x000000080126e97f libthr.so.3`___lldb_unnamed_symbol82$$libthr.so.3 + 319
    frame #6: 0x00007ffffffff193
    frame #7: 0x000000080dc54858 libxul.so`___lldb_unnamed_symbol431546$$libxul.so + 424
    frame #8: 0x000000080dbeca26 libxul.so`___lldb_unnamed_symbol427146$$libxul.so + 38
    frame #9: 0x000000080dbecb03 libxul.so`___lldb_unnamed_symbol427147$$libxul.so + 211
    frame #10: 0x000000080db855b5 libxul.so`___lldb_unnamed_symbol423055$$libxul.so + 21

(Not very usefull. Strange frame 6).

Anyway, the problem appears only when running FF as root. All is fine when running under a normal user. A recent authoritative enforcement ?

Chrome and Iridium works fine maybe because they refuse to run as root.

Please let me know how to get unstripped libs and binaries to get a usable backtrace.

Thanks.