1420582 - Crash in js::jit::TempAllocator::allocate (memory corruption?)

Status: REOPENED

(Core :: JavaScript Engine, defect, P3)

Description

[baffclan]

This bug was filed from the Socorro interface and is
report bp-5237f78e-0928-450f-b470-91a930171125.
=============================================================

Top 10 frames of crashing thread:

0 xul.dll js::jit::TempAllocator::allocate js/src/jit/JitAllocPolicy.h:50
1  @0x18b00000003 
2 xul.dll js::jit::RegisterAllocator::minimalDefEnd js/src/jit/RegisterAllocator.h:351
3  @0x96a71c839ab0 
4 xul.dll js::jit::BacktrackingAllocator::trySplitBeforeFirstRegisterUse js/src/jit/BacktrackingAllocator.cpp:2867
5 xul.dll js::jit::BacktrackingAllocator::chooseBundleSplit js/src/jit/BacktrackingAllocator.cpp:3165
6 xul.dll js::jit::BacktrackingAllocator::processBundle js/src/jit/BacktrackingAllocator.cpp:1363
7 xul.dll js::jit::BacktrackingAllocator::go js/src/jit/BacktrackingAllocator.cpp:871
8 xul.dll js::jit::GenerateLIR js/src/jit/Ion.cpp:1902
9 xul.dll js::jit::CompileBackEnd js/src/jit/Ion.cpp:1970

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


Application Basics: 
Name: Firefox
Version: 59.0a1
Build ID: 20171124220317
Update Channel: nightly
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
OS: Windows_NT 10.0

Comment 1

[Jason Orendorff [:jorendorff]]

Jan, could you take a look?

Comment 2

[Jan de Mooij [:jandem]]

Forwarding to nbp since he rewrote the LifoAlloc code.

Not much to go on here. The crash volume in the past 7 days isn't that high and most crashes are on ESR52. Someone submitted a bunch of duplicate crash reports for 58.0b6. I don't think this is worth spending a lot of time on.

Comment 3

[Nicolas B. Pierron [:nbp] {away}]

- 4.56% of the crashes are reporting the jemalloc poison value.
- 1 report has "MOZ_RELEASE_ASSERT(magic_ == magicNumber)" Which got added to report memory corruption.
- Some crashes are weird, such as [1] which is a SEGV without any memory read/write (how?)
- Most crashes are under Vector<>::growStorageBy(…)
- 4 different versions, could crash with the same bad address 0xe52d2004 [2] (how?).  It seems that this is could be a reused poisoned value but I cannot make sense of this offset yet, and why it would appear 4 times over 2000 crashes.

So far, the most likely explanation is a memory corruption. Though, I have no idea what might be causing this memory corruption.

Downgrading it to P3 as it does not seems to be actionable.

[1] https://crash-stats.mozilla.com/report/index/bb9b0be2-5a14-4c69-8dc8-fad620171204
[2] https://crash-stats.mozilla.com/signature/?product=%21Thunderbird&address=%3D0xe52d2004&signature=js%3A%3Ajit%3A%3ATempAllocator%3A%3Aallocate&date=%3E%3D2017-06-06T13%3A01%3A48.000Z&date=%3C2017-12-06T13%3A01%3A48.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_sort=-date&page=1#reports

Comment 4

[Hani Yacoub, Desktop QA]

Closing this as resolved:worksforme since there were no crashes in the last 6 months for this signature.

Comment 5

[Hani Yacoub, Desktop QA]

I'll Reopen this bug again. There have been crashes with this signature.

Comment 6

[Nicolas B. Pierron [:nbp] {away}]

Looking again at the crash addresses, comment 4 still holds.

Comment 7

[Wayne Mery (:wsmwk)]

(In reply to Nicolas B. Pierron [:nbp] from comment #6)

Looking again at the crash addresses, comment 4 still holds.

Not sure what this means, given that comment 4 didn't mention crash addresses, only crash frequency - which was inaccurate, strictly speaking, but as a practical matter the crash rate is near zero per https://crash-stats.mozilla.org/signature/?signature=js%3A%3Ajit%3A%3ATempAllocator%3A%3Aallocate&date=%3E%3D2021-08-02T07%3A56%3A00.000Z&date=%3C2021-09-02T07%3A56%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&page=1#graphs

So good to close?

Comment 8

[Steven DeTar [:sdetar]]

Nicolas, could you help answer Wayne's question in Comment 7?

Comment 9

[Nicolas B. Pierron [:nbp] {away}]

(In reply to Wayne Mery (:wsmwk) from comment #7)

So good to close?

Yes.