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/link: unable to initialize decompress status for section .debug_info after Go 1.15.3 #42136

Closed
xiekeyi98 opened this issue Oct 22, 2020 · 12 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.

Comments

@xiekeyi98
Copy link

xiekeyi98 commented Oct 22, 2020

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

before ` go version go1.15.2 linux/amd64 `
after `go version go1.15.3 linux/amd64`

Does this issue reproduce with the latest release?

yep.

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

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/keyixie/.cache/go-build"
GOENV="/home/keyixie/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/keyixie/dev/pkg/mod"
GONOPROXY="git.code.oa.com"
GONOSUMDB="git.code.oa.com"
GOOS="linux"
GOPATH="/home/keyixie/dev"
GOPRIVATE="git.code.oa.com"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/keyixie/go/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/keyixie/go/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/keyixie/dev/src/git.code.oa.com/iotvideo_appuser/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build034162450=/tmp/go-build -gno-record-gcc-switches"

What did you do?

go test ./... ( go build also can occur )

What did you expect to see?

image

What did you see instead?

image


/home/keyixie/go/go1.15.3/pkg/tool/linux_amd64/link: running gcc failed: exit status 1
/bin/ld: /tmp/go-link-815997864/000005.o: unable to initialize decompress status for section .debug_info
/bin/ld: /tmp/go-link-815997864/000005.o: unable to initialize decompress status for section .debug_info
/tmp/go-link-815997864/000005.o: file not recognized: 不可识别的文件格式
collect2: 错误:ld 返回 1

I'm sorry I haven't found a code snippet that reproduces reliably yet.
I would like to know if anyone has reported similar problems?
If there is anything I can help with for confirmation, I will add further information later.

@xiekeyi98 xiekeyi98 changed the title unable to initialize decompress status for section .debug_info @ go 1.13 unable to initialize decompress status for section .debug_info @ go 1.15.3 Oct 22, 2020
@dmitshur
Copy link
Contributor

CC @ianlancetaylor, @cherrymui.

@dmitshur dmitshur added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Oct 26, 2020
@dmitshur dmitshur changed the title unable to initialize decompress status for section .debug_info @ go 1.15.3 cmd/link: unable to initialize decompress status for section .debug_info after Go 1.15.3 Oct 26, 2020
@dmitshur
Copy link
Contributor

running gcc failed

What is the GCC version that was used?

@thanm
Copy link
Contributor

thanm commented Oct 27, 2020

Seems pretty surprising-- between Go 1.15.2 and Go 1.15.3 I don't see any changes related to DWARF generation or linker DWARF compression.

不可识别的文件格式 is "unrecognized file format" -- that says that the header was bad for the compressed section I think.

Something that is also a puzzle is that "go test" builds with "-w", meaning that there should not be any DWARF generated at all (compressed or not). Hmm.

One thing that would help diagnose this: rerun your "go test" with additional options to capture the temporary object files, then run dump the DWARF in the offending file. Something like

$ mkdir /tmp/xxx
$ go test -ldflags=-tmpdir=/tmp/xxx  [... remaining 'go test' options ]

Then when you get the "/bin/ld: /tmp/xxx/000005.o: unable to initialize decompress status for section .debug_info" error, try running

$ objdump --dwarf=info /tmp/xxx/000005.o | egrep '(DW_AT_producer|DW_AT_name)' | head -5

That might tell us more about where the offending DWARF is coming from.

@cherrymui
Copy link
Member

cherrymui commented Oct 27, 2020

I think files like 000005.o is not an object file from Go code. It is an object file from C code (handwritten or cgo generated). (That's why it has debug info even when -w is applied.)

@thanm thanm added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Oct 27, 2020
@xiekeyi98
Copy link
Author

running gcc failed

What is the GCC version that was used?

gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

@xiekeyi98
Copy link
Author

Sorry for taking up your time.
Unfortunately, due to /tmp being cleaned up, I didn't succeed in reproduce it again.
I'm guessing it has something to do with cgo or the history file in /tmp.
I closed the issue for now and will reopen it if I got it again.
Thank you all for your help and tips.

@ianlancetaylor
Copy link
Contributor

Thanks for following up.

@xiekeyi98
Copy link
Author

Fortunately, I had the same problem with another similar project.

image

objdump --dwarf=info ./000000.o | egrep '(DW_AT_producer|DW_AT_name)' | head -5
objdump: ./000000.o: unable to initialize decompress status for section .debug_info
objdump: ./000000.o: unable to initialize decompress status for section .debug_info
objdump: ./000000.o: File format not recognized

This is the file about folder.
bugReport.zip

@xiekeyi98 xiekeyi98 reopened this Oct 27, 2020
@thanm
Copy link
Contributor

thanm commented Oct 27, 2020

Thanks for posting the zip'ed folder with the intermediates.

For the record, when I run objdump (from my Debian work machine) on the object file from the zip file, it doesn't seem to have any problems with it:

$ objdump --dwarf=info ./000000.o | egrep '(DW_AT_producer|DW_AT_name)' | head -5
    <c>   DW_AT_producer    : (indirect string, offset: 0x8b): GNU C 4.8.5 20150623 (Red Hat 4.8.5-39)
    <11>   DW_AT_name        : (indirect string, offset: 0xd9): _cgo_export.c
...

In addition, looking at the object file itself, I don't see any compressed debug-- so this looks to me like some sort of problem with the binutils tools (objdump, ld) on your system.

As @cherrymui pointed out, the object file in question is being produced by gcc, and the error is triggered when the object file is read by the system linker (/bin/ld), so it does not seem at all clear that this is a problem with Go.

@ianlancetaylor
Copy link
Contributor

What version of the C linker are you using? That is, what is the output of /bin/ld --version?

Also, what version of the C assembler are you using? What is the output of as --version? You may be running into https://sourceware.org/bugzilla/show_bug.cgi?id=23919.

@xiekeyi98
Copy link
Author

image

md5sum ./000000.o 
658185dc80a44dada9ded0b003d6b208  ./000000.o

/bin/ld --version
GNU ld version 2.27-41.base.tl2.1
Copyright (C) 2016 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.


as --version
GNU assembler version 2.27-41.base.tl2.1
Copyright (C) 2016 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-redhat-linux'.


gcc --version                                 
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

The above is relevant information, thanks for your help.
I wonder if it's because I have a special version of linux (https://github.com/Tencent/TencentOS-kernel#tencentos-server-kernel), it's a GNU related bug, not golang related.

@dmitshur dmitshur removed the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Oct 28, 2020
@ianlancetaylor
Copy link
Contributor

Yes, I think this is a bug that was fixed in GNU binutils 2.32, and you are running 2.27.

Closing because I don't think this is a bug that we can fix in Go. Please comment if you disagree.

@golang golang locked and limited conversation to collaborators Oct 28, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

6 participants