Opened 17 years ago
Closed 17 years ago
#1626 closed bug (fixed)
GLTeapot doesn't quit
Reported by: | vzsolt | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Kits/OpenGL Kit | Version: | R1/pre-alpha1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
I was trying out the demos in hrev22928, in VMWare, and found that GLTeapot doesn't quit, neither when closing it's window, nor when using the keyboard shortcut. It hangs in Deskbar, with no windows, and can't be closed from there either.
On shutdown, the Shutdown Status dialog asks this question: "The application "GLTeapot" might be blocked on a modal panel." Kill/Cancel
In terminal, ps shows two entries related to GLTeapot, with semaphores GLTeapot, and thread_99_retcode_sem. (I'm not sure how to interpret this...)
And I can't start it again.
Attachments (1)
Change History (7)
comment:1 by , 17 years ago
Owner: | changed from | to
---|
comment:2 by , 17 years ago
comment:3 by , 17 years ago
I tried to drop the window thread into the debugger after it's stuck (exiting via ALT-W). Here's the backtrace.
by , 17 years ago
comment:4 by , 17 years ago
So, what's happening is that the BWindow thread tries to acquire the window's lock, but it's already acquired by the BApplication (inside WindowQuitLoop()), so there's a deadlock. Maybe we have to review our quitting path again ?
comment:5 by , 17 years ago
Component: | - Applications → Kits/OpenGL Kit |
---|---|
Owner: | changed from | to
Status: | new → assigned |
comment:6 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
What actually happened was that the "simon" thread would not always release the window lock it locked when it called the ObjectView's DrawFrame() method. It wouldn't release it because the GLRenderer is already removed after DetachFromWindow() has been called.
Fixed in hrev23691.
This doesn't happen every time, though.