go: cmd/compile: gdb 8 on windows crashes reading Go binary

What version of Go are you using (`go version`)?

> go version
go version go1.9rc2 windows/amd64

What operating system and processor architecture are you using (`go env`)?

> go env
set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Users\kjk\src\go
set GORACE=
set GOROOT=C:\Go
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0
set CXX=g++
set CGO_ENABLED=1
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config

What did you do?

I’m trying to gather more information on #20975 which involves running the executable on windows under a debugger that understands dwarf debug info (because neither msvc nor windbg do).

I tried:

clone repro program https://github.com/kjk/go20975 and run build.ps1 to build it
download gdb from https://nuwen.net/mingw.html and unpack under c:\
run C:\MinGW\bin\gdb.exe .\go20975.exe to run under dbg
enter https://vox.com in text box

What did you expect to see?

When crash happens, I expected to get a human-readable callstack.

What did you see instead?

[New Thread 2176.0xc90]
fatal: morestack on g0
../../src/gdb/buildsym.c:1773: internal-error: void buildsym_init(): Assertion `free_pendings == NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

The crash happened in the program but it also crashed gdb.

It seems that DWARF information created by Go compiler breaks gdb.

PS C:\Users\kjk\src\go\src\github.com\kjk\go20975> C:\MinGW\bin\gdb.exe --version
GNU gdb (GDB) 8.0

About this issue

Original URL
State: open
Created 7 years ago
Comments: 16 (6 by maintainers)

Commits related to this issue

runtime: improve Windows gdb tests This ensures that gdb tests run on Windows by ignoring any line ending. Works with gdb 7.7, however with gdb 7.9 and 7.12 gets an error error: internal-error:... — committed to golang/go by egonelbre 6 years ago
runtime: set procid on Windows The runtime-gdb.py script needs procid to be set in order to map a goroutine ID with an OS thread. The Go runtime is not currently setting that variable on Windows, so ... — committed to golang/go by qmuntal a year ago

Most upvoted comments

I’ve pulled the latest changes (03c3bb5f843cbda7382b5618de82a74adb779393) and retried this issue. It’s still failing with the same error:

--- FAIL: TestGdbAutotmpTypes (2.12s)
        runtime-gdb_test.go:55: gdb version 7.12
        runtime-gdb_test.go:379: could not find struct []main.astruct; in 'info typrs astruct' output
        runtime-gdb_test.go:380: gdb output:
                No symbol "startup" in current context.
                ../../gdb-7.12/gdb/buildsym.c:1773: internal-error: void buildsym_init(): Assertion `free_pendings == NULL' failed.
                A problem internal to GDB has been detected,
                further debugging may prove unreliable.
                Quit this debugging session? (y or n) [answered Y; input not from terminal]

                This is a bug, please report it.  For instructions, see:
                <http://www.gnu.org/software/gdb/bugs/>.

                ../../gdb-7.12/gdb/buildsym.c:1773: internal-error: void buildsym_init(): Assertion `free_pendings == NULL' failed.
                A problem internal to GDB has been detected,
                further debugging may prove unreliable.
                Create a core file of GDB? (y or n) [answered Y; input not from terminal]

                This application has requested the Runtime to terminate it in an unusual way.
                Please contact the application's support team for more information.
--- FAIL: TestGdbBacktrace (2.56s)
        runtime-gdb_test.go:55: gdb version 7.12
        runtime-gdb_test.go:310: could not find '#0.*main\.eee' in backtrace
        runtime-gdb_test.go:311: gdb output:
                No symbol "startup" in current context.
                ../../gdb-7.12/gdb/buildsym.c:1773: internal-error: void buildsym_init(): Assertion `free_pendings == NULL' failed.
                A problem internal to GDB has been detected,
                further debugging may prove unreliable.
                Quit this debugging session? (y or n) [answered Y; input not from terminal]

                This is a bug, please report it.  For instructions, see:
                <http://www.gnu.org/software/gdb/bugs/>.

                ../../gdb-7.12/gdb/buildsym.c:1773: internal-error: void buildsym_init(): Assertion `free_pendings == NULL' failed.
                A problem internal to GDB has been detected,
                further debugging may prove unreliable.
                Create a core file of GDB? (y or n) [answered Y; input not from terminal]

                This application has requested the Runtime to terminate it in an unusual way.
                Please contact the application's support team for more information.

tobiaskohlbau on Sep 2, 2017

I’m also on windows and encountered a similar behavior when compiling go from source. The tests TestGdbBacktrace and TestGdbAutompTypes fail to run after compilation, with the exact same internal gdb error as posted here. After the suggestion by Alex Brainman that gdb 7.8 works for him I downloaded an old gdb and was able to confirm this on my machine. In the first try I got GNU gdb (GDB) 7.9.1 which states in the release notes:

Changes in this release include: Python scripting enhancements. Source code compilation and injection into the inferior. New commands, options, convenience variables/options. MIPS SDE support (mips*-sde*-elf*). Better handling of signals when debugging threaded programs.

Within the go documentation there exists the comment that go makes use of a extension for gdb. As I’m not familiar with GDB and the extension possibility I would like to give this information as a starting point for other people to debug this error.

Edit: As suggested by mvdan I tried to build 1.8 release branch but got the exact same problem. So it’s not a bug which was introduced by go 1.9 itself.

tobiaskohlbau on Aug 14, 2017