2010-11-01 14 views
6

Actualmente estoy de nuevo en la situación de que tengo que encontrar la causa de un error que casi nunca sucede cuando se está ejecutando un depurador (probablemente alguna condición de carrera). Las únicas cosas en las que se me ocurre encontrarlo son:Estrategias para encontrar Heisenbugs

  1. Agregue las impresiones de depuración y las aserciones al código que me dice qué está pasando sin un depurador.
  2. Revise el código y piense en cada línea y los posibles efectos secundarios que pueda tener.

En general, esto es muy frustrante. ¿Cuáles son sus estrategias y experiencias con este tipo de errores?

Editar: Estoy usando Visual C++ 2005, pero creo que la pregunta se aplica a muchos (todos) los idiomas y entornos de desarrollo.

+2

@Mitch: Editó la pregunta para responder la suya. Además, quería que esto sea CW, pero no tengo la reputación de 10k requerida para hacerlo de inmediato, así que me puse en libertad para activar el tic por mí. –

+0

No veo por qué esto debería ser CW (incluso si pudiera configurarlo) –

+2

@Mitch: Porque no tiene una respuesta definitiva. Es más una pregunta de * share your experiences *. –

Respuesta

1

Cuando todas las técnicas han terminado y BoundsCheckers o RationalPurify no son de ayuda. Usualmente uso una técnica muy tonta. Lo hemos descubierto en el primer año de la universidad. En ruso se llama muy áspero.

Por lo tanto, estoy empezando a elegir el bloque/módulo sospechoso que falla en el entorno multihilo. Si es imposible, la estructura del programa se vuelve a factorizar.

Cuando se selecciona el módulo, estoy comentando pequeños bloques de código hasta que desaparece la excepción. Esto permite localizar qué causa exactamente (por ejemplo, condición de raza). Si en este paso puedes decir lo que está mal, entonces es genial.

De lo contrario, se aplica la misma técnica para detectar la condición previa de error, así que estoy comentando el código que viene antes del bloqueo culpable.

2

He encontrado que correr pelusas sobre mi código C/C++/Java y asegurarme de arreglar cada advertencia que ofrece ha llevado a que estas condiciones de carrera simplemente desaparezcan. Pero esa no es una solución. Nunca codifique por coincidencia. Debe comprender lo que ha solucionado y por qué solucionó el problema.

creo que era K (& & ||) R que afirmaron que los mensajes de registro copiosas hicieron más para ayudarles a depurar el código que cualquier depurador - sobre todo en entornos multi-hilo, pero se necesita cita.

Mirar detenidamente un rastro muy detallado de toda la actividad que conduce al error que surge realmente ayuda mucho.

+0

+1 para el registro como estrategia en lugar de confiar en un depurador. – orangepips

4

Si puede identificar el punto (s) en el que el problema es visible por primera vez (no cuando es causada, obviamente), lanzar una excepción allí y utilizar Process Dumper obtener un volcado de depuración postmortem.

Ejecute sus archivos binarios de liberación fuera del IDE y adjunte el depurador después. Esto evita el montón especial y otros indicadores que se ejecutan dentro del depurador.

Si tiene CUALQUIER idea de dónde está el error, extraiga ese código en una aplicación de prueba lo suficientemente pequeña como para intentarlo tanto como sea posible; está intentando probarlo para destruirlo. Nuevamente, conecte el depurador solo después de que el código esté funcionando para evitar muchos efectos secundarios específicos del depurador.

Opciones de inspección: compilar con /W4 solo para asegurarse de que no se haya olvidado nada obvio.Verifique el código y las advertencias para los moldes de estilo C o reinterprete_cast en caso de que alguien haya rechazado mi mensaje, pero tenga una advertencia vital o un mensaje de error.

Cuestiones relacionadas