Opened 11 years ago

Closed 6 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)

by aldeck, 11 years ago

comment:1 by aldeck, 11 years ago

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

in reply to:  1 ; comment:2 by jackburton, 11 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.

in reply to:  2 comment:3 by aldeck, 11 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 jonas.kirilla, 9 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:5 by kallisti5, 7 years ago

verified still an issue on latest nightly.

comment:6 by diver, 7 years ago

Version: R1/pre-alpha1R1/Development

comment:7 by diver, 7 years ago

Still here in hrev44036.

comment:8 by x-ist, 7 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 jscipione, 6 years ago

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

comment:10 by jscipione, 6 years ago

Resolution: fixed
Status: newclosed

Fixed in hrev45401

Note: See TracTickets for help on using tickets.