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

gccgo: go-7 crashes immediately on s390x (and other big endian architectures) #21972

Closed
mwhudson opened this issue Sep 21, 2017 · 3 comments
Closed

gccgo: go-7 crashes immediately on s390x (and other big endian architectures) #21972

mwhudson opened this issue Sep 21, 2017 · 3 comments
Labels
FrozenDueToAge
Milestone
Gccgo

Comments

@mwhudson
Copy link
Contributor

From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876353 with some extra details

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

gccgo 7.2.0-5 as compiled by Debian

Does this issue reproduce with the latest release?

It does not reproduce with gcc-snapshot 20170917-1 as compiled by debian.

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

Debian sid on s390x

What did you do?

Run go-7

What did you expect to see?

The help output.

What did you see instead?

(sid_s390x-dchroot)mwhudson@zelenka:~$ go-7
Segmentation fault
@gopherbot gopherbot added this to the Gccgo milestone Sep 21, 2017
@mwhudson
Copy link
Contributor Author

This is the backtrace as reported by gdb:

(gdb) bt
#0  0x000003fffc2a2338 in ?? () from /lib/s390x-linux-gnu/libc.so.6
#1  0x000003fffd601800 in elf_find_debugfile_by_debuglink (data=<optimized out>, error_callback=<optimized out>, debuglink_name=<optimized out>, 
    filename=0x2020202020202020 <error: Cannot access memory at address 0x2020202020202020>, state=<optimized out>) at ../../../src/libbacktrace/elf.c:862
#2  elf_open_debugfile_by_debuglink (data=<optimized out>, error_callback=<optimized out>, debuglink_crc=<optimized out>, debuglink_name=<optimized out>, 
    filename=<optimized out>, state=<optimized out>) at ../../../src/libbacktrace/elf.c:923
#3  elf_add (state=0x3fffdfb1000, filename=filename@entry=0x2020202020202020 <error: Cannot access memory at address 0x2020202020202020>, 
    descriptor=<optimized out>, base_address=2929167695872, error_callback=error_callback@entry=0x3fffd0e23f0 <error_callback>, data=<optimized out>, 
    fileline_fn=0x3ffffffde50, found_sym=0x3ffffffe020, found_dwarf=0x3ffffffde4c, exe=0, debuginfo=0) at ../../../src/libbacktrace/elf.c:1295
#4  0x000003fffd6021be in phdr_callback (info=0x3ffffffdf10, size=<optimized out>, pdata=0x3ffffffe030) at ../../../src/libbacktrace/elf.c:1453
#5  0x000003fffc344990 in dl_iterate_phdr () from /lib/s390x-linux-gnu/libc.so.6
#6  0x000003fffd60233a in backtrace_initialize (state=state@entry=0x3fffdfb1000, filename=filename@entry=0x3fffd8082cc "/proc/self/exe", 
    descriptor=<optimized out>, error_callback=error_callback@entry=0x3fffd0e23f0 <error_callback>, data=data@entry=0x3ffffffe8d8, fileline_fn=0x3ffffffe120)
    at ../../../src/libbacktrace/elf.c:1495
#7  0x000003fffd600010 in fileline_initialize (state=state@entry=0x3fffdfb1000, error_callback=error_callback@entry=0x3fffd0e23f0 <error_callback>, 
    data=data@entry=0x3ffffffe8d8) at ../../../src/libbacktrace/fileline.c:136
#8  0x000003fffd600078 in backtrace_pcinfo (state=0x3fffdfb1000, pc=4397997106389, callback=0x3fffd0e2150 <callback>, 
    error_callback=0x3fffd0e23f0 <error_callback>, data=data@entry=0x3ffffffe8d8) at ../../../src/libbacktrace/fileline.c:170
#9  0x000003fffd6006f0 in unwind (context=<optimized out>, vdata=0x3ffffffe808) at ../../../src/libbacktrace/backtrace.c:91
#10 0x000003fffc10b0b2 in _Unwind_Backtrace () from /lib/s390x-linux-gnu/libgcc_s.so.1
#11 0x000003fffd600776 in backtrace_full (state=0x3fffdfb1000, skip=skip@entry=0, callback=callback@entry=0x3fffd0e2150 <callback>, 
    error_callback=error_callback@entry=0x3fffd0e23f0 <error_callback>, data=data@entry=0x3ffffffe8d8) at ../../../src/libbacktrace/backtrace.c:127
#12 0x000003fffd0e24d6 in runtime_callers (skip=skip@entry=4, locbuf=locbuf@entry=0x3ffffffe9e8, m=m@entry=32, keep_thunks=keep_thunks@entry=false)
    at ../../../src/libgo/runtime/go-callers.c:170
#13 0x000003fffd559672 in runtime.callers (skip=4, locbuf=...) at ../../../src/libgo/go/runtime/traceback_gccgo.go:63
#14 runtime.mProf_Malloc (p=<optimized out>, p@entry=0xc208000000, size=size@entry=1536) at ../../../src/libgo/go/runtime/mprof.go:254
#15 0x000003fffd0f1e52 in runtime_profilealloc (size=1536, v=0xc208000000) at ../../../src/libgo/runtime/malloc.goc:308
#16 runtime_mallocgc (size=1536, size@entry=1432, typ=typ@entry=4398009065360, flag=0) at ../../../src/libgo/runtime/malloc.goc:245
#17 0x000003fffd0e303e in __go_new (td=td@entry=0x3fffdc49f90 <__go_tdn_runtime..runtime.g>, size=size@entry=1432) at ../../../src/libgo/runtime/go-new.c:15
#18 0x000003fffd53dac0 in runtime.allocg () at ../../../src/libgo/go/runtime/stubs.go:514
#19 0x000003fffd0f07f4 in runtime.malg (allocatestack=allocatestack@entry=true, signalstack=signalstack@entry=true, 
    ret_stack=ret_stack@entry=0x3fffde98560 <runtime_m0+1960>, ret_stacksize=ret_stacksize@entry=0x3fffde98568 <runtime_m0+1968>)
    at ../../../src/libgo/runtime/proc.c:1349
#20 0x000003fffd54bd0a in runtime.mpreinit (mp=0x3fffde97db8 <runtime_m0>) at ../../../src/libgo/go/runtime/os_gccgo.go:17
#21 runtime.mcommoninit (mp=mp@entry=0x3fffde97db8 <runtime_m0>) at ../../../src/libgo/go/runtime/proc.go:241
#22 0x000003fffd0efbe2 in runtime_schedinit () at ../../../src/libgo/runtime/proc.c:490
#23 0x000002aa000451e8 in main ()
#24 0x000003fffc2228c2 in __libc_start_main () from /lib/s390x-linux-gnu/libc.so.6
#25 0x000002aa00045264 in ?? ()
PC not saved

It looks like the allocation profiling is calling runtime.callers which is using libunwind which is exploding?

@ianlancetaylor
Copy link
Contributor

This looks like another version of https://gcc.gnu.org/PR82284, which was caused by backporting a recent libbacktrace change of mine from GCC trunk to Debian's GCC 7 branch. I've already committed a patch, to GCC trunk, to fix that problem.

@mwhudson
Copy link
Contributor Author

Oh yes, Matthias pinged me about it and I reported it here before I realized he'd reported in bugzilla already. Sorry for the noise!

@golang golang locked and limited conversation to collaborators Sep 21, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Gccgo
Development

No branches or pull requests
3 participants
@mwhudson @ianlancetaylor @gopherbot