2011-01-18 8 views
8

EDIT: Debido a un comentario que tenía razón sobre mi ejemplo lo quité y convertir esto en una pregunta genérica:herramientas para tratar con daños en la pila en C++

Algunas veces en mis proyectos en los que se encuentran con daños en la pila. No importa cuánto luche para escribir código para evitarlo, a veces es inevitable. Pero cuando sucede, ¿cuáles son las formas de combatirlo?

Encontré una macro dada por el buen tipo en este blog: http://rxwen.blogspot.com/2009/04/detect-stack-corruption.html que lee el valor del registro de ebp para detectar daños.

Pero existen herramientas más sofisticadas para ayudar a no dispararse en el pie. Estoy programando en Windows usando Codeblocks y el compilador gcc. La razón por la que hago esta pregunta es encontrar herramientas que pueda usar en mi entorno de programación para ayudarme a detectar esos errores y corregirlos. ¿Alguna sugerencia?

Gracias por cualquier respuesta y por tomarse el tiempo para leer mi pregunta.

+2

1. No se ha publicado ningún código. 2. ¿Cómo sabes que hay corrupción en la pila? 3. ¿Por qué crees que el problema radica donde has indicado? 4. ¿Puedes publicar los contenidos de los miembros y constructores de la clase 'artist'? –

+0

Voy a reformular la pregunta. No debería haber publicado este ejemplo. No es un ejemplo real de corrupción en mi proyecto, solo un ejemplo de una corrupción con la que tuve que lidiar en el pasado, que realmente me cobró los nervios. Convertiré esto en una pregunta genérica sobre corrupción de pila y herramientas para manejarlo. – Lefteris

+1

a veces es simplemente inevitable Eso es solo poppycock. Su mejor herramienta para evitar la corrupción de la pila es una buena técnica y el cumplimiento de las mejores prácticas. –

Respuesta

4

No está nada claro que está teniendo pila corrupción. Pero acepto que hay algo de corrupción de datos.

Una técnica razonablemente eficaz es agregar campos de guardia alrededor del campo (s) sospechoso:

... 
long namecheck1; 
Artist artist; 
long namecheck2; 
... 

Haga que el constructor inicializa estos para casi cualquier cosa, pero sin conocer la naturaleza de la corrupción algo distinto de cero parece más satisfactorio

myclass::myclass() : namecheck1(0x12345678), namcheck2(0x12345678) ... 

Añada un método de comprobación de coherencia:

void myclass::isokay() 
{ 
     if (namecheck1 != namecheck2 || 
      namecheck2 != 0x12345678) 
      cerr << "the object is corrupted"; 
     ... // maybe wait for input, cause core dump, etc. 
} 

A continuación, el código de pimienta con llamadas a esto, especialmente cerca de la lógica sospechosa. Si se siente cómodo con un depurador, coloque un punto de interrupción en el mensaje de error. Al desentrañar la pila, puede determinar lo que el programa ha hecho recientemente y reunir pistas sobre qué bit de código probablemente esté escribiendo fuera de los límites apropiados.

+2

Sugerencia: en lugar de '0x12345678', use el estándar' 0xBAADF00D'. :) – Mehrdad

+0

¡No me di cuenta de que había un patrón arbitrario estándar! :-) – wallyk

+3

He visto 0xDEADBEEF también. –

1

Valgrind encuentra todo tipo de daños en la memoria.

GCC tiene mudflap (-fmudflap y amigos) y -fstack-protector para detectar problemas de acceso a la memoria. Otros compiladores probablemente también lo hagan.

Cuestiones relacionadas