¿Cómo obtener stacktrace de hilo no actual?

Question

Es posible obtener stacktrace utilizando System.Diagnostics.StackTrace, pero el hilo debe suspenderse. Las funciones Suspender y Reanudar son obsoletas, por lo que espero que exista una mejor manera.

Answer 1

Según C# 3.0 in a Nutshell, esta es una de las pocas situaciones en las que es aceptable llamar suspender/reanudar.

Answer 2

Creo que si quieres hacer esto sin la cooperación del hilo de destino (por ejemplo, haciendo que llame a un método que lo bloquea en un semáforo o algo así mientras tu hilo hace el stacktrace) tendrás que usar las API desaprobadas.

Una posible alternativa es el uso de la interfaz COM-based ICorDebug que utilizan los depuradores .NET. El código base MDBG podría darle un comienzo:

• 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

Este es un tema viejo, pero solo quería advertir sobre la solución propuesta: la solución Suspender y Reanudar no funciona - Acabo de experimentar un punto muerto en mi código al intentar la secuencia Suspender/Pilatizar/Reanudar.

El problema es que el constructor de StackTrace realiza conversiones de RuntimeMethodHandle -> MethodBase, y esto cambia una MethodInfoCache interna, que toma un bloqueo. El punto muerto se produjo porque el hilo que estaba examinando también estaba haciendo un reflejo, y estaba sosteniendo ese bloqueo.

Es una lástima que las cosas de suspender/reanudar no se realicen dentro del constructor de StackTrace; entonces, este problema podría haberse eludido fácilmente.

Answer 4

Esto es lo que ha funcionado para mí hasta ahora:

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; 
} 

Si se bloquea al principio, el punto muerto se libera automáticamente y volver un rastro nulo. (Puede llamarlo de nuevo.)

Debo añadir que después de unos días de prueba, solo una vez he podido crear un interbloqueo en mi máquina Core i7. Los bloqueos son comunes, sin embargo, en la VM de un solo núcleo cuando la CPU funciona al 100%.

Answer 5

Como mencioné en mi comentario, la solución propuesta todavía tiene una pequeña probabilidad de un punto muerto. Por favor encuentra mi versión a continuación.

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(); 
    } 
} 
} 

creo, la ManualResetEventSlim "fallbackThreadReady" no es realmente necesario, pero ¿por qué arriesgar nada en este caso delicada?

Answer 6

Parece que este fue una operación apoyado en el pasado, pero, por desgracia, Microsoft hizo esta obsoleta: https://msdn.microsoft.com/en-us/library/t2k35tat(v=vs.110).aspx