Bug 263798 - www/firefox: Channel error on startup in version 100
Summary: www/firefox: Channel error on startup in version 100
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-gecko (Nobody)
: 263800 (view as bug list)
Depends on:
Reported: 2022-05-05 15:12 UTC by Jakub Šebek
Modified: 2022-05-14 04:10 UTC (History)
10 users (show)

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


Note You need to log in before you can comment on or make changes to this bug.
Description Jakub Šebek 2022-05-05 15:12:55 UTC
After upgrading to [100.0_1,2], I am unable to run firefox or thunderbird. Running `firefox --safe-mode` yields a "Trace/BPT trap (core dumped)". Previously it was logging `[Child][PCompositorManagerChild] Error: SendAndWait(msgname=PWebRenderBridge::Msg_EnsureConnected) Channel error: cannot send/recv` too. I haven't debugged ff in the past, any other useful info I can provide?
Comment 1 freebsd 2022-05-05 17:28:11 UTC
I see the same thing, so the Importance field of this bug should be at least "Affects some people".
Comment 2 Jason W. Bacon freebsd_committer 2022-05-05 18:09:01 UTC
Same here.

Thunderbird also crashes on startup.

Falkon works fine.

I tried "mv .mozilla mozilla.save" before starting firefox, in case it's an issue with old config files, but it made no difference.

This happens on my ThinkCenter M92P-Tiny, my ThinkPad T430, and in a VirtualBox guest, all running 13.0-RELEASE.
Comment 3 Jakub Šebek 2022-05-05 18:19:40 UTC
Solved: This has actually been fixed a few days ago in 100.0_3,2 - A result of buggy LLVM, buggy Rust and buggy package repos that haven't built the patch for latest FreeBSD:13:amd64, but they did for quarterly. Be better.
Comment 4 freebsd 2022-05-05 19:07:20 UTC
Can confirm, I just spent a bit of time compiling firefox from ports, it works again.
Comment 5 Jason W. Bacon freebsd_committer 2022-05-05 20:47:05 UTC
FreeBSD moray.acadix  bacon ~ 952: lldb -c firefox.core /usr/local/bin/firefox 
(lldb) target create "/usr/local/bin/firefox" --core "firefox.core"
Core file '/home/bacon/firefox.core' (x86_64) was loaded.

(lldb) bt
* thread #1, name = 'glean.ping_director', stop reason = signal SIGTRAP
  * frame #0: 0x000000080b23771c libxul.so
    frame #1: 0x000000080e60ff20
    frame #2: 0x000000080b1d869a libxul.so`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::h4c15c0a441e53c93 + 138
    frame #3: 0x0000000806286fa3 libxul.so`std::sys::unix::thread::Thread::new::thread_start::hb718d4d977950b4a + 35
    frame #4: 0x000000080123982b libthr.so.3`___lldb_unnamed_symbol11$$libthr.so.3 + 331
Comment 6 Jason W. Bacon freebsd_committer 2022-05-05 20:48:04 UTC
FreeBSD moray.acadix  bacon ~ 954: lldb -c thunderbird.core /usr/local/bin/thunderbird 
(lldb) target create "/usr/local/bin/thunderbird" --core "thunderbird.core"
Core file '/home/bacon/thunderbird.core' (x86_64) was loaded.

(lldb) bt
* thread #1, name = 'SwComposite', stop reason = signal SIGTRAP
  * frame #0: 0x000000080ad94a77 libxul.so
    frame #1: 0x000000080525d476 libxul.so
    frame #2: 0x000000080abc5d2a libxul.so`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::hde4974977d69c0bf + 122
    frame #3: 0x000000080627c7d3 libxul.so`std::sys::unix::thread::Thread::new::thread_start::hb718d4d977950b4a + 35
    frame #4: 0x000000080123482b libthr.so.3`___lldb_unnamed_symbol11$$libthr.so.3 + 331
Comment 7 Jason W. Bacon freebsd_committer 2022-05-05 20:50:58 UTC
Ooops, didn't see the replies before uploading the backtraces.  I'll try building from source and report back.
Comment 8 Santiago Martinez 2022-05-06 11:34:20 UTC
Hi gents, i see the same for firefox. 

smartinez@tucho /u/h/smartinez> lldb -c firefox.core firefox
(lldb) target create "firefox" --core "firefox.core"
Core file '/usr/home/smartinez/firefox.core' (x86_64) was loaded.
(lldb) bt
* thread #1, name = 'SwComposite', stop reason = signal SIGTRAP
  * frame #0: 0x00002fce507f3737 libxul.so
    frame #1: 0x00002fce4aca3df2 libxul.so
    frame #2: 0x00002fce5062481a libxul.so`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::hc4e0714f2e52ea49 + 122
    frame #3: 0x00002fce4bc86fa3 libxul.so`std::sys::unix::thread::Thread::new::thread_start::hb718d4d977950b4a + 35
    frame #4: 0x00002fce1ad6f83a libthr.so.3`thread_start(curthread=0x00002fcef8290a00) at thr_create.c:292:16
Comment 9 Christoph Moench-Tegeder freebsd_committer 2022-05-06 11:39:56 UTC
fixed in firefox-100.0_3,2 firefox-esr-91.9.0_2,1 thunderbird-91.9.0_3 - see commit ports fc0a979a30ea
Comment 10 Jason W. Bacon freebsd_committer 2022-05-06 14:47:52 UTC
Confirmed that building from source works here as well.
Comment 11 Tomasz "CeDeROM" CEDRO 2022-05-06 17:06:01 UTC
Thank you for the quick fix in the ports! Rebuilding updated port fixes the issue :-)

However I also notice functional problems with this Firefox on various sites, like hanging after login, not following the internal redirections and updates, etc. Probably some other internals also changed and there is a silent compatibility problem. Removing site data (cookies and local store) fixes the issue.

Thank you :-)
Comment 12 wolfgang 2022-05-07 11:23:22 UTC
I still got this error on firefox-100.0_3,2 until I recompiled it with LTO disabled.
Comment 13 Tomasz "CeDeROM" CEDRO 2022-05-07 12:04:33 UTC
Yes, as described in the patch commit message, LTO needs to be disabled.

After updating port it is good to `make rmconfig` to make sure default config is used. It is disabled now as default.
Comment 14 Christoph Moench-Tegeder freebsd_committer 2022-05-08 12:33:35 UTC
*** Bug 263800 has been marked as a duplicate of this bug. ***
Comment 15 Oleg Sidorkin 2022-05-12 11:30:03 UTC
Rust switched to LLVM14 in 1.60, so linker from llvm13 that links firefox binary doesn't know how to work with llvm14 libs.

I've built firefox with devel/llvm14 and LTO, and it works (I patched bsd.gecko.mk and created wasi-compiler14 port).