Depuración hacia atrás

Question

tengo dos preguntas:

1. Mientras se hace la depuración del nivel de fuente (usando cualquier depurador) hace cualquier depurador Guardar estado de alguna iteración/for-loop/cualquier código ejecutado y permite al usuario volver a ese estado de código/datos ejecutado previamente en un momento posterior durante la depuración? La necesidad de esto es que alguna variable/puntero esté corrupta en algún lugar en el tiempo durante la ejecución, pero se accede después de un tiempo o más tarde en la ejecución del código y cuando cuelga/cuelga el código, entonces me gustaría volver y ver ¿Qué función/en qué momento se corrompió la variable/se calculó y escribió el valor incorrecto? ¿Es posible en cualquier depurador (gcc, MSVC6.0 ...)

2. ¿Tiene algún depurador/IDE la disposición de que cuando una dirección de memoria/variable está marcada para "análisis", debe mostrar qué función en qué archivo , y qué código cambió esa memoria (escritura), cada vez que se cambia/escribe?

-AD

Answer 1

creo que la versión más reciente de OCaml tiene esta. Esto parece una moda bastante nueva, pero IIRC está en la lista de deseos de la versión futura de Visual Studio.

Una característica en VS que no he usado, puede rastrear objetos (hacer identificación de objeto o algo así).

Answer 2

No conozco ningún depurador que le permita guardar el estado para poder volver más tarde. El depurador no tendría forma de saber qué estado era relevante. Lo más cercano que podría obtener sería crear un archivo de volcado en algún momento, lo que le permitiría inspeccionar el estado completo del programa más adelante.

Visual Studio es compatible con data breakpoints que irrumpirá en el depurador siempre que se escriba una ubicación de memoria determinada.

Estos pueden ser muy útiles para descubrir qué está pisando una parte de la memoria que se está dañando. Sin embargo, existen limitaciones en la cantidad de puntos de interrupción de datos que puede establecer, ya que se implementan utilizando el soporte de registro de hardware del procesador.

Answer 3

Para # 2, es posible que desee leer acerca de watchpoints, que están disponibles en gdb, entre otros depuradores.

Los puntos de observación son similares a puntos de interrupción. Sin embargo, los puntos de observación son no configurados para funciones o líneas del código . Los puntos de observación se establecen en las variables . Cuando esas variables son leídas o escritas, el punto de observación es activado y se detiene la ejecución del programa.

Answer 4

Para el primer punto, puede probar los puntos de interrupción condicional. La mayoría de los depuradores que he usado parecen tener esta característica, aunque muchas personas no lo saben. Puede configurar el punto de interrupción para que solo se detenga cuando se cumpla alguna condición, como su variable de iterador es algún número, o alguna otra variable es nula. Por ejemplo:

for (i = 0; i < list.size(); i++) { 
    foo = list[i]; 
} 

podría establecer un punto de interrupción condicional a parar cuando i == 17, o cuando foo == null.

Answer 5

Tales depuradores están en proceso.Puede consultar el siguiente Google Talk - Debugging Backwards in Time

Answer 6

Para la primera edición: ddd/gdb tiene un backtrace que le muestra exactamente cómo llegar a ese punto. También un coredump podría ayudar.

Un interesante artículo acerca de un posible efecto secundario es this one

Answer 7

Se suena un montón, como se va a querer agarrar una copia de Visual Studio 2010.

Están implementando casi exactamente lo que está describiendo en # 1 - hay un screencast sobre el nuevo "The Historical Debugger" en Visual Studio Team System 2010 en Channel 9.

Hay un poco más sobre esto en esta entrada situado here (this one is for the April 2008 CTP of codename 'Rosario')

he encontrado esta definición del nuevo depurador histórico de una entrada de blog por Maor David (here):

"Visual Studio histórico depurador captura y registra qué hace la aplicación mientras se está ejecutando. Cuando se produce un error, puede encontrar rápidamente la causa raíz investigando la información que fue registrada por el Depurador de historial. En cualquier momento durante la depuración, puede ir hacia atrás y hacia adelante en el tiempo para determinar dónde ocurrió un error ".

¡Aquí hay otro video walkthrough también!

Edición: Estoy empezando a evaluar la caída más (1) recent CTP (31/10 - 08 de octubre) de Visual Studio 2010 y parece que tienen una versión anterior del depurador histórico implementado. Vale la pena echarle un vistazo.

(1) [http://www.microsoft.com/downloads/details.aspx?FamilyId=922B4655-93D0-4476-BDA4-94CF5F8D4814&displaylang=en]

Answer 8

Creo que está tratando de llegar a un Omniscient Debugger o Tangible Program Histories (de 1999 !!).

Por supuesto, se trata de más documentos de investigación/implementaciones, pero parece que estos conceptos finalmente están llegando a los compiladores convencionales.

Answer 9

Es posible que desee consultar Replay Debugging de VMware.

Desde el enlace:

Lo que hicimos fue integrando Estudio complemento visual para la estación de trabajo con la tecnología de grabación/reproducción. Ahora puede desarrollar su aplicación con Visual Studio y luego, con unos pocos clics del mouse, iniciarla en una VM en modo de grabación. A continuación, puede reproducir la grabación tantas veces como desee, utilizando todas las funciones de depuración que proporciona Visual Studio.

Pero no nos detuvimos en eso. También hemos implementado única función de "ejecución inversa" . Por ejemplo, si se está depurando una corrupción de memoria , puede poner punto de observación en la memoria dañada y después haga clic en "Continuar inversa" en menú de plug-in de Visual Studio - y vamos a navegar la grabación correcta en el lugar donde estaba la memoria último escrito a.

Answer 10

Si bien los depuradores actuales no guardan el estado, te permiten retroceder, hasta cierto punto. Puede usar la función "mover punto de ejecución a aquí" (el nombre real dependerá de su depurador, por supuesto) para establecer la línea que se está ejecutando.

Esto solo funciona bien para saltar dentro de una sola función, pero puede ser útil para "intentar de nuevo" con un valor diferente: se rompe después de un ciclo, usa el depurador para cambiar los valores variables y luego salta volver a la parte superior del ciclo. Alternativamente, si sabe que una llamada a función va a fallar pero desea ver qué sucede después (por ejemplo ... algo se agotó porque se detuvo en el depurador, pero quiere continuar ejecutándose como si no lo hubiera hecho) t timed out), puede usar la función "mover punto de ejecución a aquí" para omitir ese código.

Sé que no es lo que pediste, pero por el momento, es todo lo que tenemos ... Creo que tal tecnología probablemente estará disponible bastante pronto, pero por el momento creo que está en la fase de "investigación" .

Answer 11

Desde septiembre de 2009, el depurador de GNU (gdb) tiene la posibilidad de revertir la depuración, es decir, la capacidad de hacer que el programa se depure paso y continuar en reversa. Esto suena como lo que has pedido.

Consulte aquí para obtener más información: http://sourceware.org/gdb/news/reversible.html.