Qt crashing for larger programs?



  • I programmed a computer simulator/emulator, just a basic one that mimics Instruction sets and decoding/execution. However, after some of the larger example programs are run on the computer emulating class, the Qt program just crashes, all of my code is outputting to a debug file so I know it is working fine. To be precise, the program (implemented in a 'memory' simulating class by raw machine code) squares and outputs all the numbers from 1 to 99 and outputs them to a 'terminal' QWidgetList on mainWindow so the user can read through them. The debug console clearly shows it operating successfully up to the number 42, where it just decides it doesn't want to continue and crashes.

    Is there some form of watchdog timer that needs to be disabled or Cache that should be cleared?
    What else could be causing this?
    I will post additional information and segments of specific bits of code if requested



  • 0_1524848388735_dd37e73d-5cdd-491c-9d3a-da1e05d92a0d-image.png

    This is the debugger's take on the issue



  • 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.



  • 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.



  • @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



  • 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?



  • 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?


  • Qt Champions 2017

    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.



  • 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??


  • Qt Champions 2017

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



  • 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


  • Qt Champions 2017

    @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.



  • 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?


  • Lifetime Qt Champion

    Hi,

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



  • @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.



  • @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


  • Moderators

    @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).



  • 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.



  • @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.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.