Qt crashing for larger programs?
-
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?
-
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. - Is there some sort of limit on the number of elements you can have in a QListWidget?
-
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??
-
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
@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.
-
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?
-
Hi,
Then I'd recommend trying KDAB's GammaRay to watch your application's internals at work.
-
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?
@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 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 -
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.
@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
QVectororstd::vectorinstread. 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 oneI 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.
-
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.
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.
