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

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

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 progtwig 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 progtwig no detectara excepciones tan importantes como el acceso a un puntero NULL.

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

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.

Me han mordido una serie de errores en el pasado que han estado bien en las comstackciones de Debug, pero fallan en las comstackciones 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 comstackció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 comstackciones
  • 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 precomstackdos y forzados.
  • Cachés: es posible que tenga un código, como cachés, que solo se utiliza en comstackciones 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 comstackció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 comstackdor, cachés, código de depuración solo. Intenta minimizar esas diferencias temporalmente
  • Cree una comstackción de lanzamiento con optimizaciones desactivadas (para que tenga más probabilidades de obtener datos útiles en el depurador) o una comstackció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.

¡Sí !, si tiene una comstackció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.

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 comstackdor.

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 progtwig 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 comstack 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 progtwig en sí!

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!

Claro, por ejemplo, si usa construcciones como

 #if DEBUG //some code #endif 

En .NET, incluso si no utiliza la comstackción condicional como #if DEBUG , el comstackdor 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.

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 comstackn 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 comstackciones 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 comstackción de lanzamiento, es posible (aunque poco probable en estos días) que una comstackción de lanzamiento pueda cortocircuitar algo como una optimización.

Sin más detalles, asumiré que “no está bien” significa que no comstack 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 comstackción, ya sea a través de #if DEBUG declaraciones #if DEBUG o a través de métodos marcados con el atributo Conditional .

Eso es posible, si tiene una comstackció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 comstackn 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 comstackdor que pueden romper el código válido porque son demasiado agresivas.

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

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

En el modo de depuración, si olvida finalizar dicha ruta con una statement 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 progtwig.

Es posible. Si sucede y no hay comstackción condicional involucrada, entonces puede estar bastante seguro de que su progtwig 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.

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 comstackndo 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.

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.