Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#406 closed bug (fixed)

[DiskProbe] menus don't work

Reported by: diver Owned by: jackburton
Priority: normal Milestone: R1
Component: - General Version:
Keywords: Cc: ajsmale@…
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

menus don't work in rev17009 undev vmware.

Attachments (1)

patch.diff (486 bytes) - added by jackburton 13 years ago.
Replaced Unlock() with UnlockFully() in BWindow destructor

Download all attachments as: .zip

Change History (48)

comment:1 Changed 13 years ago by jackburton

Owner: changed from axeld to jackburton

comment:2 Changed 13 years ago by jackburton

Cc: ajsmale@… added

comment:3 Changed 13 years ago by jackburton

* Bug 413 has been marked as a duplicate of this bug. *

comment:4 Changed 13 years ago by diver

Also if you click on menu and then quit diskprobe it will stay in Deskbar. This is the same with Mouse app and maybe some other as well.

comment:5 Changed 13 years ago by jackburton

I noticed. I probably know already what's wrong.

comment:6 Changed 13 years ago by jackburton

Status: newassigned

comment:7 Changed 13 years ago by jackburton

Looks like a deadlock in BMenuBar::Track()

comment:8 Changed 13 years ago by jackburton

I debugged it a bit and these are the results: The menubar tries to acquire the window lock, but it's currently acquired by the window thread, which is blocking on a port semaphore (owner is -1, means owned by a port, right?). Any idea, Axel ?

comment:9 Changed 13 years ago by jackburton

Cc: axeld@… added

comment:10 Changed 13 years ago by jackburton

Resolution: fixed

comment:11 Changed 13 years ago by jackburton

Status: assignedclosed

comment:12 Changed 13 years ago by jackburton

Fixed in hrev17154, BSlider locked the looper on Draw() and never unlocked it.

comment:13 Changed 13 years ago by diver

Resolution: fixed

comment:14 Changed 13 years ago by diver

Comment #2 isn't fixed, reopening.

comment:15 Changed 13 years ago by diver

Status: closedreopened

comment:16 Changed 13 years ago by jackburton

I cant' reproduce the problem described in comment 2, does is still apply ?

comment:17 Changed 13 years ago by diver

(In reply to comment #8)

I cant' reproduce the problem described in comment 2, does is still apply ?

Yes, it is. I just tested with hrev18026 under vmware. What i dis is:

  1. Launched DiskProbe and clicked File menu
  2. While File menu is opened pressed Alt+q

comment:18 Changed 13 years ago by jackburton

Fixed in hrev18156

comment:19 Changed 13 years ago by jackburton

Status: reopenedclosed

comment:20 Changed 13 years ago by jackburton

Resolution: fixed

comment:21 Changed 13 years ago by diver

Status: closedreopened

comment:22 Changed 13 years ago by diver

I'm sorry, but i've just checked it several times with hrev18260 under vmware and this bug is still there. Reopening...

comment:23 Changed 13 years ago by diver

Resolution: fixed

comment:24 Changed 13 years ago by diver

Hmm, i'm not sure, but this could be due something with svn access on the phillip's server http://www.schmidp.com/index.php?option=com_files&path=/haiku/ images/ As you could see rev*_svn.log files are empty at the moment. So this bug could be already fixed indeed. Need to check it out.

comment:25 Changed 13 years ago by jackburton

Can I close this bug ? I definitely can't reproduce it anymore, nor under vmware, nor qemu, nor on real hardware.

comment:26 Changed 13 years ago by jackburton

Status: reopenedclosed

comment:27 Changed 13 years ago by jackburton

Resolution: fixed

comment:28 Changed 13 years ago by diver

Comment #2 still isn't fixed, reopening, hrev18356.

comment:29 Changed 13 years ago by jackburton

Which revision are you trying ? I definitely can't reproduce this bug anymore. If you still can, may you write down the exact steps you use to reproduce it ?

comment:30 Changed 13 years ago by diver

(In reply to comment #15)

Which revision are you trying ? I definitely can't reproduce this bug anymore. If you still can, may you write down the exact steps you use to reproduce it ?

I'm trying hrev18453. This is how i reproduce it: After Haiku starts i'm typing in Terminal DiskProbe, then press Probe Device. Now that DiskProbe window is opened i'm clicking "File" menu and while it open pressing alt+w. DiskProbe's window will close but will stay in Deskbar until i kill it. Hope this would help.

comment:31 Changed 13 years ago by axeld

Status: closedreopened

comment:32 Changed 13 years ago by axeld

Yes, it did, at least I can reproduce it with these steps under Qemu.

comment:33 Changed 13 years ago by axeld

Resolution: fixed

comment:34 Changed 13 years ago by jackburton

Yes, now I can reproduce it too. Following the other method

  1. Launched DiskProbe and clicked File menu
  2. While File menu is opened pressed Alt+q

I can't reproduce it anymore, though.

comment:35 Changed 13 years ago by jackburton

Status: reopenedassigned

comment:36 Changed 13 years ago by diver

Another variation: Launch any app wich have menu bar (StyledEdit, DiskProbe), click in the empty region of menu bar and then try to close this app, it will stay in the deskbar.

comment:37 Changed 13 years ago by jackburton

(In reply to comment #19)

Another variation: Launch any app wich have menu bar (StyledEdit, DiskProbe), click in the empty region of menu bar and then try to close this app, it will stay in the deskbar.

That shouldn't happen anymore. I also tracked down the bug, it's a deadlock. I can fix it by using LockWithTimeout() inside BMenuBar::Track() instead of Lock(). I'm almost sure beos did the same, but it works very bad in Qemu on slow systems. I'll try to find another solution.

comment:38 Changed 13 years ago by jackburton

I have some doubts. Axel (or anyone who knows) can you clarify ? In the following code:

BWindow::~BWindow() {

if (BMenu *menu = dynamic_cast<BMenu *>(fFocus)) {

menu->QuitTracking();

}

The BWindow is locked when the destructor is called, we need to unlock because the menubar thread tries to post a message, which will deadlock otherwise. Unlock();

Is it normal that after that Unlock() call, the window is still locked when ALT-W is used to close it, and it's unlocked when ALT-Q is used ? That's what is causing the deadlock.

comment:39 Changed 13 years ago by jackburton

I tried changing that Unlock() call to UnlockFully() and it doesn't deadlock anymore. Since it's done in the destructor shouldn't hurt, but I'd like if someone reviewed the change, though.

Changed 13 years ago by jackburton

Attachment: patch.diff added

Replaced Unlock() with UnlockFully() in BWindow destructor

comment:40 Changed 13 years ago by axeld

Don't be so shy, I would have shot you anyway if you commited something wrong to the repository ;-) I think the change is fine.

When using Alt-W the window is quit from its own quit loop, while when you press Alt-Q, the application itself is quitting it. In both cases, the window should only be locked once, though, at least AFAICT. Maybe there is an extra Lock() somewhere causing it, but I dunno. Any idea?

comment:41 Changed 13 years ago by jackburton

(In reply to comment #24)

Don't be so shy, I would have shot you anyway if you commited something wrong to the repository ;-)

Eheh, okay :)

I think the change is fine.

Ok, I'm applying it.

When using Alt-W the window is quit from its own quit loop, while when you press Alt-Q, the application itself is quitting it.

Ok, makes sense. I was thinking something like that. Thank you.

In both cases, the window should only be locked once, though, at least AFAICT. Maybe there is an extra Lock() somewhere causing it, but I dunno. Any idea?

I searched that extra Lock() for a while, but without luck. The problem is that the flow isn't easy to follow, because some parts are in BLooper and some in BWindow. I hoped someone else knew that part better :)

comment:42 Changed 13 years ago by jackburton

Resolution: fixed

comment:43 Changed 13 years ago by jackburton

Fixed in hrev18579

comment:44 Changed 13 years ago by jackburton

Status: assignedclosed

comment:45 Changed 13 years ago by axeld

Maybe it's just because Alt-Q closes all windows, and with Alt-W, the menu window keeps a lock around?

comment:46 Changed 13 years ago by jackburton

(In reply to comment #27)

Maybe it's just because Alt-Q closes all windows, and with Alt-W, the menu window keeps a lock around?

Could be. Either the Menubar or the menu itself, although the deadlock happened inside BMenuBar::Track(), when menubar tried to acquire the window lock. I'll try to debug it, though, and see if it's the case.

comment:47 Changed 13 years ago by jackburton

(In reply to comment #28)

(In reply to comment #27)

Maybe it's just because Alt-Q closes all windows, and with Alt-W, the menu window keeps a lock around?

Could be. Either the Menubar or the menu itself, although the deadlock happened inside BMenuBar::Track(), when menubar tried to acquire the window lock. I'll try to debug it, though, and see if it's the case.

I added some more debug output, and seems the window is locked twice indeed by its own thread. We just need to find out where this happen. For the moment we can live with this solution, though, as it seems safe.

Note: See TracTickets for help on using tickets.