¿Cuál es una forma rápida de rastrear la entrada y salida de funciones en un programa multiproceso de Visual Studio 2005 c ++?

Question

Tengo bloqueos intermitentes que ocurren en mis bibliotecas ActiveMQ debido a la forma en que estoy usando la API activemq-cpp. Sería mucho más fácil depurar el problema si pudiera observar que se llama a cada función antes del bloqueo. ¿Hay alguna forma rápida de rastrear la entrada y salida de funciones en un programa multiproceso de Visual Studio 2005 c ++?

Gracias de antemano!

Answer 1

Usa un objeto Tracer. Algo como esto:

class Tracer
{
public:
  Tracer(const char *functionName) : functionName_(functionName)
  {
    cout << "Entering function " << functionName_ << endl;
  }

  ~Tracer()
  {
    cout << "Exiting function " << functionName_ << endl;
  }

  const char *functionName_;
};

Ahora puede simplemente crear una instancia de un objeto Tracer en la parte superior de la función, y se imprimirá automáticamente " saliendo de ... " cuando la función sale y el destructor se llama:

void foo()
{
  Tracer t("foo");
   ...
}

Answer 2

Mientras el depurador está adjunto a un proceso, puede hacer clic derecho en el código fuente y seleccionar " breakpoint- > add TracePoint " ;, con el texto que desee (incluso se suministran algunas macros).

Tracepoint es, de hecho, un BreakPoint con el botón " When Hit " campo en alguna funcionalidad de la impresora de mensajes, y en realidad no interrumpe el proceso. Lo encontré muy útil: también tiene una macro $ FUNCTION, que hace exactamente lo que necesita: imprima la función en la que se encuentra (siempre que tenga la información de depuración disponible ...), y un $ THREADID.

Answer 3

Todas las opciones anteriores son agradables y pueden ayudarte. Pero no veo cómo la configuración de TracePoing con el mouse puede ayudarlo en caso de que el código tenga miles de funciones.
Este tipo de cosas debería ser parte de su trabajo de programación regular. Al escribir una función, debe pensar qué mensaje de seguimiento le ayudará a depurarlo.
Debe escribir / usar el registrador existente que se puede escupir a la sección (subproceso del lector, subproceso de trabajo, etc.) y diferentes niveles de registro (error, advertencia, rastreo, detallado, etc.). El buen registrador debe diseñarse de manera que no afecte su rendimiento, esto suele dañar la verbosidad, pero los problemas complejos de sincronización generalmente se pueden reproducir a menos que el registro sea muy rápido, como asignar un puntero de cadena a la matriz que se puede volcar después del problema Se reproduce. Por lo general, comienzo la depuración con un rastreo completo en la pantalla y si tengo suerte y el error se reproduce de esta manera, corregir el error es trivial porque ya tengo suficiente información, la diversión comienza cuando el problema desaparece y es necesario jugar con verbosidad para poder reproducir el problema.
De hecho, encuentro que la depuración es más creativa y satisfactoria que la escritura de código, pero esto es solo yo :).