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.

Sign up for GitHub

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

Jump to bottom

debug/elf: nil pointer dereference when opening os.Executable() #54227

Closed
ulrichSchreiner opened this issue Aug 3, 2022 · 3 comments
Closed

debug/elf: nil pointer dereference when opening os.Executable() #54227

ulrichSchreiner opened this issue Aug 3, 2022 · 3 comments
Assignees
@cherrymui
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Go1.20

Comments

@ulrichSchreiner
Copy link

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

❯ go version
go version go1.19 linux/amd64

Does this issue reproduce with the latest release?

Yes, only with 1.19

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

go env Output
$ go env
GOARCH="amd64"
GOOS="linux"

What did you do?

Compile a oneliner with the library github.com/GeertJohan/go.rice . the binary crashes when starting. Without the import everything is ok. My code works since many years with this library, but with 1.19 every binary crashes immediatly

package main

import (
        "fmt"
        _ "github.com/GeertJohan/go.rice"
)
func main () {
        fmt.Printf("Hello\n")
}

What did you expect to see?

The output Hello

What did you see instead?

❯ go build
❯ ./ricetest
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x4c34e6]

goroutine 1 [running]:
debug/elf.(*Section).ReadAt(0xc0001d2000?, {0xc0000fe480?, 0x270?, 0x24?}, 0x40?)
        <autogenerated>:1 +0x26
archive/zip.readDirectoryEnd({0x5e4d40, 0xc0000fad00}, 0x210)
        /usr/local/go/src/archive/zip/reader.go:526 +0xf5
archive/zip.(*Reader).init(0xc0000e6a10, {0x5e4d40?, 0xc0000fad00}, 0x210)
        /usr/local/go/src/archive/zip/reader.go:97 +0x5c
archive/zip.NewReader({0x5e4d40, 0xc0000fad00}, 0x210)
        /usr/local/go/src/archive/zip/reader.go:90 +0x5e
github.com/daaku/go%2ezipexe.zipExeReaderElf({0x5e5040?, 0xc000014048}, 0x42afb5)
        /home/usc/go/pkg/mod/github.com/daaku/go.zipexe@v1.0.0/zipexe.go:128 +0x8b
github.com/daaku/go%2ezipexe.NewReader({0x5e5040, 0xc000014048}, 0x0?)
        /home/usc/go/pkg/mod/github.com/daaku/go.zipexe@v1.0.0/zipexe.go:48 +0x98
github.com/daaku/go%2ezipexe.OpenCloser({0xc00001a440?, 0xc0000c7d10?})
        /home/usc/go/pkg/mod/github.com/daaku/go.zipexe@v1.0.0/zipexe.go:30 +0x57
github.com/GeertJohan/go%2erice.init.0()
        /home/usc/go/pkg/mod/github.com/!geert!johan/go.rice@v1.0.2/appended.go:42 +0x65

Using go 1.18 works fine. but with 1.19 the program crashes in the init function of the library. Perhaps the library is buggy, but there seems to be some incompatiblities
@cuonglm
Copy link
Member

cuonglm commented Aug 3, 2022

Seems relate to https://go-review.googlesource.com/c/go/+/380755

cc @mengzhuo @cherrymui

@cuonglm cuonglm added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Aug 3, 2022
@seankhliao seankhliao changed the title Crash with hello-world when using go 1.19 debug/elf: nil pointer dereference when opening os.Executable() Aug 3, 2022
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Aug 3, 2022
@dmitshur
Copy link
Contributor

dmitshur commented Aug 3, 2022

CC @golang/compiler.

@dmitshur dmitshur added this to the Go1.20 milestone Aug 3, 2022
@ianlancetaylor
Copy link
Contributor

The code in the zipexe package assumes that every ELF section is a valid io.ReaderAt. However, according to https://pkg.go.dev/debug/elf#Section this is not true for a section that contains compressed data. That comment has been there since 2015, so it's not new.

So I think this is a bug in the zipexe package: it is making an assumption that the docs do not guarantee. I don't see any simple way to fix this, so closing. Sorry.

@ianlancetaylor ianlancetaylor closed this as not planned Won't fix, can't repro, duplicate, stale Aug 3, 2022
This was referenced Aug 4, 2022
Merged
Closed
42wim added a commit to 42wim/go.zipexe that referenced this issue Aug 6, 2022
@42wim
Fix for rice with go1.19 which appends the zip at the end of the binary
85f957d 
Quickfix for golang/go#54227 until we migrate
to go embed
@pkorovin pkorovin mentioned this issue Sep 16, 2022
Closed
@Nativu5 Nativu5 mentioned this issue Nov 6, 2022
Closed
@bits01 bits01 mentioned this issue Nov 7, 2022
Closed
daaku added a commit to daaku/go.zipexe that referenced this issue Nov 9, 2022
@daaku
ignore elf sections without ReaderAt
db143eb 
Ignore sections that are compressed. There may be a more elaborate fix
using `Section.Open`, but this should be sufficient. It's likely now
with `embed` usage of this package will be going down.

Fixes #6.
See golang/go#54227 for more context.
@rigazilla rigazilla mentioned this issue May 22, 2023
Merged
@golang golang locked and limited conversation to collaborators Aug 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@cherrymui cherrymui

Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Go1.20
Development

No branches or pull requests
6 participants
@ulrichSchreiner @dmitshur @ianlancetaylor @cuonglm @gopherbot @cherrymui