Closed mokiat closed 2 years ago
/cc @nigeltao
The stack trace suggests that you're on Darwin, not Linux, so I'll pass this on to @crawshaw.
You say that it crashes on a call to gl.UniformMatrix4fv. Are you able to print the arguments to every such call? It would be helpful to know if e.g. the slice passed is ever empty.
Here is a code extract of the method that fails:
func (c *uniformClient) BindFloat4x4Uniform(location UniformLocation, data []float32) error {
fmt.Printf("Mat4x4 Uniform: %v -> %v\n", location, data)
uniform := location.(gl.Uniform)
gl.UniformMatrix4fv(uniform, data)
return nil
}
After one minute worth of resizing, here are the last few outputs that I got prior to it crashing.
Mat4x4 Uniform: Uniform(0) -> [0.004166667 0 0 0 0 0.0056244256 0 0 0 0 -0.02020202 0 -1 -1 -1.020202 1]
Mat4x4 Uniform: Uniform(4) -> [128 0 0 0 0 256 0 0 0 0 1 0 200 128 -2 1]
Mat4x4 Uniform: Uniform(9) -> [1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1]
Mat4x4 Uniform: Uniform(0) -> [0.004166667 0 0 0 0 0.0056244256 0 0 0 0 -0.02020202 0 -1 -1 -1.020202 1]
fatal error: unexpected signal during runtime execution
Unless something got buffered by fmt
, that's the output. Also, since in all the calls I make to BindFloat4x4Uniform
I always pass a slice constructed off of a fixed-sized array, the data
slice should never be empty (as seems to be the case).
P.S. Initially I though that this piece of code could be the culprit: https://github.com/golang/mobile/blob/master/example/basic/main.go#L79-L89
Since on high level look (not sure what happens underneath) it allows the Paint->Stop->Paint
sequence to occur, I though it was resulting in a Paint
call being called on a hidden surface. However, I could not reproduce it with the example
application above and even after wrapping the whole thing with an if could not get my case not to crash.
(The first 0px-by-0px bug you mention looks unrelated, please file a separate issue for it.)
The fraction of your stack trace you posted suggests some very unexpected race is occurring, possibly two goroutines calling DoWork at the same time. If you can reproduce this easily, I'd appreciate it if you could paste in the entire stack trace.
I have filed a new bug for the 0px by 0px issue: #12752
Reproducing it is not what I would call easy. It involves shaking the mouse left and right while dragging the bottom-right corner of the window for about 30 seconds and more (about the time you start feeling stupid) before it crashes.
Here is a full stack trace:
fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0xf60 pc=0xd488f75]
runtime stack:
runtime.throw(0x41afec0, 0x2a)
/usr/local/go/src/runtime/panic.go:527 +0x90
runtime.sigpanic()
/usr/local/go/src/runtime/sigpanic_unix.go:12 +0x5a
goroutine 22 [syscall, locked to thread]:
runtime.cgocall(0x4003a90, 0xc820043c30, 0xc800000000)
/usr/local/go/src/runtime/cgocall.go:120 +0x11b fp=0xc820043bf8 sp=0xc820043bc8
golang.org/x/mobile/gl._Cfunc_process(0xa)
??:0 +0x31 fp=0xc820043c30 sp=0xc820043bf8
golang.org/x/mobile/gl.DoWork()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/gl/work.go:108 +0x2be fp=0xc820043e50 sp=0xc820043c30
golang.org/x/mobile/app.loop(0x5b300f0)
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:85 +0x10b fp=0xc820043fa8 sp=0xc820043e50
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1696 +0x1 fp=0xc820043fb0 sp=0xc820043fa8
created by golang.org/x/mobile/app.startloop
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:116 +0x35
goroutine 1 [syscall, locked to thread]:
golang.org/x/mobile/app._Cfunc_runApp()
golang.org/x/mobile/app/_obj/_cgo_gotypes.go:212 +0x31
golang.org/x/mobile/app.main(0x41c28e0)
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:65 +0x18a
golang.org/x/mobile/app.Main(0x41c28e0)
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/app.go:21 +0x21
main.main()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:19 +0x23
goroutine 17 [syscall, locked to thread]:
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1696 +0x1
goroutine 20 [select]:
golang.org/x/mobile/app.pump.func1(0xc820086068, 0xc820074120)
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/app.go:146 +0x527
created by golang.org/x/mobile/app.pump
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/app.go:175 +0x96
goroutine 21 [chan receive]:
golang.org/x/mobile/gl.enqueue(0x80, 0x1, 0x1, 0xc820012300, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/gl/work.go:63 +0xc0
golang.org/x/mobile/gl.UniformMatrix4fv(0x1, 0xc820012300, 0x10, 0x10)
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/gl/gl.go:2025 +0x9f
github.com/momchil-atanasov/go-whiskey-android/gles/client.(*uniformClient).BindFloat4x4Uniform(0x427d4a0, 0x4154620, 0xc82000a300, 0xc820012300, 0x10, 0x10, 0x0, 0x0)
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/client/uniform.go:63 +0x85
github.com/momchil-atanasov/go-whiskey-android/gles/uniform.(*float4x4Uniform).Bind(0xc820012300, 0x4700028, 0x427d4a0, 0x4154620, 0xc82000a300)
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/uniform/uniform.go:103 +0x75
github.com/momchil-atanasov/go-whiskey-android/gles/item.(*renderer).Render(0xc82000a170, 0x47003a8, 0xc82000e120)
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/item/renderer.go:47 +0x4a9
github.com/momchil-atanasov/go-whiskey-android/gles.(*graphics).Flush(0xc8200b0000, 0x0, 0x0)
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/graphics.go:235 +0x1e7
github.com/momchil-atanasov/go-whiskey-demo/application.Draw()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/application/application.go:255 +0x2d5
main.(*Application).onDraw(0xc82029ff30)
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:70 +0x14
main.(*Application).handlePaint(0xc82029ff30, 0x0)
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:50 +0x25
main.(*Application).Run(0xc82029ff30)
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:33 +0x155
main.main.func1(0x4744260, 0x427d4a0)
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:18 +0x11c
golang.org/x/mobile/app.main.func1(0x41c28e0)
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:60 +0x6f
created by golang.org/x/mobile/app.main
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:63 +0x185
goroutine 34 [syscall, 1 minutes, locked to thread]:
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1696 +0x1
The application that reproduces the issue is also now available: https://github.com/momchil-atanasov/go-whiskey-demo
I am really worried that it's some stupid mistake from my side. Unfortunately, there a few layers of abstraction so it's not as easy to trace as it would be with a basic example application.
From a reading, I believe this could be a bug in the gl package, one I thought I fixed a while back but apparently only in a CL coupled with other changes I never submitted. I'll remake it today and hopefully you could test it out for me.
Unfortunately the recent gl.Context change has broken your code, but it looks like you can pass it into your GLES renderer instance and keep it as a field there, so hopefully it won't be too hard to update.
@momchil-atanasov if you want to try out, https://go-review.googlesource.com/15100, I believe it fixes a bug that may have caused that stack trace.
CL https://golang.org/cl/15100 mentions this issue.
@crawshaw Sure, I'll try it out. I might need some time though.
I tried it out with the proposed change but it failed again. This time a different method in the GLESClient
crashed.
fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0xf60 pc=0xcc88f75]
runtime stack:
runtime.throw(0x41c8ec0, 0x2a)
/usr/local/go/src/runtime/panic.go:527 +0x90
runtime.sigpanic()
/usr/local/go/src/runtime/sigpanic_unix.go:12 +0x5a
goroutine 22 [syscall, locked to thread]:
runtime.cgocall(0x4003290, 0xc82003cb78, 0x0)
/usr/local/go/src/runtime/cgocall.go:120 +0x11b fp=0xc82003cb30 sp=0xc82003cb00
golang.org/x/mobile/gl._Cfunc_process(0xc8200a2260, 0x0, 0x0, 0x0, 0x3, 0x0)
??:0 +0x3a fp=0xc82003cb78 sp=0xc82003cb30
golang.org/x/mobile/gl.(*context).DoWork(0xc8200a2240)
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/gl/work.go:128 +0x3a9 fp=0xc82003cdd0 sp=0xc82003cb78
golang.org/x/mobile/app.loop(0x454bd10)
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:88 +0x30e fp=0xc82003cfa8 sp=0xc82003cdd0
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1696 +0x1 fp=0xc82003cfb0 sp=0xc82003cfa8
created by golang.org/x/mobile/app.startloop
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:119 +0x35
goroutine 1 [chan send, locked to thread]:
golang.org/x/mobile/app.drawgl()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:113 +0x3b
golang.org/x/mobile/app._Cfunc_runApp()
golang.org/x/mobile/app/_obj/_cgo_gotypes.go:212 +0x31
golang.org/x/mobile/app.main(0x41dc508)
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:65 +0x18a
golang.org/x/mobile/app.Main(0x41dc508)
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/app.go:21 +0x21
main.main()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:20 +0x23
goroutine 17 [syscall, locked to thread]:
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1696 +0x1
goroutine 20 [select]:
golang.org/x/mobile/app.pump.func1(0xc820086068, 0xc820074060)
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/app.go:161 +0x527
created by golang.org/x/mobile/app.pump
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/app.go:190 +0x96
goroutine 21 [chan send]:
golang.org/x/mobile/gl.(*context).enqueue(0xc8200a2240, 0x2c, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/gl/work.go:87 +0x57
golang.org/x/mobile/gl.(*context).EnableVertexAttribArray(0xc8200a2240, 0x1)
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/gl/gl.go:535 +0x65
github.com/momchil-atanasov/go-whiskey-android/gles/client.(*attributeClient).EnableAttribute(0xc8200ac020, 0x4164fc0, 0xc8200ae1a0, 0x0, 0x0)
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/client/attribute.go:38 +0x90
github.com/momchil-atanasov/go-whiskey-android/gles/item.(*renderer).Render(0xc8200ae060, 0xd7c0380, 0xc8200aa040)
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/item/renderer.go:34 +0x1eb
github.com/momchil-atanasov/go-whiskey-android/gles.(*graphics).Flush(0xc8200b0000, 0x0, 0x0)
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/graphics.go:241 +0x1e7
github.com/momchil-atanasov/go-whiskey-demo/application.Draw()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/application/application.go:257 +0x303
main.(*Application).onDraw(0xc8200f3f38)
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:67 +0x14
main.(*Application).handlePaint(0xc8200f3f38, 0x0)
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:51 +0x25
main.(*Application).Run(0xc8200f3f38)
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:34 +0x195
main.main.func1(0x4744260, 0x4279a40)
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:19 +0x11c
golang.org/x/mobile/app.main.func1(0x41dc508)
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:60 +0x45
created by golang.org/x/mobile/app.main
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:63 +0x185
goroutine 34 [syscall, locked to thread]:
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1696 +0x1
I managed to hot-fix my demo application to use the gl.Context
concept. Further API modifications will need to follow, though as my idea was a bit different in terms of lifecycle.
I know all of this is experimental at his point in time but is there some thread where upcoming changes are discussed so that I can plan in advance and ask questions more freely?
OK, seeing as you're running on OS X, could you try:
$ go build yourbin
$ lldb yourbin
(lldb) run
...which will hopefully give us some kind of C backtrace.
As for the change, the discussions are mostly happening on CLs. If you filter golang-codereviews for mobile there were several context-like proposals for the gl package over the past few months. I avoided the proposal process for this because as you say this is a bit experimental, though in retrospect I probably should have so that users would get a louder warning about the API change. Sorry about that.
It would also be good to see a bit of the output before the failure of compiling the binary with -tags gldebug
. There may be a consistent sequence of calls that causes this.
Ok, so I managed to reproduce it with patch set 2 of the CL (just now noticed there is now patchset 4) and the lldb
tool. Here is the output I got:
Process 15729 launched: '/Users/momchil/Workspace/Go/bin/go-whiskey-demo' (x86_64)
2015/09/29 21:29:39 Running application...
Process 15729 stopped
* thread #3: tid = 0x4c8ac, 0x000000000ec88f75 AppleIntelHD5000GraphicsGLDriver`IntelTextureObj::getSurfaceHeapOffset(unsigned int, IntelStateHeaps*, unsigned int&, bool&) + 9, stop reason = EXC_BAD_ACCESS (code=1, address=0xf60)
frame #0: 0x000000000ec88f75 AppleIntelHD5000GraphicsGLDriver`IntelTextureObj::getSurfaceHeapOffset(unsigned int, IntelStateHeaps*, unsigned int&, bool&) + 9
AppleIntelHD5000GraphicsGLDriver`IntelTextureObj::getSurfaceHeapOffset:
-> 0xec88f75 <+9>: cmpl %esi, 0xf20(%rdi)
0xec88f7b <+15>: jne 0xec88f9d ; <+49>
0xec88f7d <+17>: cmpq %rdx, 0xf10(%rdi)
0xec88f84 <+24>: jne 0xec88f9d ; <+49>
I will try to reproduce it with gldebug
enabled but it seems to be harder due to the performance overhead of the output that is written, which might affect any race conditions, should that be the root cause.
Does typing bt
into lldb after the EXC_BAD_ACCESS is hit give you a backtrace?
Knowing that the segfault is happening inside the GL driver isn't going to make this much easier though I fear. I'll try to get your demo code running on my laptop and see if I can replicate this.
Here is a new execution with bt
.
Process 16155 launched: '/Users/momchil/Workspace/Go/bin/go-whiskey-demo' (x86_64)
2015/09/29 21:44:30 Running application...
Process 16155 stopped
* thread #3: tid = 0x4d802, 0x000000000d488f75 AppleIntelHD5000GraphicsGLDriver`IntelTextureObj::getSurfaceHeapOffset(unsigned int, IntelStateHeaps*, unsigned int&, bool&) + 9, stop reason = EXC_BAD_ACCESS (code=1, address=0xf60)
frame #0: 0x000000000d488f75 AppleIntelHD5000GraphicsGLDriver`IntelTextureObj::getSurfaceHeapOffset(unsigned int, IntelStateHeaps*, unsigned int&, bool&) + 9
AppleIntelHD5000GraphicsGLDriver`IntelTextureObj::getSurfaceHeapOffset:
-> 0xd488f75 <+9>: cmpl %esi, 0xf20(%rdi)
0xd488f7b <+15>: jne 0xd488f9d ; <+49>
0xd488f7d <+17>: cmpq %rdx, 0xf10(%rdi)
0xd488f84 <+24>: jne 0xd488f9d ; <+49>
(lldb) bt
* thread #3: tid = 0x4d802, 0x000000000d488f75 AppleIntelHD5000GraphicsGLDriver`IntelTextureObj::getSurfaceHeapOffset(unsigned int, IntelStateHeaps*, unsigned int&, bool&) + 9, stop reason = EXC_BAD_ACCESS (code=1, address=0xf60)
* frame #0: 0x000000000d488f75 AppleIntelHD5000GraphicsGLDriver`IntelTextureObj::getSurfaceHeapOffset(unsigned int, IntelStateHeaps*, unsigned int&, bool&) + 9
frame #1: 0x000000000d1075a4 AppleIntelHD5000GraphicsGLDriver`void updateBindingTable<SGfx3DStateBindingTablePointers>(Gen7Context*, unsigned int, SGfx3DStateBindingTablePointers&) + 2189
frame #2: 0x000000000d104a8b AppleIntelHD5000GraphicsGLDriver`Gen7Context::ProgramPipeline() + 17059
frame #3: 0x000000000d44dbe8 AppleIntelHD5000GraphicsGLDriver`glrIntelRenderVertexArray + 328
frame #4: 0x00007fff8d7b3c0a GLEngine`glDrawElements_ACC_GL3Exec + 388
frame #5: 0x00000000040036ac go-whiskey-demo`processFn + 876
frame #6: 0x00000000040032e7 go-whiskey-demo`_cgo_7c91b2ee9e85_Cfunc_process + 87
frame #7: 0x0000000004059e0a go-whiskey-demo`runtime.asmcgocall + 106 at asm_amd64.s:690
frame #8: 0x000000000402fda0 go-whiskey-demo`runtime.startTheWorldWithSema + 656 at proc1.go:609
frame #9: 0x000000000402fda0 go-whiskey-demo`runtime.startTheWorldWithSema + 656 at proc1.go:609
I'll be honest with you. Reproducing this is annoying as hell. At times (after you have been shaking the mouse left and right for more than 30 sec) it feels as though it is no longer reproducible until it crashes a few seconds later. I sometimes wonder if it might be something that aggregates over time, though I think once it failed much quicker.
Here is also a thread list if that helps in any way.
thread #1: tid = 0x4d7e9, 0x00007fff879dbc4c libsystem_pthread.dylib`__mtx_droplock + 426, queue = 'com.apple.main-thread'
thread #2: tid = 0x4d801, 0x000000000405bbfc go-whiskey-demo`runtime.usleep + 44 at sys_darwin_amd64.s:285
* thread #3: tid = 0x4d802, 0x000000000d488f75 AppleIntelHD5000GraphicsGLDriver`IntelTextureObj::getSurfaceHeapOffset(unsigned int, IntelStateHeaps*, unsigned int&, bool&) + 9, stop reason = EXC_BAD_ACCESS (code=1, address=0xf60)
thread #4: tid = 0x4d803, 0x000000000405bd2b go-whiskey-demo`runtime.mach_semaphore_wait + 11 at sys_darwin_amd64.s:407
thread #5: tid = 0x4d804, 0x000000000405bd2b go-whiskey-demo`runtime.mach_semaphore_wait + 11 at sys_darwin_amd64.s:407
thread #6: tid = 0x4d805, 0x00007fff8c10e232 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager'
thread #12: tid = 0x4d831, 0x000000000405bd2b go-whiskey-demo`runtime.mach_semaphore_wait + 11 at sys_darwin_amd64.s:407
thread #13: tid = 0x4d832, 0x00007fff8c10d136 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'CVDisplayLink'
thread #14: tid = 0x4d837, 0x00007fff8c1084de libsystem_kernel.dylib`mach_msg_trap + 10
thread #16: tid = 0x4d84d, 0x000000000405bd2b go-whiskey-demo`runtime.mach_semaphore_wait + 11 at sys_darwin_amd64.s:407
thread #17: tid = 0x4d84f, 0x000000000405bd2b go-whiskey-demo`runtime.mach_semaphore_wait + 11 at sys_darwin_amd64.s:407
thread #18: tid = 0x4d857, 0x000000000405bd2b go-whiskey-demo`runtime.mach_semaphore_wait + 11 at sys_darwin_amd64.s:407
thread #19: tid = 0x4d858, 0x000000000405bd2b go-whiskey-demo`runtime.mach_semaphore_wait + 11 at sys_darwin_amd64.s:407
thread #20: tid = 0x4d867, 0x000000000405bd2b go-whiskey-demo`runtime.mach_semaphore_wait + 11 at sys_darwin_amd64.s:407
thread #21: tid = 0x4d88d, 0x00007fff8c10d94a libsystem_kernel.dylib`__workq_kernreturn + 10
thread #22: tid = 0x4d8b6, 0x000000000405bd2b go-whiskey-demo`runtime.mach_semaphore_wait + 11 at sys_darwin_amd64.s:407
Ah. That's interesting.
So you are getting an EXC_BAD_ACCESS (that is, a segfault) from a call to glDrawElements. In particular, I believe it says it is trying to read the memory at address=0xf60. That's an amazingly small pointer.
In fact, it's probably not a pointer. The only version of glDrawElements we expose through the gl Go package is the one where the pointer is not a pointer, but an offset into a vertex attrib array. (This is the only meaning of the parameter in GLES2, but in desktop OpenGL it can be a host memory pointer.)
It looks like OS X's driver is treating indicies as a host memory pointer instead of an offset, which means you have probably got in a state where you don't have a vertex attribute array enabled. On a GLES2 device this would probably be an error, but on desktop GL this turns into a panic.
To diagnose this, please try replicating the bug with -tags gldebug, and then working backwards from the failure in the log looking for EnableVertexAttribArray and DisableVertexAttribArray. I'm guessing you don't have one enabled due to a hard-to-reproduce bug in your code.
(I filed #12786 to improve debugging in a case like this.)
The latest version of -tags gldebug that is submitted includes checking to make sure there's no concurrency misuse of gl.Context and should make any driver crashes a little clearer. Let me know if you have any luck tracing {Enable,Disable}VertexAttribArray through the logs it generates @momchil-atanasov. It will be many megabytes of output, but if you run it to a file only the last few kilobytes should be relevant.
I am still trying to reason this through. The code that is executed each frame in the demo application is pretty much the same (at least with regard to the number and types of EnableVertexAttribArray/DisableVertexAttribArray calls). Unless I have coded something I forgot about, there should be no concurrent routines anywhere during rendering. So if it doesn't crash during the first frame, it should never crash.
Still, I am going to give it a try. Maybe I am missing something.
I agree on your reasoning, but that means we have no leads on what's causing the bug. I got your demo building yesterday and spent a while trying to replicate the crash myself, but couldn't.
Could I suggest: put a log.Print("frame start") and log.Print("frame end") at the edges of your paint cycle, then run with -tags gldebug. When you get a failure, take the last frame and compare the text to the first frame. Any variation could give away the bug.
I will. I just have some code in one of the repositories that is unfinished that I should complete and commit.
BTW, I tried building the app with the -race
flag and running it and it crashed immediately on start with a race condition. I know this is not the paint flow but could point to a potential issue.
2015/10/01 21:24:33 Running application...
==================
WARNING: DATA RACE
Read by main goroutine:
golang.org/x/mobile/app.lifecycleAlive()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:212 +0xb6
runtime.call32()
/private/var/folders/q8/bf_4b1ts2zj0l7b0p1dv36lr0000gp/T/workdir/go/src/runtime/asm_amd64.s:437 +0x3d
golang.org/x/mobile/app.main()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:65 +0x1eb
golang.org/x/mobile/app.Main()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/app.go:21 +0x2e
main.main()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:20 +0x30
Previous write by goroutine 8:
golang.org/x/mobile/app.loop()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:82 +0x265
Goroutine 8 (running) created at:
golang.org/x/mobile/app.startloop()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:119 +0x42
runtime.call32()
/private/var/folders/q8/bf_4b1ts2zj0l7b0p1dv36lr0000gp/T/workdir/go/src/runtime/asm_amd64.s:437 +0x3d
golang.org/x/mobile/app.main()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:65 +0x1eb
golang.org/x/mobile/app.Main()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/app.go:21 +0x2e
main.main()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:20 +0x30
==================
==================
WARNING: DATA RACE
Read by goroutine 7:
golang.org/x/mobile/gl.(*context).enqueue()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/gl/work.go:88 +0x52
golang.org/x/mobile/gl.(*context).CreateBuffer()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/gl/gl.go:333 +0x7e
github.com/momchil-atanasov/go-whiskey-android/gles/client.(*bufferClient).CreateBuffer()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/client/buffer.go:25 +0x89
github.com/momchil-atanasov/go-whiskey-android/gles/client.(*glesClient).CreateBuffer()
<autogenerated>:2 +0x67
github.com/momchil-atanasov/go-whiskey-android/gles/buffer.(*indexBuffer).Create()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/buffer/index_buffer.go:56 +0x5c
github.com/momchil-atanasov/go-whiskey-android/gles/buffer.(*managedIndexBuffer).Create()
<autogenerated>:46 +0x74
github.com/momchil-atanasov/go-whiskey-android/gles/resource.(*lifecycleManager).CreateNewResources.func1()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/resource/lifecycle.go:158 +0x134
github.com/momchil-atanasov/go-whiskey-android/gles/resource.eachHandleInList()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/resource/lifecycle.go:243 +0x8c
github.com/momchil-atanasov/go-whiskey-android/gles/resource.(*lifecycleManager).CreateNewResources()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/resource/lifecycle.go:166 +0xb0
github.com/momchil-atanasov/go-whiskey-android/gles.(*graphics).Initialize()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/graphics.go:166 +0x11c
github.com/momchil-atanasov/go-whiskey-demo/application.Create()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/application/application.go:134 +0x6d3
main.(*Application).onStart()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:59 +0x38
main.(*Application).handleLifecycle()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:43 +0xe4
main.(*Application).Run()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:32 +0x282
main.main.func1()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:19 +0x178
golang.org/x/mobile/app.main.func1()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:60 +0x70
Previous write by goroutine 8:
golang.org/x/mobile/app.loop()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:82 +0x104
Goroutine 7 (running) created at:
golang.org/x/mobile/app.main()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:63 +0x1e6
golang.org/x/mobile/app.Main()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/app.go:21 +0x2e
main.main()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:20 +0x30
Goroutine 8 (running) created at:
golang.org/x/mobile/app.startloop()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:119 +0x42
runtime.call32()
/private/var/folders/q8/bf_4b1ts2zj0l7b0p1dv36lr0000gp/T/workdir/go/src/runtime/asm_amd64.s:437 +0x3d
golang.org/x/mobile/app.main()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:65 +0x1eb
golang.org/x/mobile/app.Main()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/app.go:21 +0x2e
main.main()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:20 +0x30
==================
==================
WARNING: DATA RACE
Read by goroutine 7:
golang.org/x/mobile/gl.(*context).enqueue()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/gl/work.go:91 +0x93
golang.org/x/mobile/gl.(*context).CreateBuffer()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/gl/gl.go:333 +0x7e
github.com/momchil-atanasov/go-whiskey-android/gles/client.(*bufferClient).CreateBuffer()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/client/buffer.go:25 +0x89
github.com/momchil-atanasov/go-whiskey-android/gles/client.(*glesClient).CreateBuffer()
<autogenerated>:2 +0x67
github.com/momchil-atanasov/go-whiskey-android/gles/buffer.(*indexBuffer).Create()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/buffer/index_buffer.go:56 +0x5c
github.com/momchil-atanasov/go-whiskey-android/gles/buffer.(*managedIndexBuffer).Create()
<autogenerated>:46 +0x74
github.com/momchil-atanasov/go-whiskey-android/gles/resource.(*lifecycleManager).CreateNewResources.func1()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/resource/lifecycle.go:158 +0x134
github.com/momchil-atanasov/go-whiskey-android/gles/resource.eachHandleInList()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/resource/lifecycle.go:243 +0x8c
github.com/momchil-atanasov/go-whiskey-android/gles/resource.(*lifecycleManager).CreateNewResources()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/resource/lifecycle.go:166 +0xb0
github.com/momchil-atanasov/go-whiskey-android/gles.(*graphics).Initialize()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/graphics.go:166 +0x11c
github.com/momchil-atanasov/go-whiskey-demo/application.Create()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/application/application.go:134 +0x6d3
main.(*Application).onStart()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:59 +0x38
main.(*Application).handleLifecycle()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:43 +0xe4
main.(*Application).Run()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:32 +0x282
main.main.func1()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:19 +0x178
golang.org/x/mobile/app.main.func1()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:60 +0x70
Previous write by goroutine 8:
golang.org/x/mobile/app.loop()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:82 +0x104
Goroutine 7 (running) created at:
golang.org/x/mobile/app.main()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:63 +0x1e6
golang.org/x/mobile/app.Main()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/app.go:21 +0x2e
main.main()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:20 +0x30
Goroutine 8 (running) created at:
golang.org/x/mobile/app.startloop()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:119 +0x42
runtime.call32()
/private/var/folders/q8/bf_4b1ts2zj0l7b0p1dv36lr0000gp/T/workdir/go/src/runtime/asm_amd64.s:437 +0x3d
golang.org/x/mobile/app.main()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:65 +0x1eb
golang.org/x/mobile/app.Main()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/app.go:21 +0x2e
main.main()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:20 +0x30
==================
==================
WARNING: DATA RACE
Read by goroutine 7:
golang.org/x/mobile/gl.(*context).enqueue()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/gl/work.go:96 +0xfa
golang.org/x/mobile/gl.(*context).CreateBuffer()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/gl/gl.go:333 +0x7e
github.com/momchil-atanasov/go-whiskey-android/gles/client.(*bufferClient).CreateBuffer()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/client/buffer.go:25 +0x89
github.com/momchil-atanasov/go-whiskey-android/gles/client.(*glesClient).CreateBuffer()
<autogenerated>:2 +0x67
github.com/momchil-atanasov/go-whiskey-android/gles/buffer.(*indexBuffer).Create()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/buffer/index_buffer.go:56 +0x5c
github.com/momchil-atanasov/go-whiskey-android/gles/buffer.(*managedIndexBuffer).Create()
<autogenerated>:46 +0x74
github.com/momchil-atanasov/go-whiskey-android/gles/resource.(*lifecycleManager).CreateNewResources.func1()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/resource/lifecycle.go:158 +0x134
github.com/momchil-atanasov/go-whiskey-android/gles/resource.eachHandleInList()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/resource/lifecycle.go:243 +0x8c
github.com/momchil-atanasov/go-whiskey-android/gles/resource.(*lifecycleManager).CreateNewResources()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/resource/lifecycle.go:166 +0xb0
github.com/momchil-atanasov/go-whiskey-android/gles.(*graphics).Initialize()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/graphics.go:166 +0x11c
github.com/momchil-atanasov/go-whiskey-demo/application.Create()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/application/application.go:134 +0x6d3
main.(*Application).onStart()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:59 +0x38
main.(*Application).handleLifecycle()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:43 +0xe4
main.(*Application).Run()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:32 +0x282
main.main.func1()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:19 +0x178
golang.org/x/mobile/app.main.func1()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:60 +0x70
Previous write by goroutine 8:
golang.org/x/mobile/app.loop()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:82 +0x104
Goroutine 7 (running) created at:
golang.org/x/mobile/app.main()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:63 +0x1e6
golang.org/x/mobile/app.Main()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/app.go:21 +0x2e
main.main()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:20 +0x30
Goroutine 8 (running) created at:
golang.org/x/mobile/app.startloop()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:119 +0x42
runtime.call32()
/private/var/folders/q8/bf_4b1ts2zj0l7b0p1dv36lr0000gp/T/workdir/go/src/runtime/asm_amd64.s:437 +0x3d
golang.org/x/mobile/app.main()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:65 +0x1eb
golang.org/x/mobile/app.Main()
/Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/app.go:21 +0x2e
main.main()
/Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-demo/main.go:20 +0x30
==================
If you still have the demo application setup from yesterday (currently one of the project's master branches is not aligned with the rest), you could try using -race
as well.
Done, I have pushed my changes, so master should work again.
I am still able to reproduce it with the default ./run
command. All it takes is really rapid dragging left and right - at times from end to end of the screen; at times only in a small horizontal interval - for about 30sec to 60sec.
Anyway, I tried to reproduce it with -tags gldebug
but had no luck. If it's a concurrency issue (which I think it might be), then the internal synchronization in the log
package (https://golang.org/src/log/log.go?s=4899:4953#L133) combined with the overhead of writing to stdout / file could be preventing it from occurring. Maybe you were trying to reproduce it this way and that's why you had no luck yesterday.
CL https://golang.org/cl/15460 mentions this issue.
It was an issue due to the violation of cgo pointer rules. As of e7d6f7c, it seems not an issue anymore. Today, the basic app does not produce any segmentation fault at close. This should be resolved already. Close.
Ok, I have experienced this issue in two different ways.
The first way is with the
basic
example application. If I resize the window vertically to 0px height, I get the following error on the terminal.The second one is a bit more complicated. It involves a massive amount of manual window resizing until the application crashes. Additionally, it involves a framework of mine that is not much concurrency-friendly. Then again, I am doing all of the calls from the app event lifecycle loop and never spawn any go routines so I should be all right.
Note: I have deleted parts of the stack trace and replaced with
....................
.What I noticed is that in all attempts, it always crashes when doing a call to
gl.UniformMatrix4fv
.I spent a considerable amount of time trying to reproduce it with the
basic
example but failed. In my scenario I am allocating a considerable amount more memory (textures, shaders, matrices) which could have some effect.If the stack trace doesn't give you any ideas as to what it might be, you can leave it for now. It is a pain to reproduce it with my app and it seems impossible to do with the
basic
one.