951720 - Browser Toolbox busted today on m-c debug on my OSX, Assertion failure: !k->compartment()->options_.invisibleToDebugger()

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: bt.txt

STR:
1. Start today's Nightly on m-c
2. Hit Tools/Web Developer/Browser Toolbox
3. Wait or click on it (I forget)

Assertion failure: !k->compartment()->options_.invisibleToDebugger(), at /Users/Jan/moz/mozilla-central/js/src/vm/Debugger.h:93

(lldb) p k->compartment()->options_
(JS::CompartmentOptions) $2 = {
  (JSVersion) version_ = 4294967295
  (bool) invisibleToDebugger_ = true
  (JS::CompartmentOptions::Override) baselineOverride_ = {
    (JS::CompartmentOptions::Override::Mode) mode_ = Default
  }
  (JS::CompartmentOptions::Override) typeInferenceOverride_ = {
    (JS::CompartmentOptions::Override::Mode) mode_ = Default
  }
  (JS::CompartmentOptions::Override) ionOverride_ = {
    (JS::CompartmentOptions::Override::Mode) mode_ = Default
  }
  (JS::CompartmentOptions::Override) asmJSOverride_ = {
    (JS::CompartmentOptions::Override::Mode) mode_ = Default
  }
  (JS::CompartmentOptions::<anonymous union>) zone_ = {
    (JS::ZoneSpecifier) spec = SystemZone
    (void *) pointer = 0x0000000100000001
  }
}

Workaround: Nothing obvious (clearing flag doesn't prevent future hits)

Comment 1

[Panos Astithas (he/him) [:past] (please ni?)]

I don't see this locally, but it sounds like a regression from bug 930427.

Comment 2

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Confirmed.

Comment 3

[Jon Coppeard (:jonco)]

(In reply to Panos Astithas [:past] from comment #1)
> I don't see this locally, but it sounds like a regression from bug 930427.

Bug 930427 adds an assertion that the debugger doesn't wrap values in compartments that are marked as invisible to the debugger.  Unfortunately that seems to be happening, as the assertion is going off.

So that bug is not the source of the problem, it's just showing that a problem exists.

Comment 4

[Jon Coppeard (:jonco)]

This flag is only set for compartments created by the following:

- nsXULPDGlobalObject::GetCompilationGlobal()
- nsXBLDocGlobalObject::GetCompilationGlobal()

Does anyone know if it's valid for the debugger to be touching values in these compartments?

Comment 5

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Attachment: (gdb) thread apply all bt full.txt

Here is a stack trace from fx-team.

Assertion failure: !k->compartment()->options_.invisibleToDebugger(), at /Users/mratcliffe/Desktop/fx-team/js/src/vm/Debugger.h:81

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
js::DebuggerWeakMap<js::EncapsulatedPtr<JSObject, unsigned long>, js::RelocatablePtr<JSObject> >::relookupOrAdd<JS::Handle<js::ScriptSourceObject*>, JSObject*> (this=<value temporarily unavailable, due to optimizations>, p=@0x7fff5fbf2370, k=<value temporarily unavailable, due to optimizations>, v=@0x7fff5fbf2368) at ObjectImpl.h:1178
1178          MOZ_ASSERT(shape_);

Comment 6

[Jim Blandy :jimb]

Trying to reproduce...

Comment 7

[Jim Blandy :jimb]

Okay, this is a consequence of (obviously) the assertion added in bug 930427, but also the changes in bug 637572 to make cloned scripts refer to their ScriptSourceObjects by wrappers, rather than cloning them.

What's happening is that the chrome debugger server has a Debugger.Script referring to a JSScript that was cloned from an invisible-to-debugger compartment. (This is what invisible-to-debugger compartments are generally used for: creating scripts that get cloned into other compartments.) The debug server then calls the Debugger.Script.prototype.source accessor, yielding a Debugger.Source instance referring to the JSScript's ScriptSourceObject.

As of bug 637572, those ScriptSourceObjects are not cloned, along with the JSScript, into the compartment in which the script will run. Instead, the cloned JSScript continues to refer to the original ScriptSourceObject, in the invisible-to-debugger compartment, via a cross-compartment wrapper.

I think that's the compartment in which the ScriptSourceObject properly belongs. So I think Debugger.Source objects have a legitimate need to point to objects in invisible-to-debugger compartments. The assertion should somehow be relaxed to permit the Debugger.Source DebuggerWeakMaps to point to invisible-to-debugger compartments.

Comment 8

[Jim Blandy :jimb]

Attachment: Allow the DebuggerWeakMaps used for Debugger.Source instances to have keys in invisible-to-debugger compartments.

No tests yet, but I think this will fix it.

Comment 9

[Jim Blandy :jimb]

Attachment: Allow the DebuggerWeakMaps used for Debugger.Source instances to have keys in invisible-to-debugger compartments.

Now, with tests.

Try: https://tbpl.mozilla.org/?tree=Try&rev=3ee29d5897a8

Comment 10

[Jon Coppeard (:jonco)]

Comment on attachment 8350943 [details] [diff] [review]
Allow the DebuggerWeakMaps used for Debugger.Source instances to have keys in invisible-to-debugger compartments.

Review of attachment 8350943 [details] [diff] [review]:
-----------------------------------------------------------------

This is a nice assertion to have, however this is now not strong enough for bug 930427.  This is my fault; I'll reopen that bug.

Comment 11

[Jon Coppeard (:jonco)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/d48b0f0e7fee

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/d48b0f0e7fee

Comment 13

[Paul Silaghi, QA [:pauly]]

Reproduced in 2013-12-18-mozilla-central-debug.
Verified fixed 2014-01-20-mozilla-central-debug, Mac OS X 10.9.