¿Se puede iniciar y detener la comprobación de límites (DevPartner)?

Question

Estoy tratando de usar la herramienta de control de límites para analizar un programa bastante complejo. Ejecutar el programa con la comprobación de límites es casi demasiado lento para que sea de utilidad, ya que me lleva casi un día ejecutar el programa hasta el punto del código donde sospecho que existe el problema. ¿Alguien puede darme algunas ideas sobre cómo inspeccionar solo ciertas partes de mi software usando los límites (DevPartner) en Visual Studio 2005?

¡Gracias de antemano por toda su ayuda!

Answer 1

La última vez que utilicé BoundsChecker fue hace unos años, y tuve los mismos problemas. Con proyectos grandes, hace que todo funcione tan lentamente que es inútil. Terminamos abandonándolo.

Pero, todavía necesitábamos parte de su funcionalidad, pero como tú, no para todo el programa. Así que tuvimos que hacerlo nosotros mismos.

En nuestro caso, lo usamos principalmente para tratar de rastrear pérdidas de memoria. Si ese es su objetivo también, hay otras opciones.

1. Visual Studio hace un buen trabajo al informarle sobre pérdidas de memoria cuando su programa se cierra
2. Informa fugas en el orden en que fueron creadas
3. Le dirá exactamente dónde se creó la memoria filtrada si sus archivos fuente tienen esto en la parte superior

#ifdef _DEBUG
#undef THIS_FILE
static char THIS_FILE[]=__FILE__;
#define new DEBUG_NEW
#endif

Esos ayudan mucho, pero a menudo no son suficientes. Agregar ese fragmento en todas partes no siempre es factible. Si usa clases de fábrica, saber dónde se asignó la memoria no ayuda en absoluto. Entonces, cuando todo lo demás falla, aprovechamos el # 2.

Agregue algo como lo siguiente:

#define LEAK(str) {char *s = (char*)malloc(100); strcpy(s, str);}

Luego, agregue su código con " LEAK (" leak1 "); " o lo que sea. Ejecute el programa y salga de él. Sus nuevas cadenas filtradas se mostrarán en el volcado de fugas de Visual Studio que rodea las fugas existentes. Siga agregando / moviendo sus declaraciones LEAK y vuelva a ejecutar el programa para limitar su búsqueda hasta que haya identificado la ubicación exacta. ¡Luego arregle la fuga, elimine las fugas de depuración y ya está todo listo!

Answer 2

BoundsChecker rastrea todas las asignaciones y lanzamientos de memoria en extremo detalle. Sabe, por ejemplo, que tal y tal asignación de memoria se realizó desde el montón de tiempo de ejecución C, que a su vez se tomó de un almacenamiento dinámico Win32, que a su vez comenzó su vida como memoria asignada por VirtualAlloc. Si la aplicación fue instrumentada (FinalCheck), también tiene información detallada sobre qué punteros hacen referencia a la memoria.

Esta es una razón (de muchas) por la cual la cosa es lenta.

Si BC se conectara a una aplicación tarde, no se acumularía ninguno de estos datos y (1) desenterraría todo de una vez, o (2) comenzaría a adivinar cosas. Ninguna de las soluciones es muy práctica.

Answer 3

Una forma de aligerar BoundsChecker es excluir de la instrumentación todos los pocos módulos que le interesen. Sé que eso no es genial porque si supiera dónde está la fuga, no necesitaría BoundsChecker. Lo que generalmente recomiendo es que use el modo Active Check de BC primero con solo el seguimiento de memoria disponible. Echas de menos las Validaciones de API, pero siempre puedes volver a ejecutarlo por separado. Después de ejecutar Active Check y obtener pistas sobre qué módulos tienden a ser problemáticos, solo entonces habilita la instrumentación para el módulo o módulos de interés y sus dependencias. Sabemos que Final Check es molestamente lento, pero como Mistiano dice correctamente, con Final Check BC no solo mantiene un gráfico de todos los bloques asignados, sino también todos los punteros y contextos. Ahí reside la magia de cómo Final Check puede detectar fugas y corrupciones en el punto de ocurrencia, no solo en el cierre o falla de la aplicación. Plug descarado: trabajo en el equipo DevPartner. Lanzamos DPS 10.5 el 4 de febrero de 2011 con soporte de aplicaciones x64 en BC. A diferencia del relativamente antiguo y poco vendido BC64 para Itanium que solo proporcionaba Active Check, DPS 10.5 proporciona soporte completo de Final Check para aplicaciones x64, tanto para C ++ puro como para módulos nativos que se ejecutan en procesos .NET. Visite microfocus.com en MF Developer para más detalles.