-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
1.16 Android mystery crash thread #18116
Comments
|
I finally figured out this old crash:
It can happen if a null value was inserted into the hash map, which can happen if shader generation fails (which itself is very bad and we should assert out from). Will fix this. In other news, this is still around:
|
In 1.16.1, getting some unexpected crash reports from the soft gpu:
|
Hm, these look like calling null pointers, and could be caused by me missing something in my DenseHashMap refactor ( #18129 ) The code does look right, though, and it seems to run for me.. EDIT: These are now fixed. |
OK, this one is interesting, I feel we should have caught this before and made it an artificial memory exception:
|
Hm, in 1.16.3, I still have some of those destroyed-mutex crashes.. Plus, this one has surfaced:
another:
|
I thought I had fixed every avenue for the shader promise mutex crash, but seems not:
Figuring this out is gonna be the priority 1 for 1.16.4... |
Hm, could it be some corruption of the MIPSState? Or thread data? -[Unknown] |
ANR: thread 1:
thread 2:
thread 3:
|
The FinalizeBlock crash still really bothers me, I don't see how it can possibly happen with the new assert I added to the caller...
fairly large block count, can it have anything to do with clears? I don't get it. |
Also, destroyedmutex a few posts above still haunts me. No clue how we end up trying to create a pipeline from deleted shaders. Another shutdown race condition? Can't get it to repro. |
Here's one, not so common, that's not much of a mystery, but just some lack of range checks when reading indices buffers:
|
Hm, regarding the FinalizeBlock issue above... On ARM/ARM64, MAX_JIT_BLOCK_EXITS is set to only 2, while 8 on x86. Maybe we somehow get more? Because looking at the struct, it looks like overflowing the exitPtrs/exitAddress arrays could cause trouble by stomping the |
Here's a rare-ish one, it's happened twice on two different devices. Symbolizing the address leads to somewhere in the implementation of std::map. I don't see how though:
The SymbolMap has really comprehensive locking and isn't returning any internal pointers outwards.. |
I think request responses might arrive after the calling screen has been closed.. Though shouldn't be common.. |
Closing this, will start over after the next release. I expect we'll find a couple of these again... |
Alright, looking at Google Play crash reports again, a few reports have started to come in.
Kinda similar:
Similar:
The text was updated successfully, but these errors were encountered: