Pale Moon fills up HDD and then crashes Topic is solved

[adesh]

This has happened three times in last two weeks. Pale Moon starts writing to disk non-stop until disk is 100% full and then gets killed by the OS. Process dies with code 11 (SIGSEGV).
I don't think I can provide any concrete steps to reproduce the crash, but in all three cases, the browser had been running for 2-3 days and I had at least one "private" window open. I always restore my previous session and generally have around 100 tabs (of which only 10-15 are active) in session. Other than that the issue seems to be random.

This is the first time I'm seeing crashes so the issue seems to be tied to the latest version of the browser as my browsing habits and browser configuration has not changed.

Arch Linux 32-bit ver 27.4.2

Application Basics
------------------

Name: Pale Moon
Version: 27.4.2
Build ID: 20170822041335
User Agent: Mozilla/5.0 (X11; Linux i686; rv:45.9) Gecko/20100101 Goanna/3.2 Firefox/45.9 PaleMoon/27.4.2
OS: Linux 4.12.8-2-ARCH
Multiprocess Windows: 0/2 (default: false)
Safe Mode: false

Extensions
----------

Name: NoScript
Version: 5.0.6
Enabled: true
ID: {73a6fe31-595d-460b-a920-fcc0f8843232}

Graphics
--------

Adapter Description: Intel Open Source Technology Center -- Mesa DRI Mobile Intel® GM45 Express Chipset x86/MMX/SSE2
Device ID: Mesa DRI Mobile Intel® GM45 Express Chipset x86/MMX/SSE2
Driver Version: 2.1 Mesa 17.1.7
GPU Accelerated Windows: 0/2 Basic
Vendor ID: Intel Open Source Technology Center
WebGL Renderer: Intel Open Source Technology Center -- Mesa DRI Mobile Intel® GM45 Express Chipset x86/MMX/SSE2
windowLayerManagerRemote: false
AzureCanvasBackend: cairo
AzureContentBackend: cairo
AzureFallbackCanvasBackend: none
AzureSkiaAccelerated: 0

Important Modified Preferences
------------------------------

accessibility.typeaheadfind.flashBar: 0
browser.cache.disk.capacity: 51200
browser.cache.disk.smart_size.first_run: false
browser.cache.disk.smart_size.use_old_max: false
browser.download.importedFromSqlite: true
browser.newtab.url: about:newtab
browser.places.smartBookmarksVersion: 4
browser.startup.homepage: about:newtab
browser.startup.homepage_override.buildID: 20170822041335
browser.startup.homepage_override.mstone: 3.2.2
browser.zoom.full: false
extensions.lastAppVersion: 27.4.2
general.useragent.override.beeg.com: Mozilla/5.0 (X11; Linux x86_64; rv:52.9) Gecko/20100101 Firefox/52.9
image.http.accept: image/webp,image/jxr,image/png,image/*;q=0.8,*/*;q=0.5
network.cookie.cookieBehavior: 1
network.cookie.prefsMigrated: true
network.http.referer.trimmingPolicy: 1
network.http.referer.XOriginPolicy: 1
network.http.sendRefererHeader: 1
places.database.lastMaintenance: 1505050959
places.history.expiration.transient_current_max_pages: 10000
privacy.sanitize.migrateFx3Prefs: true
storage.vacuum.last.index: 1
storage.vacuum.last.places.sqlite: 1504248152

Important Locked Preferences
----------------------------

Places Database
---------------

JavaScript
----------

Incremental GC: true

Accessibility
-------------

Activated: false
Prevent Accessibility: 1

Library Versions
----------------

NSPR
Expected minimum version: 4.15
Version in use: 4.15

NSS
Expected minimum version: 3.31.1
Version in use: 3.31.1

NSSSMIME
Expected minimum version: 3.31.1
Version in use: 3.31.1

NSSSSL
Expected minimum version: 3.31.1
Version in use: 3.31.1

NSSUTIL
Expected minimum version: 3.31.1
Version in use: 3.31.1

Experimental Features
---------------------

[gracious1]

This has happened three times in last two weeks. Pale Moon starts writing to disk non-stop until disk is 100% full and then gets killed by the OS. Process dies with code 11 (SIGSEGV).

That's a segmentation fault (caused by trying to access an unassigned memory location or something like that).

In what directory is it writing to the disk?

[Walter Dnes]

This has happened three times in last two weeks. Pale Moon starts writing to disk non-stop until disk is 100% full and then gets killed by the OS. Process dies with code 11 (SIGSEGV).
I don't think I can provide any concrete steps to reproduce the crash, but in all three cases, the browser had been running for 2-3 days and I had at least one "private" window open. I always restore my previous session and generally have around 100 tabs (of which only 10-15 are active) in session. Other than that the issue seems to be random.

This is the first time I'm seeing crashes so the issue seems to be tied to the latest version of the browser as my browsing habits and browser configuration has not changed.

This brings to mind trava90's posts in thread viewtopic.php?f=37&t=16654

I suggest starting up Pale Moon and going to about:buildconfig Please copy and paste the text into a post. The formatting will be lost, but it's the content that we're concerned about.

[adesh]

There is not much information about the crash. I tried to check if coredump is captured, but there is none. Please suggest what information to collect should it happen next.
No coredump:$ coredumpctl -1
TIME PID UID GID SIG COREFILE EXE
Wed 2017-09-13 01:11:51 IST 6111 1000 1000 11 none /usr/lib/palemoon
And this is what about:buildconfig says:

about:buildconfigBuild Machine
PM4Linux-x86

Build platform
target
i686-pc-linux-gnu

Build tools
Compiler Version Compiler flags
gcc 4.9.1 -Wall -Wdeclaration-after-statement -Wempty-body -Wpointer-to-int-cast -Wsign-compare -Wtype-limits -Wno-unused -Wcast-align -std=gnu99 -fgnu89-inline -fno-strict-aliasing -ffunction-sections -fdata-sections -fno-math-errno -pthread -pipe
c++ 4.9.1 -Wall -Wempty-body -Woverloaded-virtual -Wsign-compare -Wwrite-strings -Wno-invalid-offsetof -Wcast-align -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED -g -O2 -msse2 -mfpmath=sse -floop-parallelize-all -fpredictive-commoning -ftree-loop-distribution -ftree-vectorize -fomit-frame-pointer

Configure arguments
--enable-official-branding --enable-application=browser --enable-release '--enable-optimize=-O2 -msse2 -mfpmath=sse -floop-parallelize-all -fpredictive-commoning -ftree-loop-distribution -ftree-vectorize' --disable-installer --disable-updater --disable-debug --disable-necko-wifi --enable-devtools --enable-jemalloc --enable-shared-js --with-pthreads --enable-strip --x-libraries=/usr/lib

In what directory is it writing to the disk?

I'll try to do that if it happens next!

[Walter Dnes]

The buildconfig looks pretty normal. I see one "style difference", which may not really matter. My equivalant mozconfig would contain...

Code: Select all

ac_add_options --enable-optimize
export CFLAGS="--enable-optimize=-O2 -msse2 -mfpmath=sse -floop-parallelize-all -fpredictive-commoning -ftree-loop-distribution -ftree-vectorize"
export CXXFLAGS="${CFLAGS}"

whereas the build for your PM appears to have it rolled up into one line...

Code: Select all

--enable-optimize="-O2 -msse2 -mfpmath=sse -floop-parallelize-all -fpredictive-commoning -ftree-loop-distribution -ftree-vectorize"

I don't know if that makes a difference or not.

[adesh]

Thanks Walter Dnes for your suggestions on buildconfig. I'll probably use them someday when I get a powerful machine to compile my own Pale Moon. Moonchild specifically states that you should never compile Pale Moon on a laptop, otherwise the laptop might get vapourized .
Currently, I am using palemoon-bin from AUR which is a repack of the official tabrall. I don't expect much to be done on the issue (given its nature). Just wanted to report so that everyone knows.

[adesh]

This time Pale Moon 28 also crashed in a similar fashion. Fortunately, I had started the browser from the command line.
These were the last words of Pale Moon:

Code: Select all

Assertion failure: [unhandlable oom] Failed to allocate object while tenuring., at /home/adesh/exp/UXP/js/src/jscntxt.cpp:1153
Segmentation fault (core dumped)

Hopefully it will help to pinpoint the problem.

[Moonchild]

It doesn't help, unfortunately. This is a deliberate crash when running out of memory.
Of course a crash dump can't be written if your disk is full (how can that fill up anyway, don't you set a maximum to your VM swap space?)
It would be great to know the nature of those disk writes.

[adesh]

I thought about the problem some more and now I think this may not be an issue with Pale Moon. Actually, this may not be an issue at all. So, probably, what is happening is this:

Pale Moon runs out of memory (due to too many tabs open) and so, mighty OOM killer nukes it. Now, system wants to dump the core to the disk. This starts the writes to the disk, turns on the disk activity light and free space starts decreasing until it becomes zero, and then after a few seconds Pale Moon window is gone. After this, disk free space is back. I think problem here is that this disk (partition) does not have enough free space to hold the contents of the system memory (or just the browser's), that's why there is no crash dump at all and free space returns when the partial dump file is discarded. Considering that this happens when I am browsing heavily and close to memory limit, it looks like my theory may be correct.

Now, I feel stupid about making a noise about this without giving it proper thought by taking system variables into consideration.
This topic can be closed/deleted if you wish.

[Moonchild]

Makes sense if it tries to do a full memory dump. Confusion was when exactly the browser hit the crash, before or after the writes

[stevenpusser]

You can certainly build Pale Moon on a laptop if you don't have any cooling issues with it running at 100% usage on all cores for a while. I've done it many times. My last laptop with an i5-6200u (15 watts max) and current i7-8750H (45 watts) can run all day at 100% without getting close to critical temperatures...even if you do have cooling problems, usually it's possible to set the CPU to a lower maximum speed to avoid that. It just takes longer to build in that case. You can also undervolt modern (3rd gen or better) Intel processors with iuvolt so they run cooler at the same speeds.

[BenFenner]

This sounds eerily similar to two different issues I've experienced on Arch Linux (64-bit), neither of them Pale Moon related.

1) When launching Thunderbird, it will occasionally launch and decide to fill up all 16 GB of RAM while loading, eventually fill the RAM and then the 2 GB of swap space, then the OS kills the process. When this happens I have to create a new profile in Thunderbird, swap over all of my user profile preferences, extensions, and similar, then ditch the old profile. I've gotten so good at this, I can get it done in ~3 minutes in the morning. It seems to happen more often when I shut down the computer, or it otherwise turns off, without having closed Thunderbird properly first.

2) Even more related, I used to have a situation where permissions on some files (will look this up and update when I get to that machine) would be lost, and the OS would constantly try to perform normal work, but could not because of the permissions mix-up. This caused error logs to be created very quickly, hogging most of the CPU until finally the SSD filled up with error logs in a matter of hours. The fix was correcting the permissions SNAFU, then deleting the logs. Thankfully this hasn't happened in a long time. Some Arch update a year ago probably fixed it for me.

Sorry if this isn't too helpful, but I've seen Arch do some crazy stuff...

[BenFenner]

These are my notes on the permanent storage fill-up issue I had on Arch.

Code: Select all

If the mate-panel process takes up large amounts of CPU and begins filling the /home/username/.xsession-errors log file then:
  ls -lai /run/user/1000/dconf/
If the owner is root and not username then:
  sudo chown -R username:username /run/user/1000/dconf
If the journalctl logs have filled up a larger portion of the main storage by now then:
  sudo journalctl --vacuum-size=25M

So I had a problem with mate-panel for a while that eventually got fixed, but you might have some other issue that's filling your logs? It's worth a check I'd say.