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.

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

cmd/gc: dwarf info for code lines really bad in go1.3: gdb breakpoints completely busted inside function literals and can produce segfaults #8098

Closed
glycerine opened this issue May 26, 2014 · 9 comments

Comments

@glycerine
Copy link

commented May 26, 2014

go version go1.3beta2 linux/amd64

It seems that the dwarf information (which has always been a bit spotty for local
variables through go1.2.1, but was reliable for line/breakpoint mapping) has now gotten
worse for source code locations. Breakpoints inside function literals in go1.3beta2 are
now completely ignored (presumably because the dwarf info is quite wrong now). Two
simple examples, the second one inducing a seg fault in gdb.

example one:
jaten@i7:~/t$ cat m_test.go
package main

import (
    "fmt"
    "testing"
)

func TestBreakpointsInsideFunctionLiteral(t *testing.T) {

    func() {
        fmt.Printf("a line inside a closure.\n") // line 11
    }()
}
jaten@i7:~/t$ cat m.go  # can be any main, the m_test.go shows the problem in example one
package main

import (
    "fmt"
)

func main() {
    fmt.Printf("first line\n")
    fmt.Printf("main ran okay.\n")
}
jaten@i7:~/t$go test -c -gcflags "-N -l" -v
jaten@i7:~/t$ ls -alFtrh 
total 4.6M
-rw-rw-r--   1 jaten jaten  109 May 25 23:45 m.go~
-rw-rw-r--   1 jaten jaten  316 May 25 23:49 m_test.go~
drwxr-xr-x 141 jaten jaten  24K May 25 23:50 ../
-rw-rw-r--   1 jaten jaten  163 May 25 23:53 m_test.go
-rw-rw-r--   1 jaten jaten   97 May 25 23:57 m.go
-rwxrwxr-x   1 jaten jaten 1.8M May 25 23:57 t*
-rwxr-xr-x   1 jaten jaten 2.8M May 25 23:58 t.test*
drwxrwxr-x   2 jaten jaten 4.0K May 25 23:58 ./
jaten@i7:~/t$ gdb t.test
GNU gdb (GDB) 7.6.2
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>;...
Reading symbols from /home/jaten/t/t.test...done.
Loading Go Runtime support.
(gdb) break m_test.go:11  # set a breakpoint
Breakpoint 1 at 0x49ef45: file /home/jaten/t/m_test.go, line 11.
(gdb) run
Starting program: /home/jaten/t/t.test
warning: no loadable sections found in added symbol-file system-supplied DSO at
0x7ffff7ffd000
a line inside a closure.
PASS
[Inferior 1 (process 11309) exited normally]
(gdb) # breakpoint at line line 11 was completely ignored

################
# a second example, using just main() and not t.test, that segfaults instead:
################

jaten@i7:~/t$ cat m2.go
package main

import (
    "fmt"
)

func main() {
    func() {
        fmt.Printf("main ran okay.\n") // line 9
    }()
}
jaten@i7:~/t$ go build
jaten@i7:~/t$ ./t
main ran okay.
jaten@i7:~/t$ gdb t
GNU gdb (GDB) 7.6.2
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>;...
Reading symbols from /home/jaten/t/t...done.
Loading Go Runtime support.
(gdb) break 9
Breakpoint 1 at 0x400c3f: file /home/jaten/t/m2.go, line 9.
(gdb) run
Starting program: /home/jaten/t/t
warning: no loadable sections found in added symbol-file system-supplied DSO at
0x7ffff7ffd000

Program received signal SIGSEGV, Segmentation fault.
0x0000000000400c4b in main.func·001 () at /home/jaten/t/m2.go:9
9           fmt.Printf("main ran okay.\n")
(gdb) bt
#0  0x0000000000400c4b in main.func·001 () at /home/jaten/t/m2.go:9
#1  0x00007ffff7fc91b0 in ?? ()
#2  0x000000c208000140 in ?? ()
#3  0x0000000000000041 in ?? ()
#4  0x0000000000000041 in ?? ()
#5  0x0000000000000000 in ?? ()
(gdb)
@glycerine

This comment has been minimized.

Copy link
Author

commented May 26, 2014

Comment 1:

likely related to: https://golang.org/issue/7803
@glycerine

This comment has been minimized.

Copy link
Author

commented May 26, 2014

Comment 2:

Re-reading the initial report (I would edit it but I can't see how), hopefully it is
clear from the example that the segfault is in the go-program itself on which the
breakpoint was set, not in gdb itself.
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented May 26, 2014

Comment 3:

Labels changed: added repo-main, release-go1.3maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

commented May 27, 2014

Comment 4:

Labels changed: added release-go1.4, removed release-go1.3maybe.

Status changed to Accepted.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jun 10, 2014

Comment 5:

This issue was closed by revision 507afa6.

Status changed to Fixed.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jun 10, 2014

Comment 6:

Labels changed: added release-go1.3, removed release-go1.4.

@glycerine

This comment has been minimized.

Copy link
Author

commented Jun 10, 2014

Comment 7:

Awesome! Thanks, Ian!
@gopherbot

This comment has been minimized.

Copy link

commented Jun 11, 2014

Comment 8:

CL https://golang.org/cl/107900045 mentions this issue.
@rsc

This comment has been minimized.

Copy link
Contributor

commented Jun 11, 2014

Comment 9:

This issue was closed by revision 8fc565eea9a0.

@rsc rsc added this to the Go1.3 milestone Apr 14, 2015
@rsc rsc removed the release-go1.3 label Apr 14, 2015
rsc added a commit that referenced this issue May 11, 2015
««« CL 104950045 / 87daa424d96a
cmd/ld: fix PC deltas in DWARF line number table

The putpclcdelta function set the DWARF line number PC to
s->value + pcline->pc, which is correct, but the code then set
the local variable pc to epc, which can be a different value.
This caused the next delta in the DWARF table to be wrong.

Fixes #8098.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/104950045
»»»

LGTM=r
R=golang-codereviews, r
CC=bradfitz, golang-codereviews, iant
https://golang.org/cl/107900045
@golang golang locked and limited conversation to collaborators Jun 25, 2016
wheatman added a commit to wheatman/go-akaros that referenced this issue Jun 25, 2018
The putpclcdelta function set the DWARF line number PC to
s->value + pcline->pc, which is correct, but the code then set
the local variable pc to epc, which can be a different value.
This caused the next delta in the DWARF table to be wrong.

Fixes golang#8098.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/104950045
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
4 participants
You can’t perform that action at this time.