Closed Bug 1111367 Opened 10 years ago Closed 10 years ago

Devtools Nightly crash js::ArgumentsObject::create<CopyFrameArgs>(...)

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Version:
37 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: codacodercodacoder, Unassigned)

References

Details

(Keywords: crash)

Crash Data

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36 Steps to reproduce: Having landed on a debugger; statement in debugger, hit "play" Actual results: crash. 100% repeatable. https://crash-stats.mozilla.com/report/index/7cdc7427-c73f-4192-b8b1-9ac512141214
(In reply to Russ from comment #0) > User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, > like Gecko) Chrome/39.0.2171.71 Safari/537.36 > > Steps to reproduce: > > Having landed on a debugger; statement in debugger, hit "play" Could you detail your STR, please? Testcase maybe?
Flags: needinfo?(russgthomas)
Sorry, my steps are pretty much as I wrote them. All I can add is, I could step from the same point, but hitting play would always crash.
Flags: needinfo?(russgthomas)
I'm not able to reproduce it. Did you add a breakpoint in the code of a specific page?
Not a bp, a debugger; statement in javascript (there is a difference). My app is a large .NET app not available via public URL.
Severity: normal → critical
Crash Signature: [@ js::ArgumentsObject::create<CopyFrameArgs>(JSContext*, JS::Handle<JSScript*>, JS::Handle<JSFunction*>, unsigned int, CopyFrameArgs&) ]
Keywords: crash, crashreportid, testcase-wanted
I tried writing you a testcase: http://gijsk.com/mozilla/testcases/debugger-crash/ it's not crashing. Any chance you can try to narrow down why it's crashing on your page but not here, if you're unwilling to make the app available?
Flags: needinfo?(russgthomas)
See Also: → 1107928
"Unwilling" is the wrong word - "unable" is the correct one. I've been avoiding Nightly because of bug 1113155 but i just updated and ran it again: bang first time. https://crash-stats.mozilla.com/report/index/73ecd56f-db2e-4473-a1fe-9a0662150109 The only other thing I can do is show you this over a gotomeeting - agree a time and I'll set it up and send you the meeting ID via email. You could record it or at least see it. Lemme know.
Flags: needinfo?(russgthomas)
Just noticed that report is a different signature.
Yep, it moves around: https://crash-stats.mozilla.com/report/index/8403d973-05d2-40de-af50-1a5442150109 Regardless, the debugger; statement is in the same place (in a dynamically loaded js lib) and loaded by various pages on the site. Once hit in the debugger and then clicking play, I get the crash.
(In reply to Russ from comment #7) > "Unwilling" is the wrong word - "unable" is the correct one. Can't you save page as... webpage (complete), test that you can still crash on there, and then attach an archive of the page + the _files directory here? > I've been avoiding Nightly because of bug 1113155 but i just updated and ran > it again: bang first time. > https://crash-stats.mozilla.com/report/index/73ecd56f-db2e-4473-a1fe- > 9a0662150109 > > The only other thing I can do is show you this over a gotomeeting - agree a > time and I'll set it up and send you the meeting ID via email. You could > record it or at least see it. Lemme know. I don't have the domain-expertise in our JS engine to know what to do with this, but other people might be interested. Looking at both of these stacks, they both include the JIT... If you restart Firefox in safe mode (disables the JIT) and try there, does that make the crash go away?
Component: Untriaged → JavaScript Engine
Flags: needinfo?(russgthomas)
Product: Firefox → Core
(In reply to Russ from comment #9) > Yep, it moves around: > https://crash-stats.mozilla.com/report/index/8403d973-05d2-40de-af50- > 1a5442150109 > > Regardless, the debugger; statement is in the same place (in a dynamically > loaded js lib) and loaded by various pages on the site. Once hit in the > debugger and then clicking play, I get the crash. Hrm, but that stack doesn't include the JIT. :-( Well, try safe mode anyway, but I'm not super-hopeful. Jim or Jan, would either of you be able to look into this in more detail via gotomeeting and/or do you have other suggestions as to how to fix this or figure out more details?
Flags: needinfo?(jimb)
Flags: needinfo?(jdemooij)
(In reply to :Gijs Kruitbosch from comment #10) > (In reply to Russ from comment #7) > > "Unwilling" is the wrong word - "unable" is the correct one. > > Can't you save page as... webpage (complete), test that you can still crash > on there, and then attach an archive of the page + the _files directory here? I'm not allowed to do that. :/ > Looking at both of these stacks, they both include the JIT... If you restart > Firefox in safe mode (disables the JIT) and try there, does that make the > crash go away? Explain to me how...
Flags: needinfo?(russgthomas)
For clarity, I should probably have added to this... > Regardless, the debugger; statement is in the same place (in a dynamically > loaded js lib) and loaded by various pages on the site. Once hit in the > debugger and then clicking play, I get the crash. If I don't load the debugger, app works fine.
(In reply to Russ from comment #12) > (In reply to :Gijs Kruitbosch from comment #10) > > (In reply to Russ from comment #7) > > > "Unwilling" is the wrong word - "unable" is the correct one. > > > > Can't you save page as... webpage (complete), test that you can still crash > > on there, and then attach an archive of the page + the _files directory here? > > I'm not allowed to do that. :/ Even if you censor out whatever actual information with lorem ipsum or whatever? :-( > > Looking at both of these stacks, they both include the JIT... If you restart > > Firefox in safe mode (disables the JIT) and try there, does that make the > > crash go away? > > Explain to me how... Help > Restart with add-ons disabled... (and then click through the dialogs to restart in safe mode / with add-ons disabled --- avoid resetting/refreshing firefox :-) ) See also: https://support.mozilla.org/kb/troubleshoot-firefox-issues-using-safe-mode
Bingo. But, ALL my addons are set to "Ask" or "Never" - hmmm interesting?
Wait... it's been a while since I checked Addons... I see that ActiveTouch is "Always" and so is OpenH264/Cisco (I've been reading about this thing on dev chat recently). I'll disable those two and return normal browsing (not safe mode) and report back.
(In reply to Russ from comment #16) > Wait... it's been a while since I checked Addons... I see that ActiveTouch > is "Always" and so is OpenH264/Cisco (I've been reading about this thing on > dev chat recently). I'll disable those two and return normal browsing (not > safe mode) and report back. It's unlikely (but possible) that it's related to your add-ons. Despite its name, "restart with add-ons disabled" also disables other things, like graphics hardware acceleration, and the javascript JIT. The latter is likely what is resolving the crashiness for you.
Right so... 1 - NOT safe mode 2 - OpenH264 addon set to "Never" 3 - ActiveTouch set to "Never" 4 - debugger; statement in place 5 - Open DevTools, hit debugger; statement, click play... And I'm running... 6 - re-enable OpenH264, no crash 7 - disable OpenH264, re-enable ActiveTouch, no crash 8 - re-enable both, no crash I was just about to say "I'm Stumped, I give up" and decided to Ctrl-Shift-Delete (clear cache) and reload "just to see". I landed on the debugger; statement, hit play and... https://crash-stats.mozilla.com/report/index/e517114d-ad85-47ab-a156-217512150109 That's BOTH addons re-enabled, cache cleared, F5...
(In reply to :Gijs Kruitbosch from comment #17) > (In reply to Russ from comment #16) > > Wait... it's been a while since I checked Addons... I see that ActiveTouch > > is "Always" and so is OpenH264/Cisco (I've been reading about this thing on > > dev chat recently). I'll disable those two and return normal browsing (not > > safe mode) and report back. > > It's unlikely (but possible) that it's related to your add-ons. Despite its > name, "restart with add-ons disabled" also disables other things, like > graphics hardware acceleration, and the javascript JIT. The latter is likely > what is resolving the crashiness for you. Right. Well, it's changed - now I need a few hits to bring out a crash... so we've gone from 100% repeatable to ~30%.
This is new... 1 - NOT safe mode 2 - Both addons enabled 3 - rerun app, land on debugger; statement 4 - hit play, everything is working, but... 5 - hit F5, BANG https://crash-stats.mozilla.com/report/index/e42d02aa-7aac-4981-b16f-55d312150109
And note guys... I work in Dev Edition (36) all day and "live" in the debugger and never see this behavior. So it's definitely all 37 branch related.
Forwarding to Shu. This bug has various crash reports with different stacks, but all are related to the debugger.
Flags: needinfo?(jdemooij) → needinfo?(shu)
Hi Russ, sorry to hear about these crashes. Unfortunately the information here isn't very actionable for me. Looking at the signatures I can only make guesses. I see a couple that crash on cleanup code, especially when trying to clean up the Debugger frames map, when the Debugger is trying to clean everything up. This is usually caused by a bug in managing Debugger.Frame objects in the frames map. The gist of it is that every Debugger.Frame object created when a Debugger introspects a frame must be cleaned up when the referent, underlying frame gets popped somehow. If there's a bug and not every Debugger.Frame gets cleaned up properly, you can get crashes that look like some of the ones you've gotten. Without a test case, it's very unlikely I'll find a bug though.
Flags: needinfo?(shu)
Thanks Shu. I hope this doesn't reach Dev Edition - this would be a show-stopper for me. If there's anything else you can think I could do to help, let me know.
Russ, have you tried running the test case under a debug build, to see if any assertions are tripped? That would be very helpful, if there are assertion failures.
Short answer, no, I haven't. It's been a long time since I last used a debug build (I did that once to help you guys with a memory leak you had in the audio subsystem). I'd need some hand-holding to do that but, if you're willing, I'll carve out the time to do that for you. I'll need all the info where to get it, what hoops to jump thru on win7 etc...
(In reply to Russ from comment #26) > Short answer, no, I haven't. > > It's been a long time since I last used a debug build (I did that once to > help you guys with a memory leak you had in the audio subsystem). I'd need > some hand-holding to do that but, if you're willing, I'll carve out the time > to do that for you. I'll need all the info where to get it, what hoops to > jump thru on win7 etc... Give me a few to write up some stronger assertions and some instrumentations, and I'll make a try push where you can download the debug builds.
Sure. For reference (revealing my capabilities and the level of hand-holding required since I'm not a moz dev) https://bugzilla.mozilla.org/show_bug.cgi?id=936784 <- and, for the casual observer, NOT RELATED TO THIS BUG!
Here's a try push with debug Windows builds: https://tbpl.mozilla.org/?tree=Try&rev=ab14dfd40af7 When it's built (indicated by a green B), click on the B, look in the lower left hand corner, and follow the "go to build directory" link. You should then be able to find an installer for the debug build.
Clearing needinfo, since Shu has taken this.
Flags: needinfo?(jimb)
(In reply to Shu-yu Guo [:shu] from comment #29) > Here's a try push with debug Windows builds: > https://tbpl.mozilla.org/?tree=Try&rev=ab14dfd40af7 > > When it's built (indicated by a green B), click on the B, look in the lower > left hand corner, and follow the "go to build directory" link. You should > then be able to find an installer for the debug build. Shu - I'm snowed under atm - I will get back to this, promise!
The fuzzers just found bug 1125120. Investigating now. Hopefully it's the same bug as this one.
(In reply to Shu-yu Guo [:shu] from comment #32) > The fuzzers just found bug 1125120. Investigating now. Hopefully it's the > same bug as this one. better now that 1125120 is fixed?
Flags: needinfo?(russgthomas)
Keywords: crashreportid
Jeez... sorry guys, I haven't been able to find the time to help Shu (re comment 29). Tested Nightly and it seems fixed.
Flags: needinfo?(russgthomas)
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.