Flate image and r1083565 (Was: Re: Walkers mass-test - help needed)

[Dmitry Kazakov]

Well, i haven't tried to put qFatal there, but i'll try it later. Strangely,
reverting the patch helps.

On Tue, Feb 2, 2010 at 2:46 PM, Cyrille Berger  wrote:

> On Tuesday 02 February 2010, Boudewijn Rempt wrote:
> > On Monday 01 February 2010, Dmitry Kazakov wrote:
> > > http://dimula73.narod.ru/walkers_singlepatch_v5.diff
> <http://dimula73.naro
> > >d. ru/walkers_singlepatch_v4.diff>
> > >
> > > o Fixed undo after Flatten Image.
> > > o Fixed refresh after creation of the layer
> > >
> > > o Reverted Cyrille's commit r1083565 to eliminate crash
> >
> > For this, I think you should open a bug: "memory leak on document
> >  destruction" with the history of this patch. We should fix the memory
> >  leak, but that might be hard.
> >
> Yes and I am really sceptical that that change has anything to do. The
> destructor is only deleted by the document. To make sure of that I added a
> qFatal in the destructor, and did:
> * open krita
> * close krita
> * qFatal triggered
>
> And then I did
> * open krita
> * add layer
> * flaten image
> * undo (twice, not sure why flatten image is not grouped anymore)
> * assert somewhere else
>
> So in my case the destructor of KisShapeController (which is the only thing
> changed by r1083565) is only called on document destruction at krita exit,
> and
> not during flaten image. So can someone that can reproduce the flatten
> image bug
> with change r1083565 and not r1083565, add a qFatal("something");, in
> KisShapeController::~KisShapeController, and send me the backtrace that
> goes
> to the destructor ? (alternatively, you can use a break point in gdb, but I
> do
> tend to not find them trustworthy).
>



-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20100205/0f60caba/attachment.htm