Bug 244994 - www/firefox 72 and newer fail with channel errors at startup
Summary: www/firefox 72 and newer fail with channel errors at startup
Status: New
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:
Depends on:
Blocks:
 
Reported: 2020-03-23 01:49 UTC by Zane C. Bowers-Hadley
Modified: 2020-03-25 13:33 UTC (History)
0 users

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


Attachments
last 4k lines of truss output (614.09 KB, text/plain)
2020-03-23 01:49 UTC, Zane C. Bowers-Hadley
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Zane C. Bowers-Hadley 2020-03-23 01:49:14 UTC
Created attachment 212629 [details]
last 4k lines of truss output

Same error in 243629, but apparently not related to sqlite.

Only way around it is to keep www/firefox at r521037, last version that did not have this issue.

I've attached the last 4k lines of truss output.

You can find the full truss dump at https://vvelox.net/firefox.truss
Comment 1 Jan Beich freebsd_committer 2020-03-23 20:37:01 UTC
truss/ktrace are mainly used to debug userland->kernel boundary but most bugs occur within userland. Before attempting to troubleshoot provide clear description of "steps to reproduce", "expected output", "actual output".

Can you show what firefox prints on console? What firefox prints on browser console (run with -jsconsole)?
Comment 2 Zane C. Bowers-Hadley 2020-03-24 01:19:44 UTC
(In reply to Jan Beich from comment #1)

Same as previously referenced bug... "Exiting due to channel error."

Not sure what you want more than than previously mentioned... start it and it dies with the previously mentioned error...

Not sure what were expecting to see with -jconsole as just like the last case it never gets to that.

-----------------------------------
>firefox --new-instance -jsconsole
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
1585012241551   addons.webextension.doh-rollout@mozilla.org     WARN    Loading extension 'doh-rollout@mozilla.org': Reading manifest: Invalid extension permission: networkStatus
1585012241818   addons.webextension.screenshots@mozilla.org     WARN    Loading extension 'screenshots@mozilla.org': Reading manifest: Invalid extension permission: mozillaAddons
1585012241818   addons.webextension.screenshots@mozilla.org     WARN    Loading extension 'screenshots@mozilla.org': Reading manifest: Invalid extension permission: telemetry
1585012241818   addons.webextension.screenshots@mozilla.org     WARN    Loading extension 'screenshots@mozilla.org': Reading manifest: Invalid extension permission: resource://pdf.js/
1585012241818   addons.webextension.screenshots@mozilla.org     WARN    Loading extension 'screenshots@mozilla.org': Reading manifest: Invalid extension permission: about:reader*
Exiting due to channel error.
Exiting due to channel error.
zsh: segmentation fault  firefox --new-instance -jsconsole
-----------------------------------
Comment 3 Jan Beich freebsd_committer 2020-03-24 04:25:10 UTC
(In reply to Zane C. Bowers-Hadley from comment #2)
> Same as previously referenced bug... "Exiting due to channel error."

Preceding error messages are important as well. The one you've quoted is actually generic error when IPC fails, including any random crash.

> Not sure what were expecting to see with -jconsole as just
> like the last case it never gets to that.

I was expecting to see console output *without* -jsconsole as well.

> JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.

Looks like this is the actual issue. Try moving ~/.mozilla away, so firefox creates profile directory from scratch. If it doesn't help check if your $HOME is on NFS/autofs, uses symlinks or anything else that may confuse path resolution in firefox.
Comment 4 Zane C. Bowers-Hadley 2020-03-24 04:41:32 UTC
No symlinks and I tried moving ~/.mozilla previously with 73 it still happened. I can get you output with that tomorrow.

The one below though happens with 71 as well, but with 71 everything works as expected, minus that.

> JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
Comment 5 Zane C. Bowers-Hadley 2020-03-24 04:43:21 UTC
Just checked and those warning messages are there as well with 71.
Comment 6 Jan Beich freebsd_committer 2020-03-24 04:49:51 UTC
Try getting a backtrace from the crash using lldb or gdb. If it's not very useful try building firefox and all library dependencies WITH_DEBUG=1.
Comment 7 Jan Beich freebsd_committer 2020-03-24 05:01:37 UTC
There's also a complete lack of details regarding your environment, so guessing what can go wrong is near impossible. What FreeBSD version/architecture, whether you use binary package or ports, if the latter whether you use poudriere, any changed port options (including dependencies), make.conf contents and environ(7) variables, etc.

Assume pilot error unless you find a large number of "me too". A more reliable  (and privacy-friendly) way to track down the issue is to build new environment from scratch in a jail or VM then bisect the differnces.
Comment 8 Zane C. Bowers-Hadley 2020-03-24 05:49:29 UTC
(In reply to Jan Beich from comment #7)

12-stable, r358827, on AMD64.

Packages kept up to date,minus this one, via poudriere and the ones in question are default.

Only env change from default is below.

LANG=en_US.UTF-8

If you have questions, ask. But this is definitely not user error here as I can reproduce it very consistently.

Lots of the bits you requested have already been referenced in 243629. Opened a new bug as requested for this issue.

I'll have the back trace later.
Comment 9 Jan Beich freebsd_committer 2020-03-24 12:42:50 UTC
(In reply to Zane C. Bowers-Hadley from comment #8)
> Lots of the bits you requested have already been referenced in 243629.
> Opened a new bug as requested for this issue.

Neither bug 243629 comment 9 nor bug 243629 comment 12 documented anything other than www/firefox crashes after updating beyond ports r521037. Sorry but details about environment(s) of others are not relevant to your issue because theirs have been fixed by sqlite3 downgrade.
Comment 10 Zane C. Bowers-Hadley 2020-03-24 13:14:22 UTC
(In reply to Jan Beich from comment #9)

Sorry. Though I dumped the requested info previously in that one. :)


So initial rebuild after making sure all options are at the defaults results in the same thing.

Running it from new user who has never run it or anything else before results in the same thing. Core dump for any one that wants to take a look is at https://vvelox.net/firefox.core .
Comment 11 Zane C. Bowers-Hadley 2020-03-24 13:38:15 UTC
backtrace as below....


(gdb) bt
#0  thr_kill () at thr_kill.S:3
#1  0x00000008013d9544 in __raise (s=11) at /arc/src/FreeBSD/base/stable/12/lib/libc/gen/raise.c:52
#2  0x0000000809890d05 in nsProfileLock::FatalSignalHandler(int, __siginfo*, void*) () at /usr/local/lib/firefox/libxul.so
#3  0x000000080a2d6dca in WasmTrapHandler(int, __siginfo*, void*) () at /usr/local/lib/firefox/libxul.so
#4  0x000000080120c3be in handle_signal (actp=0x7fffdeb8e680, sig=11, info=0x7fffdeb8ea70, ucp=0x7fffdeb8e700) at /arc/src/FreeBSD/base/stable/12/lib/libthr/thread/thr_sig.c:246
#5  0x000000080120b97f in thr_sighandler (sig=11, info=0x7fffdeb8ea70, _ucp=0x7fffdeb8e700) at /arc/src/FreeBSD/base/stable/12/lib/libthr/thread/thr_sig.c:191
#6  0x00007fffffffe193 in <signal handler called> ()
#7  0x0000000000000000 in  ()
#8  0x0000000850101b43 in  () at /usr/local/lib/libdsocks.so
#9  0x000000085012b3aa in  () at /usr/local/lib/libdsocks.so
#10 0x000000085012d908 in  () at /usr/local/lib/libdsocks.so
#11 0x0000000850100886 in  () at /usr/local/lib/libdsocks.so
#12 0x0000000850100510 in  () at /usr/local/lib/libdsocks.so
#13 0x000000085010de71 in  () at /usr/local/lib/libdsocks.so
#14 0x000000080108456d in objlist_call_init (list=<optimized out>, lockstate=<optimized out>) at /arc/src/FreeBSD/base/stable/12/libexec/rtld-elf/rtld.c:2744
#15 0x00000008010891dc in dlopen_object
    (name=0x81d7cb448 "/usr/local/lib/libdsocks.so", fd=<optimized out>, refobj=<optimized out>, lo_flags=<optimized out>, mode=1, lockstate=<optimized out>)
    at /arc/src/FreeBSD/base/stable/12/libexec/rtld-elf/rtld.c:3456
#16 0x000000080108587f in rtld_dlopen (name=0x81d7cb448 "/usr/local/lib/libdsocks.so", fd=-1, mode=<optimized out>) at /arc/src/FreeBSD/base/stable/12/libexec/rtld-elf/rtld.c:3321
#17 0x000000080414d2c3 in PR_LoadLibraryWithFlags () at /usr/local/lib/libnspr4.so
#18 0x00000008082a1e2f in nsPluginFile::GetPluginInfo(nsPluginInfo&, PRLibrary**) () at /usr/local/lib/firefox/libxul.so
#19 0x00000008082a12ed in PluginFinder::ScanPluginsDirectory(nsIFile*, bool*) () at /usr/local/lib/firefox/libxul.so
#20 0x00000008082a031a in PluginFinder::FindPlugins() () at /usr/local/lib/firefox/libxul.so
#21 0x000000080829ff03 in PluginFinder::Run() () at /usr/local/lib/firefox/libxul.so
#22 0x000000080601e80d in nsThreadPool::Run() () at /usr/local/lib/firefox/libxul.so
#23 0x000000080601edcd in non-virtual thunk to nsThreadPool::Run() () at /usr/local/lib/firefox/libxul.so
#24 0x000000080601a108 in nsThread::ProcessNextEvent(bool, bool*) () at /usr/local/lib/firefox/libxul.so
#25 0x000000080601d4eb in NS_ProcessNextEvent(nsIThread*, bool) () at /usr/local/lib/firefox/libxul.so
#26 0x0000000806480ff8 in mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) () at /usr/local/lib/firefox/libxul.so
#27 0x000000080643b218 in MessageLoop::Run() () at /usr/local/lib/firefox/libxul.so
#28 0x000000080601823b in nsThread::ThreadFunc(void*) () at /usr/local/lib/firefox/libxul.so
#29 0x0000000804164a6d in  () at /usr/local/lib/libnspr4.so
#30 0x0000000801206736 in thread_start (curthread=0x815a23700) at /arc/src/FreeBSD/base/stable/12/lib/libthr/thread/thr_create.c:292
#31 0x0000000000000000 in  ()
(gdb)
Comment 12 Zane C. Bowers-Hadley 2020-03-24 13:48:50 UTC
Hmm... strange... not sure why /usr/local/lib/libdsocks.so was getting looped into this.

So deleted that and it works. That got installed for when I took a look at mail/aerc  awhile back.
Comment 13 Jan Beich freebsd_committer 2020-03-24 14:07:30 UTC
(In reply to Zane C. Bowers-Hadley from comment #10)
> Core dump for any one that wants to take a look is at
> https://vvelox.net/firefox.core .

core(5) files are not usable on its own. Even for packages from pkg.freebsd.org re-constructing environment is hard because it's a moving target.

(In reply to Zane C. Bowers-Hadley from comment #12)
> not sure why /usr/local/lib/libdsocks.so was getting looped into this.

Check about:plugins in firefox. PluginFinder::ScanPluginsDirectory suggests it maybe in ~/.mozilla/plugins, /usr/local/lib/browser_plugins or similar.
Comment 14 Zane C. Bowers-Hadley 2020-03-25 08:26:04 UTC
(In reply to Jan Beich from comment #13)

Just rebuilt and installed dante and firefox crashes in the same manner after reeling in /usr/local/lib/libdsocks.so .

I am not finding any plugins or the like that explain why it is trying to hoover up the library.
Comment 15 Jan Beich freebsd_committer 2020-03-25 12:37:50 UTC
Build www/firefox and maybe net/dante WITH_DEBUG=1 to get debug symbols then check frames that load libdsocks.so or debug the actual crash in libdsocks.so.

I wonder if you run firefox via socksify (from net/dante) which may explain why libdsocks.so is loaded.
Comment 16 Zane C. Bowers-Hadley 2020-03-25 13:33:41 UTC
(In reply to Jan Beich from comment #15)

Nope. Not calling firefox that way. In fact it did it even on a new user with fresh shell config etc. 

I'll grab that later and see how it looks. :)