Fix debug Linux #679
Fix debug Linux #679
Conversation
|
My questions:
|
| @@ -84,6 +85,7 @@ HL_API bool hl_debug_stop( int pid ) { | |||
| # elif defined(MAC_DEBUG) | |||
| return mdbg_session_detach(pid); | |||
| # elif defined(USE_PTRACE) | |||
| kill(pid, SIGTRAP); // DETACH needs ptrace-stop | |||
There was a problem hiding this comment.
I think SIGSTOP would be more appropriate here.
There was a problem hiding this comment.
I agree. But when I test with SIGSTOP, the disconnect does not works properly (maybe SIGSTOP is not actually stopping - the signal is forward to our thread? or has some delay / different behavior than SIGTRAP). :(
| // *** HACK *** | ||
| // usleep here is needed for a good result. | ||
| // Without it, waitpid can miss many stop event; | ||
| // With it, and more we wait, less we miss stop event. | ||
| usleep(100 * 1000); | ||
| int ret = waitpid(pid, &status, WNOHANG); |
There was a problem hiding this comment.
I suspect that waitpid with WNOHANG is also vulnerable to a race condition with libuv.
I'm not sure how to fix this other than by doing the same thread & semaphore dance as the Mac debugger.
There was a problem hiding this comment.
I also suspect the waitpid hack was for libuv (or vscode) waiting for all childs.
I tested your implementation with thread (it helps me a lot!), but it failed when we are actually waiting (by default the vscode extension call wait with a timeout = 0) and has a timeout. I didn't managed to get it works yet :'(
You said @ncannasse refused your PR due to complexity, so I tried this hack. I will do the thread & semaphore if hack is not a good option either.
There was a problem hiding this comment.
That was another PR, I never actually submitted the thread & semaphore implementation.
There was a problem hiding this comment.
Sorry I misunderstood :(
I made some changes for the hashlink-debugger vscode extension on Linux vshaxe/hashlink-debugger@1.4.8...1.4.9 . They are not needed for the command line version (because you can't give command when the program is still in "running" mode).
As I also made a big hack for waitpid timeout (for the moment it works on my machine without need thread+semaphore), ping @ncannasse