1476319 - Crash in JSScript::createScriptData

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect, P1)

Description

[[:philipp]]

This bug was filed from the Socorro interface and is
report bp-fe08e58e-3ee8-4f64-9037-41a0e0180717.
=============================================================

Top 10 frames of crashing thread:

0 xul.dll JSScript::createScriptData js/src/vm/JSScript.cpp:2410
1 xul.dll js::XDRScript<1> js/src/vm/JSScript.cpp:626
2 ntdll.dll RtlInitializeCriticalSectionEx 
3 xul.dll js::HelperThread::handleParseWorkload js/src/vm/HelperThreads.cpp:2010
4 xul.dll js::HelperThread::threadLoop js/src/vm/HelperThreads.cpp:2321
5 xul.dll js::HelperThread::ThreadMain js/src/vm/HelperThreads.cpp:1801
6 xul.dll js::detail::ThreadTrampoline<void  js/src/threading/Thread.h:235
7 ucrtbase.dll thread_start<unsigned int > 
8 kernel32.dll BaseThreadInitThunk 
9 mozglue.dll static void patched_BaseThreadInitThunk mozglue/build/WindowsDllBlocklist.cpp:857

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

this tab crash from 32bit windows installations is spiking up since yesterday 2018-07-16. in the past 24 hours it was the #2 content crash signature accounting for 3.8% of all content crashes on release.

the crash reports are correlated to the social networking site ok.ru + the presence of the "Adguard AdBlocker" addon, so it's primarily affecting russian users.

Comment 1

[Nicolas B. Pierron [:nbp]]

2 of these crashes are crashing with the codeLength > 0 diagnostic assertion added in Bug 1399373.

Comment 2

[Daniel Veditz [:dveditz]]

scattered crashes in the past, and a huge spike starting July 15. Many of these are on https://ok.ru -- some kind of site change? Even of the other crashes with urls many are russian sites (yandex for example, other .ru domains).

I don't see any crashes newer than 61.0.1, but maybe we don't have many Russian beta testers.

Although this spike may be due to a site change, clearly it's triggering some bug in our code.

Comment 3

[Andrew McCreight (out of office until 8/21) [:mccr8]]

Ted, can you take a look?

In addition to what Dan said, a lot of the comment talked about restoring tabs.

Comment 4

[Kris Maglione [:kmag]]

The target address in comment 0 is in edi, so presumably the crash is actually at one of these lines:

https://hg.mozilla.org/releases/mozilla-release/annotate/7d280b7e277b82ef282325fefb601c10698e075b/js/src/vm/JSScript.cpp#l636

And the value in ecx is 0x0ebdbfef, so presumably when adding several length values, the allocation size overflowed to something reasonable, but the copy failed when trying to use one of the junk values.

Comment 5

[Nicolas B. Pierron [:nbp]]

Did we recently deployed a system addon?

Comment 6

[Nicolas B. Pierron [:nbp]]

To be much more precise, did we recently deployed a system addon to ESR 61.0.1 (build id 20180704003137), or just deployed this ESR version with a 15 days old deployment process?

Comment 7

[Nicolas B. Pierron [:nbp]]

Ok, this is something I never saw before, all the crash addresses are ending with 0x…9d000.

Comment 8

[Kris Maglione [:kmag]]

(In reply to Nicolas B. Pierron [:nbp] {backlog: 39} from comment #7)
> Ok, this is something I never saw before, all the crash addresses are ending
> with 0x…9d000.

That's not super surprising. These look like memcpy operations walking off the end of a page. I'm guessing they're all 625K allocations that wind up with 0x100000 alignment preferentially.

What's interesting, though, is that it suggests they all wind up with the same allocation size. And, more interesting: they all seem to have 0xbc508c04 in ecx. Which suggests we're trying to decode the same corrupt XDR data for all of them...

Comment 9

[[:philipp]]

the signature is rapidly declining again - only 20 crashes were recorded yesterday.

Comment 10

[Nicolas B. Pierron [:nbp]]

Looking at crash URLs, I see mainly  https://ok.ru/

Can we reach out to the ok.ru maintainers and ask them if we can get a snapshot of their website which can help us reproduce this issue?

Comment 11

[Andrew Overholt [:overholt]]

Maybe Adam knows someone at ok.ru? (comment 10)

Comment 12

[Adam Stevenson [:adamopenweb]]

Yes. Reaching out to our contacts by email, CC'd Andrew and Nicolas.

Comment 13

[Jason Orendorff [:jorendorff]]

Well. Looks like this is unactionable. Closing.

Comment 14

[Nicolas B. Pierron [:nbp]]

(In reply to Adam Stevenson [:adamopenweb] (on PTO til 9/4) from comment #12)
> Yes. Reaching out to our contacts by email, CC'd Andrew and Nicolas.

To be precise we did not got any more actionable inputs after giving them refined information about the kind of issues we were looking for.

I will mark it as INCOMPLETE instead of WORKFORME, as this bug is likely to still exists except that we have no way to make further progress.

Comment 15

[Ted Campbell [:tcampbell]]

I'm rewriting JSScript::createData in Bug 1485347. I'll make sure to add overflow checks this time to cover what case in Comment 4.