The Daily WTF: Curious Perversions in Information Technology

Tsaukpaetra · 2015-10-01 Reply Admin

I guess it's better than

Last message repeated 0 times

and having to click through hundreds of those...

Filed under: Just give me the error log

Yazeran · 2015-10-01 Reply Admin

Oh I just love the smell of race conditions in the morning.... (rimshot)

RaceProUK · 2015-10-01 Reply Admin

Yazeran:
I just love the smell of race conditions in the morning

Ah yes; the scent of the morning dew infused with a hint of petrol-

Oh, wait, you're not talking about that sort of racing.

accalia · 2015-10-01 Reply Admin

RaceProUK:
Ah yes; the scent of the morning dew infused with a hint of petrol-

don't forget that subtle petrichor of damp tarmac.

that's important too!

Dlareg · 2015-10-01 Reply Admin

So close yet so far away

Onyx · 2015-10-01 Reply Admin

SomeClass::eventHandler(Event e) {

Ok...

QMessageBox::warning(this, tr("App"), tr("Error message"));

Wait... Is that a custom Event class, poor anonymization, or is my knowledge of Qt worse than I thought? There's a QEvent that represents a OS event but it's fairly useless in its base form. Is this supposed to be a slot modified to look more .NET-ish for general public?

Filed under: :pendant:

RFoxmich · 2015-10-01 Reply Admin

The smell, you know that gasoline smell, the whole hill. Smelled like... victory.

Gaska · 2015-10-01 Reply Admin

I have no idea why the code is failing. Can someone explain to me what went wrong?

Rhywden · 2015-10-01 Reply Admin

My bet is on the static bool in there.

Gaska · 2015-10-01 Reply Admin

And what's wrong with it?

Rhywden · 2015-10-01 Reply Admin

Multiple events at the same time?

accalia · 2015-10-01 Reply Admin

Rhywden:
My bet is on the `static` bool in there.

I'm no expert in.... C++ i think? whatever...

anyway, I won't claim to be an expert but that static bool looks suspiciously like a function local variable to me....

Gaska · 2015-10-01 Reply Admin

Rhywden:
Multiple events at the same time?

Single-threaded or multi-threaded? Because in the former case, everything should work as expected, and in the latter case, it should be very rare for two popups to show, and virtually impossible for three. I must be missing something here.

RaceProUK · 2015-10-01 Reply Admin

accalia:

Rhywden:
My bet is on the `static` bool in there.
I'm no expert in.... C++ i think? whatever...
anyway, I won't claim to be an expert but that static bool looks suspiciously like a function local variable to me....

If this was Java, then `static` would preserve the value of the variable between method calls; I don't know if it does the same in C++.

Of course, if QMessageBox::warning() is async, the whole static thing is :cow: anyway.

Onyx · 2015-10-01 Reply Admin

Gaska:
I have no idea why the code is failing. Can someone explain to me what went wrong?

E_NOT_ENOUGH_INFO

As I said, the prototype seems heavily anonymized. I never played with anything other than auto connections but

Gaska:
Single-threaded or multi-threaded?

Might be very important, given this:

http://doc.qt.io/qt-5.5/qt.html#ConnectionType-enum

Then again, we don't even know if it's a slot at all. If the prototype is verbatim that would indicate some kind of custom event handling, and in that case it's all up in the air at that point.

Maurizio_De_Cecco · 2015-10-01 Reply Admin

Shoulnd't a queue serialise stuff ? (ok, its depends on the queue, o know)

TheCPUWizard · 2015-10-01 Reply Admin

Uh oh.... did someone apply TLS?

NedFodder · 2015-10-01 Reply Admin

Gaska:
I have no idea why the code is failing. Can someone explain to me what went wrong?

The dev wants the message box to pop up only when the function is called the first time. He initializes a static bool to false. If it's false, the message box will pop up; if it is true, it won't. After this check, he sets it to true so that the message box will not pop up in the future. The bug is that he sets it back to false, so that the message box will pop up every time.

Zybex · 2015-10-01 Reply Admin

It really depends on weather this runs single or multi-threaded. If it's single, then there will be a popup for every message because the event will only be called for the next queued message after the user dismisses the existing popup. If it's multi, then the static bool should me marked volatile, so that multiple simultaneous calls to the function don't get a cached (wrong) value, which would also cause multiple popups.

RaceProUK · 2015-10-01 Reply Admin

static volatile just sounds really weird to me

Gaska · 2015-10-01 Reply Admin

NedFodder:
The dev wants the message box to pop up only when the function is called the first time. He initializes a static bool to false. If it's false, the message box will pop up; if it is true, it won't. After this check, he sets it to true so that the message box will not pop up in the future. The bug is that he sets it back to false, so that the message box will pop up every time.

Correct me if I'm wrong, but doesn't showing up a message box in Qt pauses execution of current thread until the box is closed? I'm pretty sure it does, since I think I did it myself several times.

Gaska · 2015-10-01 Reply Admin

Zybex:
It really depends on weather this runs

Good luck trying to debug the weather!

Protoman · 2015-10-01 Reply Admin

The static bool is actually a pretty standard way to prevent reentrancy, where you don't want the function to call itself and potentially recurse infinitely.

For example, when I was doing development for console games, we had a custom assertion handler that went into its own little modal rendering loop to render a red screen with the assertion text on it. So if an assertion failed somewhere in the game, QA would be able to see the failure on their screen (and not have to deal with terminal output or log files) and report the bug. In the unlikely event that another assertion failed while the modal rendering loop was running (say, due to out-of-memory), then it would avoid going into another modal loop on top of that and just do its normal logging behavior before halting. It looked roughly like this:

void OnAssertionFailed(const char *expression, const char *filename, int line) {
    // Logging etc.
    fprintf(logFile, "Assertion failed...");
    OutputDebugString("Assertion failed...");
    
    static bool inOnAssertionFailed = false;
    if (!inOnAssertionFailed) {
        inOnAssertionFailed = true;
        while (!buttonHasBeenPressed()) {
            RenderRedScreen("Assertion failed...");
        }
        inOnAssertionFailed = false;
    }
    
    abort();
}

Of course, assertion failures are always synchronous. In the case of this article though, I'd assume that events can be async, in which case multiple copies of the event can be queued up before the event handler runs. Since the event handler runs completely before handling the next queued event, the static bool doesn't stop those subsequent queued events from being handled — it would only work properly if QMessageBox::warning() triggered more events and dispatched them synchronously (which would be an even bigger :wtf:).

Onyx · 2015-10-01 Reply Admin

Gaska:
Correct me if I'm wrong, but doesn't showing up a message box in Qt pauses execution of current thread until the box is closed? I'm pretty sure it does, since I think I did it myself several times.

I think you're right there. I need to play more with widgets in Qt, my knowledge of its UI layer is fairly basic. I just write backend stuff in it, and I poked around Quick a bit..

Yamikuronue · 2015-10-01 Reply Admin

Gaska:
Good luck trying to debug the weather!

It's not too hard if you have the right gadget:

https://what.thedailywtf.com/t/weather-simulator-wtf/51581/1

pittsfield · 2015-10-01 Reply Admin

this, tr("App")

This is a trap!

littlefreaky36 · 2015-10-01 Reply Admin

Shoulnd't a queue serialise stuff ? (ok, its depends on the queue, o know)

I guess that's exactly the problem. The event handler blocks until the user closes the message box. Then 'showingError' is set back to false and the handler returns. The next event will then be handled. And since the 'showingError' boolean is now false again, it shows the box again.

Gaska · 2015-10-01 Reply Admin

So TRWTF is lack of even basic testing. Even in form of manual, one-time exercise to see if the code works as expected.

RaceProUK · 2015-10-01 Reply Admin

Oh, they probably did test it.

With a queue of one.

loose · 2015-10-01 Reply Admin

Ok, Sorry, but you (sorta) asked for it...........

If you are getting the smell of burnt rubber in the morning, then you are..... wait for it.....Doing It Too Fast™ :rimshot: :grimacing:

loose · 2015-10-01 Reply Admin

Obligatory meme with added :wtf: [image]

...or is it?

dcon · 2015-10-01 Reply Admin

RaceProUK:
If this was Java, then static would preserve the value of the variable between method calls; I don't know if it does the same in C++.

It does. You'll should never get 2 errors up at the same time!

Kian · 2015-10-01 Reply Admin

Looks like C++, so assuming that's the case:

When a function local variable is declared static, this means that the variable persists across calls. The initialization only runs the first time the function is called. So you could initialize the variable as false, set it to true, and then when you next call the function its value will be true.

NedFodder:
The bug is that he sets it back to false, so that the message box will pop up every time.

Mostly. If you removed setting it to false, then you would only ever show the message box *once* in the whole run of the program. There's no way to alter the state of a static local variable outside of the function, so you have no way to signal "ok, the user saw the message for all these errors, reset so we can show a message the next time something happens".

Which is why I would imagine it is reset at the end in the first place. The genius here probably saw that he was only ever showing one message and realized he had to reset the flag for the next message.

The bug is using a local static in the first place. The flag should be stored somewhere you can get at when you want to flip it.

Zybex:
It really depends on weather this runs single or multi-threaded.

Not at all. Race conditions could cause a handful of message boxes to pop up, but not four minutes worth of them. A single threaded app with this bug will queue every warning instead of collapsing them.

Spectre · 2015-10-01 Reply Admin

RaceProUK:
If this was Java, then static would preserve the value of the variable between method calls; I don't know if it does the same in C++.

It does; but it doesn't do it in Java.

RaceProUK · 2015-10-01 Reply Admin

Huh. Musta been thinking of something else then.

Protoman · 2015-10-01 Reply Admin

RaceProUK:
If this was Java, then `static` would preserve the value of the variable between method calls; I don't know if it does the same in C++.

If this was Java, it wouldn't compile. C++ allows static to be used in 3 different contexts:

In front of a class member or method declaration (making the member/method effectively have global scope but within the class's namespace)
In front of a global function (giving it internal linkage instead of external linkage)
In front of a local variable declaration (giving it static storage duration instead of automatic storage duration)

The usage here is context #3, but Java only allows static to be used in context #1.

RaceProUK · 2015-10-01 Reply Admin

Hello Mister Fifteen-Minutes-Late! :wave:

A Handle on Events

Leave a comment on “A Handle on Events”