Strange Qt problem - Window re-painting blocking threads?

This is a x-post of my post on the Qt support forum as I thought it was strange and interesting and you all might be able to help me here also.

---

I will attempt to explain a problem I am having – its a really weird one so bear with me as I try to explain it.

Let me outline my application first. It is a simple ‘Serial Data Logger’ type program written in Qt 4.7 on Windows XP; it basically receives communications on a serial port (using QExtSerialPort), does some processing to extract data from these communications and then pushes this data to a front end GUI as well as outputting it to Log Files. I also have the comms and data coming to the Application Output at various points using qDebug() so I can monitor what is flowing around inside the application.

For clarity, in case you haven’t used it, QExtSerialPort simply emits a signal when there are bytes received at the serial port and passes these to a connected slot using QByteArray.

So now to my problem – my application initially runs perfectly but after about 5 – 10 mins the whole thing locks up and stops working, forcing me to crash it.

Having investigated this further in the debugger, I have noticed a very strange thing.

The stream of communications is fairly constant so by monitoring the ‘application output’ pane in the debugger, I am able to straight away see when the program locks as no more communications seem to arrive. If at this point, I click and drag the window of my application to another part of the screen, communications begin to come in and be processed and then it stops and locks up again, until I move the window again and then it will allow more data in and so on and so on….. I have tried this for a while and each time I move the 开发者_开发百科window on the screen it allows the program to receive communications and process. If I open the top left system menu of the window (using ALT-space) this also seems to allow communications to be processed for as long as it is open.

So my limited deductions here seem to direct me to the theory that as each of these actions blocks the re-painting of the window, then the GUI/Re-painting action must be blocking my communications from coming in.

Also – the data is pushed to the GUI using two slots and what’s even more interesting (I think) is that if I remove the connection to these slots, thus allowing no interaction with the GUI class within my code, the application runs fine and never locks up with all data making it to the Log File and the Application Output. However these slots are very simple and only check the state of some combo-boxes to decide whether to update some text fields.

Has anyone ever seen anything like this before? Anyone have any ideas as to what might be going on?

---

When you drag the window around, or you open a QMenu, a temporary QEventLoop is used, and it allows the events to be received by your application.

That means that you are somewhere in your code (or QExtSerialPort is) preventing the main event loop to execute.