-
Notifications
You must be signed in to change notification settings - Fork 320
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
Support for breakpoint debugging #710
Conversation
d4e73da
to
6586c4d
Compare
50fc6e4
to
b776b91
Compare
af925c7
to
f5afe97
Compare
PTAL, this is a moderately large change that we'll likely have to iterate on quite a bit. The major shortcoming here is that this is only worker for single service configs. This should be fixable, but it would be good to get feedback in the interim. The specific example that fails is ssh://git@bitbucket.cfdata.org:7999/~bcoll/workerd-bus-error-10.git Thanks. |
This is addressed in the second commit. Wrangler does not expect to package multiple user written workers in a config, but may in practice (e.g. code that wrangler itself adds). With the second commit chrome devtools would be able to debug any code referenced by the config. Wrangler devtools only wants to be able to debug the user written workers (except if they need to debug their stuff). |
96940d3
to
dea77d4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just started looking at this, realize I need more time than I have now, so posting the couple comments I already wrote but I'll try to look at the whole thing either later today or tomorrow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(still reading, but posting a batch before going to more meetings...)
512bd36
to
1063006
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had some review comments that seem to have disappeared, but I also notice that github says I have a pending review, but it says there are no comments, but maybe if I post it anyway they will come back? Trying...
Sadly, it appears my comments were lost. Ugh. |
a4d477b
to
6409cca
Compare
@kentonv, friendly ping, last comment incorporated on 7/14, thanks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume you've tested this running in the fiddle service (internal codebase)? That should be a pretty easy way to verify it works with the internal threading model, in addition to the workerd model.
(Sorry for the slow review, this fell off my radar last week somehow.) |
awesome, approved! |
6409cca
to
f937d74
Compare
Yes, you can set breakpoints and single step. Logging to console and heap querying appear to still work as before. |
f937d74
to
f9aa9e6
Compare
src/workerd/io/worker.c++
Outdated
try { | ||
auto lockedOutgoingQueue = outgoingQueue.lockExclusive(); | ||
if (lockedOutgoingQueue->status == MessageQueue::Status::CLOSED) { | ||
co_await webSocket.close(1000, "client closed connection"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the behavior changed slightly in the coroutine conversion, previously we would send any remaining messages before closing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ack, fixed, thanks.
for (;;) { | ||
co_await outgoingQueueNotifier->awaitNotification(); | ||
try { | ||
auto lockedOutgoingQueue = outgoingQueue.lockExclusive(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You need to drop this lock before co_awaiting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
f9aa9e6
to
fb85369
Compare
This change places the InspectorService in a separate thread that manages communication with over the websocket to the inspector. The change also adds support for runMessageLoopOnPause() and quitMessageLoopOnPause() to support breakpoints and debugger break statements. There is also refactoring of the CDP message handling code so it can be called with or without the isolate lock held. This requires workerd to run with the command-line flag -i to turn on inspector support. This change only works for single service configurations. Support for multi service configurations to follow. To try this out using samples/helloworld as an example: 1) Edit "samples/helloworld/worker.js" and add a debugger statement to the handle(request) method. 2) Open workerd in VSCode, select 'workerd with inspector enabled (dbg)' as the Run and Debug Target panel. Hit F5 to run and select `samples/helloworld/config.capnp` as the config to use. 3) Open devtools in Chrome using either: * https://devtools.devprod.cloudflare.dev/js_app?ws=localhost:9229/main * chrome:://inspect 4) On the command-line run, `curl http://localhost:8080/` 5) Devtools should break into the running worker. Bug: #371 Test: manual Test: existing internal ew tests do not break
If there are multiple service workers in a config, expose them to devtools. This is largely just for Chrome devtools since wrangler does not expect to generate more than one worker per config that might need to be debugged. Test: manual using chrome devtools and https://bitbucket.cfdata.org/users/bcoll/repos/workerd-bus-error-10/browse
fb85369
to
45a8779
Compare
With cloudflare/workerd#710, `workerd` supports breakpoint debugging! Support for this in Miniflare just worked, assuming you were using a plain JavaScript worker, or you had inline source maps. `workerd` doesn't know where workers are located on disk, it just knows files' locations relative to each other. This means it's unable to resolve locations of corresponding linked `.map` files in `sourceMappingURL` comments. Miniflare _does_ have this information though. This change detects linked source maps and rewrites `sourceMappingURL` comments to `http` URLs pointing to Miniflare's loopback server. This then looks for the source map relative to the known on-disk source location. Source maps' `sourceRoot` attributes are updated to ensure correct locations are displayed in DevTools. **This enables breakpoint debugging for compiled TypeScript with linked source maps!** 🎉 Closes DEVX-872
With cloudflare/workerd#710, `workerd` supports breakpoint debugging! Support for this in Miniflare just worked, assuming you were using a plain JavaScript worker, or you had inline source maps. `workerd` doesn't know where workers are located on disk, it just knows files' locations relative to each other. This means it's unable to resolve locations of corresponding linked `.map` files in `sourceMappingURL` comments. Miniflare _does_ have this information though. This change detects linked source maps and rewrites `sourceMappingURL` comments to `http` URLs pointing to Miniflare's loopback server. This then looks for the source map relative to the known on-disk source location. Source maps' `sourceRoot` attributes are updated to ensure correct locations are displayed in DevTools. **This enables breakpoint debugging for compiled TypeScript with linked source maps!** 🎉 Closes DEVX-872
With cloudflare/workerd#710, `workerd` supports breakpoint debugging! Support for this in Miniflare just worked, assuming you were using a plain JavaScript worker, or you had inline source maps. `workerd` doesn't know where workers are located on disk, it just knows files' locations relative to each other. This means it's unable to resolve locations of corresponding linked `.map` files in `sourceMappingURL` comments. Miniflare _does_ have this information though. This change detects linked source maps and rewrites `sourceMappingURL` comments to `http` URLs pointing to Miniflare's loopback server. This then looks for the source map relative to the known on-disk source location. Source maps' `sourceRoot` attributes are updated to ensure correct locations are displayed in DevTools. **This enables breakpoint debugging for compiled TypeScript with linked source maps!** 🎉 Closes DEVX-872
With cloudflare/workerd#710, `workerd` supports breakpoint debugging! Support for this in Miniflare just worked, assuming you were using a plain JavaScript worker, or you had inline source maps. `workerd` doesn't know where workers are located on disk, it just knows files' locations relative to each other. This means it's unable to resolve locations of corresponding linked `.map` files in `sourceMappingURL` comments. Miniflare _does_ have this information though. This change detects linked source maps and rewrites `sourceMappingURL` comments to `http` URLs pointing to Miniflare's loopback server. This then looks for the source map relative to the known on-disk source location. Source maps' `sourceRoot` attributes are updated to ensure correct locations are displayed in DevTools. **This enables breakpoint debugging for compiled TypeScript with linked source maps!** 🎉 Closes DEVX-872
With cloudflare/workerd#710, `workerd` supports breakpoint debugging! Support for this in Miniflare just worked, assuming you were using a plain JavaScript worker, or you had inline source maps. `workerd` doesn't know where workers are located on disk, it just knows files' locations relative to each other. This means it's unable to resolve locations of corresponding linked `.map` files in `sourceMappingURL` comments. Miniflare _does_ have this information though. This change detects linked source maps and rewrites `sourceMappingURL` comments to `http` URLs pointing to Miniflare's loopback server. This then looks for the source map relative to the known on-disk source location. Source maps' `sourceRoot` attributes are updated to ensure correct locations are displayed in DevTools. **This enables breakpoint debugging for compiled TypeScript with linked source maps!** 🎉 Closes DEVX-872
With cloudflare/workerd#710, `workerd` supports breakpoint debugging! Support for this in Miniflare just worked, assuming you were using a plain JavaScript worker, or you had inline source maps. `workerd` doesn't know where workers are located on disk, it just knows files' locations relative to each other. This means it's unable to resolve locations of corresponding linked `.map` files in `sourceMappingURL` comments. Miniflare _does_ have this information though. This change detects linked source maps and rewrites `sourceMappingURL` comments to `http` URLs pointing to Miniflare's loopback server. This then looks for the source map relative to the known on-disk source location. Source maps' `sourceRoot` attributes are updated to ensure correct locations are displayed in DevTools. **This enables breakpoint debugging for compiled TypeScript with linked source maps!** 🎉 Closes DEVX-872
V8's profiler does not expect isolates to be locked from different threads. Pull request #710 moved inspector protocol handling to a separate thread, meaning profiling was started and stopped on the inspector thread, not the Worker's request connection thread. If I remember right, the result of this is that the profiler ends up sampling the inspector thread, which doesn't normally run JavaScript, and causes a bunch of "(program)" placeholder spans to show up in the profile. We previously discovered this issue with our internal runtime, which has always been heavily multi-threaded, and patched around the problem. This commit copies the two relevant patches from our internal repo. Fixes #1754.
No description provided.