I would like to ask something. I do not change address manually. I should explain my app little. //receiving struct struct MyObj{ İnt id; QTimer *timer = nullptr; } //socket tcp void readyRead(){ QList<MyObj> objs; //data parsing here and append list(MyObj) emit sendObjs(objs); } //mainwindow void receiveObjs(QList<MyObj> objs){ // I control here objs is exist or not // I took _objs list in mainwindow and control with new objs list receiving obj id. İf id exist in _objs update pareters, or id do not exist in _objs MyObj append to list for(MyObj &obj : objs){ İf(do not exist){ //start remove timer Obj.timer = new Timer Obj.timer->serSingleshoot(true); Connect(obj.timer … { removeObj(obj.id); }); Obj.timer->start(15000); addTable(obj) _objs.append(obj); } else{ // id control in _objs and updare parameters // timer start again // addTable again } } //send _obs list to somewhere, it just set to list local as parameters } Void removeObj(id){ //stop timer //remove from table //remove from_objs list } Void addTable(MyObj obj){ // id check // if rows has id, update row // else add new row } So, I take data from tcp socket as they are some object and, I send to main for update my list, also I check received objects still exist or not, İf they not remove. Now. How _objs list address broken? I have written on mobile device, sorry for bas syntax;

@The-Qt-Mayssa I think we're talking in circles. If you want someone in the forum to analyze the problem, you need to provide a minimal reproducer. In the unlikely case that it's a bug in Qt, it won't be fixed in an EOL version. You will have to upgrade at some point anyway.

@JonB said: Which I have always regraded as devil's spawn Agreed. I see blockSignals() as an advanced tool to be used with great care and only when you're very aware of all consequences in given case. Similar to sender(). Definitely not something to be applied on a "let's see if it helps" basis.

Also here is the stacktrace if it helps: 0 ??? 0x10a1029a8 ??? 1 <translation info unavailable> 0x10c7d5e24 ??? 2 libsystem_pthread.dylib 0x115b91ee6 pthread_kill + 263 3 libsystem_c.dylib 0x114e06e58 abort + 130 4 test5 0x104c96839 qAbort() + 9 (qglobal.cpp:161) 5 test5 0x104c9b6b8 qt_message_fatal(QtMsgType, QMessageLogContext const&, QString const&) + 24 (qlogging.cpp:2048) 6 test5 0x10510d7b6 QMessageLogger::fatal(char const*, ...) const + 246 (qlogging.cpp:934) 7 test5 0x10510d08a qt_assert(char const*, char const*, int) + 74 (qassert.cpp:68) 8 test5 0x1041c7e45 QGles2TextureRenderTarget::create() + 981 (qrhigles2.cpp:5462) 9 test5 0x103580e82 QQuickWidget::createFramebufferObject() + 1890 (qquickwidget.cpp:1137) 10 test5 0x103585ad1 QQuickWidget::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) + 225 (moc_qquickwidget.cpp:295) 11 test5 0x104da0579 void doActivate<false>(QObject*, int, void**) + 2313 (qobject.cpp:4004) 12 test5 0x104d9f039 QMetaObject::activate(QObject*, QMetaObject const*, int, void**) + 121 (qobject.cpp:4052) 13 test5 0x103607465 QQuickWindow::sceneGraphInitialized() + 37 (moc_qquickwindow.cpp:829) 14 test5 0x10360665d QQuickWindow::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) + 109 (moc_qquickwindow.cpp:570) 15 test5 0x104da0579 void doActivate<false>(QObject*, int, void**) + 2313 (qobject.cpp:4004) 16 test5 0x104d9f039 QMetaObject::activate(QObject*, QMetaObject const*, int, void**) + 121 (qobject.cpp:4052) 17 test5 0x1036b52d2 QSGRenderContext::initialized() + 34 (moc_qsgcontext_p.cpp:289) 18 test5 0x1036c7b67 QSGDefaultRenderContext::initialize(QSGRenderContext::InitParams const*) + 295 (qsgdefaultrendercontext.cpp:57) 19 test5 0x1035f1a1a QQuickRenderControl::initialize() + 378 (qquickrendercontrol.cpp:309) 20 test5 0x1035806d3 QQuickWidgetPrivate::initializeWithRhi() + 867 (qquickwidget.cpp:1058) 21 test5 0x1035837aa QQuickWidget::resizeEvent(QResizeEvent*) + 474 (qquickwidget.cpp:1404) 22 test5 0x1038782cb QWidget::event(QEvent*) + 2683 (qwidget.cpp:9076) 23 test5 0x103584fb9 QQuickWidget::event(QEvent*) + 1321 (qquickwidget.cpp:1719) 24 test5 0x1037ea0ba QApplicationPrivate::notify_helper(QObject*, QEvent*) + 458 (qapplication.cpp:3284) 25 test5 0x1037ee456 QApplication::notify(QObject*, QEvent*) + 11974 (qapplication.cpp:3231) 26 test5 0x104d2212a QCoreApplication::notifyInternal2(QObject*, QEvent*) + 282 (qcoreapplication.cpp:1115) 27 test5 0x104d22df3 QCoreApplication::sendEvent(QObject*, QEvent*) + 131 (qcoreapplication.cpp:1533) 28 test5 0x10386f721 QWidgetPrivate::sendPendingMoveAndResizeEvents(bool, bool) + 353 (qwidget.cpp:7944) 29 test5 0x103875ff0 QWidgetPrivate::show_helper() + 64 (qwidget.cpp:7995) 30 test5 0x10387707f QWidgetPrivate::setVisible(bool) + 943 (qwidget.cpp:8344) 31 test5 0x103876cc0 QWidget::setVisible(bool) + 144 (qwidget.cpp:8276) 32 test5 0x10386871e QWidget::showMaximized() + 126 (qwidget.cpp:3057) 33 test5 0x103875e94 QWidget::show() + 100 (qwidget.cpp:7900) 34 test5 0x102e70702 MyOpenGLWidget::mousePressEvent(QMouseEvent*) + 82 (main.cpp:16) 35 test5 0x103877a73 QWidget::event(QEvent*) + 547 (qwidget.cpp:8902) 36 test5 0x1037ac198 QOpenGLWidget::event(QEvent*) + 712 (qopenglwidget.cpp:1698) 37 test5 0x1037ea0ba QApplicationPrivate::notify_helper(QObject*, QEvent*) + 458 (qapplication.cpp:3284) 38 test5 0x1037ec11c QApplication::notify(QObject*, QEvent*) + 2956 (qapplication.cpp:2772) 39 test5 0x104d2212a QCoreApplication::notifyInternal2(QObject*, QEvent*) + 282 (qcoreapplication.cpp:1115) 40 test5 0x104d22e83 QCoreApplication::sendSpontaneousEvent(QObject*, QEvent*) + 131 (qcoreapplication.cpp:1547) 41 test5 0x1037eabd0 QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool, bool) + 1216 (qapplication.cpp:2356) 42 test5 0x1038a44a5 QWidgetWindow::handleMouseEvent(QMouseEvent*) + 4485 (qwidgetwindow.cpp:623) 43 test5 0x1038a2849 QWidgetWindow::event(QEvent*) + 361 (qwidgetwindow.cpp:241) 44 test5 0x1037ea0ba QApplicationPrivate::notify_helper(QObject*, QEvent*) + 458 (qapplication.cpp:3284) 45 test5 0x1037ee474 QApplication::notify(QObject*, QEvent*) + 12004 (qapplication.cpp:3235) 46 test5 0x104d2212a QCoreApplication::notifyInternal2(QObject*, QEvent*) + 282 (qcoreapplication.cpp:1115) 47 test5 0x104d22e83 QCoreApplication::sendSpontaneousEvent(QObject*, QEvent*) + 131 (qcoreapplication.cpp:1547) 48 test5 0x103e0f2b0 QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) + 2384 (qguiapplication.cpp:2277) 49 test5 0x103e0ec51 QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) + 753 (qguiapplication.cpp:2187) 50 test5 0x103e110b4 QGuiApplicationPrivate::processTouchEvent(QWindowSystemInterfacePrivate::TouchEvent*) + 5412 (qguiapplication.cpp:3081) 51 test5 0x103e0e2de QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) + 110 (qguiapplication.cpp:2035) 52 test5 0x103e74a5e QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 190 (qwindowsysteminterface.cpp:1094) 53 test5 0x102e7af11 QIOSEventDispatcher::processPostedEvents() + 545 (qioseventdispatcher.mm:443) 54 test5 0x104f9bf3b RunLoopSource<QEventDispatcherCoreFoundation>::process(void*) + 107 (qeventdispatcher_cf_p.h:111) 55 CoreFoundation 0x113e56b8f __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 56 CoreFoundation 0x113e56ad1 __CFRunLoopDoSource0 + 157 57 CoreFoundation 0x113e5632b __CFRunLoopDoSources0 + 311 58 CoreFoundation 0x113e509ba __CFRunLoopRun + 889 59 CoreFoundation 0x113e50264 CFRunLoopRunSpecific + 560 60 GraphicsServices 0x1225e324e GSEventRunModal + 139 61 UIKitCore 0x13abc47bf -[UIApplication _run] + 994 62 UIKitCore 0x13abc95de UIApplicationMain + 123 63 test5 0x102e79161 qt_main_wrapper + 705 (qioseventdispatcher.mm:206) 64 dyld_sim 0x112701384 start_sim + 10 65 dyld 0x20a3db41f start + 1903

@Axel-Spoerl The issue was with my build setup. After a clean build the debugger started behaving properly and I was able to resolve the crash.

@Chris-Kawa said in Weird connection between QComboBox, QBasicTimer and static object initialization.: In general singleton pattern doesn't go too well with QObjects. ... and is not needed in most cases - this one here is one of the most cases where a singleton is not needed

Since Qt6 does not support Windows 7 anymore you have to choose an older qt installer from e.g. https://mirror.netcologne.de/qtproject/archive/online_installers/

@Wenchi said in Crash in function: QImageData * QImageData::create(const QSize &size, QImage::Format format): Although the code is crashing in various places, but the crash point is always the same: But that is likely --- or just as possible --- indicating you have a problem elsewhere which only shows up here, such as corrupted/misallocated memory? How else would you explain it "crashing" in e.g. QList<MyWidget>.push_back()? by the way, I'm fired. ready to get a new start I am sorry to hear that, good luck for future.

@canol said in Removing a QGraphicsProxyWidget from QGraphicsScene crashes the app, but only when using a button on a toolbar: Hello, I have a medium sized app which had some random crashing problems. The crashes don't print any error messages. After a long investigation, getting rid of a lot of code, now I have a minimal example. For problems that don't appear to produce any usable output, turning on all QLoggingCategory categories can help. QT_LOGGING_RULES="*.*=true" python test.py should flood the console with information about what Qt is doing prior to the crash. In addition, installing a QObject::eventFilter() on the widget or QApplication can provide insight into how far input processing proceeded. class Filter(QObject): def __init__(self, target, *args, **kwargs): super().__init__(*args, **kwargs) target.installEventFilter(self) def eventFilter(self, target, event): print("Attempting to deliver {} to {}".format(event.type(), target)) return super().eventFilter(target, event) app = QtWidgets.QApplication([]) filter = Filter(app) The app has a QGraphicsView, and I add and remove QWidgets dynamically on the graphics view. The widgets have a toolbar, and the toolbar had a close button on it, which removes and deletes the widget from QGraphicsView. The crashes would randomly happen when I used this close button. Here is a complete example (it is a PySide2 program, I haven't tried it with C++): Porting the example to PyQt5 had crashes for the same input, on every attempt. Maybe PyQt is more aggressive in object reclamation than PySide. My questions are: **1) Why does it crash when I trigger the action using mouse click on the button? The issue appears to be a deletion of the recipient object while there are events for it remaining in the queue. As mentioned in the documentation for QObject::~QObject(), this is a problem. In C++, QObject::deleteLater() provides a convenient solution. Unfortunately, PySide and PyQt interfere by deleting the object when the last python reference is removed. Why does it NOT crash, when I use the keyboard shortcut for the action?** Different triggering mechanisms lead to a different sequence of events. If the last event triggers the action, deleting the object is fine. If there's a mouse release or a paint event after, deletion in the slot connected to the action is unsafe. The example above uses a QPushButton, instead of a QToolBar+QAction, and it does not crash. So another question: 3) Why does it not crash when I use QPushButton instead of QToolBar+QAction? As with #2, the events delivered are probably different. This example won't crash. I guess waiting for the control to return to event loop before removing the item helps. So my final question is: 4) Why does using QTimer.singleShot() helps here? Using QTimer.singleShot() schedules the slot for the next iteration of the event loop, after the currently pending events have been processed. The same thing can be accomplished using a queued connection for the action's slot instead of a 0-timer.

Found out that this error only occurres in Qt Creator version installed with online installer. The one installed with apt-get works just fine, so I will stick to it. Sorry for wasting your time

Humor me, will you? constexpr int poolSize = 16; QVector<QThread *> threadPool(poolSize); QCoreApplication * app = QCoreApplication::instance(); for (size_t i = 0; i < poolSize; i++) { QThread * thread = new QThread(app); thread->start(); QObject::connect(thread, &QThread::finished, thread, &QThread::deleteLater); } QObject::connect(app, &QCoreApplication::aboutToQuit, [threadPool] () -> void { for (QThread * thread : threadPool) { thread->quit(); thread->wait(); } }); int index = 0; for (const QString &video : videoFiles) { ThumbnailExtractor *extractor = new ThumbnailExtractor(counter, folderPath + '/' + video); extractor->moveToThread(threadPool[index++ % poolSize]); QObject::connect(extractor, &ThumbnailExtractor::finished, extractor, &QObject::deleteLater); QMetaObject::invokeMethod(extractor, &ThumbnailExtractor::generateThumbnail, Qt::QueuedConnection); } A note here: QMediaPlayer and related classes don't seem to be reentrant so you can't use them from different threads. Stick to the main one.

@YouDoItWrong said in Random crash on window resize.: By "bugreport" you mean code and error in this "head topic forum post"? No, bug report in Qt bug tracker: https://bugreports.qt.io/secure/Dashboard.jspa

@hsynkrkmz From posts I have seen elsewhere: this happens with QtWebEngine, sometimes. It seems to very picky about where it gets destroyed. If you are waiting for definitive answer, you might like to try moving around where/how you destroy it and see if different behaviour.

@VikramSamy said in QT5 application crashed after running for some long time.....: so my question which is the better, use as my original code and delete the Qstringlist somewhere, or create the QStringlist in the stack and let it get destroyed by itself after getting out of scope as above ?? There is no generic answer to this question as it simply depends on the use case. If you only need this list in that method then you simply allocate it as local variable. Having it as member variable in the class is only needed if you need the list at several places in your class. By the way this is not heap allocation: private: QStringList TableMessages; QStringList TableMessagesNOT;

@JKSH This is how I emit the OpenCV mat data: emit processedImage(2, videoFrameOut.ptr(0,0),videoFrameOut.cols, videoFrameOut.rows, videoFrameOut.step); The first parameter is just used to determine which display should draw the image and the rest are dimensions and stride which I think are ok. @SGaist You are correct, I changed the line below to make a copy: displayImage = QImage(imageData, width, height, step, QImage::Format_RGBA8888).copy(0,0,width,height); I think this fixed the issue. I got a couple of crashes in 'memcpy' but that was when loading files a little too quickly. I think most likey resizing the data quickly was the issue. I will do more testing this week and post the results. UPDATE: I did a lot more testing and making a local copy fixed the issue. The issue was that I was modifying the array before it was fully copied and this caused crashes when the array was downsized. I will need to revise the overall structure to make sure everything is done sequentially. Thanks!

@A.A.SEZEN Uhm, I think @J-Hilk is right: sometimes my Thread instance has been destroyed. I have fixed by using checking null before calling it, I don't see the crash anymore.

I ran into the same problem: VS2017, Qt 5.12.6, Windows 10, Release, static inline const QString member. interestingly, using QStringLiteral around the initializer makes the problem go away, so it seems to have something to do with memory allocation.