c++ - para - manual de programacion android pdf

Los motivos comunes para los errores en la versión de lanzamiento no están presentes en el modo de depuración (17)

¿Cuáles son las razones típicas de los errores y el comportamiento anormal del programa que se manifiestan solo en el modo de compilación de lanzamiento, pero que no se producen en el modo de depuración?

¡Sí !, si tiene una compilación condicional, puede haber errores de sincronización (verso de código de versión optimizado, código de depuración no optimizado), reutilización de memoria frente a acumulación de depuración.

Claro, por ejemplo, si usa construcciones como

#if DEBUG //some code #endif

En .NET, incluso si no utiliza la compilación condicional como #if DEBUG , el compilador es mucho más liberal con las optimizaciones en el modo de lanzamiento que en el modo de depuración, lo que también puede dar lugar a errores de liberación.

En una función no nula, todas las rutas de ejecución deben finalizar con una declaración de devolución.

En el modo de depuración, si olvida finalizar dicha ruta con una declaración de devolución, la función normalmente devuelve 0 por defecto.

Sin embargo, en el modo de lanzamiento, su función puede devolver valores basura, lo que puede afectar la ejecución de su programa.

Es posible. Si sucede y no hay compilación condicional involucrada, entonces puede estar bastante seguro de que su programa está equivocado, y está trabajando en el modo de depuración solo debido a las inicializaciones de memoria fortuitas o incluso al diseño en la memoria.

Eso es posible, si tiene una compilación condicional para que el código de depuración y el código de versión sean diferentes, y hay un error en el código que solo se usa en el modo de publicación.

Aparte de eso, no es posible. Hay diferencias en cómo se compilan el código de depuración y el código de liberación, y las diferencias en cómo se ejecuta el código si se ejecuta bajo un depurador o no, pero si cualquiera de esas diferencias causa algo más que una diferencia de rendimiento, el problema estuvo ahí todo el tiempo.

En la versión de depuración, es posible que el error no se produzca (porque el tiempo o la asignación de memoria es diferente), pero eso no significa que el error no esté allí. También puede haber otros factores que no están relacionados con el modo de depuración que cambia el tiempo del código, causando el error o no, pero todo se reduce al hecho de que si el código era correcto, el error no ocurriría en cualquiera de las situaciones.

Entonces, no, la versión de depuración no está bien solo porque puede ejecutarla sin obtener un error. Si se produce un error al ejecutarlo en modo de lanzamiento, no es por el modo de lanzamiento, sino porque el error estuvo allí desde el principio.

Hay optimizaciones del compilador que pueden romper el código válido porque son demasiado agresivas.

Intenta compilar tu código con menos optimización activada.

Las funciones de la biblioteca CRT se comportan de forma diferente en depuración frente a versión (/ MD vs / MDd).

Por ejemplo, las versiones de depuración a menudo rellenan los búferes que pasa a la longitud indicada para verificar su reclamo. Los ejemplos incluyen strcpy_s , StringCchCopy , etc. ¡Incluso si las cadenas terminan antes, tu szDest mejor tendrá n bytes de longitud!

Lo experimenté cuando llamaba a una función de ensamblaje que no restauraba los valores previos de los registros.

En la configuración "Release", VS estaba compilando con / O2, lo que optimiza el código de velocidad. Por lo tanto, algunas variables locales simplemente asignaban registros de CPU (para optimización) que se compartían con la función antes mencionada y dañaban gravemente la memoria.

De todos modos, vea si no está jugando indirectamente con los registros de la CPU en ningún lugar de su código.

Me han mordido una serie de errores en el pasado que han estado bien en las compilaciones de Debug, pero fallan en las compilaciones de Release. Hay muchas causas subyacentes (incluidas, por supuesto, las que ya se han resumido en este hilo) y me han atrapado todos los siguientes:

Variables miembro o funciones miembro en un #ifdef _DEBUG , para que una clase tenga un tamaño diferente en una compilación de depuración. A veces se usa #ifndef NDEBUG en una versión de lanzamiento
Del mismo modo, hay un #ifdef diferente que solo está presente en una de las dos compilaciones
La versión de depuración utiliza versiones de depuración de las bibliotecas del sistema, especialmente las funciones de asignación de memoria y montón
Funciones integradas en una versión de lanzamiento
Orden de inclusión de archivos de encabezado. Esto no debería causar problemas, pero si tiene algo como un #pragma pack que no se ha restablecido, esto puede ocasionar problemas desagradables. También pueden ocurrir problemas similares al utilizar encabezados precompilados y forzados.
Cachés: es posible que tenga un código, como cachés, que solo se utiliza en compilaciones de lanzamiento, o límites de tamaño de caché que son diferentes
Configuraciones de proyecto: las configuraciones de depuración y liberación pueden tener diferentes configuraciones (esto es probable que ocurra cuando se usa un IDE)
Condiciones de carrera, problemas de cronometraje y efectos secundarios diversos que se producen como resultado del código de depuración solo

Algunos consejos que he acumulado a lo largo de los años para llegar al final de los errores de depuración / liberación:

Intenta reproducir un comportamiento anómalo en una compilación de depuración si puedes, y mejor aún, escribe una prueba unitaria para capturarlo
Piense en lo que difiere entre los dos: configuración del compilador, cachés, código de depuración solo. Intenta minimizar esas diferencias temporalmente
Cree una compilación de lanzamiento con optimizaciones desactivadas (para que tenga más probabilidades de obtener datos útiles en el depurador) o una compilación de depuración optimizada. Al minimizar los cambios entre la depuración y la versión, es más probable que pueda aislar qué diferencia está causando el error.

Muchas veces, en el modo de depuración en C ++ todas las variables son inicializadas nulas, mientras que lo mismo no ocurre en el modo de lanzamiento a menos que se indique explícitamente.

Compruebe si hay macros de depuración y variables sin inicializar

¿Su programa utiliza el enhebrado? Entonces, la optimización también puede causar algunos problemas en el modo de lanzamiento.

También verifique todas las excepciones, por ejemplo, no directamente relacionadas con el modo de lanzamiento, pero a veces simplemente ignoramos algunas excepciones críticas, como la violación de acceso a la memoria en VC ++, pero lo mismo puede ser un problema en otros sistemas operativos como Linux y Solaris. Lo ideal sería que su programa no detectara excepciones tan importantes como el acceso a un puntero NULL.

Otras diferencias pueden ser:

En un lenguaje recogido de basura, el recolector suele ser más agresivo en el modo de lanzamiento;
El diseño de la memoria a menudo puede ser diferente;
La memoria puede inicializarse de manera diferente (por ejemplo, podría ponerse a cero en el modo de depuración o reutilizarse de forma más agresiva en la versión);
Los locales pueden promocionarse para registrar valores en la versión, lo que puede causar problemas con los valores de coma flotante.

Puede, especialmente si estás en el reino C.

Una de las causas podría ser que la versión de DEPURACIÓN puede agregar código para buscar punteros vagabundos y de alguna manera proteger su código para que no se bloquee (o se comporte incorrectamente). Si este es el caso, debe verificar cuidadosamente las advertencias y otros mensajes que obtiene de su compilador.

Otra causa podría ser la optimización (que normalmente está activada para las versiones de lanzamiento y desactivada para la depuración). El código y el diseño de los datos pueden haberse optimizado y, si bien su programa de depuración fue, por ejemplo, el acceso a la memoria no utilizada, la versión de lanzamiento ahora está tratando de acceder a la memoria reservada o incluso apuntando al código.

EDITAR: veo que otros lo mencionaron: por supuesto, puede tener secciones de código enteras que se excluyen condicionalmente si no se compila en modo DEPURAR. ¡Si ese es el caso, espero que realmente esté depurando el código y no algo vital para la corrección del programa en sí!

Recuerdo que hace mucho tiempo cuando estábamos construyendo dll y pdb en c / c ++.

Yo recuerdo esto:

La adición de datos de registro a veces haría que el error se moviera o desapareciera o apareciera un error totalmente diferente (por lo que no era realmente una opción).
Muchos de estos errores se debieron a la asignación de caracteres en strcpy y strcat y en las matrices de caracteres [], etc.
Eliminamos un poco al ejecutar el corrector de límites y simplemente solucionamos los problemas de aloc / dealloc de la memoria.
Muchas veces, sistemáticamente revisamos el código y arreglamos una asignación char (como a través de todos los archivos).
Definitivamente es algo relacionado con la asignación y administración de memoria y las restricciones y diferencias entre el modo de depuración y el modo de lanzamiento.

Y luego esperé lo mejor.

A veces, entregué temporalmente versiones de depuración de dlls a los clientes, para no retrasar la producción, mientras trabajaba en estos errores.

Sin más detalles, asumiré que "no está bien" significa que no compila o arroja algún tipo de error en el tiempo de ejecución. Compruebe si tiene un código que se basa en la versión de compilación, ya sea a través de #if DEBUG declaraciones #if DEBUG o a través de métodos marcados con el atributo Conditional .

Tendría que dar mucha más información, pero sí, es posible. Depende de lo que haga tu versión de depuración. Es posible que tenga logging o cheques adicionales que no se compilan en una versión de lanzamiento. Estas rutas de código solo de depuración pueden tener efectos secundarios no deseados que cambian el estado o afectan las variables de maneras extrañas. Las compilaciones de depuración generalmente se ejecutan más lentamente, por lo que esto puede afectar el enhebrado y ocultar las condiciones de carrera. Lo mismo para las optimizaciones directas de una compilación de lanzamiento, es posible (aunque poco probable en estos días) que una compilación de lanzamiento pueda cortocircuitar algo como una optimización.

Un error común es usar una expresión con efecto secundario dentro de ASSERT.