[DiskProbe] menus don't work

[diver]

menus don't work in rev17009 undev vmware.

[jackburton]

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

[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.

[jackburton]

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

[jackburton]

Looks like a deadlock in BMenuBar::Track()

[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 ?

[jackburton]

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

[diver]

Comment #2 isn't fixed, reopening.

[jackburton]

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

[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

[jackburton]

Fixed in hrev18156

[diver]

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

[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.

[jackburton]

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

[diver]

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

[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 ?

[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.

[axeld]

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

[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.

[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.

[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.

[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.

[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.

[jackburton]

Replaced Unlock() with UnlockFully() in BWindow destructor

[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?

[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 :)

[jackburton]

Fixed in hrev18579

[axeld]

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

[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.

[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.