[Interest] QTimer Freeze in 4.8

[Cjb_SW Freescale]

Dear all,
I have a strange problem on one application.
It seems that all the QTimer that I use to refresh the GUI (both c++ and
QML) are blocked after some time of inactivity.
They resume to work immediately when I press the touchscreen (everywhere on
the display).
Then after some time (1hour typical) everything get freezed again until new
touch event occur.

I really don't know where to look, I'm using Qt 4.8.5 with QWS server on
embedded platform based on freescale iMX28.

Do you have any suggestion?
Thanks a lot
Simone

[Thiago Macieira]

Post by Cjb_SW Freescale
Dear all,
I have a strange problem on one application.
It seems that all the QTimer that I use to refresh the GUI (both c++ and
QML) are blocked after some time of inactivity.
They resume to work immediately when I press the touchscreen (everywhere on
the display).
Then after some time (1hour typical) everything get freezed again until new
touch event occur.
I really don't know where to look, I'm using Qt 4.8.5 with QWS server on
embedded platform based on freescale iMX28.

Can you attach the debugger to the process while it's in that frozen state and
produce a backtrace?

[Cjb_SW Freescale]

I could, but I always had troubles with the remote debugger.
The strange thing is that while the gui is in frozen state, all the rest in my device is working, network, ssh, other programs..

...

I will investigate more and let you know tomorrow.
Thank you

Simone


Inviato da iPhone

Post by Thiago Macieira

Post by Cjb_SW Freescale
Dear all,
I have a strange problem on one application.
It seems that all the QTimer that I use to refresh the GUI (both c++ and
QML) are blocked after some time of inactivity.
They resume to work immediately when I press the touchscreen (everywhere on
the display).
Then after some time (1hour typical) everything get freezed again until new
touch event occur.
I really don't know where to look, I'm using Qt 4.8.5 with QWS server on
embedded platform based on freescale iMX28.

Can you attach the debugger to the process while it's in that frozen state and
produce a backtrace?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest

[Thiago Macieira]

Post by Cjb_SW Freescale
I could, but I always had troubles with the remote debugger.
The strange thing is that while the gui is in frozen state, all the rest in
my device is working, network, ssh, other programs..

Is "the rest in my device" being handled by the same process? Same thread,
even?

[Thiago Macieira]

yes and no, I mean that every other process is executed proper by Linux,
and also a second QThread running in the GUI application is running fine.
Seems that only the graphic Thread is "freezed". It will resume by touching
the Touchscreen (which is USB, managed via Tslib).
Unfortunately I cannot build backtraces, I have problems with GDB. I can
launch the program under gdbserver, and I can set breakpoints, but if I
press the Interrupt button, then I can see a disassembly window, and I
can't see where it is the programcounter in my sources. So I tried to
Interrupt the application while is in the freeze state, but I can't see
something useful.

Please, always reply to the mailing list. If you reply to me personally, it
may get lost in inbox and I may never reply. And no one else would have the
opportunity to, either.

Anyway, since you said that other processes are running just fine and even
other threads in the same process, my conclusion is that something is blocking
the GUI thread in your application. We've seen this happen in Qt 5 with XCB,
whenever the screensaver is on or when you swap to another virtual terminal:
there's a function call we make that blocks on waiting for a reply from the X
server, which won't come until the display is unlocked.

Clearly that's not your case, but you get the idea of what it might be.

Unfortunately, I can't help you without a backtrace (and one with debug
symbols, at that). I have NEVER built a QWS build of Qt and I don't even have
a Qt 4.8 source handy to look things up. Sorry.

My recommendations are:
* fix GDB. It's unacceptable for it not to work.
* consider upgrading to Qt 5.6 or 5.7 (which means dropping QWS for something
else)

Note that you can work around a non-working gdbserver by causing your process
to dump core while in the frozen state (kill -ABRT, for example), then loading
that core file on your host machine's target gdb.

[Simone]

Sorry, I did not pay attention to the mail recipients.
Today, after many tests I discovered that also a simple application with a QMainWindow only and a timer that increase a counter, is freezed after about 3 hours.
The timer run every 250ms.
The touch screen press recover the situation, and everything resume working magically, it seems that the event loop is waiting for some signals, but unfortunately I cannot follow the sources.
Gdb is working if I put a breakpoint, i can follow my code step by step, but since the event dispatcher is in qt libraries, I cannot see where it stuck.

Any suggestion about some tests that I can do?
Is ther a way to configure gdb to see the the qt sources when debugging?

Thanks a lot

Post by Thiago Macieira

yes and no, I mean that every other process is executed proper by Linux,
and also a second QThread running in the GUI application is running fine.
Seems that only the graphic Thread is "freezed". It will resume by touching
the Touchscreen (which is USB, managed via Tslib).
Unfortunately I cannot build backtraces, I have problems with GDB. I can
launch the program under gdbserver, and I can set breakpoints, but if I
press the Interrupt button, then I can see a disassembly window, and I
can't see where it is the programcounter in my sources. So I tried to
Interrupt the application while is in the freeze state, but I can't see
something useful.

Please, always reply to the mailing list. If you reply to me personally, it
may get lost in inbox and I may never reply. And no one else would have the
opportunity to, either.
Anyway, since you said that other processes are running just fine and even
other threads in the same process, my conclusion is that something is blocking
the GUI thread in your application. We've seen this happen in Qt 5 with XCB,
there's a function call we make that blocks on waiting for a reply from the X
server, which won't come until the display is unlocked.
Clearly that's not your case, but you get the idea of what it might be.
Unfortunately, I can't help you without a backtrace (and one with debug
symbols, at that). I have NEVER built a QWS build of Qt and I don't even have
a Qt 4.8 source handy to look things up. Sorry.
* fix GDB. It's unacceptable for it not to work.
* consider upgrading to Qt 5.6 or 5.7 (which means dropping QWS for something
else)
Note that you can work around a non-working gdbserver by causing your process
to dump core while in the frozen state (kill -ABRT, for example), then loading
that core file on your host machine's target gdb.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Thiago Macieira]

Post by Simone
Is ther a way to configure gdb to see the the qt sources when debugging?

If you built Qt in debug mode, that should already be the case.