SW parent_intercept: Crash in [@ mozilla::ipc::InputStreamHelper::PostSerializationActivation]
Categories
(Core :: DOM: Service Workers, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox-esr68 | --- | unaffected |
firefox69 | --- | unaffected |
firefox70 | --- | unaffected |
firefox71 | blocking | verified |
People
(Reporter: asuth, Assigned: perry)
References
(Regression)
Details
(Keywords: crash, regression, topcrash, Whiteboard: rca - AutoIPCStream design error)
Crash Data
Attachments
(3 files)
This bug is for crash report bp-59542135-db39-44db-8f5a-694d60190904.
Top 10 frames of crashing thread:
0 libxul.so mozilla::ipc::InputStreamHelper::PostSerializationActivation ipc/glue/InputStreamUtils.cpp:272
1 libxul.so mozilla::ipc:: ipc/glue/IPCStreamUtils.cpp:228
2 libxul.so mozilla::ipc::AutoIPCStream::~AutoIPCStream ipc/glue/IPCStreamUtils.cpp
3 libxul.so mozilla::dom::ServiceWorkerPrivateImpl::PendingFetchEvent::~PendingFetchEvent dom/serviceworkers/ServiceWorkerPrivateImpl.cpp:783
4 libxul.so mozilla::dom::ServiceWorkerPrivateImpl::PendingFetchEvent::~PendingFetchEvent dom/serviceworkers/ServiceWorkerPrivateImpl.cpp:777
5 libxul.so nsTArray_Impl<mozilla::UniquePtr<mozilla::dom::ServiceWorkerPrivateImpl::PendingFunctionalEvent, mozilla::DefaultDelete<mozilla::dom::ServiceWorkerPrivateImpl::PendingFunctionalEvent> >, nsTArrayInfallibleAllocator>::Clear mfbt/UniquePtr.h:486
6 libxul.so mozilla::dom::ServiceWorkerPrivateImpl::UpdateState dom/serviceworkers/ServiceWorkerPrivateImpl.cpp:970
7 libxul.so mozilla::dom::ServiceWorkerPrivate::UpdateState dom/serviceworkers/ServiceWorkerPrivate.cpp:1867
8 libxul.so mozilla::dom::ServiceWorkerInfo::UpdateState dom/serviceworkers/ServiceWorkerInfo.cpp:156
9 libxul.so mozilla::dom::ServiceWorkerRegistrationInfo::FinishActivate dom/serviceworkers/ServiceWorkerRegistrationInfo.cpp:369
This looks like it might be a use-after-free because the assertion about an unexpected InputStreamParams union type already has complete coverage, which suggests the allocator poisoned the memory when it performed the free.
This may have involved devtools inspecting a ServiceWorker with the debugger paused on processing a fetch event. Or it might not have.
Comment 1•5 years ago
|
||
We have a spike in this signature starting in 20191009095806 - macOS and Windows are affected. Other than the Linux crash Andrew reported in 20190903094847, there was only 2 additonal crashes in 71, in 20190914212452 and 20190927094817.
Some SW stuff is in that changeset - might that have caused the spike? ni on perry
Comment 2•5 years ago
•
|
||
I experience a crash with this signature when opening Google News. Here is one of my crash reports:
https://crash-stats.mozilla.org/report/index/901dd542-9271-47a6-850e-a39050191010
Comment 3•5 years ago
|
||
Setting dom.serviceWorkers.parent_intercept to false and restarting Firefox seems to "fix" the crash.
Updated•5 years ago
|
Updated•5 years ago
|
Comment 4•5 years ago
|
||
Blocker for 71 given the volume.
Comment 5•5 years ago
|
||
Hello! It seems that I found some easy STR for this crash:
- Open Firefox (dom.serviceWorkers.parent_intercept:true) and https://news.google.com/?hl=en&gl=US&ceid=US:en
- Middle-click multiple links from the site in order to open them in multiple tabs.
AR: Browser crashes (if not repeat the above steps).
It seems that with pref on after middle clicking some links the browser starts lagging very bad and then crashes.
Assignee | ||
Updated•5 years ago
|
Comment 6•5 years ago
|
||
Even easier STR: https://tv.bell.ca/ always causes the crash for me.
Assignee | ||
Comment 7•5 years ago
|
||
Assignee | ||
Comment 8•5 years ago
|
||
In ServiceWorkerPrivateImpl::SendFetchEvent, a heap-allocated AutoIPCStream can
point to a stack-allocated IPCStream (part of an IPCInternalRequest). If this
IPCStream is destroyed before the AutoIPCStream, the AutoIPCStream will have a
dangling pointer (and this is the case if SendFetchEvent is called when the
Service Worker's state is "activating" rather than "activated").
This patch moves around the logic to handle the AutoIPCStream's lifetime to
ensure it its lifetime is within its IPCStream's lifetime. The larger issue
might be that AutoIPCStream doesn't have inherent lifetime guarantees (it'll
definitely outlive its IPCStream if it points to its embedded one, but it
doesn't own any external IPCStreams it might point to).
Depends on D48934
Assignee | ||
Comment 9•5 years ago
|
||
This patch factors out some of the initial test case in
fetch-waits-for-activate.https.html (which only tests "pending" fetch events
for a navigation request) to share with a new test case that tests
"pending" fetch events for a subresource request with a request body.
Both tests in the file have a high-level structure of:
- Register a Service Worker and wait until its state is "activating" but don't
let its state reach "activated". - Fire a fetch event that will be controlled by that Service Worker, which
should wait until the Service Worker's state advances to "activated". - Wait for the fetch to see that the worker isn't "activated". This step isn't
directly observable by content, so the test's method to determine this can
have false posities (but should never cause the test to unexpectedly fail). - Tell the Service Worker to advance to "activated".
- Verify the fetch that was dispatched while the Service Worker was
"activating" is successfully handled.
Depends on D48935
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/19653 for changes under testing/web-platform/tests
Can't merge web-platform-tests PR due to failing upstream checks: Github PR https://github.com/web-platform-tests/wpt/pull/19653 * Taskcluster (pull_request) (https://tools.taskcluster.net/task-group-inspector/#/UH7C3P7NQVycfAAZNQEL3Q)
Assignee | ||
Comment 12•5 years ago
|
||
WPT sync failing due to testing additional test against mozilla-central, which hasn't received the non-test changes. Will re-trigger once all changesets have landed on mozilla-central.
Comment 13•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/15e4b16324a6
https://hg.mozilla.org/mozilla-central/rev/f62280bf339a
https://hg.mozilla.org/mozilla-central/rev/0464faa83b95
Comment hidden (Intermittent Failures Robot) |
Comment 15•5 years ago
•
|
||
Hello! This particular issue is verified fixed following the STR from comment 5 on Windows 10x64, macOS 10.14 and Ubuntu 18.04.
While verifying this I encountered bug 1588357 and posted the steps to reproduce here, althought is pretty intermittent.
Upstream PR merged by jgraham
Comment 17•5 years ago
|
||
I just had another Nightly crash with this signature. Crash report UID is 75e6618a-01a1-4d8a-a1e0-76d700191011. In my understanding this shouldn't be possible anymore?
Comment 18•5 years ago
|
||
Yesterday also two crashes. So three crashes in the last two days.
Comment 19•5 years ago
|
||
Hello TMart!
Are you using the latest Nightly build?
I also checked for this crash signature and did not see any crashes on the builds that contain the fix.
Comment 20•5 years ago
|
||
The build for the crash in comment 18 seems to be from Oct 10
https://crash-stats.mozilla.org/report/index/75e6618a-01a1-4d8a-a1e0-76d700191011
Comment 21•5 years ago
|
||
Sorry for the confusion, these crashes are with older builds. Nightly just crashed for me but didn't leave a crash report. That's what's gotten me confused.
Updated•5 years ago
|
Comment 23•4 years ago
|
||
This bug has been identified as part of a pilot on determining root causes of blocking and dot release drivers.
It needs a root-cause set for it. Please see the list at https://docs.google.com/document/d/1FFEGsmoU8T0N8R9kk-MXWptOPtXXXRRIe4vQo3_HgMw/.
Add the root cause as a whiteboard
tag in the form [rca - <cause> ]
and remove the rca-needed
keyword.
If you have questions, please contact :tmaity.
Assignee | ||
Updated•4 years ago
|
Updated•2 years ago
|
Description
•