Qt crashing for larger programs?

[Hubbard]

This is the debugger's take on the issue

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

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

[Hubbard]

@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

[Hubbard]

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?

[Hubbard]

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?

[mrjj]

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.

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

[mrjj]

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

[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

[mrjj]

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

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.

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

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?

[SGaist]

Hi,

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

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

[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

[JKSH]

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

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

[Hubbard]

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