1475822 - Crash in libmodule.dylib@0x20575

Status: RESOLVED DUPLICATE of bug 1473289

(Core :: JavaScript: GC, defect)

Description

[Julian Seward [:jseward]]

This bug was filed from the Socorro interface and is
report bp-5d735fb1-8e19-40ea-9e6e-8e5d50180714.
=============================================================

This is topcrash #2 in the OSX nightly 20180712220034.
There are 4 crashes from 2 installations.  They all appear to be
related to fiddling with page protections in the GC.

Top 10 frames of crashing thread:

0 libmodule.dylib libmodule.dylib@0x20575 
1 libmodule.dylib libmodule.dylib@0x203d9 
2 libmodule.dylib libmodule.dylib@0x2064c 
3 libmodule.dylib libmodule.dylib@0x1fe2d 
4 XUL js::gc::UnprotectPages js/src/gc/Memory.cpp:924
5 XUL <name omitted> js/src/ds/LifoAlloc.cpp:112
6 XUL js::LifoAlloc::release js/src/ds/LifoAlloc.h:783
7 XUL js::InterpreterActivation::~InterpreterActivation js/src/vm/Stack.h:880
8 XUL Interpret js/src/vm/Stack-inl.h:944
9 XUL js::RunScript js/src/vm/Interpreter.cpp:424

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

Comment 1

[Andrew McCreight (out of office until 8/21) [:mccr8]]

I think this LifoAlloc page protect is something that nbp has been looking at.

Comment 2

[Nicolas B. Pierron [:nbp]]

This issue definitely look like the issue I am seeing on Linux, when we OOM in an mprotect, or when Windows claim that we provided invalid parameters to VirtualProtect.  The main difference seems to be that the crash happens in libmodule.dylib instead of our own MOZ_CRASH.

I will mark it as a duplicate of Bug 1473289 for now, and we should see this issue going down. Otherwise I should investigate more what is going on.