[Interest] Will TSAN_OPTIONS=detect_deadlocks=1 work when Qt is compiled with -sanitize thread?

[Nuno Santos]

Thiago,

Thanks for your analysis.

I don’t know if I have stumbled on a Qt bug or not.

What we have found was that emitting signals even if queued inside a thread that was started from the audio thread is provoking this locks.

Sometimes it locks the UI but most of the times it locks the audio thread.

We have 18 tracks and they are processed in a different thread via qt::concurrent run inside the audio thread and then we wait for them to complete.

In order to accelerate the freezes what we have done was to call this signals hundreds or thousands of times.

As a workaround, instead of calling signals we are marking our model as dirty and using a timer on the main thread to check which entities are dirty in order to fire the signal from the main thread.

In order to submit a bug to qt I would need to be able to reproduce this in a much more simpler examples.

Taking this into account. Do you think this could be a bug on Qt?

Thanks you!
--
Nuno Santos

> No dia 19/07/2024, às 16:58, Thiago Macieira <thiago.macieira at intel.com> escreveu:
> 
> On Friday 19 July 2024 07:15:19 GMT-7 Nuno Santos via Interest wrote:
>> (lldb) bt all
>> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
>>  * frame #0: 0x00000001db7aa1cc libsystem_kernel.dylib`__psynch_cvwait + 8
>>    frame #1: 0x00000001ef5096e4 libsystem_pthread.dylib`_pthread_cond_wait
>> + 1228
>> frame #2: 0x0000000103e04bc4
>> BAM`QWaitConditionPrivate::wait(QDeadlineTimer) + 64 frame #3:
>> 0x0000000103e04b18 BAM`QWaitCondition::wait(QMutex*, QDeadlineTimer) + 148
>> frame #4: 0x000000010313a960
>> BAM`QSGThreadedRenderLoop::polishAndSync(QSGThreadedRenderLoop::Window*,
>> bool) + 1544
>> frame #5: 0x000000010313ae38
>> BAM`QSGThreadedRenderLoop::handleUpdateRequest(QQuickWindow*) + 364
> 
> This is one of the frozen threads. It's inside the Scene Graph waiting on a
> QWaitCondition for an event notification. The question is what its partner
> thread, the one that is supposed to notify on this WC but isn't doing so?
> 
> The only one running SG code is thread 26:
> 
>> thread #26, name = 'QSGRenderThread'
>>    frame #0: 0x0000000103567f40
>>    BAM`QRhiMetal::enqueueResourceUpdates(QRhiCommandBuffer*,
>>    QRhiResourceUpdateBatch*) + 948
>>    frame #1: 0x0000000103007724
>>    BAM`QSGBatchRenderer::Renderer::prepareRenderPass(QSGBatchRenderer::Ren
>>    derer::RenderPassContext*) + 2264
>>    frame #2: 0x0000000103006dcc
>>    BAM`QSGBatchRenderer::Renderer::render() + 36
>>    frame #3:
>>    0x000000010301bb70 BAM`QSGRenderer::renderScene() + 344
> 
> But this thread isn't frozen: it's not stopped at a system call. If this is
> the thread that should have notified the WC, why didn't it? Or why hasn't it
> got to the notification yet (that would be a livelock, not a deadlock)?
> 
> Or has it notified by the other thread didn't get it?
> 
> Either way, I think you've found a Qt bug. Please test with 6.7 or 6.8 betas,
> and report it with the updated backtrace.
> 
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Principal Engineer - Intel DCAI Platform & System Engineering
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest