www/firefox and www/firefox-esr not working.

I just had to deal with firefox randomly crashing after a few seconds to minutes on my work dekstop after ~30 days uptime.
Turned out to be firefox trying to swap when there was no swap active (with 32GB RAM I never bothered about swap...). From what I found, when some process tries to allocate a chunk of memory that isn't available as a continuous block, FreeBSD tries to rearrange the memory using swap. If no swap is available the process just gets killed because the memory allocation request cold not be fulfilled. (Please correct me if I got that wrong)

So bottom line: is swap space available?
 
Even if you have massive amounts of RAM in the machine, don't be tempted to turn off swap. Modern operating systems will always use some swap. Swap usage in and of itself is never a problem, it's excessive swapping that will cause significant performance degradation.
 
sko said:
I just had to deal with firefox randomly crashing after a few seconds to minutes on my work dekstop after ~30 days uptime.
Turned out to be firefox trying to swap when there was no swap active (with 32GB RAM I never bothered about swap...). From what I found, when some process tries to allocate a chunk of memory that isn't available as a continuous block, FreeBSD tries to rearrange the memory using swap. If no swap is available the process just gets killed because the memory allocation request cold not be fulfilled. (Please correct me if I got that wrong)

So bottom line: is swap space available?
Click to expand...

SirDice said:
Even if you have massive amounts of RAM in the machine, don't be tempted to turn off swap. Modern operating systems will always use some swap. Swap usage in and of itself is never a problem, it's excessive swapping that will cause significant performance degradation.
Click to expand...

I was hoping that this might be the answer but unfortunately swapctl -l reports that I do have swap space configured and not being used.

Additionally, LibreOffice is now exhibiting exactly the same behavior i.e. works for a few seconds and then core dumps.
 
chrbr said:
This should be not weak. From FreeBSD 11.1 onwards ARC is compressed which adds additional CPU load. This was very difficult on my dual core. Therefore I have disabled it by
Code: 
vfs.zfs.compressed_arc_enabled="0"
in /boot/loader.conf. Regarding pkg_libchk run it without any arguments. Then it should check everything. May be you have done that already, I just want to be sure because my earlier post is not really clear. Sorry for that.
Click to expand...

Thanks mate, I did run the command and it found nothing unfortunately.
 
SirDice said:
Even if you have massive amounts of RAM in the machine, don't be tempted to turn off swap. Modern operating systems will always use some swap. Swap usage in and of itself is never a problem, it's excessive swapping that will cause significant performance degradation.
Click to expand...

I just learned that the hard way :rolleyes:


fl1pper said:
I did not, it's not something I've done before. It's increasingly looking like something I will have to learn how to do :cool:
Click to expand...

For a start you can simply use ktrace(1):
ktrace firefox
The output is written to ktrace.out in the current directory (this file might grow a few 100MB!) and can be viewed in human readable (e.g. text) format with kdump(1). Mostly the very last breaths before the process dies are interesting, so for a first peek the tail of the dump is mostly sufficient:
kdump | tail -n 1000 | less
 
sko said:
I just learned that the hard way :rolleyes:




For a start you can simply use ktrace(1):
ktrace firefox
The output is written to ktrace.out in the current directory (this file might grow a few 100MB!) and can be viewed in human readable (e.g. text) format with kdump(1). Mostly the very last breaths before the process dies are interesting, so for a first peek the tail of the dump is mostly sufficient:
kdump | tail -n 1000 | less
Click to expand...

I've tried this and nothing jumped out me. Unfortunately I'm away for the rest of the week so I'll have a more thourough look at it next week.
 
The output of kdump has lots of the following errors.

Code: 
1389 Socket Thread RET   recvfrom 1440/0x5a0
  1389 Socket Thread CALL  recvfrom(0x62,0x82da35882,0x35d6,0,0,0)
  1389 Socket Thread RET   recvfrom -1 errno 35 Resource temporarily unavailable
  1389 Socket Thread CALL  getpeername(0x7b,0x7fffdfbfb8f0,0x7fffdfbfb8b4)
  1389 Socket Thread RET   getpeername -1 errno 57 Socket is not connected

To me they just seem like the thread waiting for data from a remote web site. Is that correct?

Eventually these errors are immediately followed by:

Code: 
1389 SignedJAR PSIG  SIGSEGV caught handler=0x801d96d90 mask=0x0 code=SEGV_ACCERR
  1389 SignedJAR CALL  sigprocmask(SIG_SETMASK,0x7fffdb9b950c,0)
  1389 SignedJAR RET   sigprocmask 0
  1389 SignedJAR CALL  unlink(0x8027f8ec0)

The error SEGV_ACCERR means "invalid permissions for mapped object" and is what causes the seg fault.

Any idea what would cause that?
 
Are you using add-ons/plugins? Something that executes via "SignedJAR" segfaults - this is most likely some buggy or outdated browser addon/plugin.
If you have enabled automaitc loading for java applets on websites it could also be some crappy applet on a site you are visiting (a lot of malware advertising networks also still use applets for their junk).

Firefox heavily mangled its addon interface and broke a lot of older addons in the process (e.g. the trusty, good old CookieMonster :(). Sometimes these addons just won't load/work, more often they crash and burn loudly while also killing the browser.

The culprit might be revealed from somewhere shortly before the segfault - maybe you could paste the latst ~100 lines at e.g. nopaste/pastebin?
 
sko said:
Are you using add-ons/plugins? Something that executes via "SignedJAR" segfaults - this is most likely some buggy or outdated browser addon/plugin.
If you have enabled automaitc loading for java applets on websites it could also be some crappy applet on a site you are visiting (a lot of malware advertising networks also still use applets for their junk).

Firefox heavily mangled its addon interface and broke a lot of older addons in the process (e.g. the trusty, good old CookieMonster :(). Sometimes these addons just won't load/work, more often they crash and burn loudly while also killing the browser.

The culprit might be revealed from somewhere shortly before the segfault - maybe you could paste the latst ~100 lines at e.g. nopaste/pastebin?
Click to expand...

I've deleted ~/.mozilla and ~/.cache/mozilla so there are no addons there. Your reply did make me wonder if I had any global addons installed and I did have the swfdec-plugin flash package installed but deleting that made no difference. It did however produce an error on the command line:

Code: 
1505203357808   addons.xpi   WARN   Error parsing extensions state: [Exception... "Component returned
failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [amIAddonManagerStartup.readStartupData]"  nsresult: "0
x80520012 (NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame :: resource://gre/modules/addons/XPIProvider.jsm
 :: loadExtensionState :: line 1596"  data: no] Stack trace: loadExtensionState()@resource://gre/modules/a
ddons/XPIProvider.jsm:1596 < getInstallState()@resource://gre/modules/addons/XPIProvider.jsm:1631 < checkF
orChanges()@resource://gre/modules/addons/XPIProvider.jsm:3152 < startup()@resource://gre/modules/addons/X
PIProvider.jsm:2246 < callProvider()@resource://gre/modules/AddonManager.jsm:271 < _startProvider()@resour
ce://gre/modules/AddonManager.jsm:741 < startup()@resource://gre/modules/AddonManager.jsm:908 < startup()@
resource://gre/modules/AddonManager.jsm:3122 < observe()@jar:file:///usr/local/lib/firefox/omni.ja!/compon
ents/addonManager.js:65 < MP_migrate()@resource:///modules/MigrationUtils.jsm:378 < onMigratingMigrate()@m
igration.js:349 < onMigratingPageShow/<()@migration.js:345 < MU_showMigrationWizard()@resource:///modules/
MigrationUtils.jsm:873 < MU_startupMigrator()@resource:///modules/MigrationUtils.jsm:966
Segmentation fault (core dumped)

I don't believe that is relevant because it continues for 20 seconds or so after the error.

I've attached the last 2000 lines of the ktrace output.
 

Attachments

This is now working. Big thanks to hruodr for providing the solution.
The issue was the version of libgcc_s.so.1 being used by Firefox. My system was using the one in /usr/local/lib/gcc5 whereas it should have been using the version in /lib. On my system the library had been renamed to /lib/libgcc_s.so.orig which was causing the problem. I have no recollection of renaming that file, but undoing that change now allows Firefox to run without problems.
 
You must log in or register to reply here.
Back
Top