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

runtime: reflect units tests trigger SIGSEGV #7159

Closed
davecheney opened this issue Jan 21, 2014 · 15 comments
Closed

runtime: reflect units tests trigger SIGSEGV #7159

davecheney opened this issue Jan 21, 2014 · 15 comments
Milestone

Comments

@davecheney
Copy link
Contributor

What steps will reproduce the problem?

Several recent build failures point to a bug in parallel garbage collection.

SIGSEGV: segmentation violation
PC=0x40dd34

scanblock(0x800a79000, 0x800a79030, 0x1, 0x7fffffffd900)
    /tmp/gobuilder/freebsd-amd64-5cfa2c933b76/go/src/pkg/runtime/mgc0.c:927 +0x8a4
markroot(0xc210026000, 0x11)
    /tmp/gobuilder/freebsd-amd64-5cfa2c933b76/go/src/pkg/runtime/mgc0.c:1261 +0xad
runtime.parfordo(0xc210026000)
    /tmp/gobuilder/freebsd-amd64-5cfa2c933b76/go/src/pkg/runtime/parfor.c:105 +0xa3
gc(0x800a6f5c0)
    /tmp/gobuilder/freebsd-amd64-5cfa2c933b76/go/src/pkg/runtime/mgc0.c:2284 +0x267
mgc(0xc210001dc0)
    /tmp/gobuilder/freebsd-amd64-5cfa2c933b76/go/src/pkg/runtime/mgc0.c:2222 +0x2e
runtime.mcall(0x424547)
    /tmp/gobuilder/freebsd-amd64-5cfa2c933b76/go/src/pkg/runtime/asm_amd64.s:181 +0x4b


Please use labels and text to provide additional information.

So far this appears to affect *BSD derived operating systems, Linux and Windows appears
unaffected so far.

http://build.golang.org/log/f26408714eca0f791fcf68110b15dde6b08c56d0
http://build.golang.org/log/4729d4c556fae522008bf22fa5a85dcd4e1a0a80
http://build.golang.org/log/ca81af64cc62ddfb0c775f5533d46cc276fda151
@dvyukov
Copy link
Member

dvyukov commented Jan 21, 2014

Comment 1:

The lines point to iface/eface scanning. GC is quite vulnerable to heap corruption in
that place, because it tries to treat the first word as Type/Itab.
I suspect that it has something to do with recent liveness changes.
I see that freebsd also uses uintptr's as pointer in syscall package:
../syscall/syscall_freebsd_386.go:func Syscall9(num, a1, a2, a3, a4, a5, a6, a7, a8, a9
uintptr) (r1, r2 uintptr, err Errno) // sic
../syscall/syscall_freebsd_amd64.go:func Syscall9(num, a1, a2, a3, a4, a5, a6, a7, a8,
a9 uintptr) (r1, r2 uintptr, err Errno)
../syscall/syscall_freebsd_arm.go:func Syscall9(num, a1, a2, a3, a4, a5, a6, a7, a8, a9
uintptr) (r1, r2 uintptr, err Errno) // sic
../syscall/zsyscall_freebsd_386.go:func bind(s int, addr uintptr, addrlen _Socklen) (err
error) {
../syscall/zsyscall_freebsd_386.go:func connect(s int, addr uintptr, addrlen _Socklen)
(err error) {
../syscall/zsyscall_freebsd_386.go:func getsockopt(s int, level int, name int, val
uintptr, vallen *_Socklen) (err error) {
../syscall/zsyscall_freebsd_386.go:func setsockopt(s int, level int, name int, val
uintptr, vallen uintptr) (err error) {
../syscall/zsyscall_freebsd_386.go:func sendto(s int, buf []byte, flags int, to uintptr,
addrlen _Socklen) (err error) {
../syscall/zsyscall_freebsd_386.go:func kevent(kq int, change uintptr, nchange int,
event uintptr, nevent int, timeout *Timespec) (n int, err error) {
../syscall/zsyscall_freebsd_386.go:func sysctl(mib []_C_int, old *byte, oldlen *uintptr,
new *byte, newlen uintptr) (err error) {
../syscall/zsyscall_freebsd_386.go:func Getdirentries(fd int, buf []byte, basep
*uintptr) (n int, err error) {
../syscall/zsyscall_freebsd_386.go:func mmap(addr uintptr, length uintptr, prot int,
flag int, fd int, pos int64) (ret uintptr, err error) {
../syscall/zsyscall_freebsd_386.go:func munmap(addr uintptr, length uintptr) (err error)
{
../syscall/zsyscall_freebsd_amd64.go:func bind(s int, addr uintptr, addrlen _Socklen)
(err error) {
../syscall/zsyscall_freebsd_amd64.go:func connect(s int, addr uintptr, addrlen _Socklen)
(err error) {
../syscall/zsyscall_freebsd_amd64.go:func getsockopt(s int, level int, name int, val
uintptr, vallen *_Socklen) (err error) {
../syscall/zsyscall_freebsd_amd64.go:func setsockopt(s int, level int, name int, val
uintptr, vallen uintptr) (err error) {
../syscall/zsyscall_freebsd_amd64.go:func sendto(s int, buf []byte, flags int, to
uintptr, addrlen _Socklen) (err error) {
../syscall/zsyscall_freebsd_amd64.go:func kevent(kq int, change uintptr, nchange int,
event uintptr, nevent int, timeout *Timespec) (n int, err error) {
../syscall/zsyscall_freebsd_amd64.go:func sysctl(mib []_C_int, old *byte, oldlen
*uintptr, new *byte, newlen uintptr) (err error) {
../syscall/zsyscall_freebsd_amd64.go:func Getdirentries(fd int, buf []byte, basep
*uintptr) (n int, err error) {
../syscall/zsyscall_freebsd_amd64.go:func mmap(addr uintptr, length uintptr, prot int,
flag int, fd int, pos int64) (ret uintptr, err error) {
../syscall/zsyscall_freebsd_amd64.go:func munmap(addr uintptr, length uintptr) (err
error) {
../syscall/zsyscall_freebsd_arm.go:func bind(s int, addr uintptr, addrlen _Socklen) (err
error) {
../syscall/zsyscall_freebsd_arm.go:func connect(s int, addr uintptr, addrlen _Socklen)
(err error) {
../syscall/zsyscall_freebsd_arm.go:func getsockopt(s int, level int, name int, val
uintptr, vallen *_Socklen) (err error) {
../syscall/zsyscall_freebsd_arm.go:func setsockopt(s int, level int, name int, val
uintptr, vallen uintptr) (err error) {
../syscall/zsyscall_freebsd_arm.go:func sendto(s int, buf []byte, flags int, to uintptr,
addrlen _Socklen) (err error) {
../syscall/zsyscall_freebsd_arm.go:func kevent(kq int, change uintptr, nchange int,
event uintptr, nevent int, timeout *Timespec) (n int, err error) {
../syscall/zsyscall_freebsd_arm.go:func sysctl(mib []_C_int, old *byte, oldlen *uintptr,
new *byte, newlen uintptr) (err error) {
../syscall/zsyscall_freebsd_arm.go:func Getdirentries(fd int, buf []byte, basep
*uintptr) (n int, err error) {
../syscall/zsyscall_freebsd_arm.go:func mmap(addr uintptr, length uintptr, prot int,
flag int, fd int, pos int64) (ret uintptr, err error) {
../syscall/zsyscall_freebsd_arm.go:func munmap(addr uintptr, length uintptr) (err error)
{

@davecheney
Copy link
Contributor Author

Comment 2:

Thanks for looking at the problem Dmitry.
When you talk about uintptrs, how is this different from other operating systems like
linux ?
func mount(source string, target string, fstype string, flags uintptr, data *byte) (err
error) {
func Times(tms *Tms) (ticks uintptr, err error) {
func munmap(addr uintptr, length uintptr) (err error) {
func bind(s int, addr uintptr, addrlen _Socklen) (err error) {
func connect(s int, addr uintptr, addrlen _Socklen) (err error) {
func getsockopt(s int, level int, name int, val uintptr, vallen *_Socklen) (err error) {
func setsockopt(s int, level int, name int, val uintptr, vallen uintptr) (err error) {
func sendto(s int, buf []byte, flags int, to uintptr, addrlen _Socklen) (err error) {
func mmap(addr uintptr, length uintptr, prot int, flags int, fd int, offset int64)
(xaddr uintptr, err error) {
Are we just lucky ?

@dvyukov
Copy link
Member

dvyukov commented Jan 21, 2014

Comment 3:

Looking at the dashboard state it does not seem that we are especially lucky :)
Russ knows more about liveness. But as far as I understand uintptr parameters do not
keep objects alive anymore.
Frequently you keep another pointer to the object, e.g. for getsockopt you want to read
the returned value. Mmap does not qualify here because it does not operate on Go heap
memory. And in the end if GC is not triggered in the small windows, then you are lucky
as well. So there are reasons why this can work "reasonably stable".

@dvyukov
Copy link
Member

dvyukov commented Jan 21, 2014

@davecheney
Copy link
Contributor Author

Comment 5:

> Here you go :)
> http://build.golang.org/log/6c7cf21100a770254708b1abb53d860151a52577
Yay, my favorite, a build failure.

@kortschak
Copy link
Contributor

Comment 6:

Also previously for another data point:
https://groups.google.com/d/topic/golang-dev/clkLoSibF9s/discussion

@bradfitz
Copy link
Contributor

Comment 7:

WIP CL to address uintptrs that should be unsafe.Pointer:
https://golang.org/cl/55410043
If that looks like the right approach, I can finish it and test build on all OS/ARCH
combinations. Let me know.

@rsc
Copy link
Contributor

rsc commented Jan 22, 2014

Comment 8:

looks good so far. commented on the CL. thanks.

@rsc
Copy link
Contributor

rsc commented Jan 22, 2014

Comment 9:

What does setsockopt have to do with these logs? Every single one is a crash in
reflect.test.

@bradfitz
Copy link
Contributor

Comment 10:

Sorry, I meant to address build breakage "dragonfly-386 broken by runtime: fix specials
deadlock" and too quickly thought this was the bug about that.
I'll remove the "Update Issue NNN" line from the CL before I submit.

@davecheney
Copy link
Contributor Author

@ianlancetaylor
Copy link
Contributor

Comment 12:

Issue #7273 has been merged into this issue.

@rsc
Copy link
Contributor

rsc commented Mar 25, 2014

Comment 13:

Is this still happening? If not let's close it.

@dvyukov
Copy link
Member

dvyukov commented Mar 25, 2014

Comment 14:

There was one on linux-race builder:
http://build.golang.org/log/370a1f515e9904f35f8b975c85253b0ab9472efa
on
https://code.google.com/p/go/source/detail?r=fcfdb8a7aa645bcaf86a351326a4a44f4105eeeb
this is after all known crasher fixes.

@rsc
Copy link
Contributor

rsc commented Apr 3, 2014

Comment 15:

I have fixed many garbage collection bugs this week, including quite a few about
scanning of interface values, so I am closing old bugs about gc crashes without
reproduction cases. If this is still happening on Monday, once my various pending CLs
are in, then please file a new bug with a new report built from tip. Thanks.

Status changed to TimedOut.

@rsc rsc added this to the Go1.3 milestone Apr 14, 2015
@rsc rsc removed the release-go1.3 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants