Crash in memcpy | nsTSubstring<T>::StartBulkWrite

RESOLVED FIXED in Firefox 63

Status

()

defect
--
critical
RESOLVED FIXED
11 months ago
11 months ago

People

(Reporter: calixte, Assigned: hsivonen)

Tracking

(Blocks 1 bug, {crash, regression})

Trunk
mozilla63
x86
Windows 10
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox-esr60 unaffected, firefox61 unaffected, firefox62 unaffected, firefox63 fixed)

Details

(crash signature)

Attachments

(1 attachment)

This bug was filed from the Socorro interface and is
report bp-49dfd04a-6887-443f-a664-a79210180827.
=============================================================

Top 5 frames of crashing thread:

0 vcruntime140.dll memcpy f:\dd\vctools\crt\vcruntime\src\string\i386\memcpy.asm:194
1 xul.dll nsTSubstring<char>::StartBulkWrite xpcom/string/nsTSubstring.cpp:210
2 xul.dll Gecko_StartBulkWriteCString xpcom/string/nsSubstring.cpp:468
3 xul.dll bool nsstring::conversions::nscstring_fallible_append_utf16_to_utf8_impl servo/support/gecko/nsstring/src/conversions.rs:713
4 xul.dll nsTSubstring<char16_t>::Assign xpcom/string/nsTSubstring.cpp:408

=============================================================

There are 2 crashes (from 1 installation) in nightly 63 with buildid 20180827100129. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1483603.

[1] https://hg.mozilla.org/mozilla-central/rev?node=c6a80a1c10a1
Flags: needinfo?(hsivonen)
Crash Signature: [@ memcpy | nsTSubstring<T>::StartBulkWrite] → [@ memcpy | nsTSubstring<T>::StartBulkWrite] [@ vcruntime140.dll@0xca27 | nsTSubstring<T>::StartBulkWrite]
Crash Signature: [@ memcpy | nsTSubstring<T>::StartBulkWrite] [@ vcruntime140.dll@0xca27 | nsTSubstring<T>::StartBulkWrite] → [@ memcpy | nsTSubstring<T>::StartBulkWrite] [@ vcruntime140.dll@0xca27 | nsTSubstring<T>::StartBulkWrite] [@ vcruntime140.dll@0xcbe0 | nsTSubstring<T>::StartBulkWrite]
The crash is probably due to the fact that newHdr is null at line 178 which is possible if shrinking is true (since we don't return in this case).
Well, this is an embarrassing oversight in the patch for bug 1483603.

(In reply to Calixte Denizet (:calixte) from comment #1)
> The crash is probably due to the fact that newHdr is null at line 178 which
> is possible if shrinking is true (since we don't return in this case).

Good point. Thanks.
Assignee: nobody → hsivonen
Status: NEW → ASSIGNED
Flags: needinfo?(hsivonen)
Comment on attachment 9004458 [details]
Bug 1486470 - Avoid overwriting newData when there's an OOM failure on buffer shrinking attempt.

Nathan Froyd [:froydnj] has approved the revision.
Attachment #9004458 - Flags: review+
Pushed by hsivonen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6d95f23e7ea2
Avoid overwriting newData when there's an OOM failure on buffer shrinking attempt. r=froydnj
https://hg.mozilla.org/mozilla-central/rev/6d95f23e7ea2
Status: ASSIGNED → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
You need to log in before you can comment on or make changes to this bug.