Opened 17 years ago
Closed 11 years ago
#2168 closed bug (fixed)
[Deskbar] freezes
Reported by: | kaoutsis | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Applications/Deskbar | Version: | R1/Development |
Keywords: | Cc: | jackburton | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
hrev25184, Move Deskbar to the bottom of the screen (a la windows)
- Press alt+F2
- Press any team button of the Deskbar or
press leaf menu (one click is enough)
- Press alt+F1
Deskbar freezes
Attachments (2)
Change History (12)
by , 17 years ago
Attachment: | lockedDeskbar-BMenuBar-Tracking-bt.txt added |
---|
by , 17 years ago
Attachment: | lockedDeskbar-TBarWindow-bt.txt added |
---|
follow-up: 2 comment:1 by , 17 years ago
Cc: | added |
---|
follow-up: 3 comment:2 by , 17 years ago
Replying to aldeck:
I couldn't go further :) cc'ing to Stefano as he surely has an idea ;)
Yes, I have :) BMenu and BMenuBar tracking loops should store the current workspace on the first loop, and then check if the workspace changed, on every iteration. I'm afraid this will uglify the code even more.
comment:3 by , 16 years ago
Replying to jackburton:
Yes, I have :) BMenu and BMenuBar tracking loops should store the current workspace on the first loop, and then check if the workspace changed, on every iteration. I'm afraid this will uglify the code even more.
Well the code does the job and is not that ugly :) If you find the time, i think it is worth giving a try.
Regards, Alex
comment:4 by , 14 years ago
This one is still with us. It can happen in normal use, when a window is on another workspace and selecting it in Deskbar triggers a workspace change.
Place Deskbar att the bottom the screen and randomly press Alt-Fx to rapidly switch workspaces while any [Deskbar > Application > window menu] is open.
comment:6 by , 13 years ago
Version: | R1/pre-alpha1 → R1/Development |
---|
comment:8 by , 12 years ago
One thing is for sure: It freezes at line 435 of BarView.cpp, in "delete fExpando;"
void TBarView::PlaceApplicationBar() { if (fExpando != NULL) { SaveExpandedItems(); fExpando->RemoveSelf(); delete fExpando; // freezes here! fExpando = NULL; }
Trying to further digg into that.
comment:9 by , 11 years ago
Fixed in hrev45401 because the expands menu bar is no longer destroyed and rebuilt on every action.
I could reproduce 100%. In deskbar/TBarWindow.cpp, the workspace change triggers a BMenuBar deletion. But the BMenuBar will block in its destructor waiting for its tracking thread to end.
See the two attached backtraces. One from the TBarWindow thread and one from the BMenuBar tracking thread.
It's not reproducible on R5. As a side note, i noticed that R5 closes any open menu on workspace change, whereas haiku keeps tracking menus on the previous workspace and the menu is still open when you come back.
I couldn't go further :) cc'ing to Stefano as he surely has an idea ;)