- 08 3月, 2018 1 次提交
-
-
由 aarzilli 提交于
-
- 07 3月, 2018 6 次提交
-
-
由 aarzilli 提交于
The windows backend isn't using the halt field so it can be removed there. On linux it can be replaced with a parameter passed to trapWait.
-
由 aarzilli 提交于
Windows and macOS aren't using this field so move it to the os-specific thread struct and remove it from everything except linux.
-
由 aarzilli 提交于
-
由 aarzilli 提交于
The proper way to stop a running process is to call RequestManualStop, which most code already did with the exception of some old test code.
-
由 aarzilli 提交于
the proper way to kill the target process is to pass true to Detach. Everything except old test code did that already.
-
由 aarzilli 提交于
If a breakpoint is hit close to process death on a thread that isn't the group leader the process could die while we are trying to stop it. This can be easily reproduced by having the goroutine that's executing main.main (which will almost always run on the thread group leader) wait for a second goroutine before exiting, then setting a breakpoint on the second goroutine and stepping through it (see TestIssue1101 in proc_test.go). When stepping over the return instruction of main.f the deferred wg.Done() call will be executed which will cause the main goroutine to resume and proceed to exit. Both the temporary breakpoint on wg.Done and the temporary breakpoint on the return address of main.f will be in close proximity to main.main calling os.Exit() and causing the death of the thread group leader. Under these circumstances the call to native.(*Thread).waitFast in native.(*Thread).halt can hang forever due to a bug similar to https://sourceware.org/bugzilla/show_bug.cgi?id=12702 (see comment in native.(*Thread).wait for an explanation). Replacing waitFast with a normal wait work in most circumstances, however, besides the performance hit, it looks like in this circumstances trapWait sometimes receives a spurious SIGTRAP on the dying group leader which would cause the subsequent call to wait in halt to accidentally reap the process without noting that it did exit. Instead this patch removes the call to wait from halt and instead calls trapWait in a loop in setCurrentBreakpoints until all threads are set to running=false. This is also a better fix than the workaround to ESRCH error while setting current breakpoints implemented in 94b50d. Fixes #1101
-
- 06 3月, 2018 2 次提交
-
-
由 aarzilli 提交于
The formula is broken and produces an endless stream of duplicate bug reports yet nobody steps up to fix it. Using the formula isn't necessary and hasn't been in almost a year, the maintainers of delve aren't using it and the original maintainer of the formula vacated.
-
由 aarzilli 提交于
If the last entry of the package path contains a '.' the corresponding DIEs for its types will replace the '.' character with '%2e'. We must do the same when resolving the package path of the concrete type of an interface variable. Fixes #1137
-
- 05 3月, 2018 1 次提交
-
-
由 Derek Parker 提交于
Fixes a bug where the 'go' statement that created a goroutine was incorrectly reported. Fixes #1135
-
- 21 2月, 2018 1 次提交
-
-
由 Derek Parker 提交于
Previously the file handle for the newly created default config was being closed and thrown away as opposed to returned to the caller to finish setting up config for the rest of the process. This patch changes to return a handle to the newly created config so setup can happen as normal. This fixes a bug where Delve can crash on first run when a config is not present on the system. Fixes #1129
-
- 20 2月, 2018 1 次提交
-
-
由 Derek Parker 提交于
Add new version to CHANGELOG and update internal version.
-
- 14 2月, 2018 1 次提交
-
-
由 Alessandro Arzilli 提交于
debug_info entries can use DW_AT_abstract_origin to inherit the attributes of another entry, supporting this attribute is necessary to support DW_TAG_inlined_subroutine. Go, starting with 1.10, emits DW_TAG_inlined_subroutine entries when inlining is enabled.
-
- 10 2月, 2018 1 次提交
-
-
由 Alessandro Arzilli 提交于
-
- 08 2月, 2018 1 次提交
-
-
由 Matt Bauer 提交于
* 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
-
- 31 1月, 2018 1 次提交
-
-
由 aarzilli 提交于
Our current frame caching strategy doesn't handle extended locations expressions correctly, disable it on variables that don't have a simple address.
-
- 28 1月, 2018 3 次提交
- 27 1月, 2018 2 次提交
- 26 1月, 2018 2 次提交
-
-
由 Graham King 提交于
Document how to pass flags to the cli program being debugged.
-
由 Lucas Molas 提交于
-
- 25 1月, 2018 1 次提交
-
-
由 Alessandro Arzilli 提交于
* core_test: fix TestCoreFpRegisters on go1.9 It was broken by 7bec20e5 * travis-ci: switch to VM builders for linux
-
- 19 1月, 2018 4 次提交
-
-
由 Alessandro Arzilli 提交于
Much like the bug in issue #1031 and commit f6f6f0bf 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
-
由 Alessandro Arzilli 提交于
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.
-
由 Chad Whitacre 提交于
Help out those of us habituated to pdb. <:^) https://docs.python.org/3/library/pdb.html
-
由 Yasushi Saito 提交于
* 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.
-
- 12 1月, 2018 1 次提交
-
-
由 Matthew Taylor 提交于
-
- 08 1月, 2018 1 次提交
-
-
由 Chad Whitacre 提交于
-
- 06 1月, 2018 2 次提交
-
-
由 aarzilli 提交于
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
-
由 aarzilli 提交于
The rr backend doesn't report the exit status (the argument of the W packet seems to always be 0). Fixes #1067
-
- 05 1月, 2018 1 次提交
-
-
由 Zaytsev Dmitriy 提交于
-
- 04 1月, 2018 2 次提交
-
-
由 Derek Parker 提交于
Improve the link ordering for the main README and add a "Getting Started" doc with basic usage information for new users.
-
由 aarzilli 提交于
I saw a test failure related to this in Travis-CI, if it happens again I would like to know what's causing it.
-
- 03 1月, 2018 2 次提交
-
-
由 Florin Patan 提交于
-
由 aarzilli 提交于
Fixes #1052
-
- 02 1月, 2018 1 次提交
-
-
由 Victor Titov 提交于
-
- 21 12月, 2017 2 次提交
-
-
由 aarzilli 提交于
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.
-
由 Koichi Shiraishi 提交于
As of Go 1.8, allows empty GOPATH environment variable.
-