Closed Bug 1746270 Opened 2 years ago Closed 4 months ago

Crash in [@ double_conversion::PowersOfTenCache::GetCachedPowerForBinaryExponentRange] on Gemini Lake-based Atom CPUs

Categories

(Core :: JavaScript Engine, defect, P3)

Unspecified
Windows 10
defect

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: gsvelto, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash)

Crash Data

Crash report: https://crash-stats.mozilla.org/report/index/5fa83b06-9775-4d9b-b58d-3eec40211215

Reason: EXCEPTION_ACCESS_VIOLATION_EXEC

Top 9 frames of crashing thread:

0 None @0x00007ff865378840 
1 mozglue.dll double_conversion::PowersOfTenCache::GetCachedPowerForBinaryExponentRange mfbt/double-conversion/double-conversion/cached-powers.cc:145
2 mozglue.dll double_conversion::FastDtoa mfbt/double-conversion/double-conversion/fast-dtoa.cc:649
3 mozglue.dll static double_conversion::DoubleToStringConverter::DoubleToAscii mfbt/double-conversion/double-conversion/double-to-string.cc:428
4 mozglue.dll double_conversion::DoubleToStringConverter::ToShortestIeeeNumber const mfbt/double-conversion/double-conversion/double-to-string.cc:182
5 xul.dll NumberToStringWithBase<js::CanGC> js/src/jsnum.cpp:1642
6 xul.dll js::ToStringSlow<js::CanGC> js/src/vm/StringType.cpp:2290
7 None @0x0000026fc1927399 
8 xul.dll _tailMerge_d3dcompiler_47.dll 

I'm completely stumped about what might be causing this. We're crashing because we're running code that is in a non-executable page, but the crashing address points to nothing of the sort. I cracked a minidump open in Visual Studio and the stack trace was pretty much the same.

Group: dom-core-security
Component: mozglue → JavaScript Engine
Summary: Crash in [@ double_conversion::PowersOfTenCache::GetCachedPowerForBinaryExponentRange] → Crash in [@ double_conversion::PowersOfTenCache::GetCachedPowerForBinaryExponentRange] on Gemini Lake-based Atom CPUs

What's happening here is that the stack is being corrupted - somehow - and at some point in the double-conversion code we return to an address pulled off of the stack which is wrong. This would be super-worrisome if it weren't happening on just one type of CPUs: the sadly very common Gemini Lake-based Intel Atom CPUs. We already encountered this in bug 1553380 and so has Chrome (see further references on that bug).

See Also: → 1553380

Bug 1702019 was another instance of this...

See Also: → 1702019

Gabriele, considering this is most likely the same issue we discussed in other public bugs, I think we can open this up?

Flags: needinfo?(gsvelto)

Yeah, let's open it up.

Group: dom-core-security
Flags: needinfo?(gsvelto)

Given this is triggered by a specific code-sequence it's likely that we'll see the spike go away in future builds.

Priority: -- → P3

Since the crash volume is low (less than 5 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.

Severity: S2 → S3

This largely seems to have abated due to the changes of code and passage of time. I don't think it's worth keeping this open

Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.