Crash in [@ js::jit::BailoutFrameInfo::BailoutFrameInfo]
Categories
(Core :: JavaScript Engine: JIT, defect, P2)
Tracking
()
People
(Reporter: yoasif, Unassigned)
Details
(Keywords: crash)
Crash Data
This bug is for crash report bp-a79b3de6-b1d0-432f-bab2-b347b0191217.
Top 4 frames of crashing thread:
0 xul.dll js::jit::BailoutFrameInfo::BailoutFrameInfo js/src/jit/x64/Bailouts-x64.cpp:52
1 xul.dll js::jit::Bailout js/src/jit/Bailouts.cpp:41
2 @0x3f08fa8116e
3 xul.dll js::jit::JitScript::MonitorAssign js/src/vm/TypeInference-inl.h:650
Reported on https://www.reddit.com/r/firefox/comments/eb14lj/my_favorite_firefox_feature_is/
|
||
Comment 1•6 years ago
|
||
This seems to highlight that we have a bad stack pointer interpretation, but this kind of bug is almost impossible to investigate without a script which is reproducing the issue.
Do you have more crash reports which we could investigate?
|
Reporter | |
Comment 2•6 years ago
•
|
||
|
||
Comment 3•6 years ago
|
||
The priority flag is not set for this bug.
:sdetar, could you have a look please?
For more information, please visit auto_nag documentation.
|
||
Updated•6 years ago
|
|
|
||
Comment 4•6 years ago
|
||
(In reply to Asif Youssuff from comment #2)
Some more crash ids here:
bp-f94eea09-5125-469c-b7cd-3bd400191216
bp-b9fed05d-0153-4509-b4a4-c982d0191216
bp-fcb8ae87-029c-4776-9028-0123c0191216
bp-3021bd4c-4b3a-41df-81ad-620330191216
Thanks,
These crashes are spread-out across different locations of the code, and each location is not a frequent crash signature either.
My blind guess would be that there is a single explanation behind all these crashes, and the most likely single explanation which cause unexpected values to be used and then crash, is a memory corruption.
-
One source of memory corruption is bad RAM:
The crash reports have a system-memory-usage of 29%, 33%, 34%, 35%. Could you run a RAM tester, to check if the RAM corrupts its content when written to or written to adjacent memory. -
Another source of memory corruption is bad code:
For these we have a different version of Firefox, which uses Address Sanitizer compilation option, to track which part of the code modifies which part of the memory.
The link to download these versions are:
Linux x64: https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/firefox-73.0a1.en-US.linux-x86_64-asan-reporter.tar.bz2
Windows x64: https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/firefox-73.0a1.en-US.win64-asan-reporter.zip
|
|
Reporter | |
Updated•6 years ago
|
|
|
||
Comment 5•6 years ago
|
||
Asif, do you have any updates on this bug? I noticed you needinfo'd yourself.
|
|
Reporter | |
Comment 6•6 years ago
|
||
I don't -- I reached out to the original poster a while ago and got no responses. I sent another message. I'll remove the NI and comment again if I get a response.
|
|
Reporter | |
Comment 7•6 years ago
|
||
User says:
Earlier i had Windows 7 as the OS. 1 week back i installed Windows 10. I dont know if it is the new OS or latest update from Mozilla, I'm not having any issues so far. But while i was using windows 7 i ran a memory test and found no hardware error.
Happy to resolve this issue as incomplete unless you have any further ideas. It is weird that installing Windows 10 seems to have resolved the issue but they ran a memory test and they say it passed.
|
||
Comment 8•6 years ago
|
||
(In reply to Asif Youssuff from comment #7)
Happy to resolve this issue as incomplete unless you have any further ideas. It is weird that installing Windows 10 seems to have resolved the issue but they ran a memory test and they say it passed.
That is weird. It could still be some kind of hardware issue, or other software messing with the system or so.
Thanks for following up on this.
|
|
||
Updated•6 years ago
|
Description
•