1593228 - Crash in [@ AssignJSString<T>]

Status: NEW

(Core :: DOM: Bindings (WebIDL), defect, P3)

Description

[Calixte Denizet (:calixte)]

This bug is for crash report bp-94c23827-9959-4795-922e-da9190191101.

Top 10 frames of crashing thread:

0 xul.dll AssignJSString<nsTSubstring<char16_t> > dom/base/nsJSUtils.h:274
1 xul.dll trunc 
2 xul.dll nsresult nsXPCWrappedJS::CallMethod js/xpconnect/src/XPCWrappedJSClass.cpp:1031
3 xul.dll PrepareAndDispatch xpcom/reflect/xptcall/md/win32/xptcstubs_x86_64.cpp:181
4 xul.dll SharedStub 
5 xul.dll XPTC__InvokebyIndex 
6  @0x87dbbf9ea7 
7 xul.dll trunc 
8 xul.dll static bool XPCWrappedNative::CallMethod js/xpconnect/src/XPCWrappedNative.cpp:1149
9 xul.dll XPC_WN_GetterSetter js/xpconnect/src/XPCWrappedNativeJSOps.cpp:986

There are 3 crashes (from 3 installations) in nightly 72 with buildid 20191031194708. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1591481.

[1] https://hg.mozilla.org/mozilla-central/rev?node=72dac552b387

Comment 1

[Boris Zbarsky [:bzbarsky]]

Hmm. It's possible, though we've had random crash spikes here before; see bug 1260757 for example.

The crash is claimed to be happening at https://hg.mozilla.org/mozilla-central/annotate/4a19c3f74d0cf11a6a2dc143b3b43a88a96f0932/dom/base/nsJSUtils.h#l274 but I really don't see what could be going wrong there, as long as s is not garbage.... And two of the three crashes don't have a useful stack apart from this frame, for some reason...

Can we keep an eye on this for a few days to see whether this persists?

Comment 2

[Calixte Denizet (:calixte)]

So almost nothing for few days and then 14 crashes (8 installs) in 20191104094118 (have a look on the table on top of this report).
In the last 6 months, no crashes in nightly with this signature except the few ones starting with 20191031194708.

Comment 3

[Boris Zbarsky [:bzbarsky]]

dmajor and emilio poked at this a bit.

It looks like every single nightly crash is on the " family 6 model 122 stepping 1 " CPU (the "CPU Info" field in the crash reports). That has some sort of known CPU bug that can lead to crashes; see https://bugs.chromium.org/p/chromium/issues/detail?id=968683 for some discussion. See also bug 1553380 and in particular bug 1553380 comment 2.

In the minidump Emilio was looking at, the JSString seems to contain bogus data (e.g. its flags field doesn't match the length we got out of it, and the chars don't make any sense)...

Comment 4

[Jim Mathies [:jimm]]

Hey Boris, you marked this p1 with no assignee. Any suggestions on who should own this?

Comment 5

[Boris Zbarsky [:bzbarsky]]

I don't know; that's the problem. If this is in fact a CPU issue, the best we can do is try to mitigate it somehow, and it likely depends on the exact alignment of the function and whatnot... The right course of action may be to just ignore it for now and hope it goes away (as it seems to have in newer nightlies).

Comment 6

[Liz Henry (:lizzard) (relman/hg->git project)]

Looks like a very low crash volume, wontfix for 72.

Comment 7

[Liz Henry (:lizzard) (relman/hg->git project)]

Crash volume is spiking now in beta 10 (buildid 20191221003008) . Pushlog for beta 10: https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=FIREFOX_72_0b9_RELEASE&tochange=FIREFOX_72_0b10_RELEASE

Comment 8

[Julien Cristau [:jcristau] (back April 22)]

As predicted this went away on its own in b11. And presumably will come back at random points again.

Comment 9

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Very low volume is the recent esrs and releases.