Crash in Nightly js::Debugger::wrapDebuggeeValue(JSContext*, JS::MutableHandle<JS::Value>)

RESOLVED WORKSFORME

Status

()

Core
JavaScript Engine
--
critical
RESOLVED WORKSFORME
3 years ago
2 years ago

People

(Reporter: Codacoder, Unassigned)

Tracking

({crash, steps-wanted})

34 Branch
x86_64
Windows 7
crash, steps-wanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36

Steps to reproduce:

Clicked "play" in the debugger


Actual results:

bang: https://crash-stats.mozilla.com/report/index/e32d1cc6-487d-401b-af49-fd3572140829
Do you have more detailed steps, ie where were you paused when you clicked resume/run/play, and on what page did that happen? It'd be helpful if we could reproduce this somehow...
Component: General → JavaScript Engine
Flags: needinfo?(russgthomas)
Keywords: steps-wanted, testcase-wanted
Product: Firefox → Core
Severity: normal → critical
Keywords: crash, crashreportid
(Reporter)

Comment 2

3 years ago
(In reply to :Gijs Kruitbosch from comment #1)
> Do you have more detailed steps, ie where were you paused when you clicked
> resume/run/play, and on what page did that happen? It'd be helpful if we
> could reproduce this somehow...

Only thing I can add is a symptom: just prior to the crash, stepping (F10) became very slow.

This is a large application (100+ pages) not a "website". There is no public-facing URL. The code being debugged was a js file inside an iframe (one of many). The js file was also loaded in the outer window.  I had to jump through hoops to get to a point where I could set breakpoints that the debugger would even stop on (because of the way the debugger presents sources - no context!).  Anyway, stepping and walking the stack trying to get to a workable and useful point in the code, it started slowing down... just when I decided "this is hopeless" and hit play, it produced the above.

Question: how to use the debugger to debug myfile.js by setting a breakpoint that only applies to a specific, single instance, og myfile.js?
Flags: needinfo?(russgthomas)
(In reply to Russ from comment #2)
> (In reply to :Gijs Kruitbosch from comment #1)
> > Do you have more detailed steps, ie where were you paused when you clicked
> > resume/run/play, and on what page did that happen? It'd be helpful if we
> > could reproduce this somehow...
> 
> Only thing I can add is a symptom: just prior to the crash, stepping (F10)
> became very slow.
> 
> This is a large application (100+ pages) not a "website". There is no
> public-facing URL. The code being debugged was a js file inside an iframe
> (one of many). The js file was also loaded in the outer window.  I had to
> jump through hoops to get to a point where I could set breakpoints that the
> debugger would even stop on (because of the way the debugger presents
> sources - no context!).  Anyway, stepping and walking the stack trying to
> get to a workable and useful point in the code, it started slowing down...
> just when I decided "this is hopeless" and hit play, it produced the above.

:-(

> Question: how to use the debugger to debug myfile.js by setting a breakpoint
> that only applies to a specific, single instance, og myfile.js?

The best idea I have is setting a conditional breakpoint (right click the line, set conditional breakpoint) and make the condition check for whatever identifies that instance (the breakpoint will be hit if the condition returns true).
(Reporter)

Comment 4

3 years ago
(In reply to :Gijs Kruitbosch from comment #3)
> (In reply to Russ from comment #2)
> > just when I decided "this is hopeless" and hit play, it produced the above.
> 
> :-(
> 
Yeah, I know :/

> > Question: how to use the debugger to debug myfile.js by setting a breakpoint
> > that only applies to a specific, single instance, og myfile.js?
> 
> The best idea I have is setting a conditional breakpoint (right click the
> line, set conditional breakpoint) and make the condition check for whatever
> identifies that instance (the breakpoint will be hit if the condition
> returns true).

That, as you're probably aware, is even more flakey. And will only work if you can identtify the file in the debugger.  Let me back that up with this: part of the code I'm debugging is a test engine and its harness. The testee is a lib loaded and clearly running in one of the iframes.  There's no sign of its corresponding harness/test script in the sources pain. But it's running - hence "the hoops" I referred to.  From what I've "learned" talking to some of the devs here and elsewhere, sources pane does not show "freed" scripts.  So it thinks it's freed, I guess.

Anyway, I filed because it's Nightly.  If a ton of these turn up, someone will want to know.
(Reporter)

Comment 5

3 years ago
I should add, as yet, it hasn't reappeared.

Comment 6

3 years ago
(In reply to Russ from comment #4)
> Anyway, I filed because it's Nightly.  If a ton of these turn up, someone
> will want to know.
(In reply to Russ from comment #5)
> I should add, as yet, it hasn't reappeared.

currently none show up on nightly, very few version 35, no version 36 - https://crash-stats.mozilla.com/search/?signature=~js%3A%3ADebugger%3A%3AwrapDebuggeeValue%28JSContext*%2C+JS%3A%3AMutableHandle%3CJS%3A%3AValue%3E%29&date=%3E2015-03-01&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#crash-reports
Russ' stack points to same line as one I checked from the list above
ms2ger@118356 	685    if (vp.isObject()) {
ms2ger@118356 	686        RootedObject obj(cx, &vp.toObject());
jorendorff@74400 687
terrence@158388 688        if (obj->is<JSFunction>()) {

So close WFM?
Flags: needinfo?(russgthomas)
Keywords: crashreportid
(Reporter)

Comment 7

3 years ago
Sure.  I can barely remember this :)
Flags: needinfo?(russgthomas)
(Reporter)

Updated

3 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
Keywords: testcase-wanted
You need to log in before you can comment on or make changes to this bug.