Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    thomasmckay
    @thomasmckay
    @alexander-myltsev i noticed your goland query above and thought maybe you could help me. i would like to use goland but the breakpoints i set are never stopped at (i am novice go but use rubymine every day ;)
    i'm trying to debug skopeo https://github.com/projectatomic/skopeo and from the Makefile there i have the "go tool arguments" in goland set to: "-buildmode=pie" -ldflags "-X main.gitCommit=563a4ac523aef8e23df732bd589731cf2f91eda1" -gcflags "-N -l" -tags " "
    Alessandro Arzilli
    @aarzilli
    PIE mode is not supported yet
    thomasmckay
    @thomasmckay
    i'll google unless you know what i should do instead (remove flag entirely, diff value, something else)
    thomasmckay
    @thomasmckay
    removed buildmode flag and breakpoints working. thanks!
    Alexander Myltsev
    @alexander-myltsev
    @thomasmckay my problem was that IDEA has broken Delve for debugging. I built Delve from sources, and replaced the binary in IDEA. everything started to work
    also, I didn’t manage to debug apps that uses console frameworks. alas, using “println”s there
    let me know if you need any further specific instructions
    thomasmckay
    @thomasmckay
    @alexander-myltsev ack, thanks. i will build from source as well and try that
    Andrei Serban
    @andofcourse
    Is there an official fix for the could not launch process: stub exited while waiting for connection: exit status 0 bug? I've tried installing different versions of commandline tools, different versions of dlv, etc, all to no avail.
    Alessandro Arzilli
    @aarzilli
    @andofcourse you should look at the output of --log --log-output=gdbwire and open a bug
    Justin
    @jpza
    I'm getting a panic that delve seems to be breaking on
    2018/05/31 16:03:40 server.go:100: could not init stream "fxe": "can't fetch master manifest: got HTTP response 400"
    received SIGINT, stopping process (will not forward signal)
    > runtime.mach_semaphore_wait() /usr/local/opt/go/libexec/src/runtime/sys_darwin_amd64.s:540 (PC: 0x105e3ab)
    Warning: debugging optimized function
       535:    // func mach_semaphore_wait(sema uint32) int32
       536:    TEXT runtime·mach_semaphore_wait(SB),NOSPLIT,$0
       537:        MOVL    sema+0(FP), DI
       538:        MOVL    $(0x1000000+36), AX    // semaphore_wait_trap
       539:        SYSCALL
    => 540:        MOVL    AX, ret+8(FP)
       541:        RET
       542:
       543:    // func mach_semaphore_timedwait(sema, sec, nsec uint32) int32
       544:    TEXT runtime·mach_semaphore_timedwait(SB),NOSPLIT,$0
       545:        MOVL    sema+0(FP), DI
    (dlv) s
    I can't step forward or debug
    Justin
    @jpza
    Actually haha this is from me hitting ctrl-C
    But it never actually shows the panic it's stalling on (which led to me hitting ctrl+C)
    Austin Parker
    @austinlparker
    I'm looking for a way to start a delve server programmatically without having the delve cmd installed; Is this unreasonable?
    Alessandro Arzilli
    @aarzilli
    @austinlparker no, you can't run it in the same process as the target
    GhostBasenji
    @GhostBasenji
    Hello everybody. Excuse me if we ask the wrong question.
    Tried to install a delve to start learning golang in the VS Code, but it does not work out. After a long googling understood that this debugger does not support 32-bit Windows.
    Correctly I understood? And how is it solved?
    Seth W. Klein
    @sethwklein
    @GhostBasenji that's correct. the issue tracking it is at derekparker/delve#656 . the solution is for someone to contribute the necessary code. the issue doesn't show that anyone is working on it right now
    Boran Car
    @borancar
    Hey guys, sorry if this question has been asked before. I am using https://please.build/ (similar to and inspired by Bazel) to build Golang programs. please likes to put relative paths from the repo root to the source files in the DWARF information and I have not seen a way to override this behavior. I am trying to debug using GoLand's external connection, but when setting breakpoints, GoLand will give the absolute path from the root of the filesystem (/) (following https://github.com/derekparker/delve/blob/master/Documentation/api/ClientHowto.md#using-rpcservercreatebreakpoint) and dlv will reject it because the DWARF information contains only relative paths to repo root. Since I haven't seen an option to modify what GoLand gives, I was thinking along the lines of a delve override inside the RPCServer - is such an approach OK or is there something I'm fundamentally missing?
    Alessandro Arzilli
    @aarzilli
    I'd like to see what the DWARF inside those executables looks like
    Boran Car
    @borancar

    here's a sample (I'm assuming you want readelf --debug-dump=decodedline | grep CU::

    CU: woz_tv/db/db.go:
    CU: woz_tv/db/product/product.go:

    When GoLand contacts via the RPC, it asks for
    /home/boran/git/project/woz_tv/db/db.go

    And these result in location not found

    (again, I'm unable to use idiomatic go folder structure due to a hard constraint)

    If I modify service/rpc2/server.go, func (s *RPCServer) CreateBreakpoint(arg CreateBreakpointIn, out *CreateBreakpointOut) error { to actually strip the /home/boran/git/project/, it works
    Alessandro Arzilli
    @aarzilli
    I'm not convinced that delve is the right place to handle this, IMHO delve is doing what the DWARF is saying, IMHO the problem is that your IDE doesn't understand your build system
    Boran Car
    @borancar
    I totally agree with this. Note that however, the easier solution for me is to have delve locally supporting workarounds (nothing new regarding workarounds in the software world, right?). The question is what is the stance on delve and workarounds?
    Boran Car
    @borancar
    The proposed workaround here would be for delve to trim the working directory from the location it receives via RPC if a certain flag is passed or config parameter set.
    Alessandro Arzilli
    @aarzilli
    the problem with including this workaround is that it needs configuration and at the moment a headless instance of delve doesn't read any configuration
    Boran Car
    @borancar
    could technically be a CLI argument, but ignoring the work that needs to be done (and that I would happily take), would this stand ground as a request and a PR from an ideological perspective?
    Alessandro Arzilli
    @aarzilli
    Definitely not in rpc2/server.go, maybe in debugger.go. I'd vote against it, you'd have to convince Derek.
    Boran Car
    @borancar
    Gotcha, thanks!
    Alessandro Arzilli
    @aarzilli
    the thing is that we already have a mechanism to mess with file paths, but it operates client-side instead of server-side
    therealssj
    @therealssj
    hello :)
    I was looking at the cli commands and dont you guys think that its a bit clustered having all the definitions in a single file https://github.com/derekparker/delve/blob/master/cmd/dlv/cmds/commands.go
    can I directly send a PR for a little cleanup proposal?
    split up the commands into separate files etc
    Omkarnath
    @Omie
    Hi, I got back to work on #1256 ( derekparker/delve#1256 ). Equivalent of display command of gdb. I looked at similar implementation of commands and wanted to confirm if I am on right track for this feature
    Seems like I have to add core functionality in proc/native/proc.go just like breakpoints' has. and keep map/list of display expressions and then expose the functionality through multiple layers viz, service/debugger/debugger.go, service/rpc2/server. service/rpc2/client, service/client.go (interface), and pkg/terminal/command.go
    • some In and Out types for client server, + required types in service/api/types etc
    I suppose this is how it should be implemented, hence any client will be able to consume the functionality
    Omkarnath
    @Omie
    I wanted to quickly confirm the approach
    Alessandro Arzilli
    @aarzilli
    @Omie: I really don't think you need to add things to proc.go, I'm pretty sure it can be done entirely in command.go, just keep a list of variables there and evaluate it when continue/next/step/stepout finishes
    Omkarnath
    @Omie
    @aarzilli thanks for getting back
    that means feature is limited to command client. Fine with it though, just making sure this is a conscious decision
    Alessandro Arzilli
    @aarzilli
    @Omie other clients have already implemented their own version of display, all they have to do is manage their own list of expressions, there isn't a big advantage to using a API to do it server side
    Omkarnath
    @Omie
    Fair, will do
    valentinewallace
    @valentinewallace
    Heya, I'm trying to use delve but getting "no source available" when i do dlv test -- -test.v and then list. and when i try to set breakpoints it says "location not found." any tips? thank you!
    valentinewallace
    @valentinewallace
    never mind, it "just works" if you use vscode
    u35tpus
    @u35tpus

    hi guys
    dlv is great thing.
    just one question.

    When I start dlv with my go binary, dlv hangs until I connect from debugger.
    dlv debug --listen=:40000 --log --log-output=/var/log/dlv.log --headless=true --api-version=2 cmd/pudge/pudge.go
    API server listening at: [::]:40000

    is there any way to let dlv just continue running until remote debugger connects?

    u35tpus
    @u35tpus
    oh. found it
    --accept-multiclient --continue