| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
The debuggee node process will never exit because the execution is blocked inside node::debugger::Agent::Stop, joining the agent thread. The debug agent thread is blocked inside uv_run. To fix this, the debug agent has to close all client connections in _debug_agent.js (process._debugAPI.onclose). Additionally all remaining opened handles have to be closed before calling uv_loop_close. Otherwise uv_loop_close will fail with UV_EBUSY.
|
|
||
| Agent.prototype.destroyAllClients = function destroyAllClients() { | ||
| this.clients.forEach(function(client) { | ||
| client.destroy(); |
There was a problem hiding this comment.
this ends up calling this.socket.destroy
I didn't dig too much further, but is this operation synchronous? If not there might be some unexpected behavior here
/cc @bnoordhuis
Sorry, something went wrong.
There was a problem hiding this comment.
I will dig into this. I used destroy, because it was already used in the close event.
Maybe this.socket.end() would be sufficient here.
Edit: It seems that this.socket.end() also works. But it eventually will also call destroy.
Sorry, something went wrong.
|
@quaidn amazing!!! this is a problem I've wanted to chase down for a bit but never quite got around to it. How comfortable would you feel making a test for this? Here is a test I wrote for a regression in util that might be useful as a starting point If we can get a test that doesn't work on master, but does work with this change we should be able to get this landed! |
Sorry, something went wrong.
Sorry, something went wrong.
|
@thealphanerd I agree. A test would be good here. I try to use your script as a starting point. |
Sorry, something went wrong.
|
@quaidn amazing. Please feel free to let me know if there is anything I can do to help |
Sorry, something went wrong.
Added a regression test for stuck debugger when the debuggee exits. The test does several cycles of 'continue' and 'run'. The test passes if the debuggee was terminated within the timeout.
|
@thealphanerd I added a regression test. Let me know what you think. On master without these changes, the timeout is hit. |
Sorry, something went wrong.
| uv_close(reinterpret_cast<uv_handle_t*>(&child_signal_), nullptr); | ||
| // Close all remaining handles: | ||
| // uv_loop_close will return UV_EBUSY for handles which are not closed. | ||
| uv_walk(&child_loop_, close_handle, nullptr); |
There was a problem hiding this comment.
This is a workaround. I can't explain why there are always two pipe handles left referenced.
[--I] signal 0x30606e8 [-AI] async 0x3060530 [---] async 0x30603e8 [R--] pipe 0x7fd8a0058520 [R--] pipe 0x7fd8a0064260
Sorry, something went wrong.
There was a problem hiding this comment.
They are the stdout and stderr pipes. Closing them like that is not very optimal, it leaves their PipeWrap instances in an invalid state.
Proper cleanup is one of the things I have to tackle for the multi-isolate work. I'll try to get around to it later this week.
Sorry, something went wrong.
|
@bnoordhuis is this something you have time to take a look at? |
Sorry, something went wrong.
| fixture | ||
| ]; | ||
|
|
||
| const TEST_TIMEOUT_MS = 4000; |
There was a problem hiding this comment.
Nit: Maybe use common.platformTimeout(4000) so Raspberry Pi devices get a little extra time in CI.
Sorry, something went wrong.
There was a problem hiding this comment.
Done
Sorry, something went wrong.
|
+1 |
Sorry, something went wrong.
Use common.platformTimout to give ARM devices extra time for test execution.
|
/cc @nodejs/diagnostics |
Sorry, something went wrong.
|
ping @nodejs/diagnostics @bnoordhuis |
Sorry, something went wrong.
|
ping @nodejs/diagnostics @bnoordhuis might make sense to fix this in LTS |
Sorry, something went wrong.
|
Does this need to stay open? |
Sorry, something went wrong.
|
Marking this stalled. Will close soon if there is no further activity |
Sorry, something went wrong.
|
The multi-isolate work didn't go anywhere but the issue remains that blindly closing all libuv handles is a bad idea (as in 'segfault bad' and 'silent data corruption bad'.) My suggestion would be to do nothing and sit it out. The old debugger is going away and the inspector doesn't have this issue. |
Sorry, something went wrong.
|
The old debugger has been removed. I'll close this out. Thanks for the PR though. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Checklist
Affected core subsystem(s)
debugger
Description of change
Referencing PR #27778
The debuggee node process will never exit because the execution
is blocked inside node::debugger::Agent::Stop,
joining the agent thread.
The debug agent thread is blocked inside uv_run.
To fix this, the debug agent has to close all client connections
in _debug_agent.js (process._debugAPI.onclose).
Additionally all remaining opened handles have to be closed
before calling uv_loop_close.
Otherwise uv_loop_close will fail with UV_EBUSY.
Assume the following script (debug.js):
Calling node debug debug.js produces the following output:
Both
and
exit immediately.