Question about possible delay

[JackKaiXing]

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.

filament/filament/backend/src/CommandBufferQueue.cpp

Line 151 in 8d6e8b8

mCondition.wait(lock);

Any other possibility of this wait?

[z3moon]

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.

[JackKaiXing]

@z3moon
Sorry for the missing information.

1. it is a delay, usually 10000+ms;
2. filament 1.56.6;
3. reproduction rate is less that 1%;
4. Metal, ios;
5. 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;
6. we do not have access to other threads stack for now.

[z3moon]

@bejado for visibility. Any suggestions to narrow this down?

[pixelflinger]

I think we fixed this very recently. Can you retry with a build from today?

[JackKaiXing]

@pixelflinger this one #9377?

[pixelflinger]

@pixelflinger this one #9377?

Yes

[JackKaiXing]

I think it is not our case since we use filament 1.56.6 where FrameInfoImpl does not have a fence as member;

filament/filament/src/FrameInfo.h

Line 62 in 51e0607

backend::FenceHandle fence{}; // the fence used for gpuFrameComplete

Would you please take a look at the stack of our delay? Can you explain more why our delay stack is related to #9377?