[Deskbar] deadlocks during icon resize

[diver]

This is hrev44133, gcc2hybrid.

• Open Deskbar preferences
• Move Icon size slider several times
• Start clicking any team menu in Deskbar

Usually after several clicks Deskbar deadlocks.

[x-ist]

Can't reproduce that in hrev44354 gcc2hybrid (VBox), however ticket #2168 could be related to this one:

The object fExpando is killed and recreated within "void TBarView::PlaceApplicationBar()" in BarView.cpp, which seems to happen rather often. Could it be that we run into a race condition this way.

[jscipione]

I also can no longer reproduce this crash. It was possibly fixed by hrev44382.

[diver]

I can still reproduce it in hrev44405.

[jscipione]

Should be fixed in hrev45321. diver can you please verify and reopen if not fixed?

[diver]

Now team menu doesn't hang but Leaf button does! It's not clickable and I also can't bring Deskbar preferences window on top in this state of Deskbar.

[jscipione]

Debugger report showing thread details on deadlock

[axeld]

Not sure if my assumption is correct, but I would assume that the problems go away if you would forward the message to the window looper, and handle it there instead of from the application thread, ie. introduce a kMsgRebuildApplicationBar, and post that one to the window.

[jscipione]

Fix reverted in hrev45324 will need to try something different to fix this one.

[diver]

Apparently, it's not related to icon resize. To reproduce:

open /system/preferences/* ; while true ; do hey Deskbar SprE ; done

Apart from deadlock, this aslo makes team list go white if you move any window above the Deskbar.

[jscipione]

This bug is not directly related to icon resizing, but by any action that triggers a deadlock due to rapidly deleting and rebuilding the fExpando menu bar. I'm not surprised that the above command, which turns the expander arrows on and off repeatedly, causes the Deskbar to get into an invalid state. I have a branch pending that fixes the problem (I hope) by building the menu bar object one time in the constructor and then only updates the list inside rather than deleting and rebuilding updating the whole menu bar. I have this working pretty well, there are just a few more cases that I need to work out before it is ready to go. Not only will this fix this bug but should make changes to Deskbar noticeably more responsive.

[jscipione]

Please check again in hrev45401 which I hope should finally fix this bug.

[diver]

The deadlock seems to be gone now, thanks! However, the team list still turns white using the above technique. Should we close this ticket and open another one with this issue?

[jscipione]

Does the team list turn white and stay white, or does it flash white and then eventually catch up and redraw? The former would be a bug, but the latter would be normal (although not optimal) behavior.

[diver]

It's the latter.

[jscipione]

Implemented icon caching in hrev45422 which should help to speed up icon resizing, minimizing although not eliminating the white flashing problem.

[diver]

Hmm, I noticed that checkboxes in Deskbar preference window don't react on hey Deskbar SprE Revert button reacts ok, though.

[jscipione]

Replying to diver:

Hmm, I noticed that checkboxes in Deskbar preference window don't react on hey Deskbar SprE Revert button reacts ok, though.

You've got it backwards, checking the checkbox causes a SprE message to get sent. If you send the message from Terminal than you've circumvented the Preferences, so, this is expected behavior. If you close and reopen the preferences window it'll read the setting and correct itself.

[jscipione]

Fixed in hrev45401. The white flashing is normal redrawing behavior. Some more Deskbar refactoring is still in progress but the lockup bug described by this ticket should be gone.