estancamientos detectar en una aplicación de C#

Question

Duplicar posibles:
C#/.NET analysis tool to find race conditions/deadlocks

estoy depurar una aplicación que sospecho es conseguir un punto muerto y colgando. Sin embargo, esto solo ocurre cada pocos días, y nunca ocurre en mi computadora, así que no puedo conectar un depurador. ¿Hay utilidades o métodos que pueda usar para consultar la aplicación en ejecución y descubrir qué métodos/bloqueos/en qué se encuentra estancado?

Actualización: Normalmente, la aplicación se ejecuta en una ubicación de cliente y no tengo acceso a la máquina, y no me siento cómodo pidiéndoles que instalen toneladas de software.

Answer 1

En lugar de utilizar el método lock & Monitor.Enter regular para bloquear algunos datos, también puede utilizar una estructura 'TimedLock'. Este TimedLock arroja una excepción si el bloqueo no se pudo adquirir de manera oportuna, y también puede darle una advertencia si tiene algunos bloqueos que no lanzó.

This artículo de Ian Griffiths podría ayudar.

Answer 2

El final de http://blogs.technet.com/askperf/archive/2007/06/15/capturing-application-crash-dumps.aspx dice que en Vista al menos puede obtener un volcado de un proceso en ejecución mediante el Administrador de tareas.

Answer 3

Este es un problema muy interesante y un dolor porque solo ocurre cada pocos días. Encontré this article on CodeProject. Puede ser un comienzo para ti.

Un enfoque de la vieja escuela es registrar una tonelada de mensajes y utilizar archivos de registro para tratar de detectar cuando se produce. :)

Answer 4

Realmente tiene un problema muy interesante allí. Hay varias cosas que puede hacer:

Utilice un buen registrador: una de las maneras de reproducir un error de múltiples hilos es tener un registrador que imprima las acciones y el hilo que las realizó, de esa manera puede encontrar un seguimiento lo guía al error. Esta es una solución bastante fácil si puede agregar el registrador.

Usar FSP: defina su sistema de múltiples hilos utilizando FSP. De esta forma, podrá crear una máquina de estados finitos del proceso que puede recorrer para encontrar el error. Esta solución es una solución más matemática.

Las dos soluciones/procedimientos que le doy son exactamente las principales diferencias de desarrollo multi-hilos que se avecina entre algunas universidades británicas y americanas. En el Reino Unido, los profesores son más amables de probar y probar que su sistema no tiene errores al utilizar FSP antes de que lo programen, y los estadounidenses prefieren probar para probar que funcionan correctamente, es una cuestión de gusto.

Realmente recomiendo leer este libro: Jeff Magee y Jeff Kramer: Modelos de Estado y los programas de Java, Wiley, 1999

Answer 5

Puede utilizar WinDbg para inspeccionar los hilos en la aplicación: concurrencia. Aquí hay un breve plan de lo que podrías hacer.

• Cuando la aplicación se cuelga, copie los archivos WinDbg a la máquina.
• O adjunte WinDbg al proceso o use ADPlus para obtener un volcado del proceso. Si elige ADPlus, luego carga el volcado en WinDbg.
• Desde WinDbg carga sos.dll, por lo que puede inspeccionar el código administrado.
• El comando !threads le mostrará todos los hilos en la aplicación y el comando !clrstack, le mostrará lo que están haciendo. Use ~e!clrstack para volcar la pila de llamadas de todos los hilos. Busque las llamadas a los métodos de Espera, ya que indican bloqueo.
• El comando !syncblk le dará información de qué subprocesos tienen los diferentes bloqueos.
• Para averiguar qué bloqueo está tratando de adquirir un hilo determinado, cambie al hilo e inspeccione los objetos de la pila (!dso). Desde aquí, debería poder encontrar el bloqueo que el hilo intenta adquirir.

Aclaración: WinDbg no necesita una instalación regular. Solo copie los archivos. Además, si toma el volcado, puede continuar la depuración en otra máquina si así lo desea.

Además: Sosex tiene el comando !dlk que identifica automáticamente interbloqueos en muchas situaciones. No funciona todo el tiempo, pero cuando lo hace, hace todo el trabajo por ti, así que esa debería ser tu primera opción.

Answer 6

Además de las respuestas aquí, otra cosa que le resultaría útil con la programación de subprocesos en general es asegurarse de que su dev box sea una máquina multiprocesador, los deadlocks en particular son (generalmente) mucho más reproducibles.

Answer 7

Los tiempos de espera en la programación simultánea son una idea horrible. Esto lleva al no determinismo y, por lo tanto, al comportamiento que no puede reproducirse. Intente utilizar una herramienta de detección de punto muerto como CHESS. Mejor aún, minimice el número de bloqueos utilizados con algoritmos sin bloqueo, o evite por completo los bloqueos y particione su programa en compartimentos de un solo subproceso y use colas para pasar datos entre compartimentos (mejor conocido como paso de mensajes/concurrencia de actores).