Crash in release mode
-
I have a project. I’m using Windows 10 and Qt 6.9. While in Release mode, the app crashes at different intervals (such as 3 minutes, 5 minutes, 10 minutes), but I don’t see the same issue when I run it in Debug mode.
I’d like to add a few more details.
I’m using WebEngineView.

As shown in the image, the WebEngineView occupies a large portion of my widget.
In debug mode, only the WebEngineView section lags.If you’re wondering why I mentioned this, it occurred to me that the WebEngine might be the cause of the crash.
I’ve added many print statements using
qDebug(), but since the crash occurs in a different place each time, I can’t figure it out.What are your suggestions?
-
The most common reasons this only shows up in release builds:
- Uninitialized memory. Debug builds tend to zero-initialize or pad allocations, so reads of uninitialized values accidentally return 0. Release reuses whatever was there.
- Use-after-free. Debug allocators often keep freed memory around a bit longer, so dangling pointer accesses "work". Release reuses memory immediately.
- Race conditions. The slower execution in debug masks timing issues between threads. In release, two threads actually collide.
- Compiler optimizations eliminating reads. If you have a flag or state variable that's written from one thread and read from another without proper synchronization, the optimizer is allowed to cache it in a register and never re-read it from memory.
Regarding WebEngine specifically: it runs Chromium in a separate process, and if your app is doing anything with shared memory, callbacks into QObjects across threads, or raw pointers that get passed around through WebEngine's JS bridge, those are all worth checking.
-
The most common reasons this only shows up in release builds:
- Uninitialized memory. Debug builds tend to zero-initialize or pad allocations, so reads of uninitialized values accidentally return 0. Release reuses whatever was there.
- Use-after-free. Debug allocators often keep freed memory around a bit longer, so dangling pointer accesses "work". Release reuses memory immediately.
- Race conditions. The slower execution in debug masks timing issues between threads. In release, two threads actually collide.
- Compiler optimizations eliminating reads. If you have a flag or state variable that's written from one thread and read from another without proper synchronization, the optimizer is allowed to cache it in a register and never re-read it from memory.
Regarding WebEngine specifically: it runs Chromium in a separate process, and if your app is doing anything with shared memory, callbacks into QObjects across threads, or raw pointers that get passed around through WebEngine's JS bridge, those are all worth checking.
@J.Hilk Thank you for your reply
-
The most common reasons this only shows up in release builds:
- Uninitialized memory. Debug builds tend to zero-initialize or pad allocations, so reads of uninitialized values accidentally return 0. Release reuses whatever was there.
- Use-after-free. Debug allocators often keep freed memory around a bit longer, so dangling pointer accesses "work". Release reuses memory immediately.
- Race conditions. The slower execution in debug masks timing issues between threads. In release, two threads actually collide.
- Compiler optimizations eliminating reads. If you have a flag or state variable that's written from one thread and read from another without proper synchronization, the optimizer is allowed to cache it in a register and never re-read it from memory.
Regarding WebEngine specifically: it runs Chromium in a separate process, and if your app is doing anything with shared memory, callbacks into QObjects across threads, or raw pointers that get passed around through WebEngine's JS bridge, those are all worth checking.
@J.Hilk This sounds like the address sanitizer or thread sanitizer could help (maybe).
-
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;