Delve: Cannot step with "next" on OSX: "Command failed: could not suspend thread ___ (ipc/send) invalid destination port"

Created on 29 Aug 2016  路  10Comments  路  Source: go-delve/delve

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)? 0.11.0-alpha f09ef23f9ec650f18f2530d7164229ea4a119700
  2. What version of Go are you using? (go version)? go version go1.7 darwin/amd64
  3. What operating system and processor architecture are you using? OSX El Capitan 10.11.6
  4. What did you do? dlv debug in the project directory.
  5. What did you expect to see? When I run my program without any debugging, or debug without any breakpoints, everything works (Input/outputs work as expected)
  6. What did you see instead?

If I use breakpoints, I'll get random "Command failed: could not suspend thread xxxxxx (ipc/send) invalid destination port" printouts sometimes when I try to "next". I noticed this happens usually when I stop and print out more complex data structures, but is otherwise just random.

If I just build and run the program, everything's fine. I used to use vscode-go integration, but when I found that I could only debug a few steps before the debugging session stops responding, I switched to dlv on the command line instead, and that's how I found the error message.

areproc kinbug omacOS

Most helpful comment

+1

All 10 comments

logs:
(dlv) n
Command failed: could not suspend thread 50463 (ipc/send) invalid destination port
(dlv) next
Command failed: next while nexting
(dlv) restart
Command failed: could not resume task
(dlv) continue
Process 42899 has exited with status 0

BTW, if there's any version combination of go/dlv that works on El Capitan 10.11.6, I'll be happy to downgrade :)
Some stack traces (if that helps):
(dlv) n
Command failed: could not suspend thread 19459 (ipc/send) invalid destination port
(dlv) stack
0 0x0000000000004fa5 in main.glob..func1
at ./cmd.go:49
1 0x00000000000e2399 in /vendor/github.com/spf13/cobra.(_Command).execute
at ./vendor/github.com/spf13/cobra/command.go:603
2 0x00000000000e2c1f in /vendor/github.com/spf13/cobra.(_Command).ExecuteC
at ./vendor/github.com/spf13/cobra/command.go:689
3 0x00000000000e264f in /vendor/github.com/spf13/cobra.(*Command).Execute
at ./vendor/github.com/spf13/cobra/command.go:648
4 0x000000000000383b in main.main
at ./main.go:8
5 0x000000000003002f in runtime.main
at /usr/local/go/src/runtime/proc.go:183
6 0x000000000005c9a0 in runtime.goexit
at /usr/local/go/src/runtime/asm_amd64.s:2086

(dlv) threads
Thread 15619 at 0x5da4b /usr/local/go/src/runtime/sys_darwin_amd64.s:418 runtime.mach_semaphore_wait
Thread 16647 at 0x5d926 /usr/local/go/src/runtime/sys_darwin_amd64.s:296 runtime.usleep
Thread 16899 at 0x5da4b /usr/local/go/src/runtime/sys_darwin_amd64.s:418 runtime.mach_semaphore_wait
Thread 17155 at 0x5da4b /usr/local/go/src/runtime/sys_darwin_amd64.s:418 runtime.mach_semaphore_wait

  • Thread 17411 at 0x4fa5 ./cmd.go:49 main.glob..func1
    Thread 18959 at :0
    Thread 19203 at :0
    Thread 19459 at :0
    Thread 19715 at 0x5da4b /usr/local/go/src/runtime/sys_darwin_amd64.s:418 runtime.mach_semaphore_wait
    Thread 19971 at 0x5db33 /usr/local/go/src/runtime/sys_darwin_amd64.s:499 runtime.kevent
    Thread 20227 at 0x5da4b /usr/local/go/src/runtime/sys_darwin_amd64.s:418 runtime.mach_semaphore_wait
    Thread 20483 at 0x5da4b /usr/local/go/src/runtime/sys_darwin_amd64.s:418 runtime.mach_semaphore_wait
    Thread 20739 at 0x5da4b /usr/local/go/src/runtime/sys_darwin_amd64.s:418 runtime.mach_semaphore_wait
    Thread 20995 at 0x5da4b /usr/local/go/src/runtime/sys_darwin_amd64.s:418 runtime.mach_semaphore_wait
    (dlv) goroutines
    [14 goroutines]
  • Goroutine 1 - User: ./cmd.go:49 main.glob..func1 (0x4fa5) (thread 17411)
    Goroutine 2 - User: /usr/local/go/src/runtime/asm_amd64.s:252 runtime.systemstack_switch (0x59a70)
    Goroutine 3 - User: /usr/local/go/src/runtime/proc.go:260 runtime.gopark (0x3049a)
    Goroutine 4 - User: /usr/local/go/src/runtime/proc.go:260 runtime.gopark (0x3049a)
    Goroutine 6 - User: /usr/local/go/src/runtime/proc.go:260 runtime.gopark (0x3049a)
    Goroutine 9 - User: /usr/local/go/src/runtime/proc.go:260 runtime.gopark (0x3049a)
    Goroutine 17 - User: /usr/local/go/src/runtime/asm_amd64.s:2087 runtime.goexit (0x5c9a1)
    Goroutine 20 - User: /usr/local/go/src/runtime/proc.go:260 runtime.gopark (0x3049a)
    Goroutine 34 - User: /usr/local/go/src/runtime/proc.go:260 runtime.gopark (0x3049a)
    Goroutine 35 - User: /usr/local/go/src/runtime/proc.go:260 runtime.gopark (0x3049a)
    Goroutine 36 - User: /usr/local/go/src/runtime/proc.go:260 runtime.gopark (0x3049a)
    Goroutine 37 - User: /usr/local/go/src/runtime/proc.go:260 runtime.gopark (0x3049a)
    Goroutine 38 - User: /usr/local/go/src/runtime/proc.go:260 runtime.gopark (0x3049a)
    Goroutine 39 - User: /usr/local/go/src/runtime/proc.go:260 runtime.gopark (0x3049a)

at this point, the contents of the struct will become a *(unreadable could not read memory)

+1

+1

I have encountered this problem in OSX, 0.11.0-alpha build, while running trace

dlv trace main

It seems that too many prints are causing the issue.

Any updates on how to fix this ?

I am getting this issue, any ideas what is going on?

@aarzilli Do you have any estimates?

@ignatov unless somebody that knows how macOS debugger API works, this (and all other subtle macOS bugs) will have to wait for #727 (assuming that fixes it) which needs to wait for a fairly extensive refactoring of proc.

Should be fixed on master, please reopen if not.

Was this page helpful?
0 / 5 - 0 ratings