Extremely strange - Window Re-painting blocking threads?!
-
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?
-
-
Without seeing the code, it is pretty hard to check what is going on. But as you said, if you don't connect the GUI slots, try to uncomment stuff insid ethe slots to break the issue down to the real problem. first uncomment one slot, to check, which slot is the problem, then ports of it etc. etc.
-
So I'm not sure if the advice you guys have provided directly solved my problem but based on the playing around that took place after reading your comments I have found a way to stop the application crashing.
Basically instead of emitting a signal to GUI every time some comm's arrived, I allowed the comms to come in and update some objects and then got the GUI to poll these objects for information intermittently in order to get screen updates.
I had a lot of comms coming in so maybe I was triggering too many signals too fast and this was growing the event queue??? I'm not sure...
-
[quote author="matthazley" date="1314876103"]I had a lot of comms coming in so maybe I was triggering too many signals too fast and this was growing the event queue??? I'm not sure... [/quote]
This could be the reason, ort perhaps you had some wrong connect statements (which threads are processing the comm's data? how did you do the connect, etc.).