gccgo crash on powerpc

Bug #1454183 reported by Robie Basak
28
This bug affects 3 people
Affects Status Importance Assigned to Milestone
gcc
Invalid
Medium
docker.io (Ubuntu)
Invalid
Medium
Unassigned
gcc-5 (Ubuntu)
Fix Released
High
Unassigned

Bug Description

I see panics of the form below in https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/7403985 and https://launchpad.net/ubuntu/+source/docker.io/1.6.0+dfsg1-1ubuntu1/+build/7397683 causing FTBFS for snappy and docker.io on powerpc. As these have separate Go codebases I assume this is a compiler bug?

   dh_auto_build -a -O--buildsystem=golang -O--fail-missing
fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0x3]

goroutine 16 [running]:
runtime_dopanic
 ../../../src/libgo/runtime/panic.c:131
runtime_throw
 ../../../src/libgo/runtime/panic.c:193
sig_panic_leadin
 ../../../src/libgo/runtime/go-signal.c:247
sig_panic_info_handler
 ../../../src/libgo/runtime/go-signal.c:281

 :0
__go_go
 ../../../src/libgo/runtime/proc.c:2328
runtime_main
 ../../../src/libgo/runtime/proc.c:598

goroutine 0 [idle]:
panic during panic

goroutine 0 [idle]:
runtime_dopanic
 ../../../src/libgo/runtime/panic.c:131
runtime_startpanic
 ../../../src/libgo/runtime/panic.c:100
runtime_throw
 ../../../src/libgo/runtime/panic.c:191
runtime_gogo
 ../../../src/libgo/runtime/proc.c:251
runtime_tracebackothers
 ../../../src/libgo/runtime/proc.c:767
runtime_dopanic
 ../../../src/libgo/runtime/panic.c:139
runtime_throw
 ../../../src/libgo/runtime/panic.c:193
sig_panic_leadin
 ../../../src/libgo/runtime/go-signal.c:247
sig_panic_info_handler
 ../../../src/libgo/runtime/go-signal.c:281

 :0
__go_go
 ../../../src/libgo/runtime/proc.c:2328
runtime_main
 ../../../src/libgo/runtime/proc.c:598
fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0x3]

goroutine 16 [running]:
runtime_dopanic
 ../../../src/libgo/runtime/panic.c:131
runtime_throw
 ../../../src/libgo/runtime/panic.c:193
sig_panic_leadin
 ../../../src/libgo/runtime/go-signal.c:247
sig_panic_info_handler
 ../../../src/libgo/runtime/go-signal.c:281

 :0
__go_go
 ../../../src/libgo/runtime/proc.c:2328
runtime_main
 ../../../src/libgo/runtime/proc.c:598

goroutine 0 [idle]:
panic during panic

goroutine 0 [idle]:
runtime_dopanic
 ../../../src/libgo/runtime/panic.c:131
runtime_startpanic
 ../../../src/libgo/runtime/panic.c:100
runtime_throw
 ../../../src/libgo/runtime/panic.c:191
runtime_gogo
 ../../../src/libgo/runtime/proc.c:251
runtime_tracebackothers
 ../../../src/libgo/runtime/proc.c:767
runtime_dopanic
 ../../../src/libgo/runtime/panic.c:139
runtime_throw
 ../../../src/libgo/runtime/panic.c:193
sig_panic_leadin
 ../../../src/libgo/runtime/go-signal.c:247
sig_panic_info_handler
 ../../../src/libgo/runtime/go-signal.c:281

 :0
__go_go
 ../../../src/libgo/runtime/proc.c:2328
runtime_main
 ../../../src/libgo/runtime/proc.c:598
dh_auto_build: go install -v returned exit code 2

Related branches

Robie Basak (racb)
Changed in docker.io (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
Adam Conrad (adconrad)
Changed in docker.io (Ubuntu):
status: Triaged → Invalid
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gcc-5 (Ubuntu):
status: New → Confirmed
Revision history for this message
Adam Conrad (adconrad) wrote :

This is not docker-specific. It happens for nuntium as well (see the duped bug). This is definitely a regression from gccgo-5 in vivid.

Changed in gcc-5 (Ubuntu):
importance: Undecided → High
Revision history for this message
Matthias Klose (doko) wrote :

seen already when calling go version

Revision history for this message
Robie Basak (racb) wrote :
Revision history for this message
In , Doko-v (doko-v) wrote :

"go version" on powerpc-linux-gnu works with the 5.1 release candidate, but crashes with the 5.1.0 release, and the current branch.

reverting the changes made in PR65787 fixes the issue. Seen on Ubuntu 15.04 and 15.10 systems, however I can't reproduce this in Debian unstable. Same binutils version, Debian has glibc-2.19, Ubuntu glibc-2.21. It looks like I can't reproduce this with a GCC trunk build on either platform. So I'm a bit lost ...

$ go version
fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0x3]

goroutine 16 [running]:
runtime_dopanic
        ../../../src/libgo/runtime/panic.c:131
runtime_throw
        ../../../src/libgo/runtime/panic.c:193
sig_panic_leadin
        ../../../src/libgo/runtime/go-signal.c:247
sig_panic_info_handler
        ../../../src/libgo/runtime/go-signal.c:281

        :0
__go_go
        ../../../src/libgo/runtime/proc.c:2328
runtime_main
        ../../../src/libgo/runtime/proc.c:598

goroutine 0 [idle]:
panic during panic

goroutine 0 [idle]:
runtime_dopanic
        ../../../src/libgo/runtime/panic.c:131
runtime_startpanic
        ../../../src/libgo/runtime/panic.c:100
runtime_throw
        ../../../src/libgo/runtime/panic.c:191
runtime_gogo
        ../../../src/libgo/runtime/proc.c:251
runtime_tracebackothers
        ../../../src/libgo/runtime/proc.c:767
runtime_dopanic
        ../../../src/libgo/runtime/panic.c:139
runtime_throw
        ../../../src/libgo/runtime/panic.c:193
sig_panic_leadin
        ../../../src/libgo/runtime/go-signal.c:247
sig_panic_info_handler
        ../../../src/libgo/runtime/go-signal.c:281

        :0
__go_go
        ../../../src/libgo/runtime/proc.c:2328
runtime_main
        ../../../src/libgo/runtime/proc.c:598

Revision history for this message
In , Doko-v (doko-v) wrote :

correction: reverting the changes from PR65787 only helps for the 5.1.0 release, not the gcc-5-branch.

Revision history for this message
In , Doko-v (doko-v) wrote :

maybe the changes from PR65787 are unrelated.

Building a compiler which has -fstack-protector strong enabled by default. The crash goes away when I add -fno-stack-protector to AM_CFLAGS in libgo. So it should be reproducible by adding -fstack-protector strong to AM_CFLAGS in libgo.

Don't know why this shows up only now, and on powerpc-linux-gnu only.

Revision history for this message
In , Boger-e (boger-e) wrote :

Let's get the obvious set up questions out of the way first...

If you are building on Ubuntu, I assume you must be trying to build powerpc64le-linux-gnu, and not powerpc-linux-gnu.

Is your LD_LIBRARY_PATH being set to the correct path for the libgo that corresponds to the go and gccgo you are using? That is, you aren't using libgo from a gcc trunk build but go and gccgo from a gcc5 build?

Revision history for this message
In , Adam Conrad (adconrad) wrote :

No, this is specifically about powerpc-linux-gnu. powerpc64le works fine.

As for the library path questions, this first came up in runtime bug reports, and has been confirmed by many on clean chroots, so no, there aren't random libraries kicking around from other builds.

doko's stack-protector discovery makes perfect sense as to why this works fine on Debian but not Ubuntu, as that's really the only difference between our two toolchains. Now, the question is *why*, and why only on ppc32? (Or maybe only on big-endian PPC, neither of us has tested a powerpc64-linux-gnu build yet).

Revision history for this message
In , Doko-v (doko-v) wrote :

building trunk libgo with -fstack-protector-strong yields:

$ go version
fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0x3]

goroutine 16 [running]:

        :0

        :0

        :0

        :0
[...]

building libgo and libbacktrace with -fstack-protector-strong yields:

fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0x3]

goroutine 16 [running]:
runtime_dopanic
        ../../../src/libgo/runtime/panic.c:131
runtime_throw
        ../../../src/libgo/runtime/panic.c:193
sig_panic_leadin
        ../../../src/libgo/runtime/go-signal.c:247
sig_panic_info_handler
        ../../../src/libgo/runtime/go-signal.c:281

        :0
__go_go
        ../../../src/libgo/runtime/proc.c:2328
runtime_main
        ../../../src/libgo/runtime/proc.c:598

goroutine 0 [idle]:
panic during panic
goroutine 0 [idle]:
runtime_dopanic
        ../../../src/libgo/runtime/panic.c:131
runtime_startpanic
        ../../../src/libgo/runtime/panic.c:100
runtime_throw
        ../../../src/libgo/runtime/panic.c:191
runtime_gogo
        ../../../src/libgo/runtime/proc.c:251
runtime_tracebackothers
        ../../../src/libgo/runtime/proc.c:767
runtime_dopanic
        ../../../src/libgo/runtime/panic.c:139
runtime_throw
        ../../../src/libgo/runtime/panic.c:193
sig_panic_leadin
        ../../../src/libgo/runtime/go-signal.c:247
sig_panic_info_handler
        ../../../src/libgo/runtime/go-signal.c:281

        :0
__go_go
        ../../../src/libgo/runtime/proc.c:2328
runtime_main
        ../../../src/libgo/runtime/proc.c:598

Revision history for this message
In , Boger-e (boger-e) wrote :

I think you've said the problem only occurs when using -fstack-protector-strong and when building with glibc-2.21.

Have you tried using gdb to see where the segv actually occurs?

>gdb go
.....

>run version
(Once it hits the segv)
>x/20ni $pc-24
>bt

The panic stacktrace is showing a line in proc.c:2328 which is making a call to __builtin_return_address according to my source. Does that match your source?

If that is the case then I have a feeling this isn't go specific, but a problem with calling __builtin_return_address on ppc32 when using -fstack-protector-strong and possibly glibc-2.21 has some affect.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gcc-5 - 5.1.1-9ubuntu2

---------------
gcc-5 (5.1.1-9ubuntu2) wily; urgency=medium

  * Merge with Debian; remaining changes:
    - Build from upstream sources.

gcc-5 (5.1.1-9) unstable; urgency=medium

  * Update to SVN 20150602 (r224029, 5.1.1) from the gcc-5-branch.
  * Remove byte-compiled libstdc++ pretty printer files on upgrade.
    Closes: #785939.
  * Fix dangling libgccjit.so symlink.
  * Fix base dependency for rtlibs stage builds.
  * Fix build failure of the hppa64 cross compiler, introduced by the
    gnat cross patches. Closes: #786692.
  * Update README.source (Michael Vogt).
  * libgo: syscall.Sendfile(): Apply proposed patch for PR go/66378.
    (Michael Vogt). LP: #1460530.
  * Set CC and CXX matching the same GCC version for the stage1 build.
  * Work around PR go/66368, build libgo with -fno-stack-protector.
    LP: #1454183.

 -- Matthias Klose <email address hidden> Wed, 03 Jun 2015 01:02:23 +0200

Changed in gcc-5 (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
In , Wschmidt-f (wschmidt-f) wrote :

FYI, PR65787 only changes behavior for powerpc64le, so it's odd that you would see any differences with or without those changes. The two patched routines are never called for big endian.

Revision history for this message
In , Rguenth (rguenth) wrote :

GCC 5.2 is being released, adjusting target milestone to 5.3.

Revision history for this message
In , Ian Lance Taylor (ianlancetaylor) wrote :

I'm not having any luck reproducing this. I built a 32-bit PPC GNU/Linux (on the GCC compile farm, which is a PPC64 machine, using glibc 2.18). I deleted the libgo files and rebuilt them with -fstack-protector-strong. I built a new go tool. It seems to work fine.

Let's try this: if you can still recreate this problem, send me the crashing binary. Maybe I can see something there.

Revision history for this message
In , Rguenth (rguenth) wrote :

GCC 5.3 is being released, adjusting target milestone.

Revision history for this message
In , Rguenth (rguenth) wrote :

GCC 5.4 is being released, adjusting target milestone.

Changed in gcc:
importance: Unknown → Medium
status: Unknown → Incomplete
Revision history for this message
In , Pinskia (pinskia) wrote :

No feedback in over 6 years so closing.

Changed in gcc:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.