Closed Bug 1603684 Opened 1 year ago Closed 11 months ago

Crash in [@ mozilla::dom::ServiceWorkerRegistrar::GetShutdownPhase]

Categories

(Core :: DOM: Service Workers, defect, P2)

71 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 1403348

People

(Reporter: pascalc, Unassigned)

Details

(Keywords: crash, regression)

Crash Data

This bug is for crash report bp-2f201de4-c9fe-4f41-9123-2c7c00191213.

Top 10 frames of crashing thread:

0 xul.dll class nsCOMPtr<nsIAsyncShutdownClient> mozilla::dom::ServiceWorkerRegistrar::GetShutdownPhase dom/serviceworkers/ServiceWorkerRegistrar.cpp
1 xul.dll void mozilla::dom::ServiceWorkerRegistrar::ProfileStarted dom/serviceworkers/ServiceWorkerRegistrar.cpp:1110
2 xul.dll nsresult mozilla::dom::ServiceWorkerRegistrar::Observe dom/serviceworkers/ServiceWorkerRegistrar.cpp:1253
3 xul.dll nsObserverList::NotifyObservers xpcom/ds/nsObserverList.cpp:66
4 xul.dll nsObserverService::NotifyObservers xpcom/ds/nsObserverService.cpp:291
5 xul.dll nsXREDirProvider::DoStartup toolkit/xre/nsXREDirProvider.cpp:968
6 xul.dll nsresult XREMain::XRE_mainRun toolkit/xre/nsAppRunner.cpp:4420
7 xul.dll int XREMain::XRE_main toolkit/xre/nsAppRunner.cpp:4746
8 xul.dll XRE_main toolkit/xre/nsAppRunner.cpp:4827
9 xul.dll int mozilla::BootstrapImpl::XRE_main toolkit/xre/Bootstrap.cpp:45

Philipp identified a spike of this signature since yesterday, most of the comments are in French

crash reason is "Failed to get async shutdown service: NS_ERROR_FILE_NOT_FOUND"

and the spike is specifically on 68esr

The crash rate is rather high, but it seems there is no crash on Nightly. Maybe Perry or Andrew have an idea about what's going on?

Points: --- → 2
Flags: needinfo?(perry)
Flags: needinfo?(bugmail)

There are crashes on nightly, but the table does not show them for some reason. If you select nightly in the box under the graph, you will see them. I already noticed this on some other bug with crash reports. Maybe the number of rows is limited, and nightly is left out if there are too many other rows.

Points: 2 → ---
Priority: -- → P2

I'm not sure what's going on. From the crash reports' MOZ_CRASH Reason (Sanitized): Failed to get profileBeforeChange shutdown blocker: NS_ERROR_FILE_NOT_FOUND, it appears that rv = svc->GetProfileBeforeChange(getter_AddRefs(client)); is failing. That method is implemented in JS, and I'm not sure where the NS_ERROR_FILE_NOT_FOUND error code is coming from...

Flags: needinfo?(perry)

Hmm, I thought it's this line because the crash reason on the reports is "Failed to get async shutdown service: NS_ERROR_FILE_NOT_FOUND"

Checking the code for getting the async shutdown service, the other component usensCOMPtr<nsIAsyncShutdownService> svc = services::GetAsyncShutdown(); rather than nsCOMPtr<nsIAsyncShutdownService> svc = do_GetService("@mozilla.org/async-shutdown-service;1", &rv);, maybe that block of code in the ServiceWorkerRegistrar.cpp needs to be changed? However, I have no idea whether this is the cause, TBH.

(In reply to Tom Tung [:tt, :ttung] from comment #7)

Hmm, I thought it's this line because the crash reason on the reports is "Failed to get async shutdown service: NS_ERROR_FILE_NOT_FOUND"

Yes, that seems to be the point of failure.

Checking the code for getting the async shutdown service, the other component usensCOMPtr<nsIAsyncShutdownService> svc = services::GetAsyncShutdown(); rather than nsCOMPtr<nsIAsyncShutdownService> svc = do_GetService("@mozilla.org/async-shutdown-service;1", &rv);, maybe that block of code in the ServiceWorkerRegistrar.cpp needs to be changed? However, I have no idea whether this is the cause, TBH.

mozilla::services::GetAsyncShutdown() calls an internal function that seems to do essentially the same but adds caching of the result. see 1. So I would not expect this change to help, though it is surely better to use the given functions and to not rely on the string identifiers copied into the code.

I see a thread working while this happens, Thread 24, Name: Cookie, it is deleting the cookie database ? Might be totally unrelated, but could this indicate, that something else did not yet initialize when we expect it to be ready? After all, it is async and we do not wait here... I did not yet check other traces, if this is a pattern, however.

(In reply to Jens Stutte [:jstutte] from comment #8)

I see a thread working while this happens, Thread 24, Name: Cookie, it is deleting the cookie database ? Might be totally unrelated, but could this indicate, that something else did not yet initialize when we expect it to be ready? After all, it is async and we do not wait here... I did not yet check other traces, if this is a pattern, however.

If the user clicks the option "Delete cookies and site data when Nightly is closed" on about:preference, then it can happen that the cookie database is deleting cookie on this stage (profile-change-teardown) during shutting down.

(In reply to Tom Tung [:tt, :ttung] from comment #9)

If the user clicks the option "Delete cookies and site data when Nightly is closed" on about:preference, then it can happen that the cookie database is deleting cookie on this stage (profile-change-teardown) during shutting down.

Oh, we are shutting down? I was misled probably by the startup crash flag set on most of these crashes. Or do we have an underlying problem of closing down immediately after startup for whatever bad reason, and this provokes an unexpected order of things? Anyway, the shutdown service clearly indicates what its name says.
So the shutdown probably provokes a premature unregister of "@mozilla.org/async-shutdown-service;1" such that we do not find it any more. Does this mean, that the underlying object has been destroyed? Because a call to mozilla::services::GetAsyncShutdown() would probably still return the cached pointer, at least I do not see any clearing of the gAsyncShutdown cache variable at a first glance. So if the service object has a longer lifetime than its registration, the change to mozilla::services::GetAsyncShutdown() could help (if this is not the first call) - otherwise it might cause a nasty UAF and we should solve the lifecycle problem or handle this situation more gracefully than with a crash.

(In reply to Jens Stutte [:jstutte] from comment #10)

Oh, we are shutting down? I was misled probably by the startup crash flag set on most of these crashes. Or do we have an underlying problem of closing down immediately after startup for whatever bad reason, and this provokes an unexpected order of things? Anyway, the shutdown service clearly indicates what its name says.

Ah, sorry, it's startup. I overlooked it's "profile-after-change" and it's ProfileStarted. Please ignore my comment in comment #9

Hmm. that would mean we are expecting a service to be registered during startup which is not yet ready? Then the change to mozilla::services::GetAsyncShutdown() will not make any difference, IMHO (but is still desirable). Can we wait for a service (or declare otherwise the dependency)?

OS: Windows 8 → All
Hardware: x86 → All

I think this is the stalled bug 1403348 where the problem is that the JS component is failing to load, hence the NS_ERROR_FILE_NOT_FOUND.

Status: NEW → RESOLVED
Closed: 11 months ago
Flags: needinfo?(bugmail)
Resolution: --- → DUPLICATE
Duplicate of bug: 1403348
You need to log in before you can comment on or make changes to this bug.