TTY deadlock issues

[anevilyak]

running objdump -r on a large executable and then hitting ctrl+c caused Terminal to deadlock. Upon further investigation, Terminal was also rendered unkillable, and according to the kernel debugger the thread was hanging on trying to autolock gGlobalTTYLock. According to Travis it would probably be good if the sem was acquired with the interruptible flag set here and appropriate error handling for the interrupted case.

[bonefish]

Stack traces of the involved threads (the one blocking on the semaphore and the one that acquired the semaphore last) would help tremendously. I'll see, if I can reproduce it myself.

Making the lock interruptible won't be necessary. It is supposed to be held only for a short time. No operations that can block for a longer time are performed with the lock held.

[anevilyak]

I'll see what I can do, unfortunately at the time I wasn't aware of how to track this one down further since I didn't know what sem was involved without rebooting back to linux to check the sources on the stack trace I got from the terminal thread, so I don't know which other thread actually had the lock held. Will let you know if I manage to reproduce it again tonight. May not be related but I do also occasionally notice temporary freezes in the Terminal (5 secs or so), but I'm not sure if that's Terminal app or TTY layer related.

[bonefish]

I couldn't reproduce a problem with gGlobalTTYLock, but I could reproduce the hanging after Ctrl-C. This issue is fixed in hrev22421.

As long as we don't use many benaphores in the kernel, it is often relatively easy to track kernel deadlocks down (without looking at the sources). You can do that in the kernel debugger and basically only need the "teams", "threads" (or "thread"), and "sem" commands. With "threads" or "thread" one can find out what semaphore a thread is waiting for. "sem" lists the threads waiting for a semaphore, the semaphore count, and, most interestingly, what thread acquired/released the semaphore last (last_acquirer/last_releaser -- if last_acquirer is negative, the semaphore has been released by last_releaser after it has been acquired by -last_acquirer). So, when you've found a semaphore that seems to be involved in a deadlock, "sem" tells you who acquired the semaphore last, "thread" in turn shows the semaphore that thread is waiting for. Alternating "sem" and "thread" until a cycle is found will then uncover the deadlock.

Theoretically the same works for userland deadlocks as well, but only when BLocker is used semaphore style (can be hacked to always be). Otherwise the last acquirer is not trackable.

[jackburton]

Replying to bonefish:

Theoretically the same works for userland deadlocks as well, but only when BLocker is used semaphore style (can be hacked to always be).

We could make it so when DEBUG is defined (I did that for BHandler)