758846 - "Assertion failure: p.found()" with gczeal and chrome-content interaction

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jesse Ruderman]

Attachment: testcase (requires extension)

1. Install https://www.squarefree.com/extensions/domFuzzLite3.xpi (version 2012-05-25 or higher)

2. Load the testcase.

Result:

Assertion failure: p.found(), at js/src/jsproxy.cpp:1474

Comment 1

[Jesse Ruderman]

Attachment: stack trace

Comment 2

[Bob Clary [:bc] (inactive)]

fwiw, I hit this on nightly winxp once at http://www.podnapisi.net/en/ppodnapisi/podnapis/i/1691083/showRelease/1/showYear/0/shortFormat/0/translateTitle/1 but it is not reproducible.
pseudo stack: proxy_TraceObject js::GCMarker::processMarkStackTop(js::SliceBudget&) js::GCMarker::drainMarkStack(js::SliceBudget&) NonIncrementalMark GCCycle

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: fix

The assertion is saying that every cross-compartment wrapper should be registered in the wrapper map. This invariant is temporarily violated when creating the wrapper. We can GC during the period when it's violated.

I don't think this is a problem. The object being wrapped should always be on the stack during the violation, so any GC at that time is guaranteed to scan the wrapped object. That's all we really care about, so I think we're safe.

This patch just keeps a count of how many invocations of JSCompartment::wrap are on the stack. If this number is non-zero, then we don't do the assertion.

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/57054d8b1582

Also, this is not sensitive.

Comment 5

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/57054d8b1582