* Handle race between fork and task_for_pid
On macOS a call to fork and a subsequent call to task_for_pid will race each other. This is because the macOS kernel assigns a new proc_t structure early but the new task, thread and uthread come much later. The function exec_mach_imgact in the XNU sources contains this logic.
In a system under load or one with delays in fork processing (i.e. various security software), task_for_pid as currently called by Delve often returns the parent task. This can be seen by printing out the task number around line 86. In a normal system we would see three calls:
-> ~/go/bin/dlv --listen=localhost:59115 --headless=true --api-version=2 --backend=native exec ./___main_go --
Task: 9731
Task: 9731
Task: 9731
API server listening at: 127.0.0.1:59115
This is the result on a system where the race is lost:
-> ~/go/bin/dlv --listen=localhost:59115 --headless=true --api-version=2 --backend=native exec ./___main_go --
Task: 8707
Task: 10499
Task: 10499
could not launch process: could not get thread count
In this latter case, task 8707 is the parent task. The child task of 10499 was desired and hence the error.
This code change checks to make sure the returned task is not that of the parent. If it is, it retries. It's possible other macOS reported Delve issues are the result of this failed race.
* proc: correct formatting
Much like the bug in issue #1031 and commit
f6f6f0bf13e4c708cb501202b83a6327a0f00e31 pointers can also escape to
the heap and then have a zero address (and no children) when we
autodereference.
1. Mark autodereferenced escaped variables with a 0 address as
unreadable.
2. Add guards to the pretty printers for unsafe.Pointer and pointers.
Fixes#1075
Depending on how the runtime schedules our goroutines we can get
unlucky and have the first call to runtime.newstack we intercept be for
a different goroutine (usually the garbage collector).
Only check stacktraces that happen on the same goroutine that executed
main.main.
* command/terminal: allow restart to change process args
Add -args flag to "restart" command. For example, "restart -args a b c" will
pass args a b c to the new process.
Add "-c" flag to pass the checkpoint name. This is needed to disambiguate the
checkpoint name and arglist.
Reverted unnecessary changes.
* Applied reviewer comments.
Vendored argv.
Change the syntax of restart. When the target is is in recording mode, it always
interprets the args as a checkpoint. Otherwise, it interprets the args as
commandline args. The flag "-args" is still there, to handle the case in which
the user wants to pass an empty args on restart.
* Add restartargs.go.
Change "restart -args" to "restart -noargs" to clarify that this flag is used to
start a process with an empty arg.
The runtime calls into g0 in many places, not necessarily using
runtime.systemstack or runtime.asmcgocall.
One example of this is the call to runtime.newstack inside
runtime.morestack.
If we stop the process while one goroutine is executing
runtime.newstack we would be unable to fully scan its stack because we
don't know that we have to switch back to the goroutine stack after
runtime.newstack.
Instead of tracking down every possible way that the runtime switches
to g0 we switch to the goroutine stack immediately after the top of the
stack, unless cgo is being executed on the systemstack.
Fixes#1066
Adds a configuration option (show-location-expr) that when activated
will cause the whatis command to also print the DWARF location
expression for a variable.
So far we have evaluated the locspec "+0" the same way we evaluate all
"+n" locspecs, this means that we turn the current PC into a file:line
pair, then we turn back the file:line into a PC address.
Normally this is harmless, however all autogenerated code returns the
source position "<autogenerated>:1" which resolves back to the very
first autogenerated instruction in the code.
This messes up the behaviour of the "disassemble" command which uses
the locspec "+0" to figure out what code to disassemble if no arguments
are passed.
We should make +0 always resolve to the current PC (of the given scope)
so that clients can use +0 as a default locspec.
On macOS, externally linked programs will have an abbrev for
DW_TAG_subprogram without the haschildren flag set. We should handle
this case instead of expecting all DW_TAG_subprogram entries to have
list of children.
Fixes#1034
When creating a stack trace we should switch between the goroutine
stack and the system stack (where cgo code is executed) as appropriate
to reconstruct the logical stacktrace.
Goroutines that are currently executing on the system stack will have
the SystemStack flag set, frames of the goroutine stack will have a
negative FrameOffset (like always) and frames of the system stack will
have a positive FrameOffset (which is actually just the CFA value for
the frame).
Updates #935
* Support --output for debug, trace, and test commands
With the `--output` parameter you can configure the output binary. For
example:
dlv debug --output /tmp/xxx
Will build the binary to `/tmp/xxx`, instead of always putting it as
`debug` in the current directory.
This ensures that the command always works (even if there is already a
file or directory named `debug`) and doesn't write to the source
directory. Especially for things like Delve/Vim integration this is a
good thing to have, I think.
* Address PR feedback and add a test
- We don't need to use `filepath.IsAbs()` on startup; I added that
because it previously did `"./" + debugname` everywhere, but I don't
think that's needed at all, since `pathname` without a leading `./`
implies the current directory.
- Repurpose the existing `TestIssue398` to also test the `--output`
flag. Also fix an issue where tests wouldn't work if `GOPATH` has
multiple entries (e..g `GOPATH=$HOME/go:$HOME/mygocode`).
- Print an error if we can't remove the debug binary on exit instead of
failing silently. Not strictly related to this PR, but a good change
to add I think.
* Also warn when delve can't remove the binary in test/trace
I only added that to debug, but good to issue this warning consistently.
Either the CPU or the kernel may not support the calls we do when
retrieving floating point registers, this isn't an error we should
propagate.
Also improve the error reporint of pkg/proc/native.fpRegisters.
Fixes#1022
StepBreakpoints are set on CALL instructions, when they are hit we
disassemble the current instruction, figure out the destination address
and set a breakpoint after the prologue of the called function.
In order to disassemble the current instruction we disassemble the area
of memory starting from PC and going to PC+15 (because 15 bytes is the
maximum length of one instruction on AMD64). This means that we won't
just disassemble one instruction but also a few instructions following
it ending with one truncated instruction.
This usually works fine but sometimes the disassembler will panic with
an array out of bounds error when trying to disassemble a truncated
instruction. To avoid this problem this commit changes the funciton
disassemble to take one extra parameter, singleInstr, when singleInstr
is set disassemble will quit after disassembling a single instruction.
Replace the unsafe.Pointer type of the buf field of channels with the
appropriate array type, allow expressions accessing member field of the
channel struct.
Fixes#962
