[GLTeapot] crash if you middle click on teapot

[diver]

GLTeapot crash if you middle click on teapot. Tested under vmware with hrev18823. back trace will follow...

[diver]

back trace

[jackburton]

I think it's a bug in BPopUpMenu::_go().

[jackburton]

Replying to jackburton:

I think it's a bug in BPopUpMenu::_go().

Actually, I'm not so sure anymore. In this particular case, GLTeapot asks for a synchronous popup menu. Since BPopUpMenu::Go() is called from MouseDown(), the looper (window) should be locked already. So I can't see why UpdateIfNeeded() could complain...

[axeld]

Maybe it's just me, but the lines in GLTeapot's ObjectView.cpp::MouseDown() look highly suspicious:

	while (Window()->IsLocked()) {
		locks++;
		Window()->Unlock();
	};

Also, it calls BPopUpMenu::Go() outside of having locked the window.

[axeld]

I've fixed this problem locally by making sure BWindow::UpdateIfNeeded() locks properly. Do you mind if I commit it?

[JackBurton]

Replying to axeld:

I've fixed this problem locally by making sure BWindow::UpdateIfNeeded() locks properly. Do you mind if I commit it?

Go on!

[axeld]

Fixed in hrev18946.

[jackburton]

Replying to axeld:

Fixed in hrev18946.

Axel, I think this causes a deadlock in the app_server. Open the Fonts application and try to change the font size (or use any other popupmenu). The whole system seems to lock (but it's "just" the app_server").

[axeld]

I'll look into it, but frankly, I don't think it can be caused by this: the window is locked anyway (usually) at this point, so an additional lock really shouldn't matter at all.

[jackburton]

Replying to axeld:

I'll look into it, but frankly, I don't think it can be caused by this: the window is locked anyway (usually) at this point, so an additional lock really shouldn't matter at all.

Ok, then it could be some other change, but could also be this :)