PDA

View Full Version : Help with out of bounds message



aarelovich
18th February 2009, 22:04
Hi I've got this code that generates some odd behaviour:



void function A(){
QString Error = "";
for (int i = 0; i < params.size(); i++){
Error = function B();
qDebug() << "Done B";
}
}


QString function B(){
//Very long cycle that does many things and calls many functions that might return erros
qDebug() << "Returning B";
return "";
}


The program crashes and shows this result on the output:

.
.
.
Returning B
ASSERT failure in QVector<T>::operator[]: "index out of range", file c:/Qt/QtCreator/qt/include/QtCore/../../src/corelib/tools/qvector.h, line 325
Done B
.
.
.
.

Even after this error the program keeps on executing a while longer (seemingly correctly) before crashing with a Runtime Error with a dialog box from the Microsoft Visual C++ Runtime Library. (I'm using the full QtCreator instalation to write and compile my soft.).

My thinking is that this QVector error found at some other point in the program and it get written to the console at the point shown. So what I want to know is how I can know exactly in which vector did the error ocurr. I was thinking something along the a try-catch but I don't know how to use them with Qt. And it seems that it's not supported.

Thanks for anyhelp.

nmuntz
18th February 2009, 22:24
In your code what type is params?

You could try adding


CONFIG += debug


to your .pro file to enable debugging on your program and try to run it from a command prompt and check the output.

The error that you are getting is related to an index being out of bounds, so it could be a loop that you are doing that is referencing the wrong index for the vector. It could also be that a vector is not being populated as you are expecting.

wysota
19th February 2009, 02:18
Are you using multiple threads in your program?

aarelovich
19th February 2009, 11:34
To answer all questions:

1) Params is a QVector<MyStruct> Where MyStruct holds a bunch (about six or seven double values). But it's not a problem with this because the size is 12 (I've printed it also) and the error occurs in the first iteration between the index going from 0 to 1. I also use QVectors of different kinds inside the program (where I put the comment).

2) As I understand it CONFIG += DEBUG builds the project in debug mode (which I'm allready doing) and the output that I show is from the console itself. Windows console will likely show the same messages.

3) Yes, I use two threads. One has the GUI interface. Since with the push of a button I have to launch a really long process I use a second thread which is where the code written lies. The class that contains the code is a QThread Child.

aarelovich
19th February 2009, 12:00
Hi:

So I've been testing out a few things like writing a bit more to the output and so forth a step by step trace. I've have come to the conclusion that the error seems to occur in a destructor. What I really don't understand is why the program keeps on running for two other iterations before stopping. Each iteration is 1000 Steps. So it does 1000 Steps that is when I get the ASSERT error. Then I does another 1000 steps this time NO error is emitted and the it does somewhere between 500 and 800 steps of the next iteration before the error message appears. The number of steps in the third iteration varies with everytime I execute it.

Any ideas?

Thanks.

wysota
19th February 2009, 19:59
My guess is your problem is related to having two threads. Can we see the code of the worker thread?

aarelovich
19th February 2009, 20:14
Hi:

Thanks for the help but I found the problem. There were two threads, right? I'm calling it worker thread and GUI thread. The worker thread sent a couple of QVectors to update a line graph managed by the GUI thread. However I was the one the wrote the code for the graph. And it that code, when the vectors were set to be equal to the internal (plot class) vectors y forgot that I made a search for the highest and lowest value of the vectors in order to do the auto-range feature. However the vectors were empty (which is a valid program condition) but it tried to access them nonetheless without checking if it was empty or not. However since there were two threads the Qt warning appeared in that by coincidence since the graph was set (by user input) to update each 1000 steps just the same amount of steps that the cycle lasted.

Thanks for all the help.

talk2amulya
19th February 2009, 20:45
hi,

i understand this thread is pretty much over with, but i have a question for wysota:

how did u know, before he even told, that there were multiple threads involved?? thats really uncanny!

aarelovich
19th February 2009, 20:49
I'm going to venture a guess and say that he probably thought of that because of the uncanny place where the QVector message appeared. If there is only one thread a message in that place would have been pretty much impossible.

But that's just a guess. I'll think I'll let the man answer.

wysota
19th February 2009, 22:30
Ok :)

Three reasons...
1. a "strange" delay in the application crashing - that's usually a sign there is another thread butting in
2. the fact that the crash was occuring (or seemed to occur) during a destructor - destructors shouldn't crash like that. Destructors crashing are often a sign of another thread wreaking havoc in internal structures of some object
3. having almost 12500 posts in this forum :) That's really a lot of experience even though some of those posts are trolling around and providing oxygen to flame wars.

Oh... there is also fourth reason - increasing popularity of multithread solutions.

aarelovich
19th February 2009, 23:36
Well I'd like then the chance to ask....

If you need to start a long process (such as a lenghty math computation and by lengthy I mean it lasts more than 10 seconds ) How do you do it without using another thread. Because if you put the process in the button or action or whatever that is suppose to begin said process then your GUI (very understandbly) freezes until the process is over.

talk2amulya
20th February 2009, 05:23
i think THAT's why threads are there..to do sm BIG computation away from a thread where the user is interacting..so using threads is the best bet in such cases. but i guess, we have to be very careful as how we use it and not start abusing them..QT provides us with a very powerful API and its important how we employ it :)

wysota
20th February 2009, 09:03
If you need to start a long process (such as a lenghty math computation and by lengthy I mean it lasts more than 10 seconds ) How do you do it without using another thread. Because if you put the process in the button or action or whatever that is suppose to begin said process then your GUI (very understandbly) freezes until the process is over.

http://doc.trolltech.com/qq/qq27-responsive-guis.html

aarelovich
20th February 2009, 09:46
Thans for the help. But according to what I've read, I've actually used the nicest solution to my problem. By using a Worker Thread.

wysota
20th February 2009, 11:17
I didn't say you used a wrong solution. I meant there were other solutions as well. Always pick a solution that's tailored to your exact situation - one time this will be a worker thread, another time it will be something else even if at first it may seem both situations are similar.

aarelovich
20th February 2009, 11:44
No, yes of course. What I meant was that since I'm kind of new at this, I was happy I chose what seemed like the nicest solution.

Besides I'm not forgetting that page anytime soon.
Thanks for everything.