Is it safe to lock in an Unhandled Exception Handler?

Question

Given that:

• taking a lock while in a finalizer can cause deadlocks
• finalizers can throw exceptions

Is it safe to take a lock while inside an unhandled exception handler or can the code below cause deadlocks?

static void Main(string[] args)
{
     AppDomain.CurrentDomain.UnhandledException += 
         new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
     //do other stuff
}

private static object loggingLock = new object();

static void CurrentDomain_UnhandledException(
    object sender, 
    UnhandledExceptionEventArgs e)
{
    lock (loggingLock)
    {
        //log the exception
    }
}

Answer 1

Given that:

• taking a lock while in a finalizer can cause deadlocks
• finalizers can throw exceptions

Edit Turns out, exceptions thrown in a finalizers are fatal by definition:

doc: If Finalize or an override of Finalize throws an exception, and the runtime is not hosted by an application that overrides the default policy, the runtime terminates the process and no active try-finally blocks or finalizers are executed. This behavior ensures process integrity if the finalizer cannot free or destroy resources.

^{See also c# finalizer throwing exception?}

Note: even though an exception may have originated from within a function, this does not mean that it would be handled in the context of that function. In fact, the stack would have been unwound:

doc: An exception is unhandled only if the entire stack for the thread has been unwound without finding an applicable exception handler, so the first place the event can be raised is in the application domain where the thread originated.

---

I don't see why it would not be safe to lock. (The usual caveats would apply: don't do blocking operations while holding the lock...).

However, you may want to think twice about reentrancy and infinite recursion here:

• how would you respond to errors while logging? The lock would be acquired by definition, because the thread already held it. But is the logging code reentrant? I.e.: would invoking another log operation mess up state for the ongoing (failing/failed) operation? Would logging even be possible?

  --> if reentrancy is not permittable (or requires special actions (like, logging elsewhere) you need an explicit 'inLoggingOperation' flag even though the lock is acquired, since single-threaded re-entrancy is nog prevented by the lock

• Minor point: If your logging isn't entirely exception-proof you may get into trouble when already in CurrentDomain.UnhandledException (AFAICT the docs do not describe what happens when an exception is raised in the event handler).

Answer 2

Well, I did some hunting and I found this from the MSDN:

A lock statement of the form

lock (x) ...

where x is an expression of a reference-type, is precisely equivalent to

System.Threading.Monitor.Enter(x);
try {
   ...
}
finally {
   System.Threading.Monitor.Exit(x);
}

except that x is only evaluated once.

While a mutual-exclusion lock is held, code executing in the same execution thread can also obtain and release the lock. However, code executing in other threads is blocked from obtaining the lock until the lock is released.

8.12 The lock statement

So, the lock will be released if an exception is thrown from within the lock because of the finally statement.

With that info, I would be 95% sure that you won't deadlock by attempting to lock from within your CurrentDomain_UnhandledException method. If someone knows otherwise I would love to here from them (and references would be nice, too).

Answer 3

for posterity... some test code:

class Program
{
    static AutoResetEvent e1 = new AutoResetEvent(false);
    static AutoResetEvent e2 = new AutoResetEvent(false);
    private static object lockObject = new object();

    private static void threadProc()
    {
        lock (lockObject)
        {
            e1.Set();
            e2.WaitOne();
            Console.WriteLine("got event");
        }
    }

    private static int finalized = 0;

    public class finalizerTest
    {

        ~finalizerTest()
        {
            try
            {
                throw new NullReferenceException();
            }
            finally
            {
                Interlocked.Increment(ref finalized);
            }
        }
    }

    static void Main(string[] args)
    {
        ThreadPool.QueueUserWorkItem((a) => threadProc());
        e1.WaitOne();
        AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
        {
            finalizerTest f = new finalizerTest();
        }

        //uncommenting this will cause logging to happen as expected
        /*
        while (finalized == 0)
        {
            GC.Collect();
            GC.WaitForPendingFinalizers();
        }
         */

    }

    static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
    {
        Console.WriteLine("in handler -- pre lock");
        e2.Set();

        lock (lockObject)
        {
            Console.WriteLine("in handler");
        }
    }
}

What happens is that if finalizerTest is finalized because the application leaves main the output reads:

in handler -- pre lock

if however it is finialized because of a GC.Collect/WaitForPending finalizers it reads:

in handler -- pre lock
got event
in handler

What this means is that in the specific case of exceptions thrown from finalizers while the application is going down you might not be able to get your lock, but in this case the application and the finalization queue is already in serious trouble and locking doesn't make it worse.

In every other test I could think of everything happens as expected, threadProc wakes up and logging occurs.