que - herramientas de debugging
Depuración hacia atrás (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.
Vea aquí para más detalles: http://sourceware.org/gdb/news/reversible.html .
Tengo dos preguntas :
Mientras se realiza la depuración a nivel de fuente (usando cualquier depurador) ¿se ejecuta algún depurador de estado de alguna iteración / for-loop / código y permite al usuario volver al 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é corrupto en algún lugar en el tiempo durante la ejecución, pero se accede después de un tiempo / más tarde en la ejecución del código y eso es cuando cuelga / cuelga el código, por lo que me gustaría volver y ver qué función / ¿a qué hora se corrompió la variable / se calculó y escribió el valor incorrecto? ¿Es posible en cualquier depurador (gcc, MSVC6.0 ...)
¿Algún depurador / IDE tiene la disposición de que cuando una dirección / variable de memoria 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?
-ANUNCIO
Creo que la última versión de OCaml tiene esto. 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í).
Es posible que desee consultar Replay Debugging de VMware.
Desde el enlace:
Lo que hicimos fue integrar el plugin de Visual Studio para Workstation con tecnología Record / Replay. 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 implementamos una característica única de "ejecución inversa". Digamos, si está depurando una corrupción de memoria, puede poner un punto de observación en la memoria dañada y luego presionar "Reverse Continue" en el menú del plugin de Visual Studio, y navegaremos la grabación directamente al lugar donde se escribió la última memoria.
No conozco ningún depurador que le permita guardar el estado para volver más adelante. 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 admite puntos de interrupción de datos que irrumpirán en el depurador siempre que se escriba una ubicación de memoria determinada.
Estos pueden ser muy útiles para descubrir qué está pisando un trozo de memoria que está siendo dañado. 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.
Para # 2, es posible que desee leer sobre los puntos de observación , que están disponibles en gdb, entre otros depuradores.
Los puntos de observación son similares a los puntos de interrupción. Sin embargo, los puntos de observación no están configurados para funciones o líneas de código. Los puntos de observación se establecen en variables. Cuando se leen o escriben esas variables, se activa el punto de observación y se detiene la ejecución del programa.
Para el primer número: ddd / gdb tiene una traza inversa que le muestra exactamente cómo llegar a ese punto. También un coredump podría ayudar.
Un interesante artículo sobre posibles efectos secundarios es este
Para el primer punto, puedes probar los puntos de interrupción condicionales. 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];
}
Puede configurar un punto de interrupción condicional para detener cuando i == 17 , o cuando foo == null .
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, utiliza el depurador para cambiar los valores de las variables y luego vuelve a la parte superior del bucle 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".
Suena como si quisiera obtener una copia de Visual Studio 2010.
Están implementando casi exactamente lo que está describiendo en el n. ° 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 ubicada aquí (esta es para el CTP de abril de 2008 del nombre clave ''Rosario'')
Encontré esta definición del nuevo Depurador Histórico de una entrada de blog de Maor David ( aquí ):
"Visual Studio Historical Debugger 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 a tiempo para determinar dónde ocurrió un error ".
¡Aquí hay otro video tutorial también!
Editar: Estoy empezando a evaluar la mayor (1) caída reciente de 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.
Creo que estás tratando de llegar a un Depurador Omnisciente o Historias de Programas Tangibles (desde 1999 !!).
Por supuesto, estos son más documentos de investigación / implementaciones, pero parece que estos conceptos finalmente están llegando a los compiladores convencionales.
Tales depuradores están en proceso. Puede consultar el siguiente Google Talk - Depuración al revés en el tiempo