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

[kjk]

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

[kjk]

The same happens for gdb 7.11.1 from http://www.msys2.org/

[New Thread 7596.0x1398]
fatal: morestack on g0
buildsym.c:1773: internal-error: buildsym_init: Assertion `free_pendings == NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

$ gdb --version
GNU gdb (GDB) 7.11.1

[mvdan]

@kjk if this worked with 1.8 and if you have the time, bisecting this to a commit made during the 1.9 cycle would be of great help.

[alexbrainman]

This works for me with GNU gdb (GDB) 7.8 and go version devel +6b6b9f69fd Wed Aug 9 05:33:09 2017 +0000 windows/amd64.
I don't have skills or time to debug gdb.

Alex

[tobiaskohlbau]

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.

[kjk]

Just noting that some dwarf fix, not necessarily related, was made: 38bd725

[dsnet]

Go 1.9 has since been released. Is this still an issue? Unfortunately, this was not placed in the right milestone, so it slipped through triaging.

[tobiaskohlbau]

I've pulled the latest changes (03c3bb5) 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.

[thanm]

FYI, it looks as though a GDB binutils bug, 18624 was filed back in 2015 for this same issue. Reported for GDB 7.9, but presumably with a version of Go that was a good deal older than 1.9. This would suggest that the problem is not specific to 1.9.

[rsc]

Given that this has been happening since 2015, not for Go 1.9.2.

[dis2]

For anyone tripping on this: A temporary workaround is to use external linker:

go build -ldflags=-linkmode=external

This seems to make gdb happy (at least on recent windows/msys2)

[gopherbot]

Change https://golang.org/cl/102419 mentions this issue: runtime: improve Windows gdb tests

[kjk]

This still happens with gdb 8.1 and go 1.11 (trunk).

I've provided more details in gdb bug tracker: https://sourceware.org/bugzilla/show_bug.cgi?id=18624#c9

[kjk]

This might be a gdb bug that only happens with COFF/PE: https://sourceware.org/ml/gdb-patches/2018-06/msg00736.html

[timou]

I believe this is fixed in gdb 8.2. It now passes for me using STL's excellent and most recent MinGW distribution.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4735f0edf4265e3e260e10a12921baf17987a020

C:\Code\go\src\runtime>go test -test.v -test.run=.*TestGdbBacktrace
=== RUN   TestGdbBacktrace
=== PAUSE TestGdbBacktrace
=== CONT  TestGdbBacktrace
--- PASS: TestGdbBacktrace (0.81s)
    runtime-gdb_test.go:66: gdb version 8.2
PASS
ok      runtime 0.880s

C:\Code\go\src\runtime>gdb -version
GNU gdb (GDB) 8.2.1
Copyright (C) 2018 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.

[dajoo75]

I'm just gonna leave this here for any poor soul on Windows who installs/updates MinGW and friends once in a blue moon or so: https://stackoverflow.com/questions/30069830/how-to-install-mingw-w64-and-msys2

[gopherbot]

Change https://go.dev/cl/470596 mentions this issue: runtime: set procid on Windows