Question about possible delay
Hi, we encountered a deadlock/severe delay. the stack is
__psynch_cvwait (in libsystem_kernel.dylib) + 8 _pthread_cond_wait (in libsystem_pthread.dylib) + 984 std::__1::condition_variable::wait(std::__1::unique_lock&) (in libc++.1.dylib) + 32 filament::FFence::FenceSignal::wait(unsigned long long) filament::FFence::waitAndDestroy(filament::FFence*, filament::Fence::Mode) filament::FRenderer::terminate(filament::FEngine&) filament::FEngine::destroy(filament::FRenderer const*)
is there any possibility that the below condition is also waiting, so that the new created Fence would never signal. Besides, we did not call Engine::setPaused. https://github.com/google/filament/blob/8d6e8b8b3cc741bfa9bcf01174208cc7199cb694/filament/backend/src/CommandBufferQueue.cpp#L151
Any other possibility of this wait?
could you share more details? e.g.,
was it just a delay or a deadlock? they're very distinct. what filament version (or hash) were you at? what is the reproduction rate? what backend (OpenGL, Vulkan, ..) did you use? which platform did you use? what was the app doing when it hung. can you share full stacktrace (including other threads) ? etc.
@z3moon Sorry for the missing information.
- it is a delay, usually 10000+ms;
- filament 1.56.6;
- reproduction rate is less that 1%;
- Metal, ios;
- we create a single engine instance, but multiple group of renderer&view&scene for different ViewController; the delay happens when we destroy the earliest created group of renderer&view&scene&ViewController. Besides, only the newest created renderer::render is called, because we hide the other ViewControllers and we just stop calling its renderer::render;
- we do not have access to other threads stack for now.
@bejado for visibility. Any suggestions to narrow this down?
I think we fixed this very recently. Can you retry with a build from today?
@pixelflinger this one https://github.com/google/filament/pull/9377?
@pixelflinger this one https://github.com/google/filament/pull/9377?
Yes
I think it is not our case since we use filament 1.56.6 where FrameInfoImpl does not have a fence as member;
https://github.com/google/filament/blob/51e0607b42374efa14412473c45022f2ea65f60a/filament/src/FrameInfo.h#L62
Would you please take a look at the stack of our delay? Can you explain more why our delay stack is related to #9377?