Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#851 closed bug (fixed)

[GLTeapot] crash if you middle click on teapot

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

Description

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

Attachments (1)

GLTeapot2.PNG (53.1 KB) - added by diver 13 years ago.
back trace

Download all attachments as: .zip

Change History (11)

Changed 13 years ago by diver

Attachment: GLTeapot2.PNG added

back trace

comment:1 Changed 13 years ago by jackburton

Component: ApplicationsUser Interface/InterfaceKit
Owner: changed from axeld to jackburton

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

comment:2 Changed 13 years ago by jackburton

Milestone: R1
Status: newassigned

comment:3 in reply to:  1 Changed 13 years ago by 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...

comment:4 Changed 13 years ago by 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.

comment:5 Changed 13 years ago by axeld

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

comment:6 in reply to:  5 Changed 13 years ago by 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!

comment:7 Changed 13 years ago by axeld

Resolution: fixed
Status: assignedclosed

Fixed in hrev18946.

comment:8 in reply to:  7 Changed 13 years ago by 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").

comment:9 Changed 13 years ago by 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.

comment:10 in reply to:  9 Changed 13 years ago by 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 :)

Note: See TracTickets for help on using tickets.