Screen freeze when app running in QNX (I think deadlock in Qt event loop)

Konstantin Tokarev

@minhthanh Seems like your application is getting into deadlock. Use appropriate debugger for your platform to find out where application is stuck.

minhthanh

But this issue only happen once. I can not reproduce. You met this issue ever? QEventLoop use a mutex (or something similar) ?

Konstantin Tokarev

@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

Konstantin Tokarev

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.

minhthanh

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

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.

Konstantin Tokarev

@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)

Konstantin Tokarev

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

minhthanh

@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::BlockingQueuedConnection

In 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

This is DirectConnection, because you send signal from this to this, 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)