Firefox aborts at exit

[dmik]

Sometimes Firefox aborts with mozalloc_abort with the following on stdout/stderr:

[4 May 2018 19:20:55, sh -c  ./firefox.exe]

DIVE is disabled - Panorama's shadow-buffer is enabled

WARNING: At least one completion condition is taking too long to complete. Conditions: [{"name":"CrashMonitor: Writing notifications to file after receiving profile-before-change","state":"(none)","filename":"resource://gre/modules/CrashMonitor.jsm","lineNumber":173,"stack":["resource://gre/modules/CrashMonitor.jsm:this.CrashMonitor.init:173","file:///D:/CODING/MOZILLA/MASTER-BUILD/DIST/BIN/components/nsCrashMonitor.js:CrashMonitor.prototype.observe:24"]}] Barrier: OS.File: Waiting for clients before profileBeforeChange
WARNING: At least one completion condition is taking too long to complete. Conditions: [{"name":"OS.File: flush I/O queued before profileBeforeChange","state":{"launched":true,"shutdown":false,"worker":true,"pendingReset":false,"latestSent":["Fri May 04 2018 19:21:30 GMT+0300 (MSK)","makeDir"],"latestReceived":null,"messagesSent":15,"messagesReceived":14,"messagesQueued":22,"DEBUG":false,"clients":[{"name":"CrashMonitor: Writing notifications to file after receiving profile-before-change","state":"(none)","filename":"resource://gre/modules/CrashMonitor.jsm","lineNumber":173,"stack":["resource://gre/modules/CrashMonitor.jsm:this.CrashMonitor.init:173","file:///D:/CODING/MOZILLA/MASTER-BUILD/DIST/BIN/components/nsCrashMonitor.js:CrashMonitor.prototype.observe:24"]}]},"filename":"resource://gre/modules/osfile/osfile_async_front.jsm","lineNumber":1511,"stack":["resource://gre/modules/osfile/osfile_async_front.jsm:setupShutdown:1511","resource://gre/modules/osfile/osfile_async_front.jsm:null:1532","resource://gre/modules/osfile.jsm:null:11","resource://gre/modules/ClientID.jsm:null:11","file:///D:/CODING/MOZILLA/MASTER-BUILD/DIST/BIN/components/DataReportingService.js:null:9"]}] Barrier: profile-before-change
console.error: 
  Message: Error: SessionFile is closed
  Stack:
    SessionFileInternal.write@resource:///modules/sessionstore/SessionFile.jsm:305:29
this.SessionFile.write@resource:///modules/sessionstore/SessionFile.jsm:76:12
SessionSaverInternal._writeState@resource:///modules/sessionstore/SessionSaver.jsm:242:12
SessionSaverInternal._saveState@resource:///modules/sessionstore/SessionSaver.jsm:213:12
SessionSaverInternal._saveStateAsync@resource:///modules/sessionstore/SessionSaver.jsm:226:5
SessionSaverInternal.runDelayed/this._timeoutID<@resource:///modules/sessionstore/SessionSaver.jsm:145:40
setTimeout_timer@resource://gre/modules/Timer.jsm:30:5
Spinner.prototype.observe@resource://gre/modules/AsyncShutdown.jsm:529:9

FATAL ERROR: AsyncShutdown timeout in profile-before-change Conditions: [{"name":"OS.File: flush I/O queued before profileBeforeChange","state":{"launched":true,"shutdown":false,"worker":true,"pendingReset":false,"latestSent":["Fri May 04 2018 19:21:30 GMT+0300 (MSK)","makeDir"],"latestReceived":null,"messagesSent":15,"messagesReceived":14,"messagesQueued":23,"DEBUG":false,"clients":[{"name":"CrashMonitor: Writing notifications to file after receiving profile-before-change","state":"(none)","filename":"resource://gre/modules/CrashMonitor.jsm","lineNumber":173,"stack":["resource://gre/modules/CrashMonitor.jsm:this.CrashMonitor.init:173","file:///D:/CODING/MOZILLA/MASTER-BUILD/DIST/BIN/components/nsCrashMonitor.js:CrashMonitor.prototype.observe:24"]}]},"filename":"resource://gre/modules/osfile/osfile_async_front.jsm","lineNumber":1511,"stack":["resource://gre/modules/osfile/osfile_async_front.jsm:setupShutdown:1511","resource://gre/modules/osfile/osfile_async_front.jsm:null:1532","resource://gre/modules/osfile.jsm:null:11","resource://gre/modules/ClientID.jsm:null:11","file:///D:/CODING/MOZILLA/MASTER-BUILD/DIST/BIN/components/DataReportingService.js:null:9"]}] At least one completion condition failed to complete within a reasonable amount of time. Causing a crash to ensure that we do not leave the user with an unresponsive process draining resources.
WARNING: No crash reporter available
[4207] ###!!! ABORT: file resource://gre/modules/osfile/osfile_async_front.jsm, line 1511
[4207] ###!!! ABORT: file resource://gre/modules/osfile/osfile_async_front.jsm, line 1511
Creating 106F_01.TRP

[4 May 2018 19:22:25, exit code 0, took 1m 29.56s]

The TRP file contains a reference to INT3 in mozalloc_abort and no further stack frame (as usual) so it's pretty useless. Note that mozalloc_abort has nothing to do with memory allocation. It's just a generic function that performs Mozilla process termination in a way that allows the debugger to kick in (when it's enabled and there). It's used in many places in Firefox to perform such an abort which are completely unrelated to memory allocation. In this case, it seems that it's JS code that wants to abort for some reason and it just uses mozalloc_abort for this purpose (via NS_DebugBreak I suppose, which eventually calls mozalloc_abort and is exposed to JS via the nsDebug interface I believe).

[dmik]

Note that compiler optimization options somehow influence whether it crashes or not. For instance, with my GA1.1 test build #3 (see #266 (comment)) where JS is built with -O3 -mno-see2 -march=pentium4 and the rest with just -Os instead of -O3 -mno-see2, this can be reproduced in 100% cases (i.e. each and every Firefox termination crashes this way). However, rebuilding it with -O3 -mno-see -mno-sse2 -march=pentium4 makes this problem completely go away. I also don't remember ever seeing this in -march=i686 builds.

[dmik]

Note that sometimes you may see the Message: Error: SessionFile is closed portion (upto the setTimeout_timer@resource://gre/modules/Timer.jsm:30:5 message) when Firefox shutdown for some reason takes too long to complete, but that seems to be unrelated to the abort call as when there is a simple delay (which exceeds some predefined timeout I believe), it doesn't abort.

[dmik]

Note that putting back -Os for XUL (and leaving -O3 -mno-sse -mno-sse2 for JS) does also not expose this problem. So it seems that you need to remove -mno-sse and/or -mno-sse2 to make this crash happen. Which makes this crash at exit look like yet another consequence of our compiler bug WRT SSE and alignment or something nearby.