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

Comments

@xiekeyi98
Copy link

@xiekeyi98 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
Member

@dmitshur dmitshur commented 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
Member

@dmitshur dmitshur commented Oct 26, 2020

running gcc failed

What is the GCC version that was used?

@thanm
Copy link
Member

@thanm 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
Contributor

@cherrymui 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.)

@xiekeyi98
Copy link
Author

@xiekeyi98 xiekeyi98 commented Oct 27, 2020

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

@xiekeyi98 xiekeyi98 commented Oct 27, 2020

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.

@xiekeyi98 xiekeyi98 closed this Oct 27, 2020
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Oct 27, 2020

Thanks for following up.

@xiekeyi98
Copy link
Author

@xiekeyi98 xiekeyi98 commented Oct 27, 2020

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
Member

@thanm 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

@ianlancetaylor ianlancetaylor commented Oct 27, 2020

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

@xiekeyi98 xiekeyi98 commented Oct 28, 2020

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.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Oct 28, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.