907440 - Breakpoints not hitting when using sourcemaps in GWT

Status: RESOLVED DUPLICATE of bug 1355126

(DevTools :: Debugger, defect, P3)

Description

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(In reply to Brian Slesinsky from comment #9)
> I don't have full repro steps yet and for GWT this would be a bit involved,
> but here are some observations from playing around with GWT's Super Dev Mode
> and nightly 26.0a1 (2013-08-13):
>  
> - The Java source shows up fine when I turn sourcemaps on. (The order of the
> files on the left is unclear; they aren't obviously grouped by directory and
> they aren't always in alphabetical order either. Fortunately search works.)
> - If I set a breakpoint in the Java source, it appears in the listing the
> left, but the breakpoint has no apparent effect.
> - If I turn sourcemaps off, there's no corresponding breakpoint listed in
> the JavaScript file.
> - If I turn sourcemaps back on and remove the Java breakpoint, it doesn't
> work. The breakpoint doesn't disappear on the left side, and if I reload the
> page, the breakpoint reappears.
> - If I turn off breakpoints, set a breakpoint in the JavaScript, then turn
> sourcemaps back on, it stops at the correct place in the Java code.

(In reply to Brian Slesinsky from comment #10)
> Also, saw this stack trace:
> 
> Error: 'delete' request packet has no destination.:
> DC_request@resource://gre/modules/devtools/dbg-client.jsm:581
> @resource://gre/modules/devtools/dbg-client.jsm:328
> Breakpoints.prototype.removeBreakpoint@chrome://browser/content/devtools/
> debugger-controller.js:1441
> Breakpoints.prototype.destroy@chrome://browser/content/devtools/debugger-
> controller.js:1247
> DebuggerView._destroyEditor@chrome://browser/content/devtools/debugger-view.
> js:195
> DebuggerView.destroy@chrome://browser/content/devtools/debugger-view.js:82
> DebuggerController.shutdownDebugger@chrome://browser/content/devtools/
> debugger-controller.js:122
> DebuggerController._onTabDetached@chrome://browser/content/devtools/debugger-
> controller.js:239
> EventEmitter_emit@resource://gre/modules/commonjs/toolkit/loader.js ->
> resource:///modules/devtools/shared/event-emitter.js:107
> TabTarget.prototype.destroy@resource://gre/modules/commonjs/toolkit/loader.
> js -> resource:///modules/devtools/framework/target.js:407
> TBOX_destroy@resource://gre/modules/commonjs/toolkit/loader.js ->
> resource:///modules/devtools/framework/toolbox.js:824

Comment 1

[Brian Slesinsky]

I now have a site to test against: www.gwtproject.org

In Firefox 26, it looks like it's partially working.

An example that works: go to GWTProjectEntryPoint.java line 61 (in openMenu), set the breakpoint, and then click on a menu item on the website. 

This also works: set a breakpoint in GWTProjectEntryPoint.java line 51 (in onModuleLoad) and then reload the page.

However, it's not reliable yet. For example, I set a breakpoint in the getModuleName() function in GWT.java line 140. The "run" cursor starts flickering for a long time and Firefox is basically locked up. The first time I tried this, I gave up and killed Firefox. On the second try, I eventually got a dialog:

A script on this page may be busy, or it may have stopped responding.
Script: chrome://browser/content/devtools/orion.js:831

I later noticed that a breakpoint showed up in Duration.java line 56.

Comment 2

[javascriptjedi]

Why has this sat idle for so long?  This is a showstopper for GWT.  FF no longer supports Dev mode, so Super Dev Mode is the only option, and it requires source maps to work properly.  As of now, my only option is Google Chrome.

Comment 3

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(In reply to javascriptjedi from comment #2)
> Why has this sat idle for so long?  This is a showstopper for GWT.  FF no
> longer supports Dev mode, so Super Dev Mode is the only option, and it
> requires source maps to work properly.  As of now, my only option is Google
> Chrome.

I feel your pain, but the team only has so many resources to allocate.

If you'd like to accelerate progress on this bug, you can help in a few ways:

* Make a reduced test case and attach it to the bug, so that whoever starts
  fixing this doesn't have to deal with large, unknown GWT code bases.

* Determine if the error messages are still the same or if there are new ones /
  different ones / etc in the latest Nightly, since things might have changed
  since the initial bug report.

* Determine if this only affects breakpoints, or all kinds of pauses, such as
  debugger statements, exceptions thrown when pause-on-exceptions is set, etc.

* Hack on the tools and try and produce a patch that fixes the problem, or at
  least determines exactly where the problem lies. Often -- especially with
  source map bugs -- the hard part is determining where things start to go
  wrong, and after that the fix is often easy. If you're interested, let me know
  and I can help mentor you. See this wiki[0] page for getting started on
  hacking on the devtools. We need to determine if this is an issue with:

    - The source maps being generated by GWT (this source map visualizer[1] can
      help determine that)

    - The source-map[2] library incorrectly translating locations.

    - SpiderMonkey's Debugger api failing to find and set breakpoints at the
      proper location on the correct script. See
      `ThreadActor.prototype._setBreakpoint`[3] which takes the source mapped
      breakpoint location and interacts with the Debugger api to actually set a
      breakpoint in SpiderMonkey.

    - SpiderMonkey actually calling the breakpoint's handler[4]

    - Somewhere else in the code.

  Once we've figured that out, it should hopefully be pretty easy for either you
  to go the last mile and fix it or for someone else to come pick it up since
  we'd likely know exactly what's going wrong at that point.

[0] https://wiki.mozilla.org/DevTools/Hacking
[1] http://sokra.github.io/source-map-visualization/
[2] https://github.com/mozilla/source-map
[3] http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/script.js?rev=c20ded724d44#1499
[4] http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/script.js?rev=c20ded724d44#4478

Comment 4

[Brian Slesinsky]

There's unlikely to be a serious problem with how GWT generates sourcemaps, since it works in Chrome and is widely used now. (I have my own tool for visualizing sourcemaps and they look okay.)

However, there may be an issue with how Firefox's JavaScript engine interprets the JavaScript ranges in the sourcemap. This might differ a bit from V8 since the internal data structures are different.

The GWT app on gwtproject.org is very small (as GWT apps go) and unoptimized, so it shouldn't be too hard to understand. Of course, narrowed-down JavaScript-only examples would be better.

Comment 5

[Tom Tromey :tromey]

I think this is most likely a dup of bug 1355126.
I'm closing it as such, since I did the work to fix GWT Super Dev Mode there.
If this is in error, please comment or reopen.
I tried the site from comment #1 with a recent build and that all seems to work.