From the DAP spec:
If this attribute exists and is non-empty, the backend must not 'break' (stop) but log the message instead.
Expressions within {} are interpolated.
This change parses the log messages and stores the parsed values as a format string and list of expressions to evaluate and get the string value of.
Updates golang/vscode-go#123
* service/dap: fix goroutine id selection for hardcoded breakpoints
Determining the stopped goroutine id on a breakpoint required
checking for breakpoints since some may be tracepoints. However,
there may be goroutines stopped on hardcoded breakpoints with
no breakpoint. We fix this by checking for runtime.breakpoint or
StopReason=proc.StopHardcodedBreakpoint.
We want to provide more flexibility for users to make changes to their configurations while the debug session is running. This could be accomplished by creating a custom request, but that were require a new UI as well, and every client of dlv dap to provide its own UI for this. By using the evaluate context, users can use the already existing debug console to change their configurations.
This change includes a refactor of the terminal code in order to share the code with the dap package.
This change provides a very similar to UI as the terminal package, but there are different configuration options that are DAP specific. We plan to use this same mechanism to expose a few other commands including "sources" to help users debug an ineffective substitutePath configuration.
This high-level goal is to push more shutdown logic into Session and not rely Server.Stop() because dap's version of Stop() is different from rpccommon. That means triggering the same shutdown steps in multiple places, so additional safeguards are added to make some of the duplicate steps no-ops to avoid errors, extra logging, etc.
This includes the following changes:
close client conn when request loop in serveDAPCodec exits (to match rpccommon)
exit request loop after processing a disconnect request (instead of relying on next read to fail because conn got closed by triggered Stop(), which is skipped in case of accept-multiclient and is not closed in Stop() in rpccommon)
reset debugger to nil to avoid shutting it down more than once and causing duplicate logging (in case stopDebugSession is called from onDisconnectRequest and Server.Stop or Session.Close as things shut down)
reset binaryToRemove to "" upon removal to avoid duplicate error (in case Close() is called more than once outside of Stop(), which technically is not the case right now)
expand testing for all possible server shutdown triggers
testing for Session-only shutdown as it will be integrated into rpccommon without dap.Server wrapper
updates golang/vscode-go#1830
updates #2328
Co-authored-by: Polina Sokolova <polinasok@users.noreply.github.com>
* service/dap: remove deadlock in TestLaunchDebugRequest
Fixes#2746
* terminal: fix TestScopePrefix flakiness
When there are more than 10 frames api.PrintStack will prefix the
output with spaces to right justify the frame number, which confuses
TestScopePrefix.
* _scripts: pass -buildvcs for Go 1.18 and later on TeamCity
Go 1.18 will try to stamp builds with the VCS version, this doesn't
work on TeamCity because the checkout isn't a valid repository (but
looks like it).
Pass -buildvcs=false to disable this feature.
* proc: switch to goroutine stack if first frame's func can not be found
If the first frame on the system stack can not be resolved to a
function switch directly to the goroutine stack.
A set breakpoints request could come in while the program is running. For a seamless user experience, the server should set the breakpoint and then continue program execution.
Updates golang/vscode-go#1676
* service/dap: refactor the server into two layers
* Add delay before setting debugger in remote tests
Co-authored-by: Polina Sokolova <polinasok@users.noreply.github.com>
Log points are special kinds of breakpoints that do not 'break' but instead log a message and then continue. This change implements basic log points that simply log the provided message, without any interpolation.
In order to resume execution after hitting a breakpoint, I added a new lock resumeMu and tracked the running state within the DAP server. resumeMu must be held in order to issue a debugger request that would start execution. This means it can be used to make sure that another goroutine does not resume execution while you are holding the lock.
Most of the synchronization logic is taken from PR #2530
Updates golang/vscode-go#123
When we set a limit on the number of threads that would be
returned, it was possible that the selected thread was not
included in the list of threads. This could cause issues
because the stopped reason is associated with the selected
goroutine, so users could be missing out on important info.
This change makes sure that the selected goroutine is included
by adding it to the end of the list.
Formally define these types and document their meaning.
We will auto-generate the dlv-dap documentation from these Go type doc.
mapToStruct is a helper that sets the given struct's fields with the
info in map[string]interface{} (launch/attach's Arguments). We achieve
this by reencoding map[string]interface{} to json and decoding back to
the target struct. If go-dap left the implementation-specific arguments
as json.RawMessage and let the implementation decode as needed, this
reencoding could've been avoided.
encoding/json itself does not have mean to enforce required fields.
There was a test case that checks substitutePath elements must set
both from/to fields. Path.UnmarshalJSON implements the check.
I am not yet sure about the need for distinction between missing
'from/to' and empty strings yet. (empty value is useful when dealing with
a binary built with trimpath, right?)
A minor behavior change - previously, if noDebug is not a boolean type,
we ignored the attribute silently. Since we use json decoding, any
mismatched types will cause an error and this non-boolean type noDebug
attribute will result in launch failure.
* service/dap: add test verifying handling of relative program path
* Add exec test, log build dir and document in --help
Co-authored-by: Polina Sokolova <polinasok@users.noreply.github.com>
* service/dap: add test that verifies output path is relative to wd
* Use cleanExeName to get the right output name on Win
Co-authored-by: Polina Sokolova <polinasok@users.noreply.github.com>
The Threads request sent immediately after the ConfigurationDone
request can be processed in two possible states:
- while the program is being executed, when it will return Id=1,
Name=Dummy
- after the program terminates, when it will return Id=-1, Name=Current
additionally the response could be received in any order with the
Terminate event.
Remove the problematic Threads request from the test.
The loop searching for a suitable goroutine is not guaranteed to ever
find it, and failing to find one is not an error.
Changes testStepParkedHelper to match the behavior of TestNextParked in
proc_test.go.
Deletes TestStepInParked because it does not test anything meaningful
beyond what's already tested by TestNextParked.
Returning monotonically increasing totalFrames values for subsequent requests can be used to enforce paging in the client. If we are not at the end of the stackFrames that are returned, we return a higher total frames to suggest to the client that they should request more frames.
To make it more clear that the user can resume the program when they encounter a next while nexting error, make the exception information have instructions for resuming the program. This implements the suggestions outlined by @polinasok in #2443.
* pkg/proc: Prefer throw instead of fatalthrow
Currently there is a breakpoint set at runtime.fatalthrow to catch any
situation where the runtime crashes (e.g. deadlock).
When we do this, we go up a frame in order to parse the crash reason.
The problem is that there is no guarentee the "s" variable we attempt to
parse will still be considered "live".
Since runtime.fatalthrow is never called directly, set a breakpoint on
runtime.throw instead and prevent having
to search up a stack frame in order to
get the throw reason.
Fixes#2602
* service/dap: Fix TestFatalThrowBreakpoint
* Reenable TestFatalThrow DAP test
* service/dap: Don't skip test on < 1.17
* service/dap: Update test constraint for 1.16
* pkg/proc: Reinstate runtime.fatalthrow as switchstack exception
Using issue419.go, I observed that the continue command fails with an error when debugger receives and forwards an interrupt. In spite of the stopped event, vscode still shows the state as RUNNING because the threads request is unable to retrieve any threads, but at least one dummy thread is always expected.
Co-authored-by: Polina Sokolova <polinasok@users.noreply.github.com>
