Welcome to the Linux Foundation Forum!

Lab 4.2 - Setting a Breakpoint Using a Code Keyword

Question: The labs-2 folder has an ​app.js​ file, edit the file so that when started in Inspect mode it willpause in the first line of the ​f​ function.

function f (n = 99) {
if (n === 0) throw Error()
f(n - 1)


Problem: I have given the command 'node --inspect app.js'
My application is not stopping in line 2. Am i doing something wrong here.


  • I am having the same issue. Node version 12.19.0

  • lcyzh
    lcyzh Posts: 1

    Only --inspect-brk works at the moment.

  • zorawar
    zorawar Posts: 14
    edited October 2020

    The same behaviour shows up when using NodeJS v12.18.4 LTS.
    The --inspect-brk option does not stop at the line with debugger statement but the first executing line. When continuing execution then it stops at the line with the debugger statement.

    I mentioned this in the second part of my post from October 4th which was made visible today.


  • Hi @anilfred . I had the same issue. I found the solution by starting the debugger using the line "node inspect .\app.js" without the two dashes and afterwards just type in chrome --> chrome://inspect and it should stop in "debugger".


  • thanks for bringing this up everyone, it does indeed seem to be a bug in Node. I'm going to reach out to core team members and see what can be done to fix it, if it continues to stall I'll update the training to work around this

  • I'm doing right now the Node.js Application Development (LFW211) training. So has the interface changed from --inspect to inspect as subcommand? Is there any updated training material?

  • @ghortat no it's not changed, node inspect is a command line interface, node --inspect initialises the devtools debugging protocol that can be connected to via chrome://inspect.

    The problem with the specific example is there is no time between executing the command with --inspect and the runtime hitting the debugger statement to actually connect to the inspector protocol. The debugger statement is ignored as usual, because when using --inspect if there's no debugger client connected, the runtime isn't in a debugging mode.

    So for given code example here, the only approach is to use --inspect-brk.

    Where --inspect is applicable is with something like an HTTP server. You can interact with the server normally, and then at some future point connect devtools to the exposed inspect interface and begin to debug it (this would also trigger any debugger statements).

  • A possible workaround would be to use the setTimeout in the app.js instead of invoking directly the f method, something like
    setTimeout(f, 5000)
    And click on the chrome "inspect" link within 5 secs

  • krave
    krave Posts: 58

    @giacomolm said:
    A possible workaround would be to use the setTimeout in the app.js instead of invoking directly the f method, something like
    setTimeout(f, 5000)
    And click on the chrome "inspect" link within 5 secs

    That would be a little less efficient because I don't want to wait that longer.
    So I tend to use the debugger integrated in vscode when I am working on a project and want to debug some code.

  • the course is being updated for Node 16 - the inspect-brk issue seems to be resolved in 16, use the --inspect-brk flag to pause at the first line of code.

  • cscharr
    cscharr Posts: 4
    edited March 2022

    Still the same problem on chapter 4...
    Running the code with debugger keyword on line 2 and "node --inspect app.js" does not stop on line 2 as expected but throws the error.

    Windows 11, Node 16.14.0 via NVM

  • xdxmxc
    xdxmxc Posts: 84

    @cscharr but --inspect-brk works right?

  • @xdxmxc said:
    @cscharr but --inspect-brk works right?

    Yes, --inspect-brk still kinda works, but --inspect still does not with Node 16. I say kinda because it initially stops at line 5(f()) and once you click to resume, it then stops at the debugger line.

    Also just checked and it is also the case with Node.js v18.2.0

  • @schalkneethling stopping at line 5 makes sense. The debugger is stopping in the first tick before the first function call, that just happens to be on line 5. The code above it is a declaration, so it doesn't execute in the first tick.


Upcoming Training