StatusBar::showMessage causes max processor load - report bug/patch qt?

[DerManu]

Hi there,
observe:
@ ui->statusBar->showMessage("hello", 4000);
ui->statusBar->showMessage("", 1);@

Now start top or htop. Funny eh? One core is busy performing an infinite loop (while the gui stays responsive).
I came across this behaviour when I was too lazy to implement an additional "clearMessage" signal in a class that needs to communicate with the statusBar. So I figured I'd be damn smart and just let it show an empty message with timeout 1 (millisecond), so it'll properly clear right at the next event loop cycle. It bit me.

I've looked at "qstatusbar.cpp":http://qt.gitorious.org/qt/qt/blobs/4.8/src/gui/widgets/qstatusbar.cpp#line595, and the problem's source is that they're handling the timeout really strange. They have a QTimer member (d->timer) which is created and deleted when showMessage/clearMessage is called. The timer timeout signal is connected to clearMessage. The problem is, that when you set an empty string, while another non-empty string is still in its showing interval, the timer never gets deleted. Because clearMessage immediately returns when the string is empty - without even checking whether there's a timer to delete. So basically you've got this rabid 1ms-timer having a party in the event loop.

Now: Would you consider this a Qt bug or is it my fault for „misusing showMessage“ (although the docs don't warn me)? If so, is it any use reporting this? I mean I'm sure there are thousands of reports waiting to get fixed. On the other hand all you'd need is to either not only check whether the string is empty, but also whether the d->timer is 0. Or just d->timer->setSingleShot(true). Or better yet, quit this nonsense d->timer business, and just call QTimer::singleShot(timeout, this, SLOT (clearMessage())) in showMessage.
Further, do I need a gitorious account to report a bug or even submit a patch or is there a way to do it anonymously (with proper patch inspection before applying it, obviously, but that should happen anyway)?

[lgeyer]

Please "report":http://qt-project.org/wiki/ReportingBugsInQt, this clearly looks like a bug to me. Don't forget to link the bug report here (and this thread in the bug report).

If you already have a solution attach it to the bug report or "contribute":http://wiki.qt-project.org/Code_Reviews directly.

[DerManu]

There it is:
https://bugreports.qt-project.org/browse/QTBUG-24948

Looked into getting a setup ready for contributing but they're certainly not interested in making it easy for new contributers, so I just posted the diff in the bugreport. Let's see what happens.

[Jeroentjehome]

Well guys, saying this is a bug is a bit strong. The program doesn't crash and why would anyone setup a empty message in the status bar. I must admit it doesn't look good and they should protect it better. On the other hand you should have used 0 as the timeout. That would clear the statusbar instantly without a timeout.

[DerManu]

Still, it's unintended behaviour with potentially really bad consequences. And as you can see, there's at least one guy that triggered it ;).
If I hadn't noticed it right away, but a week in the future (100% cpu load isn't that obvious on a quadcore, but what would a client with a singlecore experience?) it would have been very tough to trace, since even valgrind profiling couldn't pinpoint it, just showing the QApplication::exec() as the trouble function.

[lgeyer]

[quote author="Jeroentje@home" date="1332615747"]Well guys, saying this is a bug is a bit strong. The program doesn't crash and why would anyone setup a empty message in the status bar. I must admit it doesn't look good and they should protect it better. On the other hand you should have used 0 as the timeout. That would clear the statusbar instantly without a timeout.
[/quote]

Everything that does not work as intended is a bug - and this cleary does not work as intended.

[rich]

[quote author="DerManu" date="1332520217"]There it is:
https://bugreports.qt-project.org/browse/QTBUG-24948

Looked into getting a setup ready for contributing but they're certainly not interested in making it easy for new contributers, so I just posted the diff in the bugreport. Let's see what happens.[/quote]

Actually, getting set up as a contributor is pretty simple, and there's lots of docs on the wiki at http://wiki.qt-project.org/ your diff in the bug tracker cannot be used since unlike the gerrit system used for contributions, it doesn't ensure you've agreed to the contributor agreement etc.