filament
filament copied to clipboard
google
TPanic crash
Above is the crashed thread stack and info which crash at FEngine::Loop. Is there clue the crash happen?
the crash happened:
I checked the possible panic at FEngine::Loop，is the crash happened here？
Our panic macros emit messages, is it possible for you to obtain more complete log output?
yes, I've tried to print the emit messages to our app log, but I've found that sometimes it didn't invoke the panic function.
If all panic will invoke the e.log()?
@starccode Are you able to show us the full log output of your program when it crashes?
@starccode Are you able to show us the full log output of your program when it crashes?
no problem, I'm trying to collect the crash log, I will show the log as soon as I get them~
Recently, I've collected some TPanic crash macro output log, here it is:
- Panic in MetalTexture:474 reason: Could not create Metal texture. Out of memory?
2.Panic in acquireDrawable:145 reason: Could not obtain drawable.
for the first crash log, I've checked the memory info log when crash happened, and it seems not "Out of memory", maybe I should emit the reason of why create metal texture failed. And I wanna know if it's necessary to trigger abort when create texture failed? @bejado
Internally, Filament calls Metal API methods on a separate thread which is not set up to report asynchronous failures. If newTextureWithDescriptor is returning nil, then your app is most likely running out of memory. You could experiment with reducing the amount of texture allocations and/or their size/pixel format to reduce memory pressure. You could also see if iOS is sending your app low memory warnings and respond accordingly.
Closing for now, but feel free to reopen if you suspect there's a bug in Filament.