QCanvasPolygonalItem delete and SegFault or pure virtual call

[hayati]

yes i also think so; but thread at trolltech, which i gave the link at first post, states that it is because of pure virtual funcs. Another fact supporting this is sometimes i really get pure virtual func errors. but both points to the same place = QCanvas::update()

QCanvaspolygonalItem::hide() accesses areaPoints(), which is virtual.
hide() is called from the QCanvasItem destructor if the item is still
visible by the time that destructor fires. Calling a virtual in a
destructor is not legal (more precisely, it is not late bound, so the
pure-virtual is called and "undefined" behavior results), so the runtime
explodes. This behaves very differently depending on the
compiler/platform. Sometimes you get a relatively clear "pure virtual
method call" message (with no mention of *which* method, of course). Other
times, the app segfaults. This is actually mentioned in the docs, but is
easy to miss/forget.

As a result what are we supposed to do next?

[wysota]

yes i also think so; but thread at trolltech, which i gave the link at first post, states that it is because of pure virtual funcs.

But it doesn't state you have the same probalem.

Another fact supporting this is sometimes i really get pure virtual func errors. but both points to the same place = QCanvas::update()

Run the application under a debugger and when it crashes, see the backtrace.

As a result what are we supposed to do next?

Correct your code

[hayati]

ok, thanks for reply;
but i can't figure out what is wrong with my little tiny code. (and this code is absolutely written to simulate the error)
i don't mean find my errors; i mean why qt doesn't generate pure virtual call errors or segfault when i increase the Cell objects size (width or height) but if i decrease its width or height then it crushes. please check this out in provided source file, i stated the situation in comments.
so what is wrong with this code (that leads to this error) could anybody explain me?
moreover; i have nothing to do with QCanvas::update()
procedure is quite simple shrink(decrease the size of) the object, delete the object and QCanvas::update() func call and it crushes.
remember when you increase its size there is no problem! only when you decrease this happens.

[wysota]

i don't mean find my errors;

I won't - I haven't used Qt3 for about two years now.

i mean why qt doesn't generate pure virtual call errors or segfault when i increase the Cell objects size (width or height) but if i decrease its width or height then it crushes.

For me it generates regular segmentation faults on updating the canvas view... I can delete the item without a segfault and then when I force a refresh it crashes. So obviously it's not a problem with an item that got deleted a few seconds earlier.

i have nothing to do with QCanvas::update()

Really? And what is that?

void GUI::deleteCell()
{
	// just delete first item and don't mind others
	Cell* c;
	for( std::vector<Cell*>::iterator it = cells.begin(); it != cells.end(); it++ ){
		c = *it;
		cells.erase(it);
		break;
	}
	delete c;
	c = NULL;
 
	canvas->setAllChanged();
	canvas->update();	// <======== What is that?
}

void GUI::deleteCell()
{
	// just delete first item and don't mind others
	Cell* c;
	for( std::vector<Cell*>::iterator it = cells.begin(); it != cells.end(); it++ ){
		c = *it;
		cells.erase(it);
		break;
	}
	delete c;
	c = NULL;
		
	canvas->setAllChanged();
	canvas->update();	// <======== What is that?
}

To copy to clipboard, switch view to plain text mode 

remember when you increase its size there is no problem! only when you decrease this happens.

And that proves what? That something is calling pure virtual methods in the destructor? Somehow I don't see that and the debugger seems to be taking my side and not yours. Did you have a look at the backtrace? Remember to remove the "hide()" call from the destructor (although it's probably perfectly valid there) and move it to GUI::deleteCell() "just in case".

[hayati]

First of all;
you may be right.
but this doesn't solves the problem just changes the title of the thread
in either way program crushes.

and QCanvas::update() HAS TO BE CALLED in order to reflect changes, what can be done?
we both have the same code and both are crushing.
as stated before, crush scnerio is simple;
decrease the size, delete and update the canvas
is it really a bug? or what is wrong with it?

Note: i tried to remove hide() before delete item. but this didn't help.

[wysota]

First of all;
you may be right.
but this doesn't solves the problem just changes the title of the thread

It does, because you'll be looking in the right direction instead of chasing a ghost.

and QCanvas::update() HAS TO BE CALLED in order to reflect changes, what can be done?

The proper question is "why does it crash?".

Is it really a bug? or what is wrong with it?

If I were to guess, I'd say your item class is invalid. It's quite easy to check it out - simply substitute it with QCanvasRectangle and see if it still crashes.

[hayati]

yes if i use QCanvasRectangle then it works great. but it doesn't meet my requirements ofcourse. (since my drawing is more complicated. that's why i used QCanvasPolygonalItem as base class)
what is being done wrong? hmm i'll check QCanvasRectangle implementation i guess.

i'll back to inform if i fail again.

thank you very much.

[wysota]

If I were to guess again, I'd say your areaPoints() implementation was incorrect.

[hayati]

no areaPoints() is pretty good.
it's inner undocumented problem
i've just checked source code of qcanvas.cpp

and surprise appears.
but thanks to qtcentre.org which leads to me to correct answer.

at qtcentre.org similar (maybe exactly same) problem was posted before.
post ends like below:

Hi

It has been fixed. Horray. A nice chap at Qt support saw the problem and luckily my example had made the problem worst. Anyway here it is:

// Note: if you reimplement the boundingRect() function
//of your QCanvasRectangle subclass and change the values this function
//returns while the item is visible, sure to call QCanvasPolygonalItem::invalidate().
// If you do not the QCanvas will use one bounding rectangle when adding the
// item to the chunks and a different one
//when removing, causing the internal list of items to still contain your
//item after it has been hidden. When the item is deleted, QCanvas still
//believes that the item is visible and uses the pointer and thus your
//program crashes. You will need to call
//invalidate() on the item if you do change it.

I did not realise from the Qt documentation overriding the boundRect() and changing the size would have this effect.

Cya Illya

I have seen the same problems about removing properly the QCanvasItem from the QCanvas. But I did not see the satisfying answer.

I have faced with the same problem. After two days, we found and solved the result as in the following.

When we try to delete the any items from the QCanvas by using the delete statement, we are facing the problem with resize or some thing like that which causes to call the update function of the QCanvas. In detail, it call the drawUnique() function. Anyway, althoug we delete the QCanvasItem from QCanvas, it stores another list which is a memeber of QCanvasChunk. That is, QCanvas uses another list in order to improve the its performance. It uses chunks which displays the changed items in the QCanvas. Therfore, we have to clear this list as well.

In order to do that, First, we can put setVisible(false) or hide() or invalidate() functions at the begining of the overloaded areaPoints() function. Then, we can add setVisible(true) or show() or update() functions at the end of the areaPoints() function.


setVisible() (or the others listed above) call to removeFromChunks() or addChunks() function. So any action which causes to call update function can not reason any conflists between the removed QCanvasItems and the internal list ( the list member of QCanvasChunk ) .

I think it should be a function of QCanvas which clear the chunks as well and it should be used in the destructor like hide as documented.

Best regards
Serhat

and QCanvasRectangle source code was same to my Cell class except below:

void QCanvasRectangle::setSize(int width, int height)
{
    if ( w != width || h != height ) {
	removeFromChunks(); // ATTENTION HERE
	w = width;
	h = height;
	addToChunks(); // ATTENTION HERE
    }
}

void QCanvasRectangle::setSize(int width, int height)
{
    if ( w != width || h != height ) {
	removeFromChunks(); // ATTENTION HERE
	w = width;
	h = height;
	addToChunks(); // ATTENTION HERE
    }
}

To copy to clipboard, switch view to plain text mode 

which supports post of Serhat.

So now, there is no way to reach these functions (removeFromChunks() and addToChunks()) but as post says there is way to accomplish this via other functions.

Addition to post there is no way to trigger these two functions in areaPoints() because areaPoints() is const.

i'll check and report test results to you.
Guess what?
now it makes sense about pure virtual func call. because it has reference to base class(via chunk list). but real class (derived obj) is deleted. so pure virtual call happens here.


thanks for interest

Hayati
Best Regards

[hayati]

problem solved.
invalide() was like below in "segfault caught code"

void Cell::setCellWidth(int w)
{
	m_width = w;
	invalidate();
	update();
}
 
void Cell::setCellHeight(int h)
{
	m_height = h;
	invalidate();
	update();
}

void Cell::setCellWidth(int w)
{
	m_width = w;
	invalidate();
	update();
}

void Cell::setCellHeight(int h)
{
	m_height = h;
	invalidate();
	update();
}

To copy to clipboard, switch view to plain text mode 

but at the working one;

void Cell::setCellWidth(int w)
{
	invalidate();
	m_width = w;
	update();
}
 
void Cell::setCellHeight(int h)
{
	invalidate();
	m_height = h;
	update();
}

void Cell::setCellWidth(int w)
{
	invalidate();
	m_width = w;
	update();
}

void Cell::setCellHeight(int h)
{
	invalidate();
	m_height = h;
	update();
}

To copy to clipboard, switch view to plain text mode 

invalidate() clears out the chunck and update() adds item the chunck. but they should be at the correct order. ie. invalidate() should be first statement of size changing function and update() should be very last (in case a return) statement.

It's qt's undocumented issue.

Hayati
Best Regards