Opened 12 years ago

Closed 12 years ago

#1745 closed bug (fixed)

Deskbar sometimes hangs on start

Reported by: andreasf Owned by: axeld
Priority: normal Milestone: R1/alpha1
Component: Kits/Interface Kit Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

When Virtual Memory is enabled, on startup the Deskbar hangs, with feather, clock and ProcessController visible and a too large, grey-only box below. It is not redrawn (time not updated) and does not respond to mouse input. When killing it and restarting the desktop, it works okay.

This is mostly reproducible with SMP enabled. Haven't seen it with SMP disabled yet, nor with VM disabled.

Change History (8)

comment:1 Changed 12 years ago by axeld

Milestone: R1R1/alpha
Priority: normalhigh
Summary: Deskbar hangs with VM enabledDeskbar sometimes hangs on start

Virtual memory is currently a no-op. And I've also seen this without SMP, I just didn't find the time to investigate it. I've updated the title of the bug to better match the problem :-)

comment:2 Changed 12 years ago by stippi

I am using QEMU 0.7.2 on ZETA and can reproduce this problem quite reliably (maybe 50-60% of the boots?). Ingo, maybe a good candidate for your KDL usage demonstration?

comment:3 Changed 12 years ago by stippi

Oh, I forgot to add some more info: First, my QEMU session is definitely not running as an SMP system. Second, I mostly don't see the ProcessController replicant, just the empty space which seems to account for 3 items (Tracker, Terminal and ProcessController launched from the Bootscript). Sometimes when Deskbar hangs like this, Tracker hangs too, but not always. When Tracker does hang, and I use the Terminal to kill Deskbar, Tracker suddenly continues to start up and runs fine afterwards. I think the reason why this came up was the addition of ProcessController to the Bootscript, but it probably just shows an underlying problem which existed before.

comment:4 Changed 12 years ago by bonefish

Owner: changed from axeld to bonefish
Status: newassigned

I couldn't reproduce it in VMware or on real hardware yet, but it seem I can with qemu.

comment:5 Changed 12 years ago by bonefish

Owner: changed from bonefish to axeld
Status: assignednew

Fixed one reason for the deadlock in hrev23865. BLooper::_PostMessage() was holding the BLooperList lock while calling BMessenger::SendMessage(). I believe it is still incorrect, that BWindow::UpdateIfNeeded() calls DispatchMessage() while holding the message queue lock.

comment:6 Changed 12 years ago by axeld

Component: - GeneralKits/Interface Kit
Priority: highnormal

Very nice! That doesn't really sound like a very deadlock-like scenario, though (the locking order is always looper then message queue). It wouldn't be too difficult to change the loop to release the message lock before calling DispatchMessage(), though.

Do you still see the hang happening?

comment:7 in reply to:  6 Changed 12 years ago by bonefish

Replying to axeld:

Very nice! That doesn't really sound like a very deadlock-like scenario, though (the locking order is always looper then message queue). It wouldn't be too difficult to change the loop to release the message lock before calling DispatchMessage(), though.

It's not the looper lock with which I see deadlock potential. The user can easily create a deadlock by acquiring e.g. some data lock in Draw() and in another thread hold the same lock while sending a message to the window. Then you've got two code paths with opposing locking order (1. UpdateIfNeeded() [message queue lock] -> Draw() [data lock], 2. [data lock] -> BMessage::_SendMessage() [message queue lock]), and the user isn't even to blame.

Do you still see the hang happening?

Nope. I just wanted to keep the ticket open until the UpdateIfNeeded() code is fixed.

comment:8 Changed 12 years ago by axeld

Resolution: fixed
Status: newclosed

I've fixed UpdateIfNeeded() in hrev23870, no matter if it's related to this bug or not :-)

Note: See TracTickets for help on using tickets.