AccessViolationException en modo de lanzamiento (C++)

Question

Recibo la siguiente excepción cuando ejecuto mi aplicación en modo de lanzamiento desde Visual C++.

Excepción no controlada:System.AccessViolationException:Intento de leer o escribir en la memoria protegida.Esto a menudo es una indicación de que otra memoria es corrupta.AT _CEXIT () AT .LanguagesUpport._Uninitializedefaultdomain (void * cookie) en .languageSupport.uninitializedefaultdomain () en .languagesupport.domainUnload (fuente de objetos, argumentos de eve ntargs) en.

Esto no sucede en el modo de depuración.Inicialmente, vi esta excepción en la computadora de mi casa, pero no en la computadora del trabajo.Cuando seguí desarrollando en la computadora de mi trabajo, terminé topándome con ella.

Además, descubrí que cuando agregué tres variables const std::string se produjo la excepción.Si lo eliminé, todo salió bien.

Otro dato más:Descubrí que desactivar todas las optimizaciones del compilador en el modo de lanzamiento hace que la excepción desaparezca.

Algo raro está pasando.¿Alguna idea sobre cómo rastrear esto?

Gracias por la ayuda, Joe

Answer 1

Joe, que tiene una pérdida de memoria .

Probablemente se esté tratando de utilizar parte de la memoria que ha sido borrada.

este artículo por causas comunes de fugas de memoria, y cómo identificar ellos, de lo contrario, la búsqueda de "C perfilador de memoria ++" + su compilador / plataforma, que va a dar enlaces a los perfiladores de memoria adecuada para su compilador y la plataforma, esto ayudará a localizar a la pérdida de memoria al ver cómo el programa utiliza la memoria ya que se ejecuta .

Espero que esto ayude.

Editar

Cómo seguir hacia abajo? Esta es la parte superior de la cabeza, puede haber un consejo mejor en otro lugar. . .

Encuentra donde se bloquea el código, que será cuando se accede a los contenidos de algún puntero (o eliminación de un puntero). El problema es que ese puntero tiene o bien a) nunca ha sido asignado b) ya ha sido borrada. Ir a través de todas las referencias a los punteros de ese tipo, son utilizados en la copia ctors / operadores de asignación?

Si es así, es que sea el contenido que se está copiando o simplemente el puntero? Si sólo el puntero a continuación, es la clase que contiene tratando de eliminar el puntero? Si es así la primera clase de morir tendrá éxito, el segundo arrojará una violación de acceso.

Si no lo hace de forma explícita ctors copiar el código y el operador =, entonces usted debe ocultarlos (declarar prototipos privados pero no ponerlas en práctica), esto detiene el compilador de generación de implementaciones por defecto para usted.

Cuando los oculte obtendrá errores de compilación de todo el mundo están siendo usados, podría ser que usted puede limpiar estas arriba, o que necesita para implementar el ctor copia y el operador = para cada clase.

Estoy de vacaciones a partir de mañana o dos semanas, enviamos un correo electrónico hoy directa (siga el enlace en mi página de usuario SO) si tienes alguna pregunta sobre este tema.

Answer 2

¿Tiene algún código que esté #definido para depurar en su código?

es decir.

#ifndef _DEBUG
   //release only code such as liscensing code
#endif

Eso es algo que podría estar causando el problema y ya me he encontrado antes.

Otra posibilidad es un problema de VS (o cualquier IDE que estés usando).Intente ejecutar la versión .exe directamente en lugar de hacerlo a través del entorno de desarrollo y vea si todavía tiene el mismo problema.

Answer 3

Es un tiempo desde que he hecho en C ++ "en la ira" por así decirlo, por lo que algunos (o incluso todos) de lo que digo a continuación puede también estar fuera de fecha.

¿Está utilizando C ++ administrada? Si no, entonces suena como un puntero no inicializado. Lo que solía ser el caso de que todos los punteros fueron anuladas en la depuración y recuerdo algo acerca de convertir este comportamiento fuera, pero no puedo recordar todos los detalles en este momento.

¿Son las cadenas que invaden sus variables? Improbable con std :: string, pero vale la pena la eliminación.

Answer 4

Un par de posibilidades:

Me imagino que usted está leyendo / escribiendo pasado fin matriz local. En versiones de depuración esto puede funcionar, como la memoria no está bien asignado. En esta versión se basa es más probable que cause problemas, depende de lo que se asigna al lado de la matriz.

Otra posibilidad es que usted tiene un puntero no inicializado en alguna parte. VC predeterminado inicializa las variables locales en el modo de depuración, pero no en modo de lanzamiento. Por lo tanto el código como:

int* p;
if (p != NULL) { /* do something */ }

falla normalmente en modo de lanzamiento.

Answer 5

El mensaje de error es lo que sugiere fuertemente que tiene un problema de memoria, probablemente sobrescribir la memoria. Estos son difíciles de encontrar, pero se pueden encontrar algunas soluciones posibles googlear "Visual C ++ herramienta de corrupción de memoria".

Lo que pasa con la corrupción de memoria es que es impredecible. No necesariamente tiene consecuencias, y si lo hace, no puede dar lugar a un accidente. Reventando como que es buena, ya que le informa de que tienes un problema.

jugando con depuración frente a la liberación, añadiendo o quitando partes de código, cambiando las opciones de optimización y similares es poco probable que resolver el problema. Incluso si lo hace, lo más probable a surgir si se realiza algún cambio.

Por lo tanto, usted tiene un problema de corrupción de memoria. Esos son casi siempre difíciles de encontrar, pero hay herramientas. Que necesita para solucionar ese problema.

También puede buscar en sus prácticas de taller. ¿Utiliza construcciones menos seguras (arrays new en lugar de vector<>, por ejemplo)? ¿Tiene estándares de codificación para tratar de reducir el riesgo? ¿Tiene las revisiones de código? corrupción de memoria puede ser insidiosa y perjudicial, y que desea evitar en la medida de lo posible.

Answer 6

What your getting is a system exception from the OS. These are not handled because they are not C++ exception. However you can convert then into a C++ exception and catch them like a normal exception.

There is a great article here http://www.thunderguy.com/semicolon/2002/08/15/visual-c-exception-handling/ (page 3) that shows how to create a Windows Exception class that will catch the exception using the _set_se_translator method and throw a C++ exception. The great thing is you can get a stack from the EXCEPTION_RECORD structure, although your'll have to add that functionality to process the structure, but it will help narrow your search for that access violation.

Answer 7

I think the issue here is uninitialized local variable. In Debug mode generally the variables get initialized and you don't get any exceptions. But errors may occur in release mode because of this.

Try to look for uninitialized variable whose access may cause exception.

Suppose you have boolean local variable.

bool bRet;

In debug build bRet will get initailized to 0 and your code just works fine .

But in release it won't be 0 , it would be some random value and your code might be doing something based on bRet .It may later cause an exception because bRet value is wrong.