Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

assertion when attaching the Chrome dev tools #8155

Closed
vladima opened this issue Aug 18, 2016 · 56 comments
Closed

assertion when attaching the Chrome dev tools #8155

vladima opened this issue Aug 18, 2016 · 56 comments
Labels
confirmed-bug Issues with confirmed bugs. inspector Issues and PRs related to the V8 inspector protocol windows Issues and PRs related to the Windows platform.

Comments

@vladima
Copy link

vladima commented Aug 18, 2016

Version: v.6.4.0
Platform: Windows10 64 bit
Repro:

  • Run (script can be moved to the separate file, repro uses inline version only for brevity):
node --inspect -e "while(1);"
  • Open url that will be printed to start debugging.

Expected:

  • Chrome dev tools are opened without any errors

Actual:
node process shuts down the message:

C:\Program Files\nodejs\node.EXE: src\inspector_socket.cc:569: Assertion `(inspector->http_parsing_state) == (nullptr)' failed.
@Trott Trott added the inspector Issues and PRs related to the V8 inspector protocol label Aug 18, 2016
@bnoordhuis
Copy link
Member

Works for me with master (on Linux) so this probably just needs back-ports of the relevant commits from master.

cc @ofrobots @eugeneo

@vladima
Copy link
Author

vladima commented Aug 18, 2016

probably unrelated to the original issue: when I build/run debug version of node from master on Windows with the same repro - it always hits the assertion in element access inspector->buffer[inspector->data_len] at this line, because inspector->data_len is equal to buffer.size()

@busheezy
Copy link

https://gyazo.com/c3c20ffb78d985a7d07f2321154ba993

I'm running into the same issue.

@eugeneo
Copy link
Contributor

eugeneo commented Aug 22, 2016

Not sure how to assign this to myself - I am planning to look into it tomorrow, once I get to the Windows PC.

@eugeneo
Copy link
Contributor

eugeneo commented Aug 23, 2016

I was unable to reproduce this. This is what I did:

  1. Ran node --inspect -e "while(1);"
  2. Copied the printed URL to Chrome browser.
  3. Tried suspending the target, printing values to the console, etc.
  4. I also tried refreshing the browser with the web tools, disconnecting and reconnecting, opening /json URLs.

My system is Windows 10. I build a release Node.js build (vcbuild nosign). I tested both master and v6.x branches.

Please provide detailed instruction if you still see this issue.

@busheezy
Copy link

I have been using https://nodejs.org/dist/v6.4.0/node-v6.4.0-x64.msi off of the nodejs front page.

The node process crashes as soon as you try to load the page.

@ofrobots ofrobots added confirmed-bug Issues with confirmed bugs. windows Issues and PRs related to the Windows platform. labels Aug 23, 2016
@joaocgreis
Copy link
Member

I can repro (100%) in Windows 10, both with v6.4.0 and the latest nightly. On Windows 2012 with a recent master build the debugger does not attach, nothing happens.

@rainabba
Copy link
Contributor

rainabba commented Sep 1, 2016

I'm running 6.4.0 and I too can repo 100% with the steps listed by @eugeneo and discovered this as I tried to use Node V8 Inspector

It doesn't matter what I'm running or if I use the URL provided in the console or the Chrome Extension, I get C:\Program Files\nodejs\node.exe: src\inspector_socket.cc:569: Assertion '(inspector->http_parsing_state) == (nullptr)' failed. each time.

UPDATE: I just upgraded to Node 6.5.0 and npm 3.10.7 and see the same behavior

@ofrobots
Copy link
Contributor

ofrobots commented Sep 1, 2016

The next release of v6.x should include this fix.

@jbe456
Copy link

jbe456 commented Sep 7, 2016

Is this supposed to be already available in nightly builds? I tried with v6.5.1-nightly20160906180867d6a6 and I still have the exact same error message:

C:\Program Files\nodejs\node.exe: src\inspector_socket.cc:569: Assertion `(inspector->http_parsing_state) == (nullptr)' failed.

PS: I can see it has been committed in master but I don't see any 6.6 available version, only a 6.5.1 and 7.0.0 in https://nodejs.org/download/nightly/

@wzup
Copy link

wzup commented Sep 8, 2016

@uggedal
As for Sep 8 2016 the same error
Win 10, 64
node v6.5.0 (includes npm 3.10.3)

mingw64_ 2016-09-08 14 09 50

@ofrobots
Copy link
Contributor

ofrobots commented Sep 8, 2016

@jbe456, @wzup: Node 6.5.0 doesn't have this fix yet and neither do the 6.x nightlies. I expect next release of v6.x (probably 6.6.0, which isn't out yet) will pick up this fix. /cc @Fishrock123.

Fishrock123 pushed a commit to Fishrock123/node that referenced this issue Sep 8, 2016
This change simplifies buffer management to address a number of issues
that original implementation had.

Original implementation was trying to reduce the number of allocations
by providing regions of the internal buffer to libuv IO code. This
introduced some potential use after free issues if the buffer grows
(or shrinks) while there's a pending read. It also had some confusing
math that resulted in issues on Windows version of the libuv.

PR-URL: nodejs#8257
Fixes: nodejs#8155
Reviewed-By: bnoordhuis - Ben Noordhuis <[email protected]>
Fishrock123 pushed a commit that referenced this issue Sep 9, 2016
This change simplifies buffer management to address a number of issues
that original implementation had.

Original implementation was trying to reduce the number of allocations
by providing regions of the internal buffer to libuv IO code. This
introduced some potential use after free issues if the buffer grows
(or shrinks) while there's a pending read. It also had some confusing
math that resulted in issues on Windows version of the libuv.

PR-URL: #8257
Fixes: #8155
Reviewed-By: bnoordhuis - Ben Noordhuis <[email protected]>
@ofrobots
Copy link
Contributor

@jbe456, @wzup Could you try with the latest 7.0 nightlies to see if the problem still exists?

@busheezy
Copy link

Microsoft Windows [Version 10.0.10586]
(c) 2015 Microsoft Corporation. All rights reserved.

C:\Users\BuSheeZy>node --inspect -e "while(1);"
Debugger listening on port 9229.
Warning: This is an experimental feature and could change at any time.
To start debugging, open the following URL in Chrome:
    chrome-devtools://devtools/remote/serve_file/@60cd6e859b9f557d2312f5bf532f6aec5f284980/inspector.html?experiments=true&v8only=true&ws=localhost:9229/node
C:\Program Files\nodejs\node.exe: src\inspector_socket.cc:553: Assertion `(inspector->http_parsing_state) == (nullptr)' failed.

C:\Users\BuSheeZy>node -v
v7.0.0-nightly2016091353178f908f

C:\Users\BuSheeZy>

I know you asked for them but I gave it a go anyways.

I used this install:
https://nodejs.org/download/nightly/v7.0.0-nightly2016091353178f908f/node-v7.0.0-nightly2016091353178f908f-x64.msi

@fredericosilva
Copy link
Contributor

@ofrobots It still crashes here on node-v7.0.0-nightly2016091353178f908f-win-x64

src\inspector_socket.cc:553:` Assertion `(inspector->http_parsing_state) == (nullptr) failed.

Let me know if you need further testing,

@ofrobots
Copy link
Contributor

If you're able to build node.js from source, could you try with the fix here: #8536. @eugeneo is unable to reproduce the failure and the previous excepted fix doesn't seem to fix the problem.

@ofrobots ofrobots reopened this Sep 14, 2016
@ofrobots
Copy link
Contributor

I can reproduce the crash as well.

@mcollina mcollina reopened this Sep 28, 2016
@ugate
Copy link

ugate commented Sep 28, 2016

@misenesi @ofrobots According to the changlog it doesn't look like it was included in the 6.7.0 release?

@ofrobots
Copy link
Contributor

v6.7.0 was a security release which is intended to be a minimal set of changes. @misenesi can you try the latest v7.x nightly release? I'm hoping that the next patch level release picks up the fix in #8536. Thanks for your patience.

@nodejs/release let me know if I should add any additional tags to make sure the fix gets released on the next v6.x.

@MylesBorins
Copy link
Contributor

MylesBorins commented Sep 28, 2016

I'm going to go ahead and get all the backlog of inspector commits onto v6.x-staging

edit: #8832

MylesBorins pushed a commit to MylesBorins/node that referenced this issue Sep 28, 2016
Ctor has to be added as memset to 0 is no longer an option, since
the structure now has std::vector member.

Attempt at fixing nodejs#8155 (so far I was not able to repro it)

PR-URL: nodejs#8536
Reviewed-By: bnoordhuis - Ben Noordhuis <[email protected]>
@rainabba
Copy link
Contributor

rainabba commented Sep 28, 2016

Anyone have a binary for Windows that is working which they could direct me to? I'm dying without debugging and in case it's been forgotten, node-inspector is broken too; I think because of the same issue. I built 7.x the other day and it was exhibiting the same issues, though that may have been the x86 and perhaps x64 is good?

@ugate
Copy link

ugate commented Sep 28, 2016

@rainabba
Copy link
Contributor

rainabba commented Sep 28, 2016

Got --inspect and devtools working overall, but I don't get halts on breakpoints added in devtools. If I insert a debugger call, those do halt. Am I perhaps missing something or have bad expectations? I know this is a bit off-topic so if anyone wants to redirect me, I'd appreciate it.

Also, what is the best/least-ambiguous way to refer to this new --inspect/dev-tools debugger approach so it's not confused with node-inspector or devtool/Electron?

UPDATE: Was bit by a Chrome extension ( https://chrome.google.com/webstore/detail/nodejs-v8-inspector/lfnddfpljnhbneopljflpombpnkfhggl ). Instead of using the URL directly, I used this tool and the window I got didn't have the same behavior as one brought up manually.

@patrickjaja
Copy link

I had the same error in my windows env (win7 x64).
And it was solved after installing node v7.0.0-nightly201609202b5acda7a2

@rainabba using breakpoints working aswell for me.

started debugging with node --inspect --debug-brk index.js

@mcollina
Copy link
Member

@thealphanerd how can we make sure we do not break the debugger anymore in a release? It's highly important for some people.

@Fishrock123
Copy link
Contributor

The inspector is listed as expiremental, if functionality changes here and there, that's kinda what you signed up for.

@mcollina
Copy link
Member

@Fishrock123 so, with node-inspector broken on v6.7.0, and the new "experimental" thing not working either, what should everyone be using?
As far as I know, the only one that is currently working is Visual Studio Code.

@cjihrig
Copy link
Contributor

cjihrig commented Sep 29, 2016

Isn't this issue only about the V8 inspector? Is node-inspector broken too?

@Seikho
Copy link

Seikho commented Sep 29, 2016

Node-inspector appears to be broken on Windows as well at the moment.

@Fishrock123
Copy link
Contributor

so, with node-inspector broken on v6.7.0, and the new "experimental" thing not working either, what should everyone be using?
As far as I know, the only one that is currently working is Visual Studio Code.

If it's a bug, we'll try to fix it as normal? If it's a bug in a specific release the choices are roll back a bit or build your own copy with patches... 😐 (like any other software...) sounds like @thealphanerd and I will get v6.x-staging updated with the necessary patches.

@Fishrock123
Copy link
Contributor

(Also like, if you don't think releases are frequent enough and would like to dedicated some time to help make releases, we'd be glad to have more people. Let me or any other CTC member know.)

@rainabba
Copy link
Contributor

@cjihrig node-debugger was broken last I checked around 6.4.x, but then again; it seems to be more often than not as long as I've been using it (since ~0.6.x I think and since 0.12.x for sure) which is why I was excited about a more official/integrated solution with the new approach.

I've not had to work so much without a debugger since gwbasic on DOS 3.0. I love node.js, but if I have a single complaint; it's the constant lack of debugging support and with --inspect in place, that should be resolved so I'm very much looking forward to it.

@cjihrig
Copy link
Contributor

cjihrig commented Sep 29, 2016

Just to clarify, there are three debuggers that can be easily confused:

  • v8-inspector - The new thing that uses --inspect, is integrated into Node, and is currently experimental.
  • node-inspector - The npm module.
  • Node's legacy debugger. This is the old debugger that is also integrated into Node.

Of course there are other debuggers like vscode, but those are the three that are most easily confused.

@rainabba
Copy link
Contributor

@cjihrig Thanks for the clarification. That does bring up a related issue to me; the lack of clarity on "how to debug in node". Because there are multiple approaches AND they seem to change regularly (due to constant advancement and I'm not complaining there), I feel like it's not clear to someone new, how to get the best debugging experience. Of course, that's just part of the game on a platform that's evolving so quickly, but once v8-inspector is stable, I'd love to see highly visible and clear documentation. That's something I might be willing and able to tackle even though I'm not sure I'm the most qualified (see my attempt at #8704).

Even if v8-inspector was stable and great documentation written, a real push would be needed to ensure it's discoverable to someone looking for it.

That said, anyone here have an article they'd recommend on the legacy debugger? For all the time I've spent looking for debugging tools, I'm not even sure I've run across the legacy one in a usable fashion. My understanding is that it was the power behind node-inspector, but it wasn't really usable by itself and if that's not true, I'd love to know.

@Fishrock123
Copy link
Contributor

Can someone confirm if this works on master or not?

@Trott Trott assigned eugeneo and unassigned eugeneo Sep 29, 2016
@Seikho
Copy link

Seikho commented Sep 30, 2016

Just tested very briefly on Windows 10 and appears to be working. ❤️

MylesBorins pushed a commit that referenced this issue Sep 30, 2016
Ctor has to be added as memset to 0 is no longer an option, since
the structure now has std::vector member.

Attempt at fixing #8155 (so far I was not able to repro it)

PR-URL: #8536
Reviewed-By: bnoordhuis - Ben Noordhuis <[email protected]>
@s-a
Copy link

s-a commented Sep 30, 2016

Just tried on Microsoft Windows [Version 10.0.10586]

c:\git\test2>node --inspect=9222 --debug-brk index.js
Debugger listening on port 9222.
Warning: This is an experimental feature and could change at any time.
To start debugging, open the following URL in Chrome:
  chrome-devtools://devtools/remote/serve_file/@60cd6e859b9f557d2312f5bf532f6aec5f284980/inspector.html?experiments=true&v8only=true&ws=localhost:9222/node
C:\Program Files\nodejs\node.exe: src\inspector_socket.cc:553: Assertion `(inspector->http_parsing_state) == (nullptr)' failed.

c:\git\test2>node -v
v6.6.0

c:\git\test2>node --inspect=9222 --debug-brk index.js
Debugger listening on port 9222.
Warning: This is an experimental feature and could change at any time.
To start debugging, open the following URL in Chrome:
  chrome-devtools://devtools/remote/serve_file/@60cd6e859b9f557d2312f5bf532f6aec5f284980/inspector.html?experiments=true&v8only=true&ws=localhost:9222/node
C:\Program Files\nodejs\node.exe: src\inspector_socket.cc:553: Assertion `(inspector->http_parsing_state) == (nullptr)' failed.

c:\git\test2>node -v
v6.7.0

@eugeneo
Copy link
Contributor

eugeneo commented Sep 30, 2016

This PR - #8832 - should backport the fix. I believe this fix will be in v6.8.

@targos
Copy link
Member

targos commented Oct 15, 2016

I confirm it works with v6.8.0!

@targos targos closed this as completed Oct 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
confirmed-bug Issues with confirmed bugs. inspector Issues and PRs related to the V8 inspector protocol windows Issues and PRs related to the Windows platform.
Projects
None yet
Development

Successfully merging a pull request may close this issue.