Closed Bug 1459443 Opened 3 years ago Closed 3 years ago

Crash in static void mozilla::dom::`anonymous namespace'::StructuredCloneCallbacksFreeTransfer

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla62
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- unaffected
firefox59 --- unaffected
firefox60 --- unaffected
firefox61 + verified
firefox62 + verified

People

(Reporter: marcia, Assigned: bkelly)

References

(Blocks 1 open bug)

Details

(Keywords: crash, regression)

Crash Data

This bug was filed from the Socorro interface and is
report bp-d9234c55-44c1-45cc-acfb-9fe360180505.
=============================================================

Seen while reviewing nightly crash data - crashes started using 20180504220115: https://bit.ly/2woBZwf. 84 crashes/27 installations so far, and additional crashes are happening with the 2nd signature listed.

Possible regression range based on Build ID: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a2d1d4158bb4718d8bb31e1284e133aa99273600&tochange=5207b1392b11db534550a5eb801302e6dbb58f95

Bug 1456986 is in that range. ni on :bkelly

Top 10 frames of crashing thread:

0  @0x110 
1 xul.dll static void mozilla::dom::`anonymous namespace'::StructuredCloneCallbacksFreeTransfer dom/base/StructuredCloneHolder.cpp:122
2 xul.dll static void DiscardTransferables<js::SystemAllocPolicy> js/src/vm/StructuredClone.cpp:704
3 xul.dll JSAutoStructuredCloneBuffer::clear js/src/vm/StructuredClone.cpp:2832
4 xul.dll mozilla::dom::StructuredCloneHolder::~StructuredCloneHolder dom/base/StructuredCloneHolder.cpp:278
5 xul.dll mozilla::dom::`anonymous namespace'::SendMessageEventRunnable::`scalar deleting destructor' 
6 xul.dll mozilla::dom::WorkerRunnable::Release dom/workers/WorkerRunnable.cpp:212
7 xul.dll nsCOMPtr<nsISupportsCString>::~nsCOMPtr<nsISupportsCString> 
8 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1115
9 xul.dll NS_ProcessPendingEvents xpcom/threads/nsThreadUtils.cpp:461

=============================================================
Adding Mac signature.
Crash Signature: [@ static void mozilla::dom::`anonymous namespace'::StructuredCloneCallbacksFreeTransfer] [@ @0x0 | static void mozilla::dom::`anonymous namespace'::StructuredCloneCallbacksFreeTransfer] → [@ static void mozilla::dom::`anonymous namespace'::StructuredCloneCallbacksFreeTransfer] [@ @0x0 | static void mozilla::dom::`anonymous namespace'::StructuredCloneCallbacksFreeTransfer] [@ mozilla::dom::(anonymous namespace)::StructuredCloneCallbacksFr…
OS: Windows 10 → All
Hardware: Unspecified → All
Crash Signature: namespace)::StructuredCloneCallbacksFreeTransfer] → namespace)::StructuredCloneCallbacksFreeTransfer] [@ @0x0 | JSAutoStructuredCloneBuffer::clear]
In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1458836.
:baku, could you investigate please ?

[1] https://hg.mozilla.org/mozilla-central/rev?node=e73e0231a9e3
Blocks: clouseau, 1458836
Flags: needinfo?(amarchesini)
Flags: needinfo?(bkelly)
Crash Signature: namespace)::StructuredCloneCallbacksFreeTransfer] [@ @0x0 | JSAutoStructuredCloneBuffer::clear] → namespace)::StructuredCloneCallbacksFreeTransfer] [@ @0x0 | JSAutoStructuredCloneBuffer::clear] [@ StructuredCloneCallbacksFreeTransfer] [@ JSAutoStructuredCloneBuffer::clear]
It seems that holder is null here: https://hg.mozilla.org/mozilla-central/annotate/b1628ac71fcc15797baec6083650bfcde650f190/dom/base/StructuredCloneHolder.cpp#l122

This code runs during the DTOR of a WorkerRunnable. We can clean up data when ::Cancel() is executed, but I wonder why a similar setup in MessageEventRunnable works fine and here we have this issue.
Flags: needinfo?(amarchesini)
Adding another signature spotted in crash stats: https://bit.ly/2KJfZPC.
Group: dom-core-security
Crash Signature: namespace)::StructuredCloneCallbacksFreeTransfer] [@ @0x0 | JSAutoStructuredCloneBuffer::clear] [@ StructuredCloneCallbacksFreeTransfer] [@ JSAutoStructuredCloneBuffer::clear] → namespace)::StructuredCloneCallbacksFreeTransfer] [@ @0x0 | JSAutoStructuredCloneBuffer::clear] [@ StructuredCloneCallbacksFreeTransfer] [@ JSAutoStructuredCloneBuffer::clear] [@ static void DiscardTransferables<T>]
I made this bug security sensitive since several of the crash reports look like potential UAF -> https://crash-stats.mozilla.com/report/index/a0c8b388-6535-43f4-9e8d-640510180505
Adding two Linux signatures spotted in crash stats.
Crash Signature: namespace)::StructuredCloneCallbacksFreeTransfer] [@ @0x0 | JSAutoStructuredCloneBuffer::clear] [@ StructuredCloneCallbacksFreeTransfer] [@ JSAutoStructuredCloneBuffer::clear] [@ static void DiscardTransferables<T>] → namespace)::StructuredCloneCallbacksFreeTransfer] [@ @0x0 | JSAutoStructuredCloneBuffer::clear] [@ StructuredCloneCallbacksFreeTransfer] [@ JSAutoStructuredCloneBuffer::clear] [@ static void DiscardTransferables<T>] [@ mozilla::DefaultDelete<T>::ope…
Adding 62 as affected. It appears as if most of these signatures (or a high %) are startup crashes.
I think this is most likely due to bug 1456986.  That code was using a sandbox to unpack and re-pack structured clone data.  At shutdown its possible that the sandbox global is destroyed before the structured clone data.  I don't think I was using the right cloning values for this to be safe.

For now I backed out bug 1456986 on inbound and beta.  I will try to fix the cloning values and reland on trunk only.
Flags: needinfo?(bkelly)
Calling this fixed by backout. We can verify it once the backout reaches nightlies.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
No longer blocks: 1458836
The backout has merged to m-c.  Looks like the first build with the backout is 20180508231737.  Lets see if this persists in that build or later.
No crashes on Nightlies with the backout included. Won't ship on Beta until 61.0b4 on Friday, but looks like it's going to work.
Status: RESOLVED → VERIFIED
Group: dom-core-security → core-security-release
Group: core-security-release
Crash Signature: mozilla::DefaultDelete<T>::operator()] [@ @0x0 | mozilla::DefaultDelete<T>::operator()] → mozilla::DefaultDelete<T>::operator()] [@ @0x0 | mozilla::DefaultDelete<T>::operator()] [@ static void DiscardTransferables<T>] [@ @0x0 | static void DiscardTransferables<T>] [@ mozilla::dom::StructuredCloneHolderBase::CustomFreeTransferHandler] [@ …
Assignee: nobody → bkelly
Blocks: 1456986
Target Milestone: --- → mozilla62
I can reliably reproduce this on mac with today's nightly just by loading linkedin.com. Can you repro Ben?
Flags: needinfo?(bkelly)
Please see bug 1461667.  The fix should be in the next nightly build.  It just missed this morning's build.
Flags: needinfo?(bkelly)
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.