-
Notifications
You must be signed in to change notification settings - Fork 346
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
Reconnecting the inspector causes a segmentation fault #2564
Labels
bug
Something isn't working
Comments
Same issue but slightly more useful error:
Symbolizing the stack yields...
|
harrishancock
added a commit
that referenced
this issue
Aug 20, 2024
…erence This is an attempt to reproduce #2564. The test doesn't fail as I expect, but it's still useful, so if it passes on all CI, I'm going to leave it uncommented.
harrishancock
added a commit
that referenced
this issue
Aug 20, 2024
We need to revert the fix until we've diagnosed #2564.
npaun
pushed a commit
that referenced
this issue
Aug 20, 2024
…erence This is an attempt to reproduce #2564. The test doesn't fail as I expect, but it's still useful, so if it passes on all CI, I'm going to leave it uncommented.
npaun
pushed a commit
that referenced
this issue
Aug 20, 2024
We need to revert the fix until we've diagnosed #2564.
The revert has landed |
harrishancock
added a commit
that referenced
this issue
Aug 21, 2024
My initial attempt at a fix made a subtle behavior change which I did not consider fully: instead of a new `incomingQueueNotifier` XThreadNotifier being constructed for every inspector connection, my fix caused all inspector connections to re-use one long-lived XThreadNotifier. This subsequently ran afoul of the fact that XThreadNotifier::awaitNotification() is not cancel-safe: if it is cancelled while awaiting its stored promise, calling awaitNotification() a second time tries to await a moved-from promise. This commit restores the previous behavior of creating a new `incomingQueueNotifier` XThreadNotifier for every inspector connection. However, instead of constructing it in the WebSocketIoHandler constructor as before, I moved the construction to the `messageLoop()` function implementation, which also spawns the dispatch loop. This narrows the scope of access to the notifier to only those functions which actually need it, keeps our usage of the dispatch kj::Executor localized in one place, and avoids synchronously blocking the inspector thread, as we would have had to do if we constructed it in the WebSocketIoHandler constructor. Fixes #2564.
harrishancock
added a commit
that referenced
this issue
Aug 21, 2024
The previous attempt at a test didn't fail because it didn't actually exercise the inspector protocol. If it had, it would have encounterd a WebSocket error and failed. This commit removes the previous test, uncomments out the profiling test, factors it out into a separate function, then uses that function to implement two separate test cases, one to actually test profiling, and one to test repeated inspector connections.
harrishancock
added a commit
that referenced
this issue
Aug 21, 2024
The previous attempt at a test didn't fail because it didn't actually exercise the inspector protocol. If it had, it would have encounterd a WebSocket error and failed. This commit removes the previous test, uncomments out the profiling test, factors it out into a separate function, then uses that function to implement two separate test cases, one to actually test profiling, and one to test repeated inspector connections.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is likely due to 19c8ed5, but I haven't been able to fully pin it down.
Essentially, in the latest version of
workerd
, connecting, disconnecting, and then reconnecting to the inspector causes a segmentation fault:It's pretty easy to reproduce. Run:
and open up https://devtools.devprod.cloudflare.dev/js_app?ws=localhost:8989/main. Reloading that webpage twice will result in a segmentation fault.
the same problem doesn't present with the previous version of workerd:
The text was updated successfully, but these errors were encountered: