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

gollvm: crash llvm-goc with SIGSEGV #35586

Closed
heylinn opened this issue Nov 14, 2019 · 6 comments
Assignees

Comments

@heylinn
Copy link

@heylinn heylinn commented Nov 14, 2019

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

$ go version
go version go1.13 gollvm LLVM 10.0.0svn linux/amd64

Does this issue reproduce with the latest release?

Yes

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

$ uname -o -m
x86_64 GNU/Linux

What did you do?

I tried to build a client for docker.

There are a few steps to reproduce the error:

$ git clone https://github.com/docker/docker-ce.git
$ cd docker-ce
$ git checkout v19.03.4
$ cd components
$ mkdir -p .gopath/src/github.com/docker
$ export GOPATH=`pwd`/.gopath:~/go
$ ln -sf `pwd`/cli .gopath/src/github.com/docker/cli
$ cd .gopath/src/github.com/docker/cli/
$ go build ./vendor/github.com/docker/docker/client

What did you expect to see?

Clean compilation

What did you see instead?

Compiler crash:
Program received signal SIGSEGV, Segmentation fault.
0x0000555555af7d97 in Bfunction::getParameterVars() ()
(gdb) bt
#0  0x0000555555af7d97 in Bfunction::getParameterVars() ()
#1  0x0000555555b0bc67 in DIBuildHelper::endFunction(Bfunction*) ()
#2  0x0000555555aa2348 in Llvm_backend::function_set_body(Bfunction*, Bstatement*) ()
#3  0x0000555555a11c71 in Function::build(Gogo*, Named_object*) ()
#4  0x0000555555a13efc in Named_object::get_backend(Gogo*, std::vector >&, std::vector >&, std::vector >&) ()
#5  0x0000555555a1ef09 in Gogo::write_globals() ()
#6  0x00005555559e9278 in gollvm::driver::CompileGoImpl::invokeFrontEnd() ()
#7  0x00005555559f08e5 in gollvm::driver::CompileGoImpl::performAction(gollvm::driver::Compilation&, gollvm::driver::Action const&, llvm::SmallVector const&, gollvm::driver::Artifact const&) ()
#8  0x00005555559e4863 in gollvm::driver::Driver::processAction(gollvm::driver::Action*, gollvm::driver::Compilation&, bool) ()
#9  0x00005555559e4a47 in gollvm::driver::Driver::processActions(gollvm::driver::Compilation&) ()
#10 0x000055555595cb2f in main ()
@thanm

This comment has been minimized.

Copy link
Member

@thanm thanm commented Nov 14, 2019

I'll take a look.

@thanm thanm self-assigned this Nov 14, 2019
@thanm

This comment has been minimized.

Copy link
Member

@thanm thanm commented Nov 14, 2019

This I think is actually a front end oddity (gcc backend doesn't mind but it causes issues with gollvm).

Reduced testcase:

Package "a"

package a

var Avar int

func D(_ string, _ int) (uint64, string) {
	return 101, "bad"
}

Package "b":

package b

import "a"

func F(addr string) (uint64, string) {
	return a.D(addr, 32)
}

I will send a tentative fix shortly.

@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Nov 14, 2019

Change https://golang.org/cl/207258 mentions this issue: test: new test for gollvm compiler crash bug

@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Nov 14, 2019

Change https://golang.org/cl/207259 mentions this issue: compiler: fix buglet in function inlining related to sink names

@thanm

This comment has been minimized.

Copy link
Member

@thanm thanm commented Nov 14, 2019

@heylinn Thank you for reporting this bug. I have a fix out for review.

kraj pushed a commit to kraj/gcc that referenced this issue Nov 15, 2019
    
    When the compiler writes an inlinable function to the export data,
    parameter names are written out (in Export::write_name) using the
    Gogo::message_name as opposed to a raw/encoded name. This means that
    sink parameters (those named "_") get created with the name "_"
    instead of "._" (the name created by the lexer/parser). This confuses
    Gogo::is_sink_name, which looks for the latter sequence and not just
    "_". This can cause issues later on if an inlinable function is
    imported and fed through the rest of the compiler (things that are
    sinks are no recognized as such). To fix these issues, change
    Gogo::is_sink_name to return true for either variants ("_" or "._").
    
    Fixes golang/go#35586.
    
    Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/207259


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@278275 138bc75d-0d04-0410-961f-82ee72b054a4
@heylinn

This comment has been minimized.

Copy link
Author

@heylinn heylinn commented Nov 15, 2019

Thank you! I am impressed how fast you fixed it.

emsr added a commit to emsr/gcc that referenced this issue Nov 15, 2019
    
    When the compiler writes an inlinable function to the export data,
    parameter names are written out (in Export::write_name) using the
    Gogo::message_name as opposed to a raw/encoded name. This means that
    sink parameters (those named "_") get created with the name "_"
    instead of "._" (the name created by the lexer/parser). This confuses
    Gogo::is_sink_name, which looks for the latter sequence and not just
    "_". This can cause issues later on if an inlinable function is
    imported and fed through the rest of the compiler (things that are
    sinks are no recognized as such). To fix these issues, change
    Gogo::is_sink_name to return true for either variants ("_" or "._").
    
    Fixes golang/go#35586.
    
    Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/207259


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@278275 138bc75d-0d04-0410-961f-82ee72b054a4
gopherbot pushed a commit that referenced this issue Nov 18, 2019
Reduced test case for gollvm compiler crash building docker-ce.

Updates #35586.

Change-Id: Ib805dc9ab7b63cc61f207f1f000bef9809cfd428
Reviewed-on: https://go-review.googlesource.com/c/go/+/207258
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.