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. Qt crashing for larger programs?
Forum Updated to NodeBB v4.3 + New Features

Qt crashing for larger programs?

Scheduled Pinned Locked Moved Solved General and Desktop
19 Posts 5 Posters 3.3k Views 3 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.
  • W Offline
    W Offline
    wrosecrans
    wrote on last edited by
    #4

    FYI, it's extremely likely to be pointer related. Memory won't be allocated at consistent addresses from one run to the next, so flaky behavior like you describe is often pointer related. On one run, a bug clobbers a value in an address that doesn't cause a crash. On the next run, the same bug clobbers some other spot in memory and triggers a crash.

    Look into building with Address Sanitizer for some help tracking down memory usage bugs. I've found it quite helpful.

    H 1 Reply Last reply
    2
    • W wrosecrans

      FYI, it's extremely likely to be pointer related. Memory won't be allocated at consistent addresses from one run to the next, so flaky behavior like you describe is often pointer related. On one run, a bug clobbers a value in an address that doesn't cause a crash. On the next run, the same bug clobbers some other spot in memory and triggers a crash.

      Look into building with Address Sanitizer for some help tracking down memory usage bugs. I've found it quite helpful.

      H Offline
      H Offline
      Hubbard
      wrote on last edited by
      #5

      @wrosecrans Its the same spot everytime in the same program though, and I've taken almost every use of pointer out of my program

      /* Header File */
      #include "mainmemory.h"

      /* Constructor/Destructor */
      MainMemory::MainMemory(QObject *parent) : QObject(parent)
      {
      memory = new Word[300];
      CPUReadWrite = 0;

      createExampleProgram();
      

      }

      /* Public Slots */
      void MainMemory::mainMemoryFromControlBus(bool readWrite)
      {
      CPUReadWrite = readWrite; // Read control signal from Bus
      }

      void MainMemory::mainMemoryFromAddressBus(int addressReference)
      {
      if(CPUReadWrite == 0) // Read mode - Program continues from here, data outputted from memory to bus
      {
      qDebug() << " Main Memory";
      qDebug() << " " << "Address Requested: " << addressReference;

          emit mainMemoryToDataBus(memory[addressReference]);
      }
      if(CPUReadWrite == 1)                                               // Write mode - Program continues from data source
          addressReferenced = addressReference;
      

      }

      void MainMemory::mainMemoryFromDataBus(Word data)
      {
      qDebug() << "Main Memory";
      qDebug() << " " << data.data << " Written to cell " << addressReferenced;

      memory[addressReferenced] = data;                                   // Write mode, writes Word 'data' to the memory block referenced
      emit cycleComplete();
      

      }

      /* Private Methods */
      void MainMemory::createExampleProgram()
      {
      // 0 LOAD Loads memory block addressed into accumulator
      // 1 STORE Store accumulator contents into memory block addressed
      // 2 ADD Add addressed memory block contents to accumulator contents
      // 3 SUB Sub addressed memory block contents from accumulator contents
      // 4 MULT Multiply accumulator contents by addressed memory block contents
      // 5 DIV Divide accumulator contents by addressed memory block contents
      // 6 AND unused
      // 7 OR unused
      // 8 XOR unused
      // 9 NOR unused
      //10 JUMP Jump to address (set PC contents to operand)
      //11 BEQ Jump to address (operand2) if addressed memory block contents (operand1) == accumulator contents
      //12 BNE Jump to address (operand2) if addressed memory block contents (operand1) != accumulator contents
      //13 BLE Jump to address (operand2) if addressed memory block contents (operand1) <= accumulator contents
      //14 BGE Jump to address (operand2) if addressed memory block contents (operand1) >= accumulator contents
      //15 BLT Jump to address (operand2) if addressed memory block contents (operand1) < accumulator contents
      //16 BGT Jump to address (operand2) if addressed memory block contents (operand1) > accumulator contents
      //17 WFI CPU idle and waiting for interrupt

      //      Example program, does some operations and outputs result(22)
      memory[0].opcode = 0;
      memory[0].operand1 = 6;
      
      memory[1].opcode = 2;
      memory[1].operand1 = 7;
      
      memory[2].opcode = 4;
      memory[2].operand1 = 8;
      
      memory[3].opcode = 5;
      memory[3].operand1 = 9;
      
      memory[4].opcode = 1;
      memory[4].operand1 = 301;
      
      memory[5].opcode = 17;
      
      memory[6].data = 6;
      memory[7].data = 5;
      memory[8].data = 6;
      memory[9].data = 3;
      //      End
      
      //      Squares Program
      memory[10].data = 1;                // Variable i being incremented     'For' loop scope symbols ie for(int i; i < 100; i++)
      memory[11].data = 100;
      memory[12].data = 1;
      
      memory[13].opcode = 11;             // Branch to WFI (program finished) if variable i (address 10) equals 100
      memory[13].operand1 = 11;
      memory[13].operand2 = 21;
      
      memory[14].opcode = 0;              // Load i into the accumulator
      memory[14].operand1 = 10;
      
      memory[15].opcode = 4;              // Multiply accumulator contents (copy of i) by i
      memory[15].operand1 = 10;
      
      memory[16].opcode = 1;              // Store the result into the IOModule's output
      memory[16].operand1 = 301;
      
      memory[17].opcode = 0;              // Reload the variable i into the AC (unnecessary for register based topology)
      memory[17].operand1 = 10;
      
      memory[18].opcode = 2;              // Increment i
      memory[18].operand1 = 12;
      
      memory[19].opcode = 1;
      memory[19].operand1 = 10;
      
      memory[20].opcode = 10;             // Jump back to conditional operand
      memory[20].operand1 = 13;
      
      memory[21].opcode = 17;
      

      }

      The squares program always crashes on 41

      1 Reply Last reply
      0
      • H Offline
        H Offline
        Hubbard
        wrote on last edited by
        #6

        0_1524883652812_f5819f04-4be4-433f-ac88-0483be2c9561-image.png

        Update: I suspect it has something to do with this line of code (the 'output terminal') as when I run the example program (which simply adds 22 to the list) ~40 times the program crashes. Is there some sort of limit on the number of elements you can have in a QListWidget?

        1 Reply Last reply
        0
        • H Offline
          H Offline
          Hubbard
          wrote on last edited by
          #7

          Scratch that I commented it out and it still crashes

          What is it about 41 that is causing these programs to crash my Qt emulation?

          1 Reply Last reply
          0
          • mrjjM Offline
            mrjjM Offline
            mrjj
            Lifetime Qt Champion
            wrote on last edited by mrjj
            #8

            Hi
            Did you look at call stack to see what was was doing before it crashes ?

            • Is there some sort of limit on the number of elements you can have in a QListWidget?
              Yes memory. and the type used for index. on 64 bit. millions of items. :)

            Also

            • watchdog timer that needs to be disabled or Cache that should be cleared?

            Qt is just a c++ framework. there is no capping or watching going on. You are allowed
            to sink the ship in any way you like.
            so what ever makes it crash is for real.

            1 Reply Last reply
            2
            • H Offline
              H Offline
              Hubbard
              wrote on last edited by Hubbard
              #9

              Okay my call stack has thousands of items in it. Guess that will happen when you use signals and slots as traces inbetween components all interrupting each other. Is there any way to 'clear' this upon each cycle or something??

              mrjjM 1 Reply Last reply
              0
              • H Hubbard

                Okay my call stack has thousands of items in it. Guess that will happen when you use signals and slots as traces inbetween components all interrupting each other. Is there any way to 'clear' this upon each cycle or something??

                mrjjM Offline
                mrjjM Offline
                mrjj
                Lifetime Qt Champion
                wrote on last edited by
                #10

                @Hubbard
                Hi
                Not really if you mean sort of a filter.
                but when crashed, the top ones should be what happen just before crash.

                1 Reply Last reply
                0
                • H Offline
                  H Offline
                  Hubbard
                  wrote on last edited by
                  #11

                  It says ntdll!RtAllocateHeap
                  Surely the fact that there are thousands of calls is the problem?

                  Sorry I'm not used to debugging programs, i'm an engineer not a developer

                  mrjjM 1 Reply Last reply
                  0
                  • H Hubbard

                    It says ntdll!RtAllocateHeap
                    Surely the fact that there are thousands of calls is the problem?

                    Sorry I'm not used to debugging programs, i'm an engineer not a developer

                    mrjjM Offline
                    mrjjM Offline
                    mrjj
                    Lifetime Qt Champion
                    wrote on last edited by
                    #12

                    @Hubbard
                    Hmm, RtAllocateHeap does suggest its memory related.
                    Did u check the apps mem consumptions.
                    oh, well maybe we should talk about the tools available then.
                    (might help)
                    In such case here where it happens after X runs, its very useful to instruct the debugger to wait to halt at a break point until some condition or
                    simple counts.
                    If u place a break point in the main method and right click the break point. You can select edit and get dialog with options.
                    alt text
                    So it should be possible to setup so it runs till almost crash "turn" and you can single step to find the line where it something happens.

                    I dont think its possible for us to guess here what is wrong. You will have to find it with the debugger.

                    1 Reply Last reply
                    1
                    • H Offline
                      H Offline
                      Hubbard
                      wrote on last edited by
                      #13

                      I had a look through and the line it breaks upon is completely uneventful (literally writing a string to qDebug(), which, to my knowledge, shouldn't crash anything).

                      0_1524947591765_1a51bbe5-cf7d-434e-a5e9-e300def79c01-image.png

                      This is how my program works, components emit signals to each other and the target components emit more signals of processed information until its stored in that heap there in memory or a component emits a finish signal to the PC, so there is no real program flow just lots of classes interrupting each other, this is why the call stack is so huge I think. Is this a problem?

                      W 1 Reply Last reply
                      0
                      • SGaistS Offline
                        SGaistS Offline
                        SGaist
                        Lifetime Qt Champion
                        wrote on last edited by
                        #14

                        Hi,

                        Then I'd recommend trying KDAB's GammaRay to watch your application's internals at work.

                        Interested in AI ? www.idiap.ch
                        Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

                        1 Reply Last reply
                        0
                        • H Hubbard

                          I had a look through and the line it breaks upon is completely uneventful (literally writing a string to qDebug(), which, to my knowledge, shouldn't crash anything).

                          0_1524947591765_1a51bbe5-cf7d-434e-a5e9-e300def79c01-image.png

                          This is how my program works, components emit signals to each other and the target components emit more signals of processed information until its stored in that heap there in memory or a component emits a finish signal to the PC, so there is no real program flow just lots of classes interrupting each other, this is why the call stack is so huge I think. Is this a problem?

                          W Offline
                          W Offline
                          wrosecrans
                          wrote on last edited by
                          #15

                          @Hubbard said in Qt crashing for larger programs?:

                          This is how my program works, components emit signals to each other and the target components emit more signals of processed information until its stored in that heap there in memory or a component emits a finish signal to the PC, so there is no real program flow just lots of classes interrupting each other, this is why the call stack is so huge I think. Is this a problem?

                          That definitely sounds like a problem. It's not that the program has no flow -- it's just that you haven't reasoned about what the flow is, or why it should be that way.

                          H 1 Reply Last reply
                          0
                          • W wrosecrans

                            @Hubbard said in Qt crashing for larger programs?:

                            This is how my program works, components emit signals to each other and the target components emit more signals of processed information until its stored in that heap there in memory or a component emits a finish signal to the PC, so there is no real program flow just lots of classes interrupting each other, this is why the call stack is so huge I think. Is this a problem?

                            That definitely sounds like a problem. It's not that the program has no flow -- it's just that you haven't reasoned about what the flow is, or why it should be that way.

                            H Offline
                            H Offline
                            Hubbard
                            wrote on last edited by
                            #16

                            @wrosecrans
                            I cannot think of a better way of simulating digital electronics though, I've wracked my brain thinking how I can do this without signals and slots in between classes and that go on to trigger more but I can't think of one

                            W 1 Reply Last reply
                            0
                            • H Hubbard

                              This is unlikely to be pointer related because as of the crash the example program was executing a task that it had done 41 times before.

                              JKSHJ Offline
                              JKSHJ Offline
                              JKSH
                              Moderators
                              wrote on last edited by JKSH
                              #17

                              @Hubbard said in Qt crashing for larger programs?:

                              as of the crash the example program was executing a task that it had done 41 times before.

                              This sounds like a classic case of memory corruption.

                              This is unlikely to be pointer related because...

                              It doesn't need to be pointer-related. Memory corruption can come through other ways too (for example, reading/writing past the last element in a raw C array)

                              @Hubbard said in Qt crashing for larger programs?:

                              memory = new Word[300];

                              This is a raw C array, allocated on the heap.

                              I don't know if this is related to your problem or not, but I recommend using QVector or std::vector instread. They have more safeguards built-in than a raw array (for example, you will get an assertion failure if you read beyond the end of the array in Debug mode).

                              Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

                              1 Reply Last reply
                              3
                              • H Hubbard

                                @wrosecrans
                                I cannot think of a better way of simulating digital electronics though, I've wracked my brain thinking how I can do this without signals and slots in between classes and that go on to trigger more but I can't think of one

                                W Offline
                                W Offline
                                wrosecrans
                                wrote on last edited by
                                #18

                                I cannot think of a better way of simulating digital electronics though, I've wracked my brain thinking how I can do this without signals and slots in between classes and that go on to trigger more but I can't think of one

                                Something like a CPU has a synchronous clock, so it would normally be done as a loop that uses a fixed amount of resources per-iteration. Each functional unit sets a flag or something, and the functional unit that would be responding to the signal would handle it in the next iteration. A real piece of silicon doesn't use more and more stuff as time goes by, so the software version shouldn't either. The way you are describing your signals and slots system, everything gets so deep that nothing ever returns and gets back to where it started, so the first step can't finish until everything is finished.

                                H 1 Reply Last reply
                                0
                                • W wrosecrans

                                  I cannot think of a better way of simulating digital electronics though, I've wracked my brain thinking how I can do this without signals and slots in between classes and that go on to trigger more but I can't think of one

                                  Something like a CPU has a synchronous clock, so it would normally be done as a loop that uses a fixed amount of resources per-iteration. Each functional unit sets a flag or something, and the functional unit that would be responding to the signal would handle it in the next iteration. A real piece of silicon doesn't use more and more stuff as time goes by, so the software version shouldn't either. The way you are describing your signals and slots system, everything gets so deep that nothing ever returns and gets back to where it started, so the first step can't finish until everything is finished.

                                  H Offline
                                  H Offline
                                  Hubbard
                                  wrote on last edited by
                                  #19

                                  @wrosecrans

                                  Yeah I solved the problem. The PC emits the next address inside a while(1) loop contained within the computer, meaning the call stack can go back and tie up any loose ends.

                                  One thing that can be gained here is... be careful with the call stack and don't create programs relying on endless loops of functions.

                                  1 Reply Last reply
                                  1

                                  • Login

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