Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Unable to debug with VSCode or Intellij gogland #902

Closed
ataliadvanstep opened this issue Jun 28, 2017 · 19 comments
Closed

Unable to debug with VSCode or Intellij gogland #902

ataliadvanstep opened this issue Jun 28, 2017 · 19 comments
Labels
area/proc/gdbserial kind/bug os/macOS

Comments

@ataliadvanstep
Copy link

Please answer the following before submitting your issue:

Note: Please include any substantial examples (debug session output,
stacktraces, etc) as linked gists.

  1. What version of Delve are you using (dlv version)?
    Version: 1.0.0-rc.1

  2. What version of Go are you using? (go version)?
    go version go1.8.3 darwin/amd64

  3. What operating system and processor architecture are you using?
    MacOs 10.12.5

  4. What did you do?
    I try to debug a simple program step by step

  5. What did you expect to see?
    I should be able to go next line when nexting while debugging

  6. What did you see instead?
    It seems the debugger stucks randomly when I try to debug into vscode or intellij on macos.

image
@aarzilli
Copy link
Member

If it's random it's possible that the fix is in #876.

@ataliadvanstep
Copy link
Author

@aarzilli I have checkout the branch from fix #876, I compiled dlv and installed into my gopath. but still same issue.

For example this is the output from gogland. I have changed the path to the new dlv (/Users/atali/Development/go/bin/dlv)

GOROOT=/usr/local/Cellar/go@1.7/1.7.6/libexec
GOPATH=/Users/atali/Development/go:/Users/atali/Development/imapura/go-workspace
/usr/local/Cellar/go@1.7/1.7.6/libexec/bin/go test -c -o /private/var/folders/62/cc5sglt13z78rh_pbdhx_mww0000gn/T/ContactSuite_TestCreateContact_in_contact_test_gogo -gcflags "-N -l" rocketbrain/database
/Users/atali/Development/go/bin/dlv --listen=localhost:53463 --headless=true --api-version=2 --backend=default exec /private/var/folders/62/cc5sglt13z78rh_pbdhx_mww0000gn/T/ContactSuite_TestCreateContact_in_contact_test_gogo -- -test.v -check.f ^TestCreateContact$ -check.vv
API server listening at: 127.0.0.1:53463

image

@aarzilli
Copy link
Member

Can you send SIGQUIT to the dlv process and paste the stack dump here?

@ataliadvanstep
Copy link
Author

dump generated with gcore on my mac :

https://www.dropbox.com/s/4w95k5ljsttn0lz/dlv-9549-20170628T123947Z?dl=0

@aarzilli
Copy link
Member

The core dump is useless unless you also give me the binary. But a kill -QUIT <dlv pid> would have been enough to start.

@aarzilli
Copy link
Member

Actually, never mind, I don't have a way to examine a macOS core dump, you should go with the kill -QUIT.

@ataliadvanstep
Copy link
Author

I tried to kill -QUIT or kill -SIGQUIT on Mac OS sierra but no core dump are generated . I try to find how to enable core dump.

@aarzilli
Copy link
Member

I don't want a core dump, I want a stack dump.

@ataliadvanstep
Copy link
Author

Is that useful ?
stack dump dlv.txt

@aarzilli
Copy link
Member

No, because it doesn't tell me where it's stopped.

@ataliadvanstep
Copy link
Author

ataliadvanstep commented Jun 28, 2017 •
edited
Loading

is the backtrace from the macos debugger is useful ?
I do my best to give you all the informations but I am not an expert on debugging a debugger and core dump :-) If you have any step by step guide I can follow on mac os, I will be glad to help you.

(lldb) bt all

@aarzilli
Copy link
Member

Output of stat /Library/Developer/CommandLineTools/Library/PrivateFrameworks/LLDB.framework/Versions/A/Resources/debugserver?

@ataliadvanstep
Copy link
Author

stat /Library/Developer/CommandLineTools/Library/PrivateFrameworks/LLDB.framework/Versions/A/Resources/debugserver
16777220 527142 -rwxr-xr-x 1 root admin 0 4719552 "Jun 28 17:35:38 2017" "Apr 12 20:41:08 2017" "May 5 16:55:41 2017" "Apr 12 20:41:08 2017" 4096 520 0x20 /Library/Developer/CommandLineTools/Library/PrivateFrameworks/LLDB.framework/Versions/A/Resources/debugserver

@aarzilli
Copy link
Member

Can you upload your /Users/atali/Development/go/bin/dlv

@ataliadvanstep
Copy link
Author

https://www.dropbox.com/s/o1ycmmvfxvaise5/dlv?dl=0

@aarzilli
Copy link
Member

You didn't actually update your dlv binary to the branch I told you. I can tell because:

$ go tool objdump ./dlv | head -2
TEXT github.com/derekparker/delve/pkg/proc/gdbserial.(*gdbConn).waitForvContStop(SB) /Users/atali/Development/go/src/github.com/derekparker/delve/pkg/proc/gdbserial/gdbserver_conn.go
	gdbserver_conn.go:572	0x42cbd50	65488b0c25a0080000		GS MOVQ GS:0x8a0, CX

But on that branch the first instruction of waitForvContStop is at line :581. Furthermore the disassembly of that function on your executable does not contain calls to sendCtrlC.

@ataliadvanstep
Copy link
Author

@aarzilli you are totally correct ! My bad ! I had the previous package on my gopath and I compiled your branch in another path (outside of gopath). the makefile was compiling the previous package located in gopath.

I tested your version and it works perfectly ! Do you know when your patch will be merged to the next version ?

@aarzilli
Copy link
Member

Glad to hear it works. It should be merged soon.

aarzilli added a commit to aarzilli/delve that referenced this issue Jun 29, 2017
@aarzilli
proc/gdbserial: fix ContinueOnce getting stuck on macOS
3610bd9 
Fixes go-delve#902
@ataliadvanstep
Copy link
Author

@aarzilli Thanks a lot for your time !

@aarzilli aarzilli mentioned this issue Jun 30, 2017
Closed
aarzilli added a commit to aarzilli/delve that referenced this issue Jun 30, 2017
@aarzilli
proc/gdbserial: fix ContinueOnce getting stuck on macOS
2ce6426 
Fixes go-delve#902
abner-chenc pushed a commit to loongson/delve that referenced this issue Mar 1, 2024
@aarzilli @abner-chenc
proc: fix interaction of RequestManualStop and conditional breakpoints (
5426fdb 
go-delve#876)

* proc: fix interaction of RequestManualStop and conditional breakpoints

A conditional breakpoint that is hit but has the condition evaluate to
false can block a RequestManualStop from working. If the conditional
breakpoint is set on an instruction that is executed very frequently by
multiple goroutines (or many conditional breakpoints are set) it could
prevent all calls to RequestManualStop from working.

This commit fixes the problem by changing proc.Continue to exit
unconditionally after a RequestManualStop is called.

* proc/gdbserial: fix ContinueOnce getting stuck on macOS

Fixes go-delve#902
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/proc/gdbserial kind/bug os/macOS
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@aarzilli @ataliadvanstep