Jak zdobyć stos przejściowy wątku?

Question

Możliwe jest pobranie stacktrace za pomocą System.Diagnostics.StackTrace, ale wątek musi zostać zawieszony. Funkcje zawieszenia i wznowienia są przestarzałe, więc spodziewam się, że istnieje lepszy sposób.

Answer 1

Według C# 3.0 in a Nutshell, jest to jedna z nielicznych sytuacji, kiedy jest dobrze, aby zadzwonić do wstrzymania/wznowienia.

Answer 2

Myślę, że jeśli chcesz to zrobić bez współpracy z docelowym wątkiem (np. Poprzez wywołanie metody blokującej go na semaforze lub czymś, gdy twój wątek wykonuje ślad stosu), musisz użyć przestarzałe interfejsy API.

Ewentualną alternatywą jest użycie interfejsu COM-based ICorDebug używanego przez debugery .NET. MDbg codebase może dać początek:

• http://blogs.msdn.com/jmstall/archive/2005/11/07/views_on_cordbg_and_mdbg.aspx
• http://geekswithblogs.net/johnsPerfBlog/archive/2008/10/13/mdbg-a-managed-wrapper-around-icordebug.aspx

Answer 3

To jest stara nitka, ale chciałem tylko ostrzec o proponowanym rozwiązaniu: rozwiązanie Suspend and Resume nie działa - po prostu doświadczyłem zakleszczenia w moim kodzie próbując sekwencji Suspend/StackTrace/Resume.

Problem polega na tym, że konstruktor StackTrace wykonuje RuntimeMethodHandle -> konwersji MethodBase, a to zmienia wewnętrzną metodę MethodInfoCache, która przyjmuje blokadę. Zakleszczenie nastąpiło, ponieważ wątek, który badałem również robił odbicie i trzymał ten zamek.

Szkoda, że ​​zawieszanie/wznawianie pracy nie jest wykonywane wewnątrz konstruktora StackTrace - później ten problem mógł zostać ominięty.

Answer 4

Oto, co pracował dla mnie do tej pory:

StackTrace GetStackTrace (Thread targetThread) 
{ 
    StackTrace stackTrace = null; 
    var ready = new ManualResetEventSlim(); 

    new Thread (() => 
    { 
     // Backstop to release thread in case of deadlock: 
     ready.Set(); 
     Thread.Sleep (200); 
     try { targetThread.Resume(); } catch { } 
    }).Start(); 

    ready.Wait(); 
    targetThread.Suspend(); 
    try { stackTrace = new StackTrace (targetThread, true); } 
    catch { /* Deadlock */ } 
    finally 
    { 
     try { targetThread.Resume(); } 
     catch { stackTrace = null; /* Deadlock */ } 
    } 

    return stackTrace; 
} 

Jeśli zakleszczenia, impas zostanie automatycznie zwolniona i wrócisz null śladu. (Możesz potem zadzwonić jeszcze raz.)

Powinienem dodać, że po kilku dniach testowania, tylko raz udało mi się stworzyć zakleszczenie na mojej maszynie Core i7. Zakleszczenia są powszechne w przypadku jednordzeniowej maszyny wirtualnej, gdy procesor działa na 100%.

Answer 5

Jak wspomniano w moim komentarzu, proponowane rozwiązanie nadal ma niewielkie prawdopodobieństwo wystąpienia impasu. Poniżej znajdziesz moją wersję.

private static StackTrace GetStackTrace(Thread targetThread) { 
using (ManualResetEvent fallbackThreadReady = new ManualResetEvent(false), exitedSafely = new ManualResetEvent(false)) { 
    Thread fallbackThread = new Thread(delegate() { 
     fallbackThreadReady.Set(); 
     while (!exitedSafely.WaitOne(200)) { 
      try { 
       targetThread.Resume(); 
      } catch (Exception) {/*Whatever happens, do never stop to resume the target-thread regularly until the main-thread has exited safely.*/} 
     } 
    }); 
    fallbackThread.Name = "GetStackFallbackThread"; 
    try { 
     fallbackThread.Start(); 
     fallbackThreadReady.WaitOne(); 
     //From here, you have about 200ms to get the stack-trace. 
     targetThread.Suspend(); 
     StackTrace trace = null; 
     try { 
      trace = new StackTrace(targetThread, true); 
     } catch (ThreadStateException) { 
      //failed to get stack trace, since the fallback-thread resumed the thread 
      //possible reasons: 
      //1.) This thread was just too slow (not very likely) 
      //2.) The deadlock ocurred and the fallbackThread rescued the situation. 
      //In both cases just return null. 
     } 
     try { 
      targetThread.Resume(); 
     } catch (ThreadStateException) {/*Thread is running again already*/} 
     return trace; 
    } finally { 
     //Just signal the backup-thread to stop. 
     exitedSafely.Set(); 
     //Join the thread to avoid disposing "exited safely" too early. And also make sure that no leftover threads are cluttering iis by accident. 
     fallbackThread.Join(); 
    } 
} 
} 

jak sądzę, ManualResetEventSlim „fallbackThreadReady” nie jest naprawdę konieczne, ale dlaczego ryzykować niczego w tej delikatnej sprawie?

Answer 6

Wygląda na to, że był to obsługiwane operacja w przeszłości, ale niestety, Microsoft udostępnił ten przestarzały: https://msdn.microsoft.com/en-us/library/t2k35tat(v=vs.110).aspx