jpolitz
commented
7 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)
gireeshpunathil
bnoordhuis
I got a crashing error in the debugger on the
btcommand. 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
cand the setting and clearing of breakpoints, and the crash didn't happen.Removing the
--stack-trace-limitoption doesn't change the behavior I see.The sequence of debugger commands (summarized) was:
The whole trace was: