profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/nd/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

nd/lein-teamcity 13

A Leiningen plugin for TeamCity

nd/bird 11

Exercises from "Introduction to Functional Programming using Haskell" by Richard Bird

nd/sicp 6

sicp exercises

nd/thread-dump.el 3

Emacs mode for java thread dumps

nd/e 1

issue closedgo-delve/delve

No response to RPCServer.State request

  1. What version of Delve are you using (dlv version)?
Delve Debugger
Version: 1.6.1
Build: 7a3faca71f7e01a97833e11ebf0683543e8159cb
  1. What version of Go are you using? (go version)?

1.14.4

  1. What operating system and processor architecture are you using?

Mac OS X (10.15.7, x86_64)

  1. What did you do?

Debugged the program:

package main

import "fmt"

func main() {
	a := 1
	fmt.Println(a) // breakpoint
}

Delve was launched from IDE with the command:

dlv --listen=0.0.0.0:57555 --headless=true --api-version=2 --check-go-version=false --only-same-user=false exec /path/to/executable --

The executable was compiled with the -gcflags "all=-N -l" option.

  1. What did you expect to see?

Debugger responds to IDE requests.

  1. What did you see instead?

Debugger doesn't respond.

Judging by IDE logs it connected to delve successfully and sent the {"method":"RPCServer.State","params":[{"NonBlocking":true}],"id":1} request, but didn't get any response back.

If delve is launched with --log --log-output lldbout,rpc, it prints only

API server listening at: [::]:55744
2021-07-05T18:48:22+07:00 debug layer=rpc API server pid = 43752

in its own log. Debugserver log doesn't seem to contain any errors.

Reportedly delve does work fine if launched as dlv debug /path/to/main.go.

closed time in 11 days

nd

issue commentgo-delve/delve

No response to RPCServer.State request

Sorry, forget to close it. It looks like something called VMware Carbon Black Endpoint was blocking the debugger.

nd

comment created time in 11 days

issue commentgo-delve/delve

Wrong constant is returned in a variable value

Looks like any 'different package' heuristics breaks some valid cases..

nd

comment created time in 18 days

issue commentgo-delve/delve

Wrong constant is returned in a variable value

if the constant is unexported and comes from a different package it seems to be a coincidence

nd

comment created time in 18 days

issue openedgo-delve/delve

Wrong constant is returned in a variable value

  1. What version of Delve are you using (dlv version)?
Delve Debugger
Version: 1.7.0
Build: b41e47a30539294818283b89dae4d4879242e0c5
  1. What version of Go are you using? (go version)?
go version go1.17 windows/amd64
  1. What operating system and processor architecture are you using?
windows/amd64
  1. What did you do?

Debugged a program

package main

import (
  "time"
)

func main() {
  t := 10 * time.Second
  println(t) //break
  http.ServeTLS(net.Listener(nil), nil, "", "") // just to use make net/http.http2prefaceTimeout appear in the executable
}

  1. What did you expect to see?

value of t is 10000000000

  1. What did you see instead?

value of t is net/http.http2prefaceTimeout (10000000000)

If I remove the http.ServeTLS line and еру corresponding import, the value is returned as expected.

created time in 18 days

pull request commentgo-delve/delve

pkg/proc: Parse Goroutine ID in eBPF tracer

They use Ubuntu 20.04.2 LTS. Kernel versions for arm64 is5.4.0-1045-aws, for x86 and x64 - 5.8.0-1041-aws. The easiest way to get more details is to run something like

cat /boot/config-`uname -r` 

as a first build step.

derekparker

comment created time in a month

pull request commentgo-delve/delve

pkg/proc: Parse Goroutine ID in eBPF tracer

Looks like rebooting the builder helped. You can do that from UI on the build agent page ('Reboot agent machine' link in the bottom) .

derekparker

comment created time in a month

issue commentgo-delve/delve

Next command skips lines with code

Debugger stops at line 126

nd

comment created time in a month

issue openedgo-delve/delve

Next command skips lines with code

  1. What version of Delve are you using (dlv version)?
Delve Debugger
Version: 1.7.0
Build: b41e47a30539294818283b89dae4d4879242e0c5
  1. What version of Go are you using? (go version)?
go version go1.17 windows/amd64
  1. What operating system and processor architecture are you using?
windows/amd64
  1. What did you do?

Cloned github.com/dolthub/dolt. Built tests using:

go.exe test -c -o test.exe -gcflags "all=-N -l" github.com/dolthub/dolt/go/libraries/doltcore/sqle

in the go directory. Ran the TestTableEditor using delve:

dlv.exe --log --log-output rpc --log-dest dlv.log exec test.exe -- -test.run ^\QTestTableEditor\E$

Added a breakpoint at testutil.go:116. Once it is reached, executed next.

  1. What did you expect to see?

Program stops on the next line with code, line 120.

  1. What did you see instead?

Program skips lines 120 and 121 and stops at 122.

If one explicitly adds breakpoints at lines 120 and 121, program stops there.

Delve log: https://gist.github.com/nd/82776aba8fcdc82bdbae419975dca839

created time in a month

pull request commentgo-delve/delve

pkg/proc: Parse Goroutine ID in eBPF tracer

@derekparker yes. Use the 'Run...' button on the build page. It will open custom build dialog. On the 'Changes' tab select Use settings: from VCS

Screenshot (219)

It doesn't work for all changes in dsl. As far as I can see you changed build steps, such a change should work.

derekparker

comment created time in a month

push eventnd/dotfiles

Dmitry Neverov

commit sha a870ea949691d65950b786ed292d404d7c581a97

disable electric shit: emacs cannot parse c literals

view details

push time in a month

pull request commentgo-delve/delve

pkg/proc: Fix Windows ebpf build errors

@derekparker json output is shown if you select 'View: Verbose' in the top of the page. You can also download full build log, it might be more convenient to view it in the editor inside the browser. Filed an issue for better output from go test: https://youtrack.jetbrains.com/issue/TW-72558.

It looks like your build failed to install gcc. I've rerun it, now it shows which test failed: https://delve.teamcity.com/viewLog.html?buildId=18326&buildTypeId=Delve_windows_amd64_1_17&tab=buildResultsDiv&branch_Delve_windows_amd64=pull%2F2637

derekparker

comment created time in a month

pull request commentgo-delve/delve

pkg/proc: Fix Windows ebpf build errors

@derekparker looks like compilation errors are not reported in json, that's why teamcity misses them. I hope reporting test exit code (#2638) will make it fail.

derekparker

comment created time in a month

PR opened go-delve/delve

teamcity: report go test exit code on windows
+1 -0

0 comment

1 changed file

pr created time in a month

push eventnd/delve

nd

commit sha 150ef04177a8aa8be26b8988847702b2ccc30444

TeamCity: prefer go rc builds over beta (#2619) Works around https://github.com/golang/go/issues/47367.

view details

Alessandro Arzilli

commit sha e9b20d5ee10aea3fcc600ce57685af7309fba921

proc: use signed comparison when searching image for module data (#2621) StaticBase is the difference between the entry point declared in the image file and the entry point as loaded in memory, since this difference could be a negative number we have to use a signed comparison when searching for a mapping. Causes intermittent test failures on windows when resolving interface types for position independent executables. Fixes #2620

view details

Alessandro Arzilli

commit sha 2ecc025311ce39aa2ec4bdb24c05934351c191fd

terminal: add prompt when breakpoint is hit during next/step/stepout (#2548) * terminal: add prompt when breakpoint is hit during next/step/stepout Adds a prompt asking the user what to do when a breakpoint is hit on a different goroutine while next/step/stepout is being executed. Gives the user the opportunity to cancel next/step/stepout, continue once skipping the breakpoint or automatically skipping all other concurrent breakpoints until next/step/stepout is finished. Fixes #2317

view details

Hyang-Ah Hana Kim

commit sha 26e7f67cc403d6729e9291f629cf2741bc173c61

cmd/dlv: dlv version --verbose (#2615) * cmd/dlv: dlv version --verbose That prints out runtime/debug.BuildInfo read from the dlv binary. Users can retrieve the same info using `go version -m <path_to_dlv>` but I think it is convenient to have. If dlv was built from cloned delve repo: ``` $ ./dlv version -v Delve Debugger Version: 1.7.0 Build: $Id: e353a65161e6ed74952b96bbb62ebfc56090832b $ Build Details: go1.16.5 mod github.com/go-delve/delve (devel) dep github.com/cosiner/argv v0.1.0 h1:BVDiEL32lwHukgJKP87btEPenzrrHUjajs/8yzaqcXg= ... ``` If dlv was built with `go install github.com/go-delve/delve@latest` with go1.16+, or `GO111MODULE=on go get github.com/go-delve/delve@latest` from a clean main module: ``` $ ./dlv version -v Delve Debugger Version: 1.7.0 Build: $Id: e353a65161e6ed74952b96bbb62ebfc56090832b $ Build Details: go1.16.5 mod github.com/go-delve/delve v1.7.0 dep github.com/cosiner/argv v0.1.0 h1:BVDiEL32lwHukgJKP87btEPenzrrHUjajs/8yzaqcXg= ... ``` * remove an accidentally added bogus test

view details

Derek Parker

commit sha f6681c60903cc126ba060f01e2eab1341b06b526

pkg/proc: Prefer throw instead of fatalthrow (#2616) * 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

view details

Derek Parker

commit sha 56731bd88a880ae8563ff23498793e6b3bd6641e

Documentation: Improve help output for examinemem (#2623) Before this change when you typed `help` at the Delve prompt you would only see the following: ``` examinemem (alias: x) Examine memory: ``` Now with this patch the output is more descriptive: ``` examinemem (alias: x) Examine raw memory at the given address. ```

view details

Derek Parker

commit sha cb73ef8f83d7837486b3f7b9043ce07df96e466c

pkg/terminal: Ignore existing breakpoints for continue until (#2624) Ignore existing breakpoints when using the continue command to continue to a specific location such as `continue main.main`. The point of this command is to continue to a specific location, so if there is already a breakpoint set there there should be no error returned, just continue until we hit the breakpoint already set in that location.

view details

Austin Clements

commit sha a2b839990e21690e9e60a74c582c4acece6196d8

Fix crashes on Go dev.typeparams (soon to be Go main branch) (#2627) * proc: Go 1.18 removes the _defer.siz field As of Go 1.17, the _defer.siz field is always 0 because _defer no longer stores defer call arguments at all. golang.org/cl/326062 removes it entirely for Go 1.18. Simply treat it as 0 if the field is missing from the _defer type. * proc: Go 1.18 changes _defer.fn from *funcval to func() golang.org/cl/325918 changed the type of the _defer.fn field from *funcval to func() for Go 1.18. This CL was later reverted because it caused failures in Delve, but we would like to un-revert it. Handle this change by inspecting the type of this field before decoding it.

view details

Suzy Mueller

commit sha b87a1fc55d6175de83ab20d0a712eacb5253509d

service/dap: make next while nexting error more clear (#2622) 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.

view details

Suzy Mueller

commit sha 89ed5a0b19725999db55706a7b191a6e94065414

service/dap: page stack frames (#2597) 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.

view details

Derek Parker

commit sha 10406f96d539d905fbe8e8d102d7a01e61f26f04

*: Initial eBPF tracing support (#2625)

view details

Suzy Mueller

commit sha df5812bf2d623647ef705cacb9ac5fc4eb37f29e

pkg/proc: add tests for next interrupted by bp (#2632) Adds tests that make sure that when a next request is interrupted by a breakpoint, the stepping breakpoints are cleared.

view details

polinasok

commit sha 229fcf1559ac4755b013c734181f0e956670af20

cmd: refactor building logic into a helper (#2629) * cmd: refactor building logic into a helper * Address review comments Co-authored-by: Polina Sokolova <polinasok@users.noreply.github.com>

view details

Alessandro Arzilli

commit sha fdb5189e8cf9721f0500a3512993fd4ecef71369

dwarf/op,proc: implement more DWARF expression opcodes (#2606)

view details

Dmitry Neverov

commit sha 633eedf953ef285c27bf8058cdea2f2e94bf3695

teamcity: report go test exit code on windows

view details

push time in a month

pull request commentgo-delve/delve

[WIP] pkg/proc: Prefer throw instead of fatalthrow

@derekparker hopefully #2619 does that

derekparker

comment created time in 2 months

PR opened go-delve/delve

TeamCity: prefer go rc builds over beta

Works around https://github.com/golang/go/issues/47367.

+14 -5

0 comment

3 changed files

pr created time in 2 months

push eventnd/delve

Suzy Mueller

commit sha 3941af1d02e85e5c316d72ac4077ff13cdaa2e08

service/dap: limit the number of goroutines to return from a threads request (#2595) This adds a cap and a log message if there are many goroutines. This will help prevent the debugger from freezing, but does not yet address making sure the interesting goroutines are the ones that are returned. Updates golang/vscode-go#129

view details

nd

commit sha b41e47a30539294818283b89dae4d4879242e0c5

teamcity: use same token everywhere (#2609)

view details

polinasok

commit sha b7d8edcdaf67e7255c9610e7fed224b0db75fb02

service/dap: handle unexpected debugger termination (EOF) error (#2574) 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>

view details

Alessandro Arzilli

commit sha 898907354835213f97d10adbd4ba62caba127b08

terminal: improve 'on' command (#2556) * terminal: improve 'on' command Adds the ability to edit the list of commands executed after stopping on a breakpoint, as well as converting a breakpoint into a tracepoint and vice versa. Prior to this it was possible to add commands to a breakpoint but removing commands or changing a breakpoint into a tracepoint, or vice versa, could only be done by removing and recreating the breakpoint.

view details

Hyang-Ah Hana Kim

commit sha f74b7a6e395ab9885b740e7fe80e5efa7cc73690

all: update github.com/spf13/cobra to v1.1.3 (#2572) This removes indirect dependencies from go.mod, and includes the fix for the missing -help flag info. The latest cobra release is v1.2.1. Given that there were minor security-related dependency cleanup during v1.2 release, I was tempted to pick up the latest version, but that caused dependency updates in golang.org/x/sys and golang.org/x/tools which may be too recent (golang.org/x/* follow the go's release support policy, so recent versions may not be compatible with go versions beyond go's official version support policy). Verified that dlv still builds with go1.12.x. (go1.12 is the oldest version of go that can build the latest delve already). $ go get -d github.com/spf13/cobra@v1.1.3 $ go mod tidy $ go mod vendor $ go run _scripts/gen-usage-docs.go

view details

Alessandro Arzilli

commit sha 39274f6028b38e7b7b674e84bf96694080e537fe

proc: make moduleDataToImage more robust (#2613) Conversion form a moduledata object into an image object was implemented by looking for a function covering the start address of the text section of the moduledata object, and then converting that into its corresponding image. Unfortunately this seems to not always work. In particular it does not work on linux/386 with go1.17 (but it might also fail on other combinations): the start address of the text section is, for whatever reason, not part of any function. As a fallback simply scan all images we know of and return the closest one that has start address less than or equal to the start address of the text section we are looking for. Fixes TestPluginVariables on go1.17/linux/386. Fixes #2611 Co-authored-by: a <a@kra>

view details

Suzy Mueller

commit sha f1edc45f7518ab976b5ab3e26775f8c17707be66

service/dap: disable TestFatalThrowBreakpoint for Go 1.17 (#2614) * service/dap: disable TestFatalThrowBreakpoint for Go 1.17

view details

polinasok

commit sha aaed14ffcbc76d7d856e8bcf3961789ad9fe5a42

service/dap: fix backend parsing in replay mode (#2618) Co-authored-by: Polina Sokolova <polinasok@users.noreply.github.com>

view details

Dmitry Neverov

commit sha 428415ab6b8f46eb14ce186714fd521d8e67137b

TeamCity: prefer go rc builds over beta Works around https://github.com/golang/go/issues/47367.

view details

push time in 2 months

issue openedgolang/go

dl: site returns rc versions after beta

What did you do?

Ran curl "https://golang.org/dl/?mode=json&include=all" in console

What did you expect to see?

go1.17rc1 before go1.17beta1

What did you see instead?

go1.17rc1 after go1.17beta1

created time in 2 months

issue closedgo-delve/delve

Delve exists on attempt to evaluate long array

  1. What version of Delve are you using (dlv version)?
Delve Debugger
Version: 1.6.1
Build: f0a32c8e1b6571c8c1cd4ed89dcb9c784481f422
  1. What version of Go are you using? (go version)?
go version go1.17beta1 windows/amd64
  1. What operating system and processor architecture are you using? windows/amd64

  2. What did you do?

Evaluated dat at breakpoint in:

package main

import "io/ioutil"

func main() {
	dat, _ := ioutil.ReadFile("file")
	print(dat) //break
}

File is any file longer than ~250Kb.

Variable is evaluated fully with the request

2021-07-19T11:35:55+02:00 debug layer=rpc <- RPCServer.Eval(rpc2.EvalIn{"Scope":{"GoroutineID":1,"Frame":0,"DeferredCall":0},"Expr":"dat","Cfg":{"FollowPointers":true,"MaxVariableRecurse":1,"MaxStringLen":269957,"MaxArrayValues":269957,"MaxStructFields":-1}})
  1. What did you expect to see?

Either full content or error describing why it cannot be evaluated

  1. What did you see instead?

Delve exists with exit code 0. Before exiting it allocates ~500Mb of memory. From windows event log it seems like delve wasn't killed and existed by itself.

--

250K array is big and client should be smarter and use paging, but maybe delve can report an error instead of exiting. The issue is not specific to windows and can be observed on mac.

closed time in 2 months

nd

issue commentgo-delve/delve

Delve exists on attempt to evaluate long array

Cannot reproduce in terminal, looks like a client problem indeed.

nd

comment created time in 2 months

PR opened go-delve/delve

teamcity: use same token everywhere
+2 -2

0 comment

1 changed file

pr created time in 2 months

push eventnd/delve

Luis Gabriel Gomez

commit sha 69615b3604d5921c574f0df79be4b865614db50a

service/dap: Support for replay and core modes (#2367) This PR aims to add support for rr replay and core actions from the DAP layer. This basically encloses the following: New launch modes: replay and core The following modes are added: replay: Replays an rr trace, allowing backwards flows (reverse continue and stepback). Requires a traceDirPath property on launch.json pointing to a valid rr trace directory. Equivalent to dlv replay <tracedir> command. core: Replays a core dump file, showing its callstack and the file matching the callsite. Requires a coreFilePath property on launch.json pointing to a valid coredump file. Equivalent to dlv core <exe> <corefile> command. Dependencies To achieve this the following additional changes were made: Implement the onStepBackRequest and onReverseContinueRequest methods on service/dap Adapt onLaunchRequest with the requried validations and logic for these new modes Use CapabilitiesEvent responses to enable the StepBack controls on the supported scenarios (see dicussion here) Add the corresponding launch.json support on vs code: Support for replay and core modes golang/vscode-go#1268

view details

polinasok

commit sha c5e533b131d8c8f1801a9b1cc15f68241f746833

Treat SIGTERM as a server disconnect signal (#2580) Co-authored-by: Polina Sokolova <polinasok@users.noreply.github.com>

view details

Alessandro Arzilli

commit sha 658d36cb1909cd4267e538b10f2f84df8f752216

proc: allow multiple overlapping internal breakpoints (#2519) Changes Breakpoint to allow multiple overlapping internal breakpoints on the same instruction address. This is done by changing the Breakpoint structure to contain a list of "breaklets", each breaklet has a BreakpointKind and a condition expression, independent of the other. A breakpoint is considered active if any of its breaklets are active. A breakpoint is removed when all its breaklets are removed. We also change the terminology "internal breakpoint" to "stepping breakpoint": HasInternalBreakpoints -> HasSteppingBreakpoints IsInternal -> IsStepping etc... The motivation for this change is implementing watchpoints on stack variables. Watching a stack variable requires also setting a special breakpoint to find out when the variable goes out of scope. These breakpoints can not be UserBreakpoints because only one user breakpoint is allowed on the same instruction and they can not be internal breakpoints because they should not be cleared when a next operation is completed (they should be cleared when the variable watch is cleared). Updates #279

view details

Dmitry Neverov

commit sha e18aee6fb0d7bd6bbb5546711de863646c83f856

teamcity: use same token everywhere

view details

push time in 2 months

push eventnd/delve

nd

commit sha 65f436494cbad4841a89f8c76dda45395698a391

teamcity: specify working github token in dsl (#2607)

view details

nd

commit sha a14bec4cfc52e00806e359a8dd2ca4f10126ea14

Make teamcity ui settings readonly (#2608) * teamcity: specify working github token in dsl * teamcity: disable settings editing in UI If VCS root doesn't have push permissions, push of settings changes made in UI fail. After that synchronization with VCS is disabled in order to not loose UI changes. With read-only UI all changes have to be made in dsl.

view details

Dmitry Neverov

commit sha d7fcd03cbe659b26485acba5bf55f20320e663ec

teamcity: use same token everywhere

view details

push time in 2 months

pull request commentgo-delve/delve

teamcity: specify working github token in dsl

I've changed only one token because others were working fine. If token in commit status publisher has necessary permissions in github, I can specify it in the other feature as well.

nd

comment created time in 2 months

pull request commentgo-delve/delve

teamcity: specify working github token in dsl

I'm not sure what's going on, but now token specified in pull requests build feature fails with unauthorized error. Maybe tokens are changed in github settings?

nd

comment created time in 2 months

PR opened go-delve/delve

Make teamcity ui settings readonly

It looks like editing settings both in UI and in git leads to problems. This change disables settings editing in UI. If applied, all changes should be made by editing settings.kts. Feel free to reject if you want edit settings in UI, but in this case it is better to give teamcity permissions to push changes in settings to the repository, currently push fails. Otherwise every failed push disables settings synchronization.

+4 -1

0 comment

1 changed file

pr created time in 2 months

create barnchnd/delve

branch : readonly

created branch time in 2 months

pull request commentgo-delve/delve

terminal: config -list should print strings in quotes

Derek changed the token in UI, but push of updated settings failed (looks like token specified in the VCS root is either invalid or doesn't have push permissions). Here is the update for dsl: #2607.

aarzilli

comment created time in 2 months

PR opened go-delve/delve

teamcity: specify working github token in dsl
+1 -1

0 comment

1 changed file

pr created time in 2 months