Crash in js::jit::TempAllocator::allocate (memory corruption?)
Categories
(Core :: JavaScript Engine, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox59 | --- | affected |
People
(Reporter: baffclan, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: crash)
Crash Data
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
Updated•7 years ago
|
Comment 2•7 years ago
|
||
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•7 years ago
|
||
- 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
Updated•6 years ago
|
Comment 4•3 years ago
|
||
Closing this as resolved:worksforme since there were no crashes in the last 6 months for this signature.
Comment 5•3 years ago
|
||
I'll Reopen this bug again. There have been crashes with this signature.
Comment 6•3 years ago
|
||
Looking again at the crash addresses, comment 4 still holds.
Comment 7•3 years ago
|
||
(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•3 years ago
|
||
Nicolas, could you help answer Wayne's question in Comment 7?
Comment 9•3 years ago
|
||
Updated•3 years ago
|
Description
•