Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Crash in release mode
Qt 6.11 is out! See what's new in the release blog

Crash in release mode

Scheduled Pinned Locked Moved Unsolved General and Desktop
crashcrash apprelease modewebengine
5 Posts 3 Posters 403 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • Joe von HabsburgJ Offline
    Joe von HabsburgJ Offline
    Joe von Habsburg
    wrote last edited by Joe von Habsburg
    #1

    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.
    IMG_0980.jpeg
    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?

    1 Reply Last reply
    1
    • J.HilkJ Offline
      J.HilkJ Offline
      J.Hilk
      Moderators
      wrote last edited by
      #2

      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.


      Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


      Q: What's that?
      A: It's blue light.
      Q: What does it do?
      A: It turns blue.

      Joe von HabsburgJ S 2 Replies Last reply
      4
      • J.HilkJ J.Hilk

        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.

        Joe von HabsburgJ Offline
        Joe von HabsburgJ Offline
        Joe von Habsburg
        wrote last edited by
        #3

        @J.Hilk Thank you for your reply

        1 Reply Last reply
        2
        • J.HilkJ J.Hilk

          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.

          S Offline
          S Offline
          SimonSchroeder
          wrote last edited by
          #4

          @J.Hilk This sounds like the address sanitizer or thread sanitizer could help (maybe).

          1 Reply Last reply
          0
          • Joe von HabsburgJ Offline
            Joe von HabsburgJ Offline
            Joe von Habsburg
            wrote last edited by
            #5

            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;

            1 Reply Last reply
            0

            • Login

            • Login or register to search.
            • First post
              Last post
            0
            • Categories
            • Recent
            • Tags
            • Popular
            • Users
            • Groups
            • Search
            • Get Qt Extensions
            • Unsolved