Skip to content

x/mobile: App exits with Segmentation Fault #12718

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
mokiat opened this issue Sep 22, 2015 · 25 comments
Closed

x/mobile: App exits with Segmentation Fault #12718

mokiat opened this issue Sep 22, 2015 · 25 comments
Labels
FrozenDueToAge mobile Android, iOS, and x/mobile
Milestone
Unreleased

Comments

@mokiat
Copy link

mokiat commented Sep 22, 2015

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.

$ go install golang.org/x/mobile/example/basic && basic
Segmentation fault: 11

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.

fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0xf60 pc=0xcc88f75]

runtime stack:
runtime.throw(0x421d500, 0x2a)
    /usr/local/go/src/runtime/panic.go:527 +0x90
runtime.sigpanic()
    /usr/local/go/src/runtime/sigpanic_unix.go:12 +0x5a

goroutine 7 [syscall, locked to thread]:
runtime.cgocall(0x40035c0, 0xc820231c30, 0xc800000000)
    /usr/local/go/src/runtime/cgocall.go:120 +0x11b fp=0xc820231bf8 sp=0xc820231bc8
golang.org/x/mobile/gl._Cfunc_process(0xa)
    ??:0 +0x31 fp=0xc820231c30 sp=0xc820231bf8
golang.org/x/mobile/gl.DoWork()
    /Users/momchil/Workspace/Go/src/golang.org/x/mobile/gl/work.go:108 +0x2be fp=0xc820231e50 sp=0xc820231c30
golang.org/x/mobile/app.loop(0x4737450)
    /Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:85 +0x10b fp=0xc820231fa8 sp=0xc820231e50
runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:1696 +0x1 fp=0xc820231fb0 sp=0xc820231fa8
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(0x4233fd8)
    /Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/darwin_amd64.go:65 +0x18a
golang.org/x/mobile/app.Main(0x4233fd8)
    /Users/momchil/Workspace/Go/src/golang.org/x/mobile/app/app.go:21 +0x21
main.main()
                                        ......................................

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:1696 +0x1

goroutine 5 [select]:
golang.org/x/mobile/app.pump.func1(0xc820030070, 0xc820016240)
    /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 6 [chan receive]:
golang.org/x/mobile/gl.enqueue(0x80, 0x0, 0x1, 0xc8200b8e80, 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(0x0, 0xc8200b8e80, 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(0x43091e0, 0x41afbc0, 0xc8202600e0, 0xc8200b8e80, 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(0xc8200b8e80, 0xe724000, 0x43091e0, 0x41afbc0, 0xc8202600e0)
    /Users/momchil/Workspace/Go/src/github.com/momchil-atanasov/go-whiskey-android/gles/uniform/uniform.go:103 +0x75
                                        ......................................
golang.org/x/mobile/app.main.func1(0x4233fd8)
    /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 18 [syscall, 1 minutes, locked to thread]:
runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:1696 +0x1

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.
@rakyll
Copy link
Contributor

rakyll commented Sep 22, 2015

/cc @nigeltao

@rakyll rakyll added this to the Unreleased milestone Sep 22, 2015
@nigeltao
Copy link
Contributor

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.

@mokiat
Copy link
Author

mokiat commented Sep 23, 2015

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).

@mokiat
Copy link
Author

mokiat commented Sep 23, 2015

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.

@crawshaw
Copy link
Member

(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.

@mokiat
Copy link
Author

mokiat commented Sep 25, 2015

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.

@crawshaw
Copy link
Member

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.

@crawshaw
Copy link
Member

@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.

@gopherbot
Copy link
Contributor

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

@mokiat
Copy link
Author

mokiat commented Sep 28, 2015

@crawshaw Sure, I'll try it out. I might need some time though.

@mokiat
Copy link
Author

mokiat commented Sep 28, 2015

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?

@crawshaw
Copy link
Member

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.

crawshaw added a commit to golang/mobile that referenced this issue Sep 29, 2015
@crawshaw
gl: compatibility with cgo pointer rules proposal
0081b7a 
The current cgo proposal (golang/go#12416) is at:

https://github.com/golang/proposal/blob/master/design/12416-cgo-pointers.md

Maybe relevant to golang/go#12718

Change-Id: I5a399eec703ba3a793ab64d979bb73b083f23df9
Reviewed-on: https://go-review.googlesource.com/15100
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
@crawshaw
Copy link
Member

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.

@mokiat
Copy link
Author

mokiat commented Sep 29, 2015

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.

@crawshaw
Copy link
Member

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.

@mokiat
Copy link
Author

mokiat commented Sep 29, 2015

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.

@mokiat
Copy link
Author

mokiat commented Sep 29, 2015

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

@crawshaw crawshaw mentioned this issue Sep 29, 2015
Closed
@crawshaw
Copy link
Member

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.)

@crawshaw
Copy link
Member

crawshaw commented Oct 1, 2015

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.

@mokiat
Copy link
Author

mokiat commented Oct 1, 2015

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.

@crawshaw
Copy link
Member

crawshaw commented Oct 1, 2015

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.

@mokiat
Copy link
Author

mokiat commented Oct 1, 2015

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.

@mokiat
Copy link
Author

mokiat commented Oct 1, 2015

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.

@gopherbot
Copy link
Contributor

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

crawshaw added a commit to golang/mobile that referenced this issue Oct 6, 2015
@crawshaw
app: move glctx into app.App
8a578fa 
Also move the initialization of glctx to an init function, removing
the data race mentioned in golang/go#12718. (Unfortunately the data
race is not the cause of the bug.)

Change-Id: If5f1fd7755d5645cf25ccc780ee8d138011c8f10
Reviewed-on: https://go-review.googlesource.com/15460
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
@gopherbot gopherbot added the mobile Android, iOS, and x/mobile label Jul 20, 2017
This was referenced Mar 25, 2019
Merged
Open
imWildCat pushed a commit to imWildCat/go-mobile that referenced this issue Apr 10, 2021
@crawshaw
gl: compatibility with cgo pointer rules proposal
e7d6f7c 
The current cgo proposal (golang/go#12416) is at:

https://github.com/golang/proposal/blob/master/design/12416-cgo-pointers.md

Maybe relevant to golang/go#12718

Change-Id: I5a399eec703ba3a793ab64d979bb73b083f23df9
Reviewed-on: https://go-review.googlesource.com/15100
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
imWildCat pushed a commit to imWildCat/go-mobile that referenced this issue Apr 10, 2021
@crawshaw
app: move glctx into app.App
5621ef1 
Also move the initialization of glctx to an init function, removing
the data race mentioned in golang/go#12718. (Unfortunately the data
race is not the cause of the bug.)

Change-Id: If5f1fd7755d5645cf25ccc780ee8d138011c8f10
Reviewed-on: https://go-review.googlesource.com/15460
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
imWildCat pushed a commit to imWildCat/go-mobile that referenced this issue Apr 11, 2021
@crawshaw
gl: compatibility with cgo pointer rules proposal
2fa2daf 
The current cgo proposal (golang/go#12416) is at:

https://github.com/golang/proposal/blob/master/design/12416-cgo-pointers.md

Maybe relevant to golang/go#12718

Change-Id: I5a399eec703ba3a793ab64d979bb73b083f23df9
Reviewed-on: https://go-review.googlesource.com/15100
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
imWildCat pushed a commit to imWildCat/go-mobile that referenced this issue Apr 11, 2021
@crawshaw
app: move glctx into app.App
68ae6b6 
Also move the initialization of glctx to an init function, removing
the data race mentioned in golang/go#12718. (Unfortunately the data
race is not the cause of the bug.)

Change-Id: If5f1fd7755d5645cf25ccc780ee8d138011c8f10
Reviewed-on: https://go-review.googlesource.com/15460
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
@changkun
Copy link
Member

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.

@golang golang locked and limited conversation to collaborators Jun 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge mobile Android, iOS, and x/mobile
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
6 participants
@rakyll @crawshaw @changkun @mokiat @nigeltao @gopherbot