STR: * Open test case in browser * Set a breakpoint on line 5: "let result = await this.bar();" * Refresh ER: Pause on the line AR: Debugger UI never pauses, error in console: > error occurred while processing 'frames: TypeError: originalLocation.originalSourceActor is null > Stack: ThreadActor.prototype.onFrames/promise<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/script.js:1267:13 > Handler.prototype.process@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/Promise-backend.js:933:23 > this.PromiseWalker.walkerLoop@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/Promise-backend.js:812:7 > this.PromiseWalker.scheduleWalkerLoop/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/Promise-backend.js:746:11 > EventLoop.prototype.enter@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/script.js:347:5 > ThreadActor.prototype._pushThreadPause@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/script.js:541:5 > ThreadActor.prototype._pauseAndRespond@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/script.js:744:7 > BreakpointActor.prototype.hit@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/script.js:3343:12 > foo/<@file:///Users/fitzgen/scratch/my-class.built.js:10:11 > step@file:///Users/fitzgen/scratch/my-class.built.js:1:183 > _asyncToGenerator/</<@file:///Users/fitzgen/scratch/my-class.built.js:1:423 > _asyncToGenerator/<@file:///Users/fitzgen/scratch/my-class.built.js:1:99 > foo@file:///Users/fitzgen/scratch/my-class.built.js:8:12 > @file:///Users/fitzgen/scratch/my-class.built.js:31:1 > Line: 1267, column: 13 ------------------------------------- Found this while investigating https://github.com/mozilla/source-map/issues/221

I've been curious if there are places where we don't check for null values, looks like this is one of them. This is a weird place though, what do we do if get null when sourcemapping a frame?

This is just a WIP patch thrown together to get the frames request working and the pausing to happen so I could keep debugging that GH issue. Not clean at all. Not even sure what is going on with the controller and view. The core issue is us just not handling frames from null mappings properly.

(In reply to James Long (:jlongster) from comment #2) > I've been curious if there are places where we don't check for null values, > looks like this is one of them. This is a weird place though, what do we do > if get null when sourcemapping a frame? I think it makes sense to either pretend the frame doesn't exist, or something similar to what we do with black boxed frames.

FWIW, I ran into this problem as I was preparing to add the first async/await function to a codebase in TypeScript and wanted to make sure I would be able to debug such code using Firefox. Here's the minimized test case I prepared in order to figure out what was triggering the problem so I could search for this bug. The idea is the same as Nick's test case. This line of the generated JavaScript is synthesized by the TypeScript compiler and has no source mappings: function f() { return __awaiter(this, void 0, Promise, function* () { // <=== debugger; }); } I get the same "TypeError: originalLocation.originalSourceActor is null" and no stack trace in the debugger with Firefox 45. If I manually edit the source map and add some mappings to the line, the problem goes away. You (Nick and James) probably know all this, but I thought I'd write it up in case it helps the next person find this bug more quickly. (In reply to Nick Fitzgerald [:fitzgen] [⏰PDT; UTC-7] from comment #4) > (In reply to James Long (:jlongster) from comment #2) > > This is a weird place though, what do we do > > if get null when sourcemapping a frame? > > I think it makes sense to either pretend the frame doesn't exist, or > something similar to what we do with black boxed frames. I tried my case in Chrome 49 and it just showed the generated source code for that frame, which seems more useful to me.

Matt, thanks for taking the time to comment! This is actually a dupe of bug 1177329 now, which has fix pending. Sorry, if you want this you'll have to use nightly for a while.

(In reply to James Long (:jlongster) from comment #6) > Matt, thanks for taking the time to comment! This is actually a dupe of bug > 1177329 now, which has fix pending. Sorry, if you want this you'll have to > use nightly for a while. > > *** This bug has been marked as a duplicate of bug 1177329 *** Why wouldn't we uplift to dev edition, at least?

We can, but it'll have to sit on nightly for a few days at least. Good to clarify that though. It's a small patch, but could even uplift to beta if we feel it's safe.