Skip to content

cmd/compile: escape analysis bug involving interfaces #11931

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
Closed
cryptix opened this issue Jul 30, 2015 · 8 comments
Closed

cmd/compile: escape analysis bug involving interfaces #11931

cryptix opened this issue Jul 30, 2015 · 8 comments
Labels
FrozenDueToAge
Milestone
Go1.5

Comments

@cryptix
Copy link

cryptix commented Jul 30, 2015

We started seeing this panic in our tests at ipfs.io. I didn't try go1.5beta1 but its in beta 2 and 3. (They work fine in 1.4.x)

[cryptix@higgs ~] uname -a
Linux higgs 4.0.7-2-ARCH #1 SMP PREEMPT Tue Jun 30 07:50:21 UTC 2015 x86_64 GNU/Linux
[cryptix@higgs ~] go version
go version devel +d3ffc97 Wed Jul 29 23:50:20 2015 +0000 linux/amd64
[cryptix@higgs ~] go get  github.com/ipfs/go-ipfs/cmd/ipfs
[cryptix@higgs ~] go test github.com/ipfs/go-ipfs/test/integration
unexpected fault address 0x0
fatal error: fault
[signal 0xb code=0x80 addr=0x0 pc=0x40b911]

goroutine 328 [running]:
runtime.throw(0xb2e3c8, 0x5)
    /home/cryptix/go15exp/src/runtime/panic.go:527 +0x96 fp=0xc820055340 sp=0xc820055328
runtime.sigpanic()
    /home/cryptix/go15exp/src/runtime/sigpanic_unix.go:27 +0x2ab fp=0xc820055390 sp=0xc820055340
runtime.mapaccess2_faststr(0x93b560, 0xc82004f800, 0xc82055c1b0, 0x22, 0xc838d780c2, 0xe97a60)
    /home/cryptix/go15exp/src/runtime/hashmap_fast.go:352 +0x3f1 fp=0xc8200553f0 sp=0xc820055390
github.com/ipfs/go-ipfs/p2p/peer.(*metrics).RecordLatency(0xc8205a4098, 0xc82055c1b0, 0x22, 0x4c472)
    /tmp/gotest/src/github.com/ipfs/go-ipfs/p2p/peer/metrics.go:45 +0xb3 fp=0xc820055460 sp=0xc8200553f0
github.com/ipfs/go-ipfs/routing/dht.(*IpfsDHT).sendRequest(0xc82067a000, 0x7fd87e9b00c0, 0xc82056ac40, 0xc82055c1b0, 0x22, 0xc820104af0, 0x0, 0x0, 0x0)
    /tmp/gotest/src/github.com/ipfs/go-ipfs/routing/dht/dht_net.go:103 +0xdc2 fp=0xc820055828 sp=0xc820055460
github.com/ipfs/go-ipfs/routing/dht.(*IpfsDHT).findProvidersSingle(0xc82067a000, 0x7fd87e9b00c0, 0xc82056ac40, 0xc82055c1b0, 0x22, 0xc82065fc80, 0x22, 0x0, 0x0, 0x0)
    /tmp/gotest/src/github.com/ipfs/go-ipfs/routing/dht/dht.go:276 +0x3d8 fp=0xc820055920 sp=0xc820055828
github.com/ipfs/go-ipfs/routing/dht.(*IpfsDHT).findProvidersAsyncRoutine.func1(0x7fd87e9b00c0, 0xc82056ac40, 0xc82055c1b0, 0x22, 0x1, 0x0, 0x0)
    /tmp/gotest/src/github.com/ipfs/go-ipfs/routing/dht/routing.go:217 +0x157 fp=0xc820055c18 sp=0xc820055920
github.com/ipfs/go-ipfs/routing/dht.(*dhtQueryRunner).queryPeer(0xc82067c480, 0x7fd8809f84b8, 0xc8205fed80, 0xc82055c1b0, 0x22)
    /tmp/gotest/src/github.com/ipfs/go-ipfs/routing/dht/query.go:251 +0x789 fp=0xc820055f08 sp=0xc820055c18
github.com/ipfs/go-ipfs/routing/dht.(*dhtQueryRunner).spawnWorkers.func1(0x7fd8809f84b8, 0xc8205fed80)
    /tmp/gotest/src/github.com/ipfs/go-ipfs/routing/dht/query.go:195 +0x53 fp=0xc820055f48 sp=0xc820055f08
github.com/ipfs/go-ipfs/Godeps/_workspace/src/github.com/jbenet/goprocess.(*process).Go.func1(0xc8206c6ec0, 0xc8205fed80, 0xc8205feea0)
    /tmp/gotest/src/github.com/ipfs/go-ipfs/Godeps/_workspace/src/github.com/jbenet/goprocess/impl-mutex.go:112 +0x51 fp=0xc820055f88 sp=0xc820055f48
runtime.goexit()
    /home/cryptix/go15exp/src/runtime/asm_amd64.s:1696 +0x1 fp=0xc820055f90 sp=0xc820055f88
created by github.com/ipfs/go-ipfs/Godeps/_workspace/src/github.com/jbenet/goprocess.(*process).Go
    /tmp/gotest/src/github.com/ipfs/go-ipfs/Godeps/_workspace/src/github.com/jbenet/goprocess/impl-mutex.go:115 +0x3eb

...

(Full trace log)

It seems to come from this map lookup but I can't figure out whats wrong with it. I wish I had a more minimal test case.
@cryptix cryptix changed the title unexpected fault address 0x0 go1.5 beta: test crashes with 'unexpected fault address 0x0' Jul 30, 2015
@davecheney
Copy link
Contributor

Confirmed. I see a slightly different error on OSX, but a panic non the less. The suspicious looking fault address is a side effect of the SIGSEGV handler on darwin freaking out if the fault address is higher than the 48th bit.

zapf(~/src/golang.org/x/crypto/ssh) % go test github.com/ipfs/go-ipfs/test/integration                                                                                   
unexpected fault address 0xb01dfacedebac1e
fatal error: fault
[signal 0xb code=0x1 addr=0xb01dfacedebac1e pc=0xc7b5]

goroutine 196 [running]:
runtime.throw(0x730e30, 0x5)
        /Users/dfc/go/src/runtime/panic.go:527 +0x96 fp=0xc8200b2cc8 sp=0xc8200b2cb0
runtime.sigpanic()
        /Users/dfc/go/src/runtime/sigpanic_unix.go:27 +0x2ba fp=0xc8200b2d18 sp=0xc8200b2cc8
runtime.mapaccess1_faststr(0x53bde0, 0xc82005b800, 0xc82057a750, 0x22, 0x20)
        /Users/dfc/go/src/runtime/hashmap_fast.go:262 +0x415 fp=0xc8200b2d78 sp=0xc8200b2d18
github.com/ipfs/go-ipfs/p2p/peer.(*metrics).LatencyEWMA(0xc82057c028, 0xc82057a750, 0x22, 0x0)
        /Users/dfc/src/github.com/ipfs/go-ipfs/p2p/peer/metrics.go:60 +0x70 fp=0xc8200b2dc0 sp=0xc8200b2d78
github.com/ipfs/go-ipfs/routing/kbucket.(*RoutingTable).Update(0xc8200e8000, 0xc82057a750, 0x22)
        /Users/dfc/src/github.com/ipfs/go-ipfs/routing/kbucket/table.go:69 +0x1f3 fp=0xc8200b2e50 sp=0xc8200b2dc0
github.com/ipfs/go-ipfs/routing/dht.(*IpfsDHT).Update(0xc82009a000, 0x19000c0, 0xc820556000, 0xc82057a750, 0x22)
        /Users/dfc/src/github.com/ipfs/go-ipfs/routing/dht/dht.go:252 +0x163 fp=0xc8200b2ed0 sp=0xc8200b2e50
github.com/ipfs/go-ipfs/routing/dht.(*netNotifiee).Connected(0xc82009a000, 0x1940308, 0xc820584000, 0x1980098, 0xc8200180c0)
        /Users/dfc/src/github.com/ipfs/go-ipfs/routing/dht/notif.go:23 +0x107 fp=0xc8200b2f48 sp=0xc8200b2ed0
github.com/ipfs/go-ipfs/p2p/net/mock.(*peernet).openConn.func1(0x19408a0, 0xc82009a000)
        /Users/dfc/src/github.com/ipfs/go-ipfs/p2p/net/mock/mock_peernet.go:172 +0x94 fp=0xc8200b2fb0 sp=0xc8200b2f48
runtime.goexit()
        /Users/dfc/go/src/runtime/asm_amd64.s:1696 +0x1 fp=0xc8200b2fb8 sp=0xc8200b2fb0
created by github.com/ipfs/go-ipfs/p2p/net/mock.(*peernet).notifyAll
        /Users/dfc/src/github.com/ipfs/go-ipfs/p2p/net/mock/mock_peernet.go:401 +0xc2

The same code passes with the race detector under 1.4.2 on the same host so for the moment it is possible that this is memory corruption unrelated to a data race.

/cc @rsc @randall77

@davecheney davecheney added this to the Go1.5 milestone Jul 30, 2015
@mikioh mikioh changed the title go1.5 beta: test crashes with 'unexpected fault address 0x0' runtime: go1.5beta3: test crashes with 'unexpected fault address 0x0' Jul 30, 2015
@dr2chase
Copy link
Contributor

I'm bisecting...

@dr2chase
Copy link
Contributor

See b3be360

b3be360f16c44d21b2594d06e8d0e609e8fe3c0c is the first bad commit
commit b3be360f16c44d21b2594d06e8d0e609e8fe3c0c
Date:   Thu Jan 29 19:40:02 2015 +0300

    cmd/gc: allocate non-escaping maps on stack

    Extend escape analysis to make(map[k]v).
    If it does not escape, allocate temp buffer for hmap and one bucket on stack.

@ianlancetaylor
Copy link
Member

CC @dvyukov

@rsc
Copy link
Contributor

rsc commented Jul 30, 2015

Escape analysis bug. Reproduction:

package p

type T1 struct {
    m map[string]string
    p *int
}

type T2 struct {
    T1 T1
}

func F() *T2 {
    var x interface{}
    x = &T1{
        m: make(map[string]string),
        p: new(int),
    }
    return &T2{
        T1: *x.(*T1),
    }
}

$ go tool compile -m x.go
x.go:12: can inline F
x.go:19: &T2 literal escapes to heap
x.go:15: F make(map[string]string) does not escape <<< WRONG
x.go:16: F new(int) does not escape <<< WRONG
x.go:16: F &T1 literal does not escape
x.go:17: F &T1 literal does not escape

So it's nothing to do with maps. Plain *int isn't handled correctly either. But it's something to do with interfaces.

@rsc rsc changed the title runtime: go1.5beta3: test crashes with 'unexpected fault address 0x0' cmd/compile: escape analysis bug involving interfaces Jul 30, 2015
@aclements
Copy link
Member

Just to add what @dr2chase and I just found: in the original test case, the hmap is being allocated on a stack and then accessed from another G, so clearly it shouldn't have been stack allocated. The hmap appears to be long gone by this point.

@gopherbot
Copy link
Contributor

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

@cryptix
Copy link
Author

cryptix commented Jul 30, 2015

Just tested with latest master and our tests pass again. 👍

Thanks for the quick fix and happy sailing to 1.5!

@golang golang locked and limited conversation to collaborators Aug 5, 2016
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
Go1.5
Development

No branches or pull requests
7 participants
@davecheney @rsc @cryptix @dr2chase @aclements @ianlancetaylor @gopherbot