delve: Printing an uninitialized variable prints seemingly random information
With this simple program:
package main
import (
"fmt"
)
func main() {
branch := "master"
fmt.Println(branch)
}
Breaking on the branch := master
line gives the following output:
$ dlv debug .
Type 'help' for list of commands.
(dlv) break a.go:8
Breakpoint 1 set at 0x49c1af for main.main() ./a.go:8
(dlv) c
> main.main() ./a.go:8 (hits goroutine(1):1 total:1) (PC: 0x49c1af)
3: import (
4: "fmt"
5: )
6:
7: func main() {
=> 8: branch := "master"
9: fmt.Println(branch)
10: }
(dlv) locals
branch = "H�D$8�FH�D$(H���\x00\x00\x00H�\f$�G_\x03\x00H�D$\bH�D$8H�L$(Hǁ�\x00\x00\x00\x00\x00\x00\x00H�\f$H�D$\b\x03...+842350542940 more"
(dlv) step
> main.main() ./a.go:9 (PC: 0x49c1c4)
4: "fmt"
5: )
6:
7: func main() {
8: branch := "master"
=> 9: fmt.Println(branch)
10: }
(dlv) locals
branch = "master"
Similar output occurs with other variable types; for example branch := 42
is branch = 842350543032
on locals
.
I understand that this happens because the branch
variable isn’t assigned a value yet, but printing seemingly random information doesn’t strike me as a good user experience, and something that might confuse people a lot. I think it would be better to print something like <uninitialized>
or the type’s zero value.
$ dlv version
Delve Debugger
Version: 1.0.0
Build: $Id: c98a142125d0b17bb11ec0513bde346229b5f533 $
$ go version
go version go1.10 linux/amd64
$ uname -a
Linux arch.arp242.net 4.15.2-2-ARCH #1 SMP PREEMPT Thu Feb 8 18:54:52 UTC 2018 x86_64 GNU/Linux
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 3
- Comments: 15 (5 by maintainers)
Commits related to this issue
- proc: start variable visibility one line after their decl line In most cases variables shouldn't be visible on their declaration line because they won't be initialized there. Function arguments are t... — committed to aarzilli/delve by aarzilli 4 years ago
- proc: start variable visibility one line after their decl line In most cases variables shouldn't be visible on their declaration line because they won't be initialized there. Function arguments are t... — committed to aarzilli/delve by aarzilli 4 years ago
- proc: start variable visibility one line after their decl line In most cases variables shouldn't be visible on their declaration line because they won't be initialized there. Function arguments are t... — committed to aarzilli/delve by aarzilli 4 years ago
- proc: start variable visibility one line after their decl line In most cases variables shouldn't be visible on their declaration line because they won't be initialized there. Function arguments are t... — committed to aarzilli/delve by aarzilli 4 years ago
- proc: start variable visibility one line after their decl line In most cases variables shouldn't be visible on their declaration line because they won't be initialized there. Function arguments are t... — committed to aarzilli/delve by aarzilli 4 years ago
Yay, many thanks. It’s great to be able to debug Go programs again without fearing undefined behavior.
I also find the current behavior confusing (see GO-6280).
In my opinion, if the for loop indices need special handling, they should get them. All other variables should only be shown when they are in scope.