Crash in [@ InvalidateActivation] with MOZ_RELEASE_ASSERT(makeWritable())
Categories
(Core :: JavaScript Engine: JIT, defect)
Tracking
()
People
(Reporter: mccr8, Unassigned)
Details
(Keywords: crash)
Crash Data
This bug is for crash report bp-53fa07c7-27d9-420c-a588-48c6a0200812.
Top 6 frames of crashing thread:
0 libxul.so InvalidateActivation js/src/jit/Ion.cpp:2535
1 libxul.so js::jit::Invalidate js/src/jit/Ion.cpp:2630
2 libxul.so js::jit::Invalidate js/src/jit/Ion.cpp:2721
3 libxul.so js::jit::IonGetPropertyIC::update js/src/jit/IonIC.cpp:222
4 @0x2be09674dfe7
5 libxul.so _fini
The crash reason is MOZ_RELEASE_ASSERT(makeWritable()). There aren't a ton of these crashes, but it is a release assert so I figured that I'd file it.
|
||
Comment 1•4 years ago
|
||
The assertion basically mention that the system refused to change the memory protection (likely due to having too much fragmentation of the page table), which as far as I experienced, is only truly reported on Linux, badly reported on Windows as being incorrect arguments, and simply crashes on Mac.
I do not think there is much we could do here, except falling back on mapping all executable code as X^W at once, instead of the few pages which are being requested. However doing so would make it easier for an attacker to take over Firefox processes.
Another alternative would be to increase the executable page sizes as we detect these crashes, and update it across all our pages. However this also sounds risky to get the implementation right for such a corner case.
Thus I would be inclined of leaving these crashes as-is, as the alternative sounds riskier.
Description
•