> 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
>
>
_______________________________________________
Plasma-devel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/plasma-devel
