RE: Bug #13355

Not sure it is a gtk bug, it might be a new feature as well ;-)

Anyway, I don't see why dblBufferingObj should be moved inside the while
loop. The issue is not there, but after, when we call the notifyers.
I'll track this more deeply next week if time permits.

Cheers,
Jean

Le jeudi 24 mai 2012 à 01:48 +0000, Martin Edmund Sevior a écrit :
> Hi Jean,
>
> If my patch never triggers an assert even though you get a crash, it is a sign that the bug is in gtk3. While I'm in favour of a work around that prevents a crash, it is important that the bug in gtk be fixed. Therefore
> please commit your patch with the following big comment in capital letters and let the gtk developers that we've exposed a crash bug that is present in gtk-3.4 but not gtk-.3.2.4 (distributed in Fedora 16).
>
> //
> // WORK AROUND FOR BUG 13355 CAUSED BY A BUG IN GTK-3.4. PLEASE TEST
> // AND REVERT TO EARLIER CODE ONCE THIS IS
> // FIXED.
> //
> #if 0
> FV_ViewDoubleBuffering dblBufferingObj(this, false, false);
> dblBufferingObj.beginDoubleBuffering();
>
> while ((!bDone || bIsDirty) && pCurRun)
> {
> #eise
> while ((!bDone || bIsDirty) && pCurRun)
> {
> FV_ViewDoubleBuffering dblBufferingObj(this, false, false);
> dblBufferingObj.beginDoubleBuffering();
> #endif
>
> Cheers
>
> Martin
> ________________________________________
> From: Jean Brefort [jean.brefort@normalesup.org]
> Sent: Tuesday, May 22, 2012 7:33 PM
> To: Martin Edmund Sevior
> Subject: RE: Bug #13355
>
> Hi Martin,
>
> Your patch did not help. Attached one fixes the issue, it just calls
> notifyListener() after ending the double buffering operation. The patch
> looks large, it actually just add a block (two lines added) and some
> tabulations between the twon new braces. I might investigate more to
> find out which listener destroys the cairo surface and how.
>
> Cheers,
> Jean
>
> Le lundi 21 mai 2012 à 19:33 +0000, Martin Edmund Sevior a écrit :
> > Hi Jean,
> >
> > Try following patch on your trunk. All it does is check that the depth of the double buffer is valid at the pop.
> >
> > It all look fine on my trunk build. I suspect you've hit a gtk3 bug.
> >
> > Cheers
> >
> > Martin
> >
> > ________________________________________
> > From: Jean Brefort [jean.brefort@normalesup.org]
> > Sent: Tuesday, May 22, 2012 4:47 AM
> > To: Martin Edmund Sevior
> > Subject: RE: Bug #13355
> >
> > Ubuntu has 3.4.1 so might be related to the version change. gtk+-3.4 is
> > known to have compatibility issues with previous versions. Anyway if a
> > listener needs to draw anything to the window we need to pass the
> > cairo_t to it, or move the notification out of the double buffering.
> >
> > Cheers,
> > Jean
> >
> > Le lundi 21 mai 2012 à 15:27 +0000, Martin Edmund Sevior a écrit :
> > > Hi Jean,
> > >
> > > I don't see this bug in abiword trunk in fedora 16. Nothing shows up in valgrind.
> > >
> > > Fedora 16 uses [msevior@seviorlap2 bin]$ rpm -qv gtk3
> > > gtk3-3.2.4-1.fc16.i686
> > >
> > > Is this a bug in the version of gtk3 distributed with Ubuntu 12.4?
> > >
> > > Cheers
> > >
> > > Martin
> > > ________________________________________
> > > From: Jean Brefort [jean.brefort@normalesup.org]
> > > Sent: Monday, May 21, 2012 8:04 PM
> > > To: Martin Sevior
> > > Subject: Bug #13355
> > >
> > > Hi Martin,
> > >
> > > I'm facing this annoying bug, which makes abiword crash a lot. After
> > > some analysis, I came to the conclusion that some listener destroys the
> > > cairo surface while we are doing a double buffering operation. I just
> > > found that 10 listeners are notified, but did not search more. Removing
> > > the call to notifyListener() in FV_View::_drawOrClearBetweenPositions(),
> > > or ending the double buffering before calling it seems to fix the issue.
> > >
> > > Do you have any hint about that?
> > >
> > > Thanks,
> > > Jean
> > >
> > >
> > >
> >
> >
> >
>
>
Received on Thu May 24 16:32:09 2012