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.@minhthanh Seems like your application is getting into deadlock. Use appropriate debugger for your platform to find out where application is stuck.
-
But this issue only happen once. I can not reproduce. You met this issue ever? QEventLoop use a mutex (or something similar) ?
@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.Also, 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.
-
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.@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)
-
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
@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.This is DirectConnection, because you send signal from
thistothis, which are obviously in same thread. It actually can be replaced with direct method call (virtualif you have class hierarchy and slot if implemented in derived class)