Change History (8)

I tried Ctrl-C several times with the new OpenFire? version and can't make it hang any more...

What I can see in Odin though since we switched it to GCC is that pressing Ctrl-C in debug builds may lead to the infamous "LIBC panic" message. My quick tests showed that this happens if the thread which is currently writing to the log file is terminated (by the Ctrl-C handler) while holding the fmutex used to serialize file access in LIBC and this is why it complains so loud. In some cases this could leave to the exit thread hang. The next time I get this, I will try to fix it in LIBC. Clearly, it should not panic in such cases.

This problem may be the reason for the OpenFire? hang as well. I will test some more.

As I mentioned in #133:
The hang with control-C with OpenFire? have been there all the time - also
with the VAC builds of Odin. The best way to avoid is is to let OF be idle
for some time with no clients connected - then there is the biggest chance,
that control-C will work.

Ok, I think I now more or less know why we sometimes hang at Ctrl-C. The Odin code internally uses a class called VMutex to serialize access to many resources. This class in turn uses a set of DosEnterCriticalSection?() functions which use a couple of interlocked exchange operations in pair with an event semaphore to implement the mutex functionality.

However, if a thread which is currently holding such a VMutex instance, gets unexpectedly terminated (e.g. by the Ctrl-C handler telling the process to exit and terminate all threads), the mutex remains in a held state. If there happens to be any other thread that requests this mutex after it has been issued a terminate request (e.g. in its exception handler), it will never get it (since the owning thread is already dead) and hang forever. This in turn keeps thread 1 (which is responsible for handling process termination and killing other threads) to hang out forever -- a well known unkillable zobmie with the "exit thread 1" status.

The reason why it is easy to catch this condition in the debug build is because it does heavy logging (also in the exception handler) through WriteLog?() which uses VMutex. But it's not only about logging, there may be other functions called from the exception handlers which use VMutex (or a similar mutex implementation). I need to check that.

Now I'm going to fix the Ctrl-C hang in debug builds that happens in WriteLog? (which has nothing to do with #33) by installing an exception handler and releasing the log mutex upon exception, this should help.