Closed jpolitz closed 6 years ago
Ah, figured it out. There was a function created by Function
as part of the stack trace, which is causing the error because it doesn't have a source location. Here's a much simpler repro:
var synthf = Function("f", "return f() + 1");
var g = function() {
return synthf(h);
}
var h = function() {
console.log("In h");
debugger;
return 6;
}
console.log(g());
⤇ node debug ~/scratch/eval-fun.js
< Debugger listening on port 5858
connecting to 127.0.0.1:5858 ... ok
break in scratch/eval-fun.js:1
> 1 var synthf = Function("f", "return f() + 1");
2 var g = function() {
3 return synthf(h);
debug> c
< In h
break in scratch/eval-fun.js:7
5 var h = function() {
6 console.log("In h");
> 7 debugger;
8 return 6;
9 }
debug> bt
(node:45862) There was an internal error in Node's debugger. Please report this bug.
Path must be a string. Received undefined
TypeError: Path must be a string. Received undefined
at assertPath (path.js:7:11)
at Object.basename (path.js:1357:5)
at _debugger.js:1174:22
at _debugger.js:639:7
at _debugger.js:294:5
at Client._onResponse (_debugger.js:250:5)
at Protocol.Client.protocol.onResponse (_debugger.js:163:39)
at Protocol.execute (_debugger.js:121:14)
at Client.<anonymous> (_debugger.js:160:14)
at emitOne (events.js:96:13)
@jpolitz - is this still outstanding? if so can you try with the latest?
This can be closed. The old debugger was deprecated in favor of the V8 inspector.
Thanks for following up. Confirmed that this works fine with node inspect
.
I got a crashing error in the debugger on the
bt
command. The whole trace is at the end of the report. Using iTerm2 3.0.8.The file under test is pretty huge (20M), and is gnarly compiled output; I can provide it if it's helpful, along with instructions for running it (though it will be somewhat involved). I'm not totally sure how to begin isolating it to something smaller – I use the debugger in this way relatively frequently, and this is the first crash I've seen.
The sequence below seems to reliably cause the crash, but I haven't found a variation or shorter sequence that causes it. For example, I tried leaving out all the commands other than
c
and the setting and clearing of breakpoints, and the crash didn't happen.Removing the
--stack-trace-limit
option doesn't change the behavior I see.The sequence of debugger commands (summarized) was:
The whole trace was: