Skip to content

reflect: Call fails with large values because of GC program misunderstanding #8917

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

Closed
ianlancetaylor opened this issue Oct 10, 2014 · 3 comments
Milestone

Comments

@ianlancetaylor
Copy link
Member

package main

import (
    "reflect"
)

func main() {
    fv := reflect.ValueOf(func([256]*byte){})
    fv.Call([]reflect.Value{reflect.ValueOf([256]*byte{})})
}


go run foo.go

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x4398f0]

goroutine 1 [running]:
reflect.(*gcProg).appendProg(0xc20801e040, 0x459ce0)
    /home/iant/go/src/reflect/type.go:1524 +0x190
reflect.funcLayout(0x45d680, 0x0, 0x459ce0, 0x459c01, 0x7f02c6b6d4e8, 0xc20801e020)
    /home/iant/go/src/reflect/type.go:1805 +0x606
reflect.Value.call(0x45d680, 0x4975f0, 0x0, 0x130, 0x47f1a0, 0x4, 0xc20802b750, 0x1,
0x1, 0x0, ...)
    /home/iant/go/src/reflect/value.go:485 +0xeed
reflect.Value.Call(0x45d680, 0x4975f0, 0x0, 0x130, 0xc20802b750, 0x1, 0x1, 0x0, 0x0, 0x0)
    /home/iant/go/src/reflect/value.go:388 +0xd2
main.main()
    /home/iant/foo.go:9 +0x1b7

goroutine 2 [runnable]:
runtime.forcegchelper()
    /home/iant/go/src/runtime/proc.go:90
runtime.goexit()
    /home/iant/go/src/runtime/proc.c:1651

goroutine 3 [runnable]:
runtime.bgsweep()
    /home/iant/go/src/runtime/mgc0.go:66
runtime.goexit()
    /home/iant/go/src/runtime/proc.c:1651


The problem is that the code in reflect/type.go gcProg.appendProg does not consider the
case in which the first word in t.gc is nil.  This case arises for large objects: ones
with more than 128 pointers.
@dvyukov
Copy link
Member

dvyukov commented Oct 10, 2014

Comment 1:

The problem is that allocation does not fill GC bitmask for large types now as it was
initially envisioned. I would just delete unrollgcproginplace and everything related to
it. It will automatically fix this bug. The programs are intended to be compact on-disk
format, like DWARF.
+rsc

@gopherbot
Copy link
Contributor

Comment 2:

CL https://golang.org/cl/156930044 mentions this issue.

@ianlancetaylor
Copy link
Member Author

Comment 3:

This issue was closed by revision 3cf9acc.

Status changed to Fixed.

@rsc rsc added this to the Go1.4 milestone Apr 14, 2015
@rsc rsc removed the release-go1.4 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jun 25, 2018
The code for a generated type is already generating an
unrolled GC bitmask.  Rather than unrolling the the source
type bitmasks and copying them, just generate the required
bitmask directly.  Don't mark it as an unrolled GC program,
since there is no need to do so.

Fixes golang#8917.

LGTM=rsc
R=dvyukov, rsc
CC=golang-codereviews
https://golang.org/cl/156930044
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jun 26, 2018
The code for a generated type is already generating an
unrolled GC bitmask.  Rather than unrolling the the source
type bitmasks and copying them, just generate the required
bitmask directly.  Don't mark it as an unrolled GC program,
since there is no need to do so.

Fixes golang#8917.

LGTM=rsc
R=dvyukov, rsc
CC=golang-codereviews
https://golang.org/cl/156930044
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jul 9, 2018
The code for a generated type is already generating an
unrolled GC bitmask.  Rather than unrolling the the source
type bitmasks and copying them, just generate the required
bitmask directly.  Don't mark it as an unrolled GC program,
since there is no need to do so.

Fixes golang#8917.

LGTM=rsc
R=dvyukov, rsc
CC=golang-codereviews
https://golang.org/cl/156930044
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jul 30, 2018
The code for a generated type is already generating an
unrolled GC bitmask.  Rather than unrolling the the source
type bitmasks and copying them, just generate the required
bitmask directly.  Don't mark it as an unrolled GC program,
since there is no need to do so.

Fixes golang#8917.

LGTM=rsc
R=dvyukov, rsc
CC=golang-codereviews
https://golang.org/cl/156930044
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

4 participants