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 > Il giorno 22/giu/2016, alle ore 21:41, Thiago Macieira > <thiago.macie...@intel.com> ha scritto: > >> On quarta-feira, 22 de junho de 2016 14:49:39 PDT Cjb_SW Freescale wrote: >> 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. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
