sendPostedEvents() or processEvents() causes SIGSEGV

So I have had this issue with what appeared to be too many events occuring in my application, so the event loop was getting blocked and basically the application became completely unresponsive.
The way I was trying to fix this issue was to call sendPostedEvents() or processEvents() at the very beginning of a function which is essentially the starting point of all GUI updates that are happening too frequently causing this event loop blocking / unresponsiveness (i.e this function is what is being called so many times within a short period of time). So when I have the sendPostedEvents() or processEvents() function calls, it seems to run a lot better( faster updates and makes the GUI responsive), but after a little while, I suddenly get a segmentation fault, and I'm really not understanding what the cause could be just by reading the stack trace. Any ideas as to what could be going on?

#4 0xf70684e2 in OA::QtEventHandler::DispatchEvent::invoke (this=0xec9c8050)
at QtEventHandler.cpp:278
#5 0xf706857d in OA::QtEventHandler::customEvent (this=0x94e1f48, event=0xec9c8050)
at QtEventHandler.cpp:254
#6 0xf579be1a in QObject::event(QEvent*) ()
from /view/qt-everywhere-opensource-src-4.8.7/lib/libQtCore.so.4
#7 0xf5a436e4 in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
from /view/qt-everywhere-opensource-src-4.8.7/lib/libQtGui.so.4
#8 0xf5a4a0ad in QApplication::notify(QObject*, QEvent*) ()
from /view/qt-everywhere-opensource-src-4.8.7/lib/libQtGui.so.4
#9 0xf70654c0 in OA::QtApplication::notify (this=0xffb17c58, receiver=0x94e1f48, event=0xec9c8050)
at QtApplication.cpp:55
#10 0xf5783daa in QCoreApplication::notifyInternal(QObject*, QEvent*) ()
from /view/qt-everywhere-opensource-src-4.8.7/lib/libQtCore.so.4
#11 0xf578713d in QCoreApplicationPrivate::sendPostedEvents(QObject* , int, QThreadData*) ()
from /view/qt-everywhere-opensource-src-4.8.7/lib/libQtCore.so.4
#12 0xf578762c in QCoreApplication::sendPostedEvents(QObject*, int) ()
from /view/qt-everywhere-opensource-src-4.8.7/lib/libQtCore.so.4
#13 0xf678514e in sendPostedEvents ()



Thanks.

It is very likely that the cause of the unresponsiveness in your app has nothing at all to do with event processing. This sounds more like a classic case of a memory leak (or unrestrained growth of heap data) which is gradually eating all system resources and causing your application to thrash ("thrashing" means that you app has used so much memory that the OS has to keep swapping parts of it out to disk so that other parts can be swapped into execute).

The crash is most likely related to this as well and also has nothing to do with event processing. Likely there is some memory corruption and it just happens to manifest itself with a crash at this point.

Unresponsiveness can also be caused by not allowing the Qt event loop to run frequently enough - such as when the app has a big number-crunching function that takes a long time to run before it returns to the event loop. During the time the method is running, the event loop is blocked. Your app could also simply be generating too many events - if you have a timer that is firing every few ms and causing a cascade of more events as a result of this timeout handler, then it could be that your event queue is simply growing without limit because the app cannot process the events that are there before more get added. Calling processEvents() doesn't help if that just results in even more events being added.

So:

- look for memory leaks or other sources of unrestrained memory growth
- look for use of uninitialized or deleted and invalid memory references
- look for cases where you are calling delete() instead of deleteLater() on a QObject pointer - this can cause crashes if something pending in the event loop still needs that pointer
- look for code that generates too many events - timeouts that are too short, recursive event handlers that create more events, etc.

Note that paintEvent() calls are usually not a source of problems. Qt's event loop is optimized so that if successive paint events are pushed onto the queue, all but the last one will be discarded so painting only happens once.

Thanks for your reply.

I don't think unrestrained growth is the issue because i'm not really storing crazy amounts of data. A memory leak is possible somewhere, but figuring out what it is would be very difficult I imagine as there are way too many lines of code to go through and I'd have to look at pretty much all the code that exists line by line to figure that out. I don't have a recursion problem with time out handlers ( there are no timer handlers anywhere). It looks like there's just so many calls to a function and somehow the application is unable to process that many things in that short amount of time. I have about 1000 calls to this function every 2 seconds and this function will update fields on a table widget as well as create items to be added to a QGraphicsScene every time and there doesn't seem to be a way to make it go faster except by calling something like sendPostedEvents() or processEvents() to keep the event loop running without being blocked, but obviously doing this results in a crash. I guess I have to either track down memory leaks , and other things you mentioned such as usages of delete instead of deleteLater or unitialized, or deleted and invalid memory references which would likely take an extremely long time, or I have to find some other means of keeping the event loop alive without causing a crash. I'm wondering if you know of some other ways I could attempt to keep the GUI responsive? I guess running things in separate QThreads seems like an obvious thing to try.

Quote:

---

I have about 1000 calls to this function every 2 seconds and this function will update fields on a table widget as well as create items to be added to a QGraphicsScene every time

---

Think about this. What sense does it make to update a UI 500 times per second? You can't detect changes that occur on a two millisecond basis even if the GUI architecture could keep up. Videos run at 30 frames / sec (or 33 ms per frame) and your brain detects that as continuous motion, so you could easily update your UI at a much slower rate, especially a table. At even 30 times / sec, it will just be a blur.

If the only thing your sampling is doing is to update the GUI, then don't sample at a rate that overwhelms the ability of Qt to keep up. If you have to sample at 500 times / sec, then decouple the GUI updates from the signal handling: store the data, average it, and update your GUI once per second or even less if the changes in the data are gradual.