screen corruption

[Rolf Leggewie]

Binary package hint: xxdiff

Running xxdiff on a hardy host and forwarding the display over ssh -X to a karmic host results in screen corruption. This was still working fine when the receiving host was running jaunty.

I actually don't think this is a bug in xxdiff, but rather in one of the used libraries. Likely candidates are libqt3-mt, libx11-6 and libxext6. Including all likely candidate packages for triage.

[Rolf Leggewie (r0lf)]

qgit is affected as well. In qgit I realized something interesting. When I click one of the lines that represent a commit in the upper part of the window, the corruption for that subwindow clears. The corruption comes back when bringing another window to the front to cover the qgit window and then switching back to gqit. It is possible to reverse the corruption again by clicking one of the lines.

[Robert Hooker (sarvatt)]

all qt based apps.. can you reproduce it on anything not qt based?

[Rolf Leggewie (r0lf)]

Robert, not thus far. I've listed the apps that give me problems here. Although I do experience something very similar in my XFCE desktop (no ssh forwarding at all). File names are displayed fine, but when I select an icon, a very similar corruption of the filename occurs. Not sure if this isn't a separate issue, though. I attach another screenshot (the name of the second file is "test2.txt").

[Rolf Leggewie (r0lf)]

thinking about it, I remember now that fslint-gui was affected as well when forwarded from hardy over ssh. fslint-gui is based on GTK.

[Timo Aaltonen (tjaalton)]

libxext is the same version on both jaunty and karmic, and libx11 is an unlikely candidate as well. Maybe the driver to blame.

[Jonathan Thomas (echidnaman)]

There haven't really been all that many changed in Qt3 either, (it's till at the same/latest upstream release) so it's probably not that either.

[Rolf Leggewie (r0lf)]

Yeah, guys. Really cool! Padraig did not even bother making a comment when setting to invalid. Pretty soon, this bug will be completely off the radar. I'm quite certain that it's not an issue per se in the last two remaining applications. This bug hasn't even been open for 24 hours. Is it bothering you so much?

Reopening all tasks until you can *prove* 100% that your app/lib isn't faulty. "likely not a problem in XY" or other 99% statements will not be accepted until we know what package the problem is hiding in.

Guys, this is bug triage. It's not a race to close the most bugs as invalid. It's a race to *fix* the most bugs.

[Rolf Leggewie (r0lf)]

*really* understanding a bug is a precondition to fixing a bug. We're not there yet. The race to *fix* this bug has only just started.

[Pádraig Brady (p-draigbrady)]

Sorry Rolf. I assumed it was something lower that FSlint when other apps were affected.
I can confirm that FSlint is a pygtk app.

[Rolf Leggewie (r0lf)]

It very likely is something lower than any of the apps. It may even be something lower than the libs listed so far. Timo raised the possibility this may be a driver issue. I've added an ATI task here and will test later tonight.

[Jonathan Thomas (echidnaman)]

Happens in a GTK+ app too -> Not a Qt issue.

[Rolf Leggewie (r0lf)]

Jonathan, congratulations on your complete non-understanding of triaging this bug.

BTW, your logic is flawed and you are not helping to fix or triage this issue. I kindly ask you to stay away from this ticket and let those who are not only after increasing their "bragging rights" try and find the real issues.

Again, Jonathan, this is not a race to close the largest number of tickets. It's about fixing bugs. This is something you still don't seem to understand.

[Jonathan Thomas (echidnaman)]

If I am not committing bug fix to a piece of software you filed a bug against, I therefore must not understand at all how any of the said software works. Brilliant logic.

The fact is that this bug is affecting software at a level *lower* than either the application or toolkit layer, hence somewhere in the font rendering or X stack. This is evidenced by the fact that it affects applications, regardless of which GUI toolkit they use. Therefore, it is a quite reasonable deduction that the problem does not lie with the application or the toolkit libraries, and that the best act of triage would be to file a bug against the graphics driver, and close the bugs against the other packages. If reasonable evidence is found that it is any of the individual application's faults, (which there won't be, by the way) one could always re-open the task against the software and close the task against the driver tasks.

[Timo Aaltonen (tjaalton)]

Does it happen if you run the apps locally?

Try disabling acceleration on the karmic host, by adding Option "NoAccel" to the Device section in your xorg.conf.

[C de-Avillez (hggdh2)]

@R0lf: please respect the CoC. Bewing aggressive will not help any. On the same token, opening task against all possible culprits also does not help...

Thank you.

[Rolf Leggewie (r0lf)]

C, thank you for your message. I don't think I fell foul of the CoC. I don't have any problem to stand by any word I said, although I will gladly admit that Jonathan's behaviour infuriated me. And no, I don't think I opened any of the tasks unnecessarily. Unfortunately, it seems that these days people are more concerned with closing tasks and tickets (numbers) instead of gathering information, understanding a problem properly (yes, knowledge is more than a hunch, I even agree with that hunch and said so several times).

I'll just close all tasks as invalid. It looks like people are happier that way (there's more than just the comments documented here). Timo seems to be the notable acception. I thank you sincerely for your good efforts here. I don't feel like helping to fix this in Ubuntu anymore. I'm sure I can fix it for me personally and if not, I'll just have to live with it.

Congratulations people, you've reached your goal. Ticket closed.

[Jonathan Thomas (echidnaman)]

Fully closing this bug was not my nor anyone else's goal. My goal was only to close the extraneous tasks against packages that I knew weren't causing the problem; a proper form a triage. I would have no qualms whatsoever if this bug was pursued against the xserver-xorg-video-ati driver, which is currently where the most suspicion falls. I would not presume to reopen a bug you've closed yourself that before was pending info, but if you do feel like reopening the bug task against the xserver driver and provide the information, feel free to do so.

[Rolf Leggewie (r0lf)]

Jonathan, you strongly suspected, you never knew and you still don't know. The arguments you gave are valid and decrease the likelihood of a QT bug, but not to 0.

While it probably was nobody's intent to completely close this ticket, essentially that's what was rapidly happening yesterday morning with everybody "getting it off their personal radar" and thus eventually off the global radar, too. When I was asking for a little time in comment 8, Jonathan, you were the only one unwilling to grant that, and for what benefit?

There was no need to rush and interfere with somebody else's effort to try and properly understand an issue so it can be fixed for everybody's gain. That opportunity is now lost.