1815653 - Assertion failure: (ptrBits & 0x7) == 0, at include/js/Value.h:984

Status: RESOLVED DUPLICATE of bug 1817933

(Core :: JavaScript Engine, defect, P2)

Description

[lukas.bernhard]

Steps to reproduce:

On commit e66cff951667dacd0faa95dfde830564a58a8a3f, the attached sample crashes with an assertion violation: Assertion failure: (ptrBits & 0x7) == 0, at obj-x86_64-pc-linux-gnu/dist/include/js/Value.h:984.
Commandline: obj-x86_64-pc-linux-gnu/dist/bin/js --fuzzing-safe crash.js.
This might be debugger-only and not affecting Firefox; still marking as s-s just in case this is a GC issue.

function f0(a1, a2) {
    JSON.parse(JSON.stringify([a2,a2]), a2);
    function f8() {
        function f11(a12) {
            f11 += a2; 
            function f14() {
                return a12;
            }
            for (let v18 = 0; v18 < 100; v18++) { } 

            a12.sameZoneAs = f0; 
            const v17 = this.newGlobal(a12).Debugger(a12);
            v17.getNewestFrame(a2).eval(f11);
            return f11;
        }
        new Promise(f11);
        eval();
    }   
    new Promise(f8);
}
f0(f0, f0);

#0  JS::Value::toGCThing (this=<optimized out>) at obj-x86_64-pc-linux-gnu/dist/include/js/Value.h:984
#1  JS::GCPolicy<JS::Value>::isValid (value=...) at obj-x86_64-pc-linux-gnu/dist/include/js/Value.h:1273
#2  JS::MutableHandle<JS::Value>::set (this=<optimized out>, v=...)
    at obj-x86_64-pc-linux-gnu/dist/include/js/RootingAPI.h:711
#3  0x000055555764b3b6 in mozilla::detail::VariantImplementation<unsigned char, 0ul, js::Completion::Return, js::Completion::Throw, js::Completion::Terminate, js::Completion::InitialYield, js::Completion::Yield, js::Completion::Await>::match<js::Completion::ToResumeModeMatcher, mozilla::Variant<js::Completion::Return, js::Completion::Throw, js::Completion::Terminate, js::Completion::InitialYield, js::Completion::Yield, js::Completion::Await> const&> (aMatcher=..., aV=...) at js/src/debugger/Debugger.cpp:2148
#4  mozilla::Variant<js::Completion::Return, js::Completion::Throw, js::Completion::Terminate, js::Completion::InitialYield, js::Completion::Yield, js::Completion::Await>::match<js::Completion::ToResumeModeMatcher>(js::Completion::ToResumeModeMatcher&&) const & (aMatcher=..., 
    this=<optimized out>) at obj-x86_64-pc-linux-gnu/dist/include/mozilla/Variant.h:840
#5  js::Completion::toResumeMode (value=..., exnStack=..., this=<optimized out>, resumeMode=<optimized out>)
    at js/src/debugger/Debugger.cpp:2181
#6  js::DebugAPI::slowPathOnLeaveFrame (cx=<optimized out>, frame=..., 
    pc=0x7ffff7497068 "\241ȡ&\006\220\060 \f`P\220\020G\005&\021 \n`P&\003fP\221 \v`P\226@\a \f`P\220\060 \030`P\220 \005P/\017P8 \f`P\220 \004P/\023P4 \f`P5 \bT", frameOk=<optimized out>) at js/src/debugger/Debugger.cpp:1218
#7  0x0000555556e94d50 in js::DebugAPI::onLeaveFrame (cx=0x7ffff742f100, frame=..., 
    pc=0x7ffff7497068 "\241ȡ&\006\220\060 \f`P\220\020G\005&\021 \n`P&\003fP\221 \v`P\226@\a \f`P\220\060 \030`P\220 \005P/\017P8 \f`P\220 \004P/\023P4 \f`P5 \bT", ok=true) at js/src/debugger/DebugAPI-inl.h:78
#8  0x0000555557ae35c4 in js::jit::DebugEpilogue (cx=0x7ffff742f100, frame=0x7fffffffa418, pc=0x7ffff7497068 "\241ȡ&\006\220\060 \f`P\220\020G\005&\021 \n`P&\003fP\221 \v`P\226@\a \f`P\220\060 \030`P\220 \005P/\017P8 \f`P\220 \004P/\023P4 \f`P5 \bT", ok=true) at js/src/jit/VMFunctions.cpp:1012

Comment 1

[Nicolas B. Pierron [:nbp]]

Jon, is this be a duplicate of Bug 1816158?

Comment 2

[Jon Coppeard (:jonco)]

(In reply to Nicolas B. Pierron [:nbp] from comment #1)
This still reproduces.

The problem is that |completion| in DebugAPI::slowPathOnLeaveFrame ends up with a Return completion holding a Value poisoned with JS_ALLOCATED_NURSERY_PATTERN. This value came from BaselineFrame::returnValue, via AbstractFramePtr::returnValue, via Completion::fromJSFramePop.

Maybe a JIT issue?

Comment 3

[Iain Ireland [:iain]]

This appears to be related to bug 1817933. Similarly to that bug, we are loading an uninitialized value out of a call object based on a GetName EnvironmentName IC, because debugger eval can unexpectedly change the shape of a CallObject. The quick-and-dirty fix in that bug (force NeedEnvironmentShapeGuard to always generate a shapeguard) also seems to fix this testcase, although I'm not convinced it's the correct fix.

This is debugger-only.

Comment 4

[Iain Ireland [:iain]]

The patch that I've posted for bug 1817933 also fixes this testcase.

Comment 5

[Daniel Veditz [:dveditz]]

Sorry for the burst of bugspam: filter on tinkling-glitter-filtrate
Adding reporter-external keyword to security bugs found by non-employees for accounting reasons