> 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.
>
> Mark Harmstone wrote:
> 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.
well that's me close to happy. Good investigation :)
Any chance you can put a breakdown just after
QRect r3(r)
and type
"watch r3.y2"
we can see who does the clobbering.
- David
-----------------------------------------------------------
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
