Screen freeze when app running in QNX (I think deadlock in Qt event loop)
-
Hi everyone
This is first time I make a question in Qt forum. (forgive my mistake)
I develop an UI application using Qml in QNX 7.0 board. In normal case, mean user touch screen slowly, board work smoothly. But in stress test, user touch quickly, my app have to transit screen quickly (load and unload), screen freeze. No log in main thread, other thread work properly. In QNX, main thread status is CONDVAR.
Experienced programmer, please help me how to detect freezing reason and resolve it. Or guide me how to know Qt event loop status and get Qt log.
Help please.wrote on 28 Nov 2017, 14:48 last edited by@minhthanh Seems like your application is getting into deadlock. Use appropriate debugger for your platform to find out where application is stuck.
-
wrote on 1 Dec 2017, 02:55 last edited by
But this issue only happen once. I can not reproduce. You met this issue ever? QEventLoop use a mutex (or something similar) ?
-
But this issue only happen once. I can not reproduce. You met this issue ever? QEventLoop use a mutex (or something similar) ?
wrote on 1 Dec 2017, 08:39 last edited by@minhthanh If deadlock is caused by race, it may be very hard to reproduce.
You met this issue ever?
I haven't ever used QNX
QEventLoop use a mutex
There is mutext acquisition when signal is handled in a different thread
-
Hi everyone
This is first time I make a question in Qt forum. (forgive my mistake)
I develop an UI application using Qml in QNX 7.0 board. In normal case, mean user touch screen slowly, board work smoothly. But in stress test, user touch quickly, my app have to transit screen quickly (load and unload), screen freeze. No log in main thread, other thread work properly. In QNX, main thread status is CONDVAR.
Experienced programmer, please help me how to detect freezing reason and resolve it. Or guide me how to know Qt event loop status and get Qt log.
Help please.wrote on 1 Dec 2017, 08:47 last edited byAlso, deadlock is most probably not in event loop but in your code. It just prevents event loop from running, so one of locked threads is probably main thread.
-
wrote on 4 Dec 2017, 07:03 last edited by
Thank for your supports.
I think deadlock happen when we have 2 mutexs.
I only use 1 pthread_mutex_lock in main thread and I don't think it cause deadlock. I will try to remove it and reproduce. -
wrote on 4 Dec 2017, 07:53 last edited by
We have a thread to fetch data (QAbstractiListModel) to display in UI. Last log show it finished fetching data then emit for MainThread using signal/sot.
-
Thank for your supports.
I think deadlock happen when we have 2 mutexs.
I only use 1 pthread_mutex_lock in main thread and I don't think it cause deadlock. I will try to remove it and reproduce.wrote on 4 Dec 2017, 10:19 last edited by@minhthanh said in Screen freeze when app running in QNX (I think deadlock in Qt event loop):
I think deadlock happen when we have 2 mutexs.
Not really. You can have one mutex, but your code might fail to release it for some reason, or you might even deadlock-like behavior when you run some other blocking system call in the main thread which prevents main Qt event loop from running (though maybe in QNX this is not possible to run into this due to it's RT nature)
-
wrote on 4 Dec 2017, 10:22 last edited by
Anyway, it's not really useful to guess here. Attach debugger when you reproduce freeze, or kill your application and analyze core dump (if this is possible on your platform, and you may need to enable core dumps before starting application), or try some specialized software for finding multithreading bugs
-
Anyway, it's not really useful to guess here. Attach debugger when you reproduce freeze, or kill your application and analyze core dump (if this is possible on your platform, and you may need to enable core dumps before starting application), or try some specialized software for finding multithreading bugs
wrote on 4 Dec 2017, 10:40 last edited by@Konstantin-Tokarev One more question please
Which connection type really set in this case:
connect(this, SIGNAL(modelReset()), this, SLOT(onModelResetDone()), Qt::UniqueConnection);Qt::AutoConnection
Qt::DirectConnection
Qt::QueuedConnection
Qt::BlockingQueuedConnectionIn Qt doc say "This is a flag that can be combined with any one of the above connection types, using a bitwise OR."
If is Qt::BlockingQueuedConnection, deadlock will be happen. -
@Konstantin-Tokarev One more question please
Which connection type really set in this case:
connect(this, SIGNAL(modelReset()), this, SLOT(onModelResetDone()), Qt::UniqueConnection);Qt::AutoConnection
Qt::DirectConnection
Qt::QueuedConnection
Qt::BlockingQueuedConnectionIn Qt doc say "This is a flag that can be combined with any one of the above connection types, using a bitwise OR."
If is Qt::BlockingQueuedConnection, deadlock will be happen.wrote on 4 Dec 2017, 11:09 last edited by Konstantin Tokarev 12 Apr 2017, 11:09This is DirectConnection, because you send signal from
this
tothis
, which are obviously in same thread. It actually can be replaced with direct method call (virtual
if you have class hierarchy and slot if implemented in derived class)
11/11