Closed Bug 1599479 Opened 5 years ago Closed 11 months ago

Crash in [@ AsyncShutdownTimeout | profile-before-change | SessionFile: Finish writing Session Restore data,SessionFile: Finish writing Session Restore data,SessionFile: Finish writing Session Restore data,SessionFile: Finish writing Session Restore da...

Categories

(Firefox :: Session Restore, defect)

All
Windows
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox-esr68 --- unaffected
firefox70 --- wontfix
firefox71 --- wontfix
firefox72 --- wontfix
firefox73 --- wontfix
firefox74 --- wontfix

People

(Reporter: philipp, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash, regression)

Crash Data

This bug is for crash report bp-6621e884-20a4-4774-8e18-572940191126.

AsyncShutdownTimeout:
{

    "phase":"profile-before-change",
    "conditions":[
        {
            "name":"SessionFile: Finish writing Session Restore data",
            "state":{
                "options":{
                    "isFinalWrite":false,
                    "performShutdownCleanup":false
                },
                "attempts":116,
                "successes":0,
                "failures":0
            },
            "filename":"resource:///modules/sessionstore/SessionFile.jsm",
            "lineNumber":478,
            "stack":[
                "resource:///modules/sessionstore/SessionFile.jsm:write:478",
                "resource:///modules/sessionstore/SessionFile.jsm:write:75",
                "resource:///modules/sessionstore/SessionSaver.jsm:_writeState:360",
                "resource:///modules/sessionstore/SessionSaver.jsm:_saveState:294",
                "resource:///modules/sessionstore/SessionSaver.jsm:_saveStateAsync:344",
                "resource:///modules/sessionstore/SessionSaver.jsm:saveStateAsyncWhenIdle:191",
                "resource://gre/modules/Timer.jsm:callback:125"
            ]
        },
		...
        {
            "name":"SessionFile: Finish writing Session Restore data",
            "state":{
                "options":{
                    "isFinalWrite":true,
                    "performShutdownCleanup":true
                },
                "attempts":116,
                "successes":0,
                "failures":0
            },
            "filename":"resource:///modules/sessionstore/SessionFile.jsm",
            "lineNumber":478,
            "stack":[
                "resource:///modules/sessionstore/SessionFile.jsm:write:478",
                "resource:///modules/sessionstore/SessionFile.jsm:write:75",
                "resource:///modules/sessionstore/SessionSaver.jsm:_writeState:360",
                "resource:///modules/sessionstore/SessionSaver.jsm:_saveState:294",
                "resource:///modules/sessionstore/SessionSaver.jsm:run:154",
                "resource:///modules/sessionstore/SessionSaver.jsm:run:69",
                "resource:///modules/SessionStore.jsm:ssi_uninit:844",
                "resource:///modules/SessionStore.jsm:ssi_onQuitApplication:1980",
                "resource:///modules/SessionStore.jsm:ssi_observe:878"
            ]
        }
    ]

}

this shutdown hang signature is getting worse in firefox 70 - it's mostly affecting users of zh-cn builds.

Mike, could this bug be prioritized and triaged wrt to our upcoming releases? Thanks

Looks like crash volume is slightly better on 71 than on 70.0.1. Hard to tell if that's because something got fixed or because we lost those users though.

So comment 0 tells us there have been 116 attempts at flushing the sessionstore.jsonlz4 file to disk, but has failed to do so every time. To be clear: this file was never reported to be saved successfully EVER(!)
Also, 0 failures were reported, so this must mean that something for these users causes a hard crash in the ChromeWorker where the file is written in a different (background-)thread, but somehow still keeps the worker itself alive. At this point the only thing I can think of to fix this shutdown crash is to move SessionStore away from using OS.File to something more reliable, perhaps? That may be something for our Storage workgroup to ponder over, but it's unfortunately not actionable.

Unless somehow one of these users turns up with a reproducible scenario, I don't think this is something we can track effectively.

Flags: needinfo?(mdeboer)
Priority: -- → P1
Severity: normal → --
Priority: P1 → --

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 11 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.