You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We now have a command buffer and a thread switch between when a GL method is called in Go and when it is executed in the driver, making it hard to debug a segfault or similar from the GL driver (see #12718 for an example).
This could be improved in -tags gldebug mode by shrinking the workbuffer from 3 to 1, and turning all GL calls into blocking calls. Then a Go panic would at least include the name of the GL function that caused the segfault.
The text was updated successfully, but these errors were encountered:
This means that if the OpenGL driver crashes, the stack trace will
contain a goroutine blocked in the function that caused the panic.
Fixesgolang/go#12786
Change-Id: I039c74f9e24de777b925475a50e8c96129692f70
Reviewed-on: https://go-review.googlesource.com/15160
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
imWildCat
pushed a commit
to imWildCat/go-mobile
that referenced
this issue
Apr 11, 2021
This means that if the OpenGL driver crashes, the stack trace will
contain a goroutine blocked in the function that caused the panic.
Fixesgolang/go#12786
Change-Id: I039c74f9e24de777b925475a50e8c96129692f70
Reviewed-on: https://go-review.googlesource.com/15160
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
We now have a command buffer and a thread switch between when a GL method is called in Go and when it is executed in the driver, making it hard to debug a segfault or similar from the GL driver (see #12718 for an example).
This could be improved in -tags gldebug mode by shrinking the workbuffer from 3 to 1, and turning all GL calls into blocking calls. Then a Go panic would at least include the name of the GL function that caused the segfault.
The text was updated successfully, but these errors were encountered: