runtime: crash in copyabletopsegment for defer of nil func #8047

dvyukov · 2014-05-20T16:42:40Z

go version devel +fb7122476042 Tue May 20 11:42:25 2014 -0400 linux/amd64

The attached reproducer crashes as:

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

runtime stack:
runtime.throw(0x45b3a5)
    src/pkg/runtime/panic.c:520 +0x69 fp=0x7fff63f1f420
runtime.sigpanic()
    src/pkg/runtime/os_linux.c:222 +0x3d fp=0x7fff63f1f438
copyabletopsegment(0xc208002120)
    src/pkg/runtime/stack.c:347 +0x107 fp=0x7fff63f1f4c8
runtime.newstack()
    src/pkg/runtime/stack.c:746 +0x3f2 fp=0x7fff63f1f610
runtime: unexpected return pc for runtime.newstackcall called from 0x45ebe8
runtime.newstackcall(0x41fb77, 0x1)
    src/pkg/runtime/asm_amd64.s:275 +0x68 fp=0x7fff63f1f618

goroutine 16 [stack growth]:
runtime.newstackcall(0x440098, 0xc208026028)
    src/pkg/runtime/asm_amd64.s:239 fp=0x7fb65354cd30
runtime.panic(0x42a460, 0x45b453)
    src/pkg/runtime/panic.c:248 +0x18d fp=0x7fb65354cdc8
runtime.panicstring(0x45b453)
    src/pkg/runtime/panic.c:552 +0x12d fp=0x7fb65354cdf0
runtime.sigpanic()
    src/pkg/runtime/os_linux.c:237 +0x10e fp=0x7fb65354ce08
main.id7(0x3ff199999999999a, 0x0, 0x0)
    0.go:33 +0xbb fp=0x7fb65354ce90
main.id3(0x0, 0x0, 0x415500, 0xc20801096c)
    0.go:20 +0x31 fp=0x7fb65354ced0
main.init()
    0.go:18 +0x62 fp=0x7fb65354cf50
runtime.main()
    src/pkg/runtime/proc.c:240 +0xda fp=0x7fb65354cfa8

Attachments:

0.go (4563 bytes)

rsc · 2014-05-21T14:56:45Z

Comment 1:

Labels changed: added release-go1.3maybe.

Status changed to Accepted.

randall77 · 2014-05-23T23:13:44Z

Comment 2:

Easier repro:
package main
func stackit(n int) {
    if n == 0 {
        return
    }
    stackit(n - 1)
}
func main() {
    defer ((func())(nil))()
    stackit(1000)
}
It's deferring a call to a nil object.  The stack copier barfs when it comes upon such a
defer record.  The defer hasn't executed yet.
It's easy enough to make the stack copier ignore such defers.  But shouldn't we panic on
such a defer as soon as it is requested?
This is related to issue #8045.  "defer nil()" should do the same thing as "go nil()".

Owner changed to @randall77.

randall77 · 2014-05-23T23:44:54Z

Comment 3:

I'm leading towards rejecting these defers at creation time.  During a panic they can
only lead to a panic on top of that panic.  That gets really ugly, really fast.

randall77 · 2014-05-24T03:46:32Z

Comment 4:

Issue #8046 has been merged into this issue.

rsc · 2014-05-27T20:20:16Z

Comment 6:

Labels changed: added release-go1.3, removed release-go1.3maybe.

gopherbot · 2014-05-27T20:44:37Z

Comment 7:

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

randall77 · 2014-05-27T23:26:22Z

Comment 8:

This issue was closed by revision 3d1c3e1.

Status changed to Fixed.

dvyukov · 2014-06-05T12:04:51Z

Comment 9:

The test from the merged issue #8046 still fatal errors.
cl/101800043 does not contain test for 8047, so it's unclear whether 8047 is fixed as
well.

Status changed to Accepted.

gopherbot · 2014-06-09T23:01:39Z

Comment 10:

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

randall77 · 2014-06-12T00:35:02Z

Comment 11:

This issue was closed by revision aa04caa.

Status changed to Fixed.

rsc · 2014-06-12T00:42:26Z

Comment 12:

This issue was closed by revision bfc80b43b7ff.

dvyukov · 2014-06-12T06:41:11Z

Comment 13:

Sorry, it still crashes:
go version devel +1282e1d59a81 Wed Jun 11 22:52:01 2014 -0700 darwin/amd64
fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0x0 pc=0x1a6d7]
runtime stack:
runtime: unexpected return pc for runtime.newstackcall called from 0x5e708
runtime.throw(0x5bad6)
        src/pkg/runtime/panic.c:520 +0x69
runtime.sigpanic()
        src/pkg/runtime/os_darwin.c:439 +0x3d
runtime.gostartcallfn(0x7fff5fbff940, 0x0)
        src/pkg/runtime/stack.c:859 +0x27
runtime.newstack()
        src/pkg/runtime/stack.c:843 +0x6e4
runtime: unexpected return pc for runtime.newstackcall called from 0x5e708
runtime.newstackcall(0x235f7, 0x7fff00000001)
        src/pkg/runtime/asm_amd64.s:275 +0x68

Status changed to Accepted.

gopherbot · 2014-06-12T19:00:32Z

Comment 14:

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

rsc · 2014-06-12T19:02:20Z

Comment 15:

Owner changed to @rsc.

rsc · 2014-06-12T20:34:47Z

Comment 16:

This issue was closed by revision 36207a9.

Status changed to Fixed.

gopherbot · 2014-06-12T20:54:27Z

Comment 17:

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

rsc · 2014-06-12T20:55:36Z

Comment 18:

This issue was closed by revision 3825729c6921.

gopherbot · 2014-06-13T01:09:59Z

Comment 19:

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

rsc · 2014-06-13T01:13:02Z

Comment 20:

This issue was closed by revision 060a988.

gopherbot · 2014-06-13T01:17:22Z

Comment 21:

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

rsc · 2014-06-13T01:53:00Z

Comment 22:

This issue was closed by revision 67de4afa60e7.

««« CL 108840043 / 3a2306461574 runtime: add test for issue 8047. Make sure stack copier doesn't barf on a nil defer. Bug was fixed in https://golang.org/cl/101800043 This change just adds a test. Fixes #8047 LGTM=dvyukov, rsc R=dvyukov, rsc CC=golang-codereviews https://golang.org/cl/108840043 »»» TBR=adg CC=golang-codereviews https://golang.org/cl/102320043

««« CL 105140044 / c2832405e9b9 runtime: fix defer of nil func Fixes #8047. LGTM=r, iant R=golang-codereviews, r, iant CC=dvyukov, golang-codereviews, khr https://golang.org/cl/105140044 »»» LGTM=r R=golang-codereviews, r CC=adg, golang-codereviews, iant https://golang.org/cl/103370044

…rk on Windows ««« CL 105120044 / 824ea5943ba8 runtime: revise CL 105140044 (defer nil) to work on Windows It appears that something about Go on Windows cannot handle the fault cause by a jump to address 0. The way Go represents and calls functions, this never happened at all, until CL 105140044. This CL changes the code added in CL 105140044 to make jump to 0 impossible once again. Fixes #8047. (again, on Windows) TBR=bradfitz R=golang-codereviews, dave CC=adg, golang-codereviews, iant, r https://golang.org/cl/105120044 »»» LGTM=bradfitz R=golang-codereviews, bradfitz, alex.brainman CC=adg, golang-codereviews https://golang.org/cl/108890045

fixes golang#8047 LGTM=rsc R=golang-codereviews, rsc CC=golang-codereviews https://golang.org/cl/101800043

Make sure stack copier doesn't barf on a nil defer. Bug was fixed in https://golang.org/cl/101800043 This change just adds a test. Fixes golang#8047 LGTM=dvyukov, rsc R=dvyukov, rsc CC=golang-codereviews https://golang.org/cl/108840043

Fixes golang#8047. LGTM=r, iant R=golang-codereviews, r, iant CC=dvyukov, golang-codereviews, khr https://golang.org/cl/105140044

It appears that something about Go on Windows cannot handle the fault cause by a jump to address 0. The way Go represents and calls functions, this never happened at all, until CL 105140044. This CL changes the code added in CL 105140044 to make jump to 0 impossible once again. Fixes golang#8047. (again, on Windows) TBR=bradfitz R=golang-codereviews, dave CC=adg, golang-codereviews, iant, r https://golang.org/cl/105120044

dvyukov added fixed labels Jun 13, 2014

dvyukov assigned rsc Jun 13, 2014

rsc added this to the Go1.3 milestone Apr 14, 2015

rsc removed the release-go1.3 label Apr 14, 2015

randall77 mentioned this issue Apr 27, 2016

runtime: confusing stack trace in case of deferring <nil> function #15466

Closed

golang locked and limited conversation to collaborators Jun 25, 2016

gopherbot added the FrozenDueToAge label Jun 25, 2016

wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jun 25, 2018

runtime: stack copier should handle nil defers without faulting.

ac5510c

fixes golang#8047 LGTM=rsc R=golang-codereviews, rsc CC=golang-codereviews https://golang.org/cl/101800043

wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jun 25, 2018

runtime: fix defer of nil func

fdbbdff

Fixes golang#8047. LGTM=r, iant R=golang-codereviews, r, iant CC=dvyukov, golang-codereviews, khr https://golang.org/cl/105140044

rsc removed their assignment Jun 23, 2022

This issue was closed.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

runtime: crash in copyabletopsegment for defer of nil func #8047

runtime: crash in copyabletopsegment for defer of nil func #8047

dvyukov commented May 20, 2014

rsc commented May 21, 2014

randall77 commented May 23, 2014

randall77 commented May 23, 2014

randall77 commented May 24, 2014

rsc commented May 27, 2014

gopherbot commented May 27, 2014

randall77 commented May 27, 2014

dvyukov commented Jun 5, 2014

gopherbot commented Jun 9, 2014

randall77 commented Jun 12, 2014

rsc commented Jun 12, 2014

dvyukov commented Jun 12, 2014

gopherbot commented Jun 12, 2014

rsc commented Jun 12, 2014

rsc commented Jun 12, 2014

gopherbot commented Jun 12, 2014

rsc commented Jun 12, 2014

gopherbot commented Jun 13, 2014

rsc commented Jun 13, 2014

gopherbot commented Jun 13, 2014

rsc commented Jun 13, 2014

runtime: crash in copyabletopsegment for defer of nil func #8047

runtime: crash in copyabletopsegment for defer of nil func #8047

Comments

dvyukov commented May 20, 2014

rsc commented May 21, 2014

randall77 commented May 23, 2014

randall77 commented May 23, 2014

randall77 commented May 24, 2014

rsc commented May 27, 2014

gopherbot commented May 27, 2014

randall77 commented May 27, 2014

dvyukov commented Jun 5, 2014

gopherbot commented Jun 9, 2014

randall77 commented Jun 12, 2014

rsc commented Jun 12, 2014

dvyukov commented Jun 12, 2014

gopherbot commented Jun 12, 2014

rsc commented Jun 12, 2014

rsc commented Jun 12, 2014

gopherbot commented Jun 12, 2014

rsc commented Jun 12, 2014

gopherbot commented Jun 13, 2014

rsc commented Jun 13, 2014

gopherbot commented Jun 13, 2014

rsc commented Jun 13, 2014