DebuggerExceptions while stepping through code

[Rpinski]

When stepping through the code with F10 sometimes a DebuggerException occurs and debugger loses its context (application is still halted on some statement, but you don't see that in GUI). To get out of this strange state you have to add a breakpoint on a later statement and press F5.

Exception thrown:
Debugger.DebuggerException: Thread has exited
   at Debugger.Thread.get_CorThread()
   at Debugger.Thread.get_IsInValidState()
   at Debugger.Thread.<get_Callstack>d__0.MoveNext()
   at Debugger.Thread.get_MostRecentStackFrame()
   at ICSharpCode.SharpDevelop.Services.WindowsDebugger.debuggedProcess_DebuggingPaused(Object sender, DebuggerPausedEventArgs e)
   at Debugger.Process.OnPaused(DebuggerPausedEventArgs e)
   at Debugger.ManagedCallback.<>c__DisplayClass1.<ExitCallback>b__0()
   at Debugger.MTA2STA.<>c__DisplayClass4.<EnqueueCall>b__1()
   at Debugger.MTA2STA.PerformCall()
   at Debugger.MTA2STA.PerformAllCalls()
   at System.Windows.Forms.Control.InvokeMarshaledCallbackDo(ThreadMethodEntry tme)
   at System.Windows.Forms.Control.InvokeMarshaledCallbackHelper(Object obj)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Windows.Forms.Control.InvokeMarshaledCallback(ThreadMethodEntry tme)
   at System.Windows.Forms.Control.InvokeMarshaledCallbacks()

It might happen occasionally on any statement, so I don't have a specific way to reproduce it.

[dgrunwald]

Here is a test program that can be used to reproduce the error:

class Program
{
    public static void Main(string[] args)
    {
        new Thread(new ThreadStart(DebugMe)).Start();

        while (true) {
            new Thread(new ThreadStart(delegate { })).Start();
        }
    }

    static void DebugMe()
    {
        for (int i = 0; i < 100; i++) {
            Console.WriteLine("Test");
        }
    }
}

Set a breakpoint on the Console.WriteLine statement, then single-step through the method. On my machine, this reproduces the crash after a dozen steps or so.

[dgrunwald]

Note that in this simple example, the 'current thread' that we are pausing on should be the DebugMe thread, which does not exit. The debugger confuses the current thread with the thread that has exited.

Here's the debugger trace log for the crashing step:

2014-03-11 18:33:07,552 [1] INFO - Debugger Command: StepOver
Debugger: Step over: Program.cs:27,29-27,32 IL:12-16
Debugger: Debugger event: OnResumed()
Debugger: Callback: CreateThread 2636
Debugger: Callback: ExitThread 1324
Debugger: Thread 1324 exited
Debugger: Process has queued callbacks
Debugger: Callback: StepComplete (STEP_NORMAL)
Debugger:  - stopped at DebuggerTestApp.Program.DebugMe because of StepOver from [Method DebuggerTestApp.Program.DebugMe():System.Void] name="normal"
Debugger:  - pausing in user code
Debugger: Process has queued callbacks
Debugger: Callback: ExitThread 4832
Debugger: Thread 4832 exited
Debugger: Debugger event: OnPaused()

[dgrunwald]

It seems that we should report the pause on the thread that caused us to decide to pause (i.e. the callback that ended up setting pauseOnNextExit), not the thread associated with the latest callback.

But the whole story with the pauseEventArgs in ManagedCallback seems fishy... there seem to be code paths that pause without creating the event args (e.g. in ExceptionUnwind), thus pausing without calling OnPaused.

[dgrunwald]

Generally the code in ManagedCallback is weird... pauseOnNextExit = true; causes us to pause, but if GetPausedEventArgs() wasn't called; OnPaused won't be called.
This happens in HandleEvalComplete, ExceptionUnwind and the post-break-callback handling in EnterCallback. The last of these three seems intentional, but I don't know if the others are. @dsrbecky ?

To fix this bug, we should remove threadToReport and instead store the thread when the PausedEventArgs are created. My suggestion would be to replace GetPausedEventArgs with this method:

PausedEventArgs RequestPause(Thread thread)
{
     pauseOnNextExit = true;
     if (pauseEventArgs == null) {
         pauseEventArgs = new DebuggerPausedEventArgs(process);
         pauseEventArgs.Thread = thread;
     }
     return pauseEventArgs;
}