Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    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
    onequid
    @onequid
    Hello guys. Found that quiting program executed with dlv exec will just kill the process without doing the "graceful shutdown" if there is. Is it designed so?
    It happens on my Linux machine.
    Alessandro Arzilli
    @aarzilli
    @OneQuid yes, the "graceful shutdown" is a result of your process receiving a SIGINT (probably) which delve doesn't send.
    onequid
    @onequid
    @aarzilli Thank you. However when dlv attach is used (probably with args --api-version=2 --accept-multiclient=true), the process would receive the sys Signals. Does it sound good that dlv exec and dlv debug(This would behave similar with dlv exec) would send sys signals as well?
    Seth Bromberger
    @sbromberger
    hi :)
    Sylvain Rabot
    @sylr
    Hi
    I am trying to tweak terraformto fork their plugin with delve in the to be able to debug the plugins
    It works but terraform is waiting for the plugin to output some json
    It seems that this json is intercepted by delve but not forwared to terraform
    because I see the json in my shell but terraform still hangs
    so I’m wondering what I have to do to make delve forward the stdout of the plugin to the father process 
     | |   \-+= 22577 s.rabot -zsh
 | |     \-+= 57717 s.rabot terraform plan
 | |       \-+- 57719 s.rabot /Users/s.rabot/go/bin/dlv exec --headless --listen=127.0.0.1:2346 --api-version=2 --log-dest=/dev/console -- /Users/s.rabot/go/bin/terraform-provider-azurerm
 | |         \-+= 57720 s.rabot /Library/Developer/CommandLineTools/Library/PrivateFrameworks/LLDB.framework/Versions/A/Resources/debugserver --stdio-path /dev/tty -F -R 127.0.0.1:51650 -- /Users/s.rabot/go/bin/terraform-provider-azurerm
 | |           \--- 57721 s.rabot /Users/s.rabot/go/bin/terraform-provider-azurerm
    pablochacin
    @pablochacin
    Hi @sylr I'm now facing a similar issue. I need to debug a tf plugin. Would you mind to share how did you setup terraform to use launch delve instead of the plugin? As for the problem with returning the json, did you manage to solve it? Thanks in advance
    chainhelen
    @chainhelen
    @pablochacin go-delve/delve#1880
    pablochacin
    @pablochacin

    @pablochacin go-delve/delve#1880

    Thanks @chainhelen I'll keep a look at it.

    liangsj
    @liangsj
    i want to know how to use dlv connect
    when i run 'dlv attach $pid --headless --api-version=2 --log --listen=:8181' in romote
    and i run dlv connect $hostname:port in local
    when i use command list after breakpoint and continue. I cannot find my work
    iterm2 shows xx files not find
    i cannot find my code and the local code path maybe has some troubles
    chainhelen
    @chainhelen
    @liangsj The source code is related to your remote machine instead of your local path.
    You should ensure your remote machine keep the source code of program for this $PID .
    It is better that the program is just compiled by those remote's source codes.
    liangsj
    @liangsj
    if i want to use dlv in remote， I must ensure the source code in remote？
    i just keep bin execute in the remote，I think it resean i can't use dlv
    Michito
    @mic4ael
    hey guys, is there anyone who managed to debug dockerd with dlv?
    I modified the scripts that build dockerd to avoid some optimizations that apparently might break dlv
    but I am still getting some errors like "could not launch process: could not get .debug_frame section: could not find .debug_frame section"
    Ronan Mac Fhlannchadha
    @RonanMacF
    Did anyone manage to get the 32bit version working? I have cloned the 32bit branch and rbtree but when I run go install in delve/cmd/dlv it spits out .
    ../../proctl/variables_linux.go:13:2: must be imported as dwarf
../../proctl/proctl_linux.go:15:2: must be imported as elf
    chainhelen
    @chainhelen
    @mic4ael The dockerd must be compiled with flag '-gc-flag="-all=-N -l"'
    @RonanMacF It looks your local project include others .go files which is not belong to delve.