<pre class="notranslate">What steps will reproduce the problem?
1. edit httpd.go with sample code in Effective Go,
2. 6g httpd.go &amp;&amp; 6g httpd.6
3. 6prof ./6.out

What is the expected output? What do you see instead?

davies@boromir ~ $ 6g http.go &amp;&amp; 6l http.6 &amp;&amp; 6prof ./6.out
futexsleep addr=0x4aab20 val=3 returned -110
SIGSEGV: segmentation violation
Faulting address: 0x1005
PC=0x43974a

futexsleep+0xc2 /home/davies/go/src/pkg/runtime/linux/thread.c:58
        futexsleep(0x4aab20, 0x0, 0x3, 0x3)
futexlock+0x7a /home/davies/go/src/pkg/runtime/linux/thread.c:126
        futexlock(0x4aab20, 0x0)
notesleep+0x1c /home/davies/go/src/pkg/runtime/linux/thread.c:206
        notesleep(0x4aab20, 0x0)
nextgandunlock+0xfc /home/davies/go/src/pkg/runtime/proc.c:350
        nextgandunlock()
scheduler+0xe0 /home/davies/go/src/pkg/runtime/proc.c:503
        scheduler()
mstart+0x47 /home/davies/go/src/pkg/runtime/proc.c:394
        mstart()
_rt0_amd64+0x74 /home/davies/go/src/pkg/runtime/amd64/asm.s:46
        _rt0_amd64()

goroutine 2 [3]:
runtime·entersyscall+0x50 /home/davies/go/src/pkg/runtime/proc.c:543
        runtime·entersyscall()
syscall·Syscall6+0x5 /home/davies/go/src/pkg/syscall/asm_linux_amd64.s:41
        syscall·Syscall6()
syscall·EpollWait+0x84 /home/davies/go/src/pkg/syscall/zsyscall_linux_amd64.go:1       
                                                                     
32
        syscall·EpollWait(0x7, 0x2ace, 0x7a2f6a20, 0x2ace, 0x1, ...)
net·*pollster·WaitFD+0x2f5 /home/davies/go/src/pkg/net/fd_linux.go:118
        net·*pollster·WaitFD(0x7a2f69b0, 0x2ace, 0x0, 0x0, 0x0, ...)
net·*pollServer·Run+0x9e /home/davies/go/src/pkg/net/fd.go:236
        net·*pollServer·Run(0x7a2fe240, 0x2ace)
goexit /home/davies/go/src/pkg/runtime/proc.c:136
        goexit()
0x2ace7a2fe240 unknown pc

goroutine 1 [4]:
gosched+0x34 /home/davies/go/src/pkg/runtime/proc.c:522
        gosched()
chanrecv+0x167 /home/davies/go/src/pkg/runtime/chan.c:347
        chanrecv(0x7a31c300, 0x2ace, 0x7a301d80, 0x2ace, 0x0, ...)
runtime·chanrecv1+0x50 /home/davies/go/src/pkg/runtime/chan.c:417
        runtime·chanrecv1(0x7a31c300, 0x2ace)
net·*pollServer·WaitRead+0x49 /home/davies/go/src/pkg/net/fd.go:276
        net·*pollServer·WaitRead(0x7a2fe240, 0x2ace, 0x7a2ff0a0, 0x2ace)
net·*netFD·accept+0x2e2 /home/davies/go/src/pkg/net/fd.go:512
        net·*netFD·accept(0x7a2ff0a0, 0x2ace, 0x427e9a, 0x0, 0x7a301e80, ...)
net·*TCPListener·AcceptTCP+0x5a /home/davies/go/src/pkg/net/tcpsock.go:253
        net·*TCPListener·AcceptTCP(0x7a2f50c8, 0x2ace, 0x4260a6, 0x0, 0x0, ...)
net·*TCPListener·Accept+0x34 /home/davies/go/src/pkg/net/tcpsock.go:263
        net·*TCPListener·Accept(0x7a2f50c8, 0x2ace, 0x0, 0x0, 0x0, ...)
http·Serve+0x66 /home/davies/go/src/pkg/http/server.go:532
        http·Serve(0x7a2fe2c0, 0x2ace, 0x7a2f50c8, 0x2ace, 0x7a2fd7e0, ...)
http·ListenAndServe+0x8e /home/davies/go/src/pkg/http/server.go:576
        http·ListenAndServe(0x44cff8, 0x0, 0x5, 0x0, 0x0, ...)
main·main+0x77 /home/davies/http.go:22
        main·main()
mainstart+0xf /home/davies/go/src/pkg/runtime/amd64/asm.s:54
        mainstart()
goexit /home/davies/go/src/pkg/runtime/proc.c:136
        goexit()
rax     0x1
rbx     0x1
rcx     0x439b10
rdx     0x1
rdi     0x1
rsi     0x4932b8
rbp     0x4932b8
rsp     0x7fff307ee970
r8      0x0
r9      0x0
r10     0x46acd8
r11     0x202
r12     0x250
r13     0x7fff307eeaa0
r14     0x4aaa78
r15     0x4aa9d8
rip     0x43974a
rflags  0x10202
cs      0x33
fs      0x0
gs      0x0
7 samples (avg 2 threads)
 42.86% clone
 42.86% syscall·Syscall6
 14.29% breakpoint
 14.29% exit
 14.29% futex
 14.29% futexsleep
 14.29% syscall·Syscall

What is your $GOOS?  $GOARCH?

$GOOS=linux
$GOARCH=amd64

Which revision are you using?  (hg identify)

5074575b745b+ tip

Please provide any additional information below.</pre>
<pre class="notranslate">go ((func())(nil))()

Should it panic in the calling go routine, or at the start of the called goroutine?

    defer ((func())(nil))()

Should it panic at the defer statement, or at the return point?

We've had some argument either way.  Panicing in the calling goroutine / at defer
statement is failing early, might be useful for people.  Panicing late might be
expected, as the go/deferred routine doesn't actually use the nil value until then.

Panicing late is what we do now.

The runtime meeting decided gri should figure this out, maybe update the spec.

Related to issues 8045 (go) and 8047 (defers).</pre>