Skip to content
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

Jump to bottom

x/exp/shiny: panic is not panicky #13963

Closed
jnjackins opened this issue Jan 15, 2016 · 3 comments
Closed

x/exp/shiny: panic is not panicky #13963

jnjackins opened this issue Jan 15, 2016 · 3 comments
Milestone
Unreleased

Comments

@jnjackins
Copy link
Contributor

go version devel +c5a2f36 Thu Jan 14 20:57:21 2016 +0000 darwin/amd64

Once a window has been initialized, any panics (either by calling panic() or some other means) do not exit the program or print a stack trace, but rather cause the program to hang. If the window has been published, the cursor becomes a spinning beachball.

$ git diff
diff --git a/shiny/example/basic/main.go b/shiny/example/basic/main.go
index d427b34..f88d34b 100644
--- a/shiny/example/basic/main.go
+++ b/shiny/example/basic/main.go
@@ -40,6 +40,8 @@ func main() {
                }
                defer w.Release()

+               panic("help!")
+
                winSize := image.Point{256, 256}
                b, err := s.NewBuffer(winSize)
                if err != nil {
$ go build main.go 
$ ./main 
(hangs forever)

cc @crawshaw @nigeltao
@nigeltao
Copy link
Contributor

Darwin means I'm assigning this to crawshaw.

@crawshaw
Copy link
Member

With a similar panic inserted and go version devel +57b1e55 Sat Jan 9 03:30:40 2016 +0000 darwin/amd64 I get:

$ go run ./example/basic/main.go 
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x40c03a0]

goroutine 1 [running, locked to thread]:
golang.org/x/exp/shiny/driver/gldriver.preparedOpenGL(0x4324850, 0x50190d0, 0x1)
    /Users/crawshaw/src/golang.org/x/exp/shiny/driver/gldriver/cocoa.go:79 +0x130
golang.org/x/exp/shiny/driver/gldriver._cgoexpwrap_3f811e6e7553_preparedOpenGL(0x4324850, 0x50190d0, 0x1)
    golang.org/x/exp/shiny/driver/gldriver/_obj/_cgo_gotypes.go:310 +0x35
golang.org/x/exp/shiny/driver/gldriver._Cfunc_startDriver()
    golang.org/x/exp/shiny/driver/gldriver/_obj/_cgo_gotypes.go:272 +0x31
golang.org/x/exp/shiny/driver/gldriver.main(0x41985b0, 0x0, 0x0)
    /Users/crawshaw/src/golang.org/x/exp/shiny/driver/gldriver/cocoa.go:95 +0x18a
golang.org/x/exp/shiny/driver/gldriver.Main(0x41985b0)
    /Users/crawshaw/src/golang.org/x/exp/shiny/driver/gldriver/gldriver.go:26 +0x30
golang.org/x/exp/shiny/driver.main(0x41985b0)
    /Users/crawshaw/src/golang.org/x/exp/shiny/driver/driver_darwin.go:15 +0x21
golang.org/x/exp/shiny/driver.Main(0x41985b0)
    /Users/crawshaw/src/golang.org/x/exp/shiny/driver/driver.go:24 +0x21
main.main()
    /Users/crawshaw/src/golang.org/x/exp/shiny/example/basic/main.go:105 +0x23
exit status 2

Which is not right, but is a little more information.

@jnjackins do you get a stack trace if you send a SIGQUIT?

@jnjackins
Copy link
Contributor Author

Hi David. Thanks for having a look.

I couldn't reproduce the issue the same way this time either, but I was able to reproduce it by inserting a panic into the handling of paint.Event in the tile example program:

diff --git a/shiny/example/tile/main.go b/shiny/example/tile/main.go
index ad30f68..58fdc4c 100644
--- a/shiny/example/tile/main.go
+++ b/shiny/example/tile/main.go
@@ -85,6 +85,7 @@ func main() {
                                }

                        case paint.Event:
+                               panic("hello")
                                generation++
                                var wg sync.WaitGroup
                                for y := -(origin.Y & 0xff); y < sz.HeightPx; y += 256 {

And here is the stack trace I got by sending SIGQUIT:

$ ./main 
SIGQUIT: quit
PC=0x405c76b m=0
signal arrived during cgo execution

goroutine 1 [chan receive, locked to thread]:
runtime.mach_semaphore_wait(0xc800001003, 0x422fd00, 0x40322c2, 0x40e3480, 0x7fff5fbfd690, 0x422fd00, 0x4050819, 0xffffffffffffffff, 0x419f450, 0x7fff5fbfd6a4, ...)
    /Users/jnj/src/go/src/runtime/sys_darwin_amd64.s:411 +0xb fp=0x7fff5fbfd638 sp=0x7fff5fbfd630
runtime.semasleep1(0xffffffffffffffff, 0x419f450)
    /Users/jnj/src/go/src/runtime/os1_darwin.go:418 +0xdf fp=0x7fff5fbfd670 sp=0x7fff5fbfd638
runtime.semasleep.func1()
    /Users/jnj/src/go/src/runtime/os1_darwin.go:434 +0x29 fp=0x7fff5fbfd690 sp=0x7fff5fbfd670
runtime.systemstack(0x7fff5fbfd6a8)
    /Users/jnj/src/go/src/runtime/asm_amd64.s:307 +0xab fp=0x7fff5fbfd698 sp=0x7fff5fbfd690
runtime.semasleep(0xffffffffffffffff, 0x0)
    /Users/jnj/src/go/src/runtime/os1_darwin.go:435 +0x36 fp=0x7fff5fbfd6c8 sp=0x7fff5fbfd698
runtime.notesleep(0x4230148)
    /Users/jnj/src/go/src/runtime/lock_sema.go:166 +0xed fp=0x7fff5fbfd700 sp=0x7fff5fbfd6c8
runtime.stoplockedm()
    /Users/jnj/src/go/src/runtime/proc.go:1674 +0xae fp=0x7fff5fbfd720 sp=0x7fff5fbfd700
runtime.schedule()
    /Users/jnj/src/go/src/runtime/proc.go:2018 +0x6e fp=0x7fff5fbfd758 sp=0x7fff5fbfd720
runtime.park_m(0xc820000180)
    /Users/jnj/src/go/src/runtime/proc.go:2125 +0x18b fp=0x7fff5fbfd780 sp=0x7fff5fbfd758
runtime.mcall(0x405aaba)
    /Users/jnj/src/go/src/runtime/asm_amd64.s:233 +0x5b fp=0x7fff5fbfd790 sp=0x7fff5fbfd780

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /Users/jnj/src/go/src/runtime/asm_amd64.s:1998 +0x1

goroutine 5 [syscall, locked to thread]:
golang.org/x/exp/shiny/driver/gldriver._Cfunc_doCloseWindow(0x5030710)
    golang.org/x/exp/shiny/driver/gldriver/_obj/_cgo_gotypes.go:188 +0x36
golang.org/x/exp/shiny/driver/gldriver.closeWindow(0x5030710)
    /Users/jnj/src/golang.org/x/exp/shiny/driver/gldriver/cocoa.go:84 +0x21
golang.org/x/exp/shiny/driver/gldriver.(*windowImpl).Release(0xc820078000)
    /Users/jnj/src/golang.org/x/exp/shiny/driver/gldriver/window.go:88 +0x9d
main.main.func1(0x476b318, 0x422f940)
    /Users/jnj/src/golang.org/x/exp/shiny/example/tile/main.go:88 +0x641
golang.org/x/exp/shiny/driver/gldriver.driverStarted.func1()
    /Users/jnj/src/golang.org/x/exp/shiny/driver/gldriver/cocoa.go:102 +0x47
created by golang.org/x/exp/shiny/driver/gldriver.driverStarted
    /Users/jnj/src/golang.org/x/exp/shiny/driver/gldriver/cocoa.go:104 +0x2b

goroutine 18 [select, locked to thread]:
golang.org/x/exp/shiny/driver/gldriver.drawLoop(0xc820078000, 0x1)
    /Users/jnj/src/golang.org/x/exp/shiny/driver/gldriver/cocoa.go:147 +0x482
created by golang.org/x/exp/shiny/driver/gldriver.preparedOpenGL
    /Users/jnj/src/golang.org/x/exp/shiny/driver/gldriver/cocoa.go:80 +0x117

rax    0xe
rbx    0x4230040
rcx    0x7fff5fbfd630
rdx    0x7fff5fbfd6a8
rdi    0x1003
rsi    0x7fff5fbfd648
rbp    0x1003
rsp    0x7fff5fbfd630
r8     0x80008ff
r9     0x0
r10    0x700000429068
r11    0x286
r12    0x2c
r13    0x419e60c
r14    0x0
r15    0x8
rip    0x405c76b
rflags 0x286
cs     0x7
fs     0x0
gs     0x0

I wonder if there is a deadlock occurring when the panic comes at an unlucky time, which would explain why it's difficult to reproduce consistently.

@bradfitz bradfitz added this to the Unreleased milestone Jan 21, 2016
@jnjackins jnjackins closed this as not planned Won't fix, can't repro, duplicate, stale Sep 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
4 participants
@bradfitz @crawshaw @jnjackins @nigeltao