Issue 1:
What steps will reproduce the problem?
1. edit httpd.go with sample code in Effective Go,
2. 6g httpd.go && 6g httpd.6
3. 6prof ./6.out

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

davies@boromir ~ $ 6g http.go && 6l http.6 && 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.

Issue 2:
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).