Review Request 120057: Fix scrollbar appearing on FolderView

[Mark Harmstone]

> On Sept. 5, 2014, 11:55 a.m., David Edmundson wrote:
> > I'm not very happy with this. I'm sure it works, but it's a workaround without knowing the root problem (or at least I'm not convinced we do). It almost certainly is not memory corruption, and blind patching isn't a good longterm strategy. 
> > 
> > I imagine the case will be:
> >  - widget is made (with QGraphicsScene that corana inherits from having size 0,0)
> >  - we run this FolderView::constraintsEvent
> >  - corona resizes
> >  - folderview doesn't see it has resized
> > or something along these lines
> >   
> > Can you test what path we take in Corona::screenGeometry? and what the sceneRect is at the point this runs?
> 
> David Edmundson wrote:
>     forgot to say: Thanks for looking into this, it's really appreciated.

You're welcome, no problem.

Blind patching might not be a good idea in general, but I think it's worth bearing in mind that this fixes a major usability bug, and one that for two years has proven nearly impossible to debug, let alone fix. Plus it obviously doesn't break anything - and, by way of comparison, the comment a few lines above it has read "FIXME: a pretty horrible hack" for a couple of years now...

I'm almost certain this is a memory corruption issue, though. If you insert a line "volatile QRect r3(r);" just before DesktopCorona::availableScreenRect returns, and put a breakpoint on the return, gdb says that when this bug is triggered, r3 and r differ. (Specifically, r = {x1 = 0, y1 = 0, x2 = 1919, y2 = 1079}, as it should be, but r3 = {x1 = 0, y1 = 0, x2 = 1919, y2 = 0}, which is what is actually returned.)
I've uploaded a disassembly of DesktopCorona::availableScreenRect, as compiled by gcc -O2, to http://burntcomma.com/dc.txt. There's a couple of "volatile" debugging lines there, which is why the line numbering doesn't match up exactly. I don't understand assembly all that well - certainly not well enough to diagnose and fix the problem in gcc, if there is one - but it looks like r.bottom() is being stored in DWORD PTR [rsp+0x3c]. Even though there's nothing wrong with the C++ code (as far as I can see), this is then being clobbered within the foreach loop, for some reason.


- Mark


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120057/#review65827
-----------------------------------------------------------


On Sept. 5, 2014, 11:25 a.m., Mark Harmstone wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120057/
> -----------------------------------------------------------
> 
> (Updated Sept. 5, 2014, 11:25 a.m.)
> 
> 
> Review request for Plasma and Ignat Semenov.
> 
> 
> Bugs: 294795
>     http://bugs.kde.org/show_bug.cgi?id=294795
> 
> 
> Repository: kde-baseapps
> 
> 
> Description
> -------
> 
> Fixes bug 294795. See there for further details.
> 
> 
> Diffs
> -----
> 
>   plasma/applets/folderview/folderview.cpp f56cab1fee8848c551d3687dbd480ed1ed5ac591 
> 
> Diff: https://git.reviewboard.kde.org/r/120057/diff/
> 
> 
> Testing
> -------
> 
> The patch fixes a race condition, meaning it is difficult to reproduce. However, with the patch applied I have not been able to reproduce it after dozens of reboots on a handful of different machines. Plus the scrollbar issue was always accompanied by the toolbox changing position, which still happens sporadically - strongly implying that the scrollbar is fixed.
> 
> 
> Thanks,
> 
> Mark Harmstone
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140905/c25b5425/attachment.html>