If /proc/net/tcp contains a large number of entries (>9999), parsing lines with len(sl) > 4 fails with the fixed width pattern. In that case the lines are silently ignored.
Add a waitfor option for 'dap attach' that waits for a process with a
given name to appear before attaching to it.
This recovers PR #3584, originally by @muggle-nil, which was fine
except for a broken test.
When the users uses a reslice operation load the whole resliced
variable, ignoring the MaxArrayValues setting.
Only apply this when the 'high' part is specified and a literal and the
'low' part is either unspecified or a literal.
Fixes#3600
We used to autoremove the trace recorded by rr but as a result of
various refactorings done to implement follow exec mode this broke.
Restore the functionality.
Also remove the _fixtures/testfnpos.go file which is autogenerated
during testing.
_fixtures/fncall.go was made to support TestCallFunction in pkg/proc
and new things must be added to fncall.go to test new features. Having
a test depend on precise line numbers makes the process tedious.
With the glibc loader the link map entry for the static executable has
an empty name field and address equal to 0x0. This case was already
handled by the check in bininfo.go AddImage for names to be valid
paths.
With the musl loader however the first entry, corresponding to the
static executable, has a valid path with address equal to 0x0, since we
record a real address for the image corresponding to the static
executable this results in having two entries for the executable when
musl is used to link go programs.
Change the code scanning the debug link map so that the first entry is
skipped if it has address equal to zero.
Fixes#3617
The flake manifests as an error where the variable i can not be found in
frame 1 and happens in go1.22rc1 between 0.1% and 0.5% of the time (it is highly dependent on CPU contention)
This problem is caused by the new code in evalop.PushLocal referencing the
stale value of SelectedGoroutine. This happens because:
- evalop.PushLocal calls ConvertEvalScope
- ConvertEvalScope calls FindGoroutine
- FindGoroutine checks the value of selectedGoroutine
When breakpoint conditions are evaluated both the value of selectedGoroutine
and currentThread are stale because we can only set their definitive value
*after* all breakpoint conditions have been evaluated.
The fact that it only happens in 1.22rc1 is coincidental, it's probably
caused by the fact that 1.22rc1 migrates goroutines between threads more in
this particular circumstance.
This commit fixes the problem in two ways:
1. selectedGoroutine and currentThread are given temprorary non-stale values
before breakpoint conditions are evaluated
2. evalop.PushLocal is changed so it takes a stack trace of the current
thread rather than resolving it through the selected goroutine.
Either one would suffice however I think we should do both, (2) ensures that
the runtime.frame(n).var will work even if the current thread is not running
any goroutine and (1) ensures that we don't accidentally reference a stale
selectedGoroutine in the future.
The builder is currently spending 15 to 20 minutes installing gcc and
upgrading packages every time we run the tests.
Because of this the build fails sometimes by running out of time.
This change reduces that to 5 minutes by:
* switching from curl to wget (which seems to have fewer dependencies)
* not installing gcc on ppc64le
* skipping tests that depend on gcc or other binutils
Update version of go-delve/liner to include the Ctrl-Z fix (SIGTSTP
should be sent to our process group instead of just sending it to
ourselves to correctly imitate a terminal).
Fixes#3605
Change VersionAfterOrEqual(x, A, B) to return true for pre-releases of
version A.B. This is what it did before, it was broken when goversion
was changed to support the new version format.
* proc: make some type casts less counterintuitive
The interaction of type casts with load configuration is sometimes
counterintuitive. This commit changes the way it is performed so that
when converting slices to strings and vice versa the maximum size
corresponding to the target type is used (i.e. MaxStringLen when
converting slices to strings and MaxArrayValues when converting slices
to strings).
This doesn't fully solve the problem (conversions to []rune are
problematic and multiple chained type casts will still be confusing)
but removes the problem for the majority of practical uses.
Fixes#3595, #3539
This allows us to update this dependency on our schedule which is important because the module relies on manually updating the known list of Go versions to function correctly. Forking allows us to keep this up to date ourselves and possibly create a new system to prevent having to perform this manual step in the future.
* Add pprofLabelForThreadNames config
The config is a string value that indicates the key of a pprof label whose value
should be shown as a goroutine name in the threads view.
Go1.22 has changed some line number assignments. The new line number
assignments are still valid however some tests in dap relied on them
being different and broke as a result. This commit fixes those tests
and makes them less brittle.
Also disables TestDebugStripped and TestDebugStripped2 temporarily on
1.22.
When using debugserver as a backend a manual stop request can end up
looking like an hardcoded breakpoint if the thread that receives the
stop request happens to be stopped right after a hardcoded breakpoint
(and the space between functions is filled with hardcoded breakpoints).
When creating hardcoded breakpoints we should ignore the trapthread if
a manual stop has been requested.
This problem made TestSetBreakpointWhileRunning and
TestSetFunctionBreakpointWhileRunning fail on macOS between 1.7% and 6%
of the time.
TestIssue1376 in rr_test.go used to pass accidentally, the stop when
the start of the recording was reached was mistaken for a hardcoded
breakpoint.
