[SOLVED] Qt Programm crashes after calling a function.
-
Hi,
One thing I can see is that you don't check in BitsToUINT16 that bitstart and bitend are within the range 0-63 so you might be trying to access the array at a wrong index
-
Hi,
Looking at the variables window, I see that the this pointer is null. Somehow you called that MainWindow::addTreeChild() function on a null MainWindow pointer. candatabank->CANSignalList() is the first line in that function where the this pointer is called, therefore it crushes there.
You should find out how you end up using a null MainWindow pointer.
PS: A call like
@candatabank->CANSignalList()@is actually
@this->candatabank->CANSignalList()@ -
[quote author="SGaist" date="1420665508"]Hi,
One thing I can see is that you don't check in BitsToUINT16 that bitstart and bitend are within the range 0-63 so you might be trying to access the array at a wrong index[/quote]
i was thinking about it but i made this change to code!
@int CANdatabank::CANSignalList()
{
return 1;
}
@
i deleted everything and with the call
int results = candatabank->CANSignalList();
The program crashes also!! i think it is not in function but something else in call structure -
[quote author="xmaze" date="1420667424"]
[quote author="SGaist" date="1420665508"]Hi,One thing I can see is that you don't check in BitsToUINT16 that bitstart and bitend are within the range 0-63 so you might be trying to access the array at a wrong index[/quote]
i was thinking about it but i made this change to code!
@int CANdatabank::CANSignalList()
{
return 1;
}
@
i deleted everything and with the call
int results = candatabank->CANSignalList();
The program crashes also!! i think it is not in function but something else in call structure[/quote]Since the * this * pointer is null, a call to CANSignalList() will crash the program regardless of the body of that function.
-
What's puzzling is if "this" is null, how can it even go so far ?
On a completely unrelated note, slots should not return values. Use Q_INVOKABLE if needed and you have several memory leaks.
-
[quote author="ckakman" date="1420670165"]
Since "this" is just a parameter passed to member functions, you can go until you use the "this" pointer.[/quote]Do you have an idea how to find the solution?
When the DLC is 8 why the program runs completely without malfunction? -
[quote author="ckakman" date="1420670165"]
[quote author="SGaist" date="1420669005"]What's puzzling is if "this" is null, how can it even go so far ?[/quote]Since "this" is just a parameter passed to member functions, you can go until you use the "this" pointer.[/quote]
I guess you meant how it could go that deep in the call stack if this were null all along. That's puzzling indeed.
I wonder how that file is compiled because line 382 in the screenshot doesn't look like valid c++. B.DLC is a member variable of the struct. The compiler couldn't have determined the array size statically.
The inner and outer loops always iterate over the same ranges since s is sizeof(B.Data). However bits has varying size depending on B.DLC.
Here comes my conspricy theory: If bits is not large enough, an out-of-bounds access occurs and maybe "this" pointer variable in the stack frame gets overwritten, hence the crush.
-
@for(int i=0; i<s; ++i){
for(int b=0; b<8; ++b) {
int f=i*8+b; bool bit = (B.Data[i]&(1<<(7-b)));
if(bit) bits[f]=1; else bits[f]=0;
}}@in this loop when f is equal to 34 then <<like in screen shots>> the pointer "parent" is NULL and after some loops, when f is 44 or 43 i dont remeber exactly, the this pointer is NULL. why??
-
The screenshot is taken on Gnome, so the compiler is probably GCC. If I am not mistaken GCC has this nonstandard feature where arrays can have their sizes be specified during runtime. I think this was a C feature.
xmaze noted in the issue description that the crash occurs when DLC is less than 8. So bits is a smaller array if DLC is smaller, but the outer for loop always iterates 8 times (Data is an array of size 8). Inner loop also iterates 8 times, so bits must always be of size 64 but it is not when DLC is less than 8. So out of bounds array access happens for sure.
It seems that the "this" pointer is rather close to bits in the stack frame so it gets overwritten when out if array access occurs.
-
but i tried to workaround this problem before few days, in function SortTheFrameToStructure() i put all the arrived frames from the usb dongle in Vector as a Structure!
@for (int i=0; i<R.DLC;i++) {R.Data[i] = list[5+i].toUInt(&ok,16);}
if(R.DLC<8) {for(int k=R.DLC;k<8;k++) R.Data[k]=0;} //Work around NEED to TESTED@when the DLC is lower i try to put some data to eliminate the overflow.
Do u think is that a mess? it is a bad idea or what? -
[quote author="xmaze" date="1420674425"]but i tried to workaround this problem before few days, in function SortTheFrameToStructure() i put all the arrived frames from the usb dongle in Vector as a Structure!
@for (int i=0; i<R.DLC;i++) {R.Data[i] = list[5+i].toUInt(&ok,16);}
if(R.DLC<8) {for(int k=R.DLC;k<8;k++) R.Data[k]=0;} //Work around NEED to TESTED@when the DLC is lower i try to put some data to eliminate the overflow.
Do u think is that a mess? it is a bad idea or what? [/quote]The problem is not in Data. What you are doing there is initializing unused bytes. That is OK.
You need to make sure that the bits array in add child function is of size 64. Otherwise you will have out of bounds access since your loops always iterate 64 times in total.
-
[quote author="ckakman" date="1420668650"]
Since the * this * pointer is null, a call to CANSignalList() will crash the program regardless of the body of that function.
[/quote]Not quite true. A call to a memberfunction of a null or deleted object may succeed if that function doesn't access any members. Not that I recommend calling functions on those "shells of" objects, but still...
[quote author="SGaist" date="1420669005"]What's puzzling is if "this" is null, how can it even go so far ?
On a completely unrelated note, slots should not return values. Use Q_INVOKABLE if needed and you have several memory leaks.[/quote]
Sorry, also need to disagree on that. It is perfectly fine for slots to have return values. Don't expect them to be used in cases where the slot is used as slot, but it is possible and may be valid. Q_INVOKABLE is there for methods that you want to be callable from for instance QtScript but that are not slots.[quote author="xmaze" date="1420705632"]Thank you very much!!
Solution found!!
i have and some more questions for this programm, need i make new thread or can i ask in this thread?[/quote]
If they are not related to this problem, but only to this program, please use new threads. And for each problem, please use the search here, the documentation and the general internet first of course. -
[quote author="Andre" date="1420707497"]
[quote author="ckakman" date="1420668650"]
Since the * this * pointer is null, a call to CANSignalList() will crash the program regardless of the body of that function.
[/quote]Not quite true. A call to a memberfunction of a null or deleted object may succeed if that function doesn't access any members. Not that I recommend calling functions on those "shells of" objects, but still...
[/quote]I am aware of that possibility and I myself explained it to the OP. But the situation here is different:
Note that CANSignalList() is not a member function of a null or deleted object. Instead, that function is a member function of a member variable of the null object. Therefore it is called via the null this pointer. See the line 398 in the screenshot. -
[quote author="Andre" date="1420707497"]
/snip
[quote author="SGaist" date="1420669005"]What's puzzling is if "this" is null, how can it even go so far ?On a completely unrelated note, slots should not return values. Use Q_INVOKABLE if needed and you have several memory leaks.[/quote]
Sorry, also need to disagree on that. It is perfectly fine for slots to have return values. Don't expect them to be used in cases where the slot is used as slot, but it is possible and may be valid. Q_INVOKABLE is there for methods that you want to be callable from for instance QtScript but that are not slots.
/snip again
[/quote]I completely agree with you they can. However I've already seen cases where people where using that in a multithreaded environment and there's no need to tell you what happened. That's why I recommend against that use and rather use Q_INVOKABLE also as a mean to make the code clearer about what it can do and how it can be properly used.
-
Lets discuss prof1ts! Are you afraid of big numbers? I protest, you don’t know what that is. You are no different than N4ZIs book burners if you DEF4CE this, you deserve to have it splattered around.
annualreport2013.digia dot com/ financial_statement/consolidated_income_statement
@
Digia
Total assets in 2013 83,277,864.58Operating prof1t
2006 2007 2008 2009 2010 2011 2012 2013 2014 Total
8,3 11 13,4 -7,8 17,1 -22,1 6,9 -2,8 XXX 24,0
@You might have a hard time to find info older then 2008, but don’t take my word on it, even if you discount years before 2008 you are still on 4,7 Million green mark TOTAL.
Now listen, do you see that forbidden triple X? You are there now, that’s you critical branch-point. I could call you a bunch of cry babies, but I won’t. Here’s my message to you.MILLIONS IN PROF1T! Most people yearly “salaries” are not even close to “1%” of that smaller million of that smaller mostly unknown company. All while paying many millions on an undervalued Qt from a fading company, with salesman altering/faking peoples CVs just to sell/dump people to customers signing whatever prof1table contracts and ultimately firing LOTS of people with fake excuses.
There’s a very pertinent question that demands an answer.
Even though, many world economies, Nokia, Digia and all other companies are still under the wise guidance of the best supreme leaders available, why does at least the first three are still in crisis or under a steep decline in operating prof1ts, among other things.
This question is not, I think, irreverent, although it may trouble whatever supreme leaders may be.“Those worlds in space are as countless as all the grains of sand on all the beaches of the Earth. Each of those worlds is as real as ours. In every one of them, there's a succession of incidents, events, occurrences which influence its future. Countless worlds, numberless moments, an immensity of space and time. And our small planet, at this moment, here we face a critical branch-point in the history. What we do with our world, right now, will propagate down through the centuries and powerfully affect the destiny of our descendants. It is well within our power to destroy our civilization, and perhaps our species as well. If we capitulate to superstition, or greed, or stupidity we can plunge our world into a darkness deeper than time between the collapse of classical civilization and the Italian Renaissance. But, we are also capable of using our compassion and our intelligence, our technology and our wealth, to make an abundant and meaningful life for every inhabitant of this planet. To enhance enormously our understanding of the Universe, and to carry us to the stars.”
https://www.youtube dot com/watch?v=hLkC7ralR30The Earth is the only world known, so far, to harbor life. There is nowhere else, at least in the near future, to which our species could migrate. Visit, yes. Settle, not yet. Like it or not, for the moment, the Earth is where we make our stand. It has been said that astronomy is a humbling and character-building experience. There is perhaps no better demonstration of the folly of human conceits than this distant image of our tiny world. To me, it underscores our responsibility to deal more kindly with one another and to preserve and cherish the pale blue dot, the only home we've ever known.”””
!https://upload.wikimedia.org/wikipedia/commons/7/73/Pale_Blue_Dot.png (https://upload.wikimedia.org/wikipedia/commons/7/73/Pale_Blue_Dot.png)!
765765657
