Closed hajimehoshi closed 1 year ago
Hmm? They use a mutex in slice
, so this seems concurrent safe.
I think I found the cause, but the fix would not be obvious.
I'm not sure the output from the race detector and the stack trace after panicking are 100% the same issue but they seem related. Full logs of both can be found here: https://gist.github.com/sinisterstuf/644ef4d47aba4f5737e540001305c5cb
@sinisterstuf Is there a minimum program to reproduce this issue? Thanks!
Not yet but I can try to write one. Currently the crashes are coming from running this game as-is, however it is rare, and unpredictable when the crash will occur because of the nature of the data race. Maybe on Friday I can try to write a small program that does concurrent draw calls, similarly to this, but with much higher load, so as to increase the chances of a panic.
As 1) this is pretty rare, and 2) we need nonsignificant amount of work to fix this, I'll postpone to fix this to v2.5.
Please try 61f1d8b69f144c84ba8fe8914cd51309ca7bf822. Thanks
Yes, I can confirm that using this version the go tool does not detect any data races and the game does not crash ☺️🎉
Ebitengine Version
d898bb1ce4f2cb6a819e00c0b5bd30ef1e638775
Operating System
Go Version (
go version
)go version go1.19.2 darwin/amd64
What steps will reproduce the problem?
-race
sometimes detects the race condition in this function.What is the expected result?
No race condition.
What happens instead?
A race condition is detected at https://github.com/hajimehoshi/ebiten/blob/2.4/internal/graphics/vertex.go#L153
Anything else you feel useful to add?
@sinisterstuf reported this.