Bug 244994

Comment 1 Jan Beich 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)?

(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 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.

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.

Just checked and those warning messages are there as well with 71.

Comment 6 Jan Beich 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 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.

(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 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.

(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 .

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)

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 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.

(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 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.

(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. :)

Me too :-)

I installed dante 1.4.3 in order to get away from ancient socks5. After that,
firefox-78 SEGVs. After removing libdsocks.so things are OK again.

And, no, I am not socksifying firefox. ff also wasn't rebuilt after dante had been
installed. No idea why it is loading it at all. It seems that it loads every
lib in /usr/local/lib, therefore replacing system network routines with Dante's.
ktrace/kdump showed that even /usr/local/etc/socks.conf gets loaded. And it does not help removing or emptying that...