[Solved] ~BApplication hang

Software Native
1

I’m seeing this hang in ~BApplication after my application opens a dialog, but not when I don’t open the dialog.

haiku-ide-hang

I dumped out the state of the locks in both cases in and they are the same:

~LAppPrivate: team=2681 name=AppLooperPort count=0 latest=0
~LAppPrivate: IsLocked()=1
~LAppPrivate: CountLocks()=1
~LAppPrivate: CountLockRequests()=1
~LAppPrivate: GuiThreadId=2681 LockingThread()=2681

There is nothing terribly unusual in the state of the BLooper before it shuts down. LAppPrivate inherits from BApplication.

I’m not sure how to actually debug why it’s stuck waiting on that sem. Is there a mode to print out more info on semaphores that can’t be acquired? I’m assuming that something else has acquired the sem_id and there is a deadlock?

2

You can use SystemManager to inspect who owns semaphore.

3 Likes
3

I’ve built SystemManager and used it to inspect the sem_id and it shows:

Count: 0
LatestHolder: 2018 (sftp-server)

However if I look in the debugger at the registers in the _kern_acquire_sem_etc call the only value that looks like a sem_id is 80236, which is NOT the sem_id that the application BLooper has. So somebody elses sem_id? The problem is that SystemManager doesn’t list 80236 as a valid sem_id, it has 80234 and 80238.

4

You can look at threads tab to see sem_id that thread currently locked by.

5

The main thread is waiting on sem 80326 (…loading…)

I guess “…loading…” is the name of the semaphore? It’s count is -1 in the sem tab. And it’s latest_holder is sshd. I am running the app from an ssh shell.

Ok so I’ve found the “…loading…” string in my app, it’s a default name for a BWindow constructor before it gets it’s actual name later. I changed that to some descriptive and now it seems clear there is a BWindow that is not deleted. Why that would be an issue I don’t know yet. But I’ll track down where it’s allocated and maybe try freeing it somewhere appropriate.

6

Ok, so the missing BWindow was an unused popup. And in the wrapper class the WaitForExit was calling BWindow::Quit but not actually deleting the BWindow. Adding the delete solved the BApplication shutdown hang. Gahh.

SystemManager was very useful though… and I don’t think I’d have it solved at this point without it.

4 Likes