Unsolved Finding GUI Event-Handling Crashes
-
Final update on this...unless I learn more about why my changes worked and believe it could help others...
Today I deployed a (seemingly) fixed version after almost two months' testing. I made many changes including most of those @SGaist had suggested -- thanks for the super helpful feedback and suggestions!
This was a difficult bug to fix. The program is a really, really large in-house application used by hundreds of people every day. Some of the source files were written in the late 90's and are still used today; it uses MFC; it uses the QMfcApp class; it uses Qt; it uses Boost; and I'm skeptical of the smooth integration of these frameworks into a cohesive unit. In fact, I'm not sure QMfcApp was intended to be a long-term solution...it looks more like a bridge for moving from MFC to Qt...
At any rate, I made several changes that led to a fix. First, I moved the vector into the Model rather than injecting a pointer to a vector anchored in the dialog as the original author had done. I also disable UI controls while the data is acquired, then disable updates ( setUpdatesEnabled(false) ) to the TableView and TableModel while major changes are made, remove events (removePostedEvents(Table, 0) & removePostedEvents(Model, 0)) before clearing the vector, and I changed the app from emitting a restart-event after N items are processed and then exited knowing that when the restart bubbles off the queue it can pickup where it left off, to simply processing every item and issuing a qApp->processEvents() periodically to keep the UI responsive. I created a state variable to control when the app is busy or idle.
I don't know if all of this is in line with the standard Qt rules of engagement, particularly disabling controls and flushing their event queues, but it has been working after hours and hours of testing. Before I disabled updates and removed enqueued pending update events, I would get intermittent update events for stale data. I thought the documentation said if you emptied your Model's container between a beginModelReset() and endModelReset() the framework would recognize that data requests were stale and would purge them. Either I misunderstood how this works, failed some other necessary step, or there's just a bug in Qt or our code or the commingling of both that allowed UI updates after the table was emptied.
If something illuminating happens that provides greater understanding as to why these changes "fixed" the crashes, I'll come back here and update this thread. But I do want to say thanks to @SGaist for your input and suggestions. It helped a lot.
- john