Opened 11 years ago

Closed 5 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:
Has a Patch: no 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)

lockedDeskbar-BMenuBar-Tracking-bt.txt (2.4 KB) - added by aldeck 11 years ago.
lockedDeskbar-TBarWindow-bt.txt (3.1 KB) - added by aldeck 11 years ago.

Download all attachments as: .zip

Change History (12)

Changed 11 years ago by aldeck

Changed 11 years ago by aldeck

comment:1 Changed 11 years ago by aldeck

Cc: jackburton added

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 ;)

comment:2 in reply to:  1 ; Changed 11 years ago by jackburton

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 in reply to:  2 Changed 11 years ago by aldeck

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 Changed 8 years ago by jonas.kirilla

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:5 Changed 7 years ago by kallisti5

verified still an issue on latest nightly.

comment:6 Changed 7 years ago by diver

Version: R1/pre-alpha1R1/Development

comment:7 Changed 7 years ago by diver

Still here in hrev44036.

comment:8 Changed 7 years ago by x-ist

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 Changed 5 years ago by jscipione

Fixed in hrev45401 because the expands menu bar is no longer destroyed and rebuilt on every action.

comment:10 Changed 5 years ago by jscipione

Resolution: fixed
Status: newclosed

Fixed in hrev45401

Note: See TracTickets for help on using tickets.