Release vs Debug mode

Queridos compañeros de fatígas vjeros, escribo esta vez porque hemos descubierto mi compañero y yo en el curro el maravilloso y misterioso mundo del "Modo release" en el Compilador.

Basicamente, nuestros resultados (con inputs idénticos) eran diferentes, y no ligeramente diferentes, sino terriblemente diferentes. Y todo por que, después de mucho investigar, recordamos que él había cambiado el modo Debug a Release, porque iba más rápido. Antes de irme para casa he mirado un poco sobre el tema, y parece que es un mundo oscuro en el que cualquiera que se mete sale escaldado.

¿Habéis tenido historias similares? ¿Algún consejo para garantizar que el cambio de un modo a otro no supone perder miles de horas en re-debugear el código?

Jeje sip es bastante habitual y más cuando mezclas diferentes tecnologías y lenguajes, pues un compilador lo puede entender de una manera y sin embargo en la versión montada en el usuario el compilador o lo que sea lo entiende diferente.

Mi ciclo de desarrollo suele ser el siguiente (obviando las fases de análisis y diseño):
Desarrollo de un modulo o unidad. Controlar todas las posibles salidas con un Debug (pruebas de "caja Blanca"). Si fuera necesario ya que el módulo es muy grande o hay muchas capas, si compensa en tiempo se puede desarrollar pruebas unitarias automaticas por cada capa ( JUnit ). Si está todo correcto, se siguen con las pruebas de integración probando el funcionamiento de 2 ó más módulos capas o lo que sea (pruebas de "caja Negra").

El tema es programar y fracccionar todo lo posible el programa en módulos de tal forma que las pruebas de integración sean mucho más sencillas. En esto es primordial la fase de diseño, no sólo un diseño bueno debe satisfacer las necesidades del cliente sino también facilitar el trabajo al programador durante su desarrollo.

Uh... el consejo es que vigiles que inicialices todo y tal y cual, porque el modo release ES el modo que tienes que usar cuando vas a generar el binario para dárselo al cliente. El modo debug no sólo es mucho más lento (porque está hecho para que el usuario pueda, valga la redundancia, debuggear y saber por ejemplo los valores de variables, o detener la ejecución en puntos concretos o etc), es que además añade un montón de inicializaciones por defecto, de "protecciones" ante cierto tipo de fallos, lee cierto tipo de instrucciones que en release son ignoradas (como los assert) y patatín y patatán.

El último bug que arreglamos en A Fistful of Cows, irónicamente, fue una variable sin inicializar que nos habíamos dejado por ahí muerta de risa. En toooodo el juego no había dado problemas, pero en el último momento cambiamos un par de posiciones y sorpresa, ahí sí los daba. Lo mejor es que yo soy normalmente ultramaniático con lo de inicializar variables y tal y cual, pero ya ves. Costó bastante rato (y sudores fríos) encontrar qué coño era lo que pasaba, porque "claro", estaba testeado y retesteado

Pues... eso. Ojo que el modo release no sólo es fundamental sino que de hecho es necesario. Como digo, tu aplicación la obtendrás de lo generado al compilar en release, NUNCA deberías dar a un cliente (o usar fuera de testeo, vaya) la aplicación generada en debug, en especial porque está hecha para ser ejecutada desde el IDE y no a saco. Amos, que hay que ir alternando entre los dos modos cuando sepas que ciertas partes están testeadas y tal y cual y patatín. Si os dan resultados distintos es que estáis haciendo cosas mal y el compilador/IDE se está encargando de intentar arreglarlo. La aplicación tiene que dar los resultados correctos en release!

Y eso. Lo mismo toda la explicación sobra pero es que al leerlo...

Pues es la primera vez que leo algo así. La versión debug y la release deben generar la misma salida, más que nada porque en la debug estás probando lo que luego tendrá que ejecutar el usuario. Imagina que un programa lo das por bueno tras probarlo a fondo en debug, para luego obtener un release que hace otra cosa bien diferente. Vamos, que no tiene sentido.

Si no inicializas una variable, en debug el compilador/IDE pone ciertos valores standard según su tipo (por ejemplo, en c++ pone generalmente el equivalente a 0 de ese tipo de variable: 0 en el caso de números, falso, etc). En release, según el lenguaje, compilador y entorno, el valor de esa variable sin inicializar puede ser muchísimas cosas - desde el valor por defecto que decía antes hasta cosas como la última dirección de memoria que había en donde se reserve ahora etc. Con c# en .net creo que te ponía el valor por defecto, por ejemplo, desde luego con c++ NO es eso.

Ejemplo tonto: no inicializo el valor entero X, que utilizo como contador. En debug se inicializa como 0, con lo que yo no noto absolutamente nada raro. Luego ejecuto en release la aplicación y mágicamente el primer valor es 20. O 225, o un número mayor que el máximo de enteros y se me va el programa a tomar por saco en tiempo de ejecución, con coredump y mensaje de error de windows especialmente cómico si esto sólo se ve cuando NO estás ejecutando desde IDE sino como aplicación independiente, que era nuestro caso.

El debug, en especial en ciertos IDEs, lleva muy de la manita al programador con estos errores... y al final puede dar problemas. Por experiencia, vaya!

EDIT: de hecho hay una razón para que muchos tipos de terminales (y ciertas consolas ) permitan marcar que sólo ejecuten código que esté compilado en release y no en debug!
Es que lo estaba comentando justo ahora a los programadores en el curro y alguno se ha llevado las manos a la cabeza

Yo es que siempre inicializo mis variables, quizá por eso nunca he notado esto que me comentas. Y en cualquier caso te puedo decir que en Visual Studio .NET el mismo editor te subraya variables que estás utilizando sin haberlas inicializado, no como error, pero sí como advertencia.

Opino como PalmaSoft, en los dos modos, debug y release, deben dar la misma salida para la misma entrada. Otra cosa es lo que comenta Gangrena:



Lo que sí puede pasar es que las dos máquinas donde se ejecuta no tengan la misma versión del entorno de ejecución o del editor. A mí esto sí me ha pasado, que, por ejemplo, con alguna versión de Eclipse no me funciona algo y con otra sí (lo que se llama "puto bug" del Eclipse o de quien sea ), o que un compañero tenga una versión diferente de Java y le falle algo que a mí me funciona (o al revés ). Por lo que comenta meruelo, este debe ser el problema, pero no que los modos release y debug den salidas diferentes.

Hombre, que no lo digo por decir

http://bobmoore.mvps.org/Win32/w32tip40....

sólo por ejemplo, es uno de los primeros enlaces al buscar esto. Muchas veces, eso sí, hacen referencia a que no has configurado bien el proyecto en release y patatín y patatán, pero eso.

Quicir, la salida DEBERÍA ser la misma. A veces no.

EDIT: y sí, salvo que seas retrasao y mandes al compilador ignorar esos warnings, al usar variables sin inicializar deberías de recibir un aviso en compilación. Eso es otro tema

Bien, bien, no puedo negar la evidencia. En C/C++ no me ha pasó nunca algo así (es verdad que en este lenguaje tenías mucho cuidado con las inicializaciones), aunque ya hace como 7 años que no lo uso En .NET sí que no pongo la mano en el fuego porque lo he utilizado poco y lo entendía menos

A ver, yo sí que he visto casos de programas que fallan en release pero no en debug, pero nunca he visto que un programa genere salidas diferentes en las dos versiones, y menos tan radicalmente diferentes como dice meruelo.

Bien, me gusta que de que hablar, que así aprendo (y con suerte otro con el mismo problema) cosas.

En primer lugar... el código es un código que nos hemos encontrado "así". Quiere decir, esto es un código que lleva así... pues mínimo tres o cuatro años, que así se entregó y patatín patatán. Teníamos código y ejecutables, y principalmente usabamos los ejecutables, usando el código solo en momentos puntuales y/o para aprender/enteder qué hacía el programar principal (no hay nada de documentación de este software). El tema yo creo que es FORTRAN, pero bueno, yo os lo cuento todo que en este hilo parece que no os importa escribir/leer mucho.

El tema ha sido que estabamos introduciendo cambios para optimizar y hacer otra serie de cosas. Y si bien siempre hemos usado un compilador concreto, por temas de compatibilidad y cambios de equipo mi compañero ha tenido que instalar Intel Visual Fortran, y allí ha visto una opción tan apetecible como "release/debug". Activó "release" y empezo´a notar cosas raras, pero no le dió demasiada importancia hasta que nos metimos a fondo a checquear resultados y aquellos no cuadraba.

Yo en primer lugar pensé que podría ser por el tema de usar diferentes procesadores/compiladores: el software es, basicamente, una monstruosa máquina de resolver ecuaciones diferenciales, por lo que cualquier mínimo cambio en algúna operación en algún pequeño punto (cambiar un 7 por un 8 en el decimal que ocupa la posición 15) se puede propagar hasta convertirse en un error de orden unidad si se integra en un tiempo suficientemente grande. Esto quedaba por comprobar, pero casualidad me comentó esto de que había cambiado el modo, y joder, me puse a buscar y empecé a ver que aquello daba muchos problemas. Leí entre muchas otras cosas lo de inicializar variables (creo que lo pongo en el primer post)

Temas: el código es bastante monstruoso, escrito en F-77 (repleto hasta arriba de GO-TO), sin nada de documentación (cero, nada, nothing, niente) y un infierno de proporciones monstruosas. La mayoría de las variables (yo diría 95%) no están inicializadas, y si lo están lo están en un sitio tan oculto que ni dedicando todas mis jornadas laborales de aquí hasta que me jubile lo encontraría. Por lo tanto me temo que no queda otra que dejarlo como estar y correrlo en modo debug.

Me sirve esto para aprender (ya ves que cosa, no tenía ni guarra de que esto existía) que existe un modo Debug, y añadirlo a la ristra de cosas que debería poder mirar cuando tenga algún ratejo. De momento también me sirve para empezar a inicializar todas mis variables.

@Gangrena ¿Cómo haces eso de "caja blanca"? Yo creo que en mi compilador no tengo otra que compilar todo el programa (suele compilar) y correrlo en modo Debug para asegurarme de que el módulo nuevo hace exactamente lo que quiero hacer. Pero según te entiendo, tú lo que haces es decirle al compilador "llama a este módulo con estas entradas que yo te meto a mano, y debuggeamos desde aquí" ¿no? Si es así investigaré a ver.

Es complicado si como has dicho es un código que ya te ha venido escrito y diseñado. Tampoco te puedo concretar mucho cómo podrías hacerlo porque de Fortran ni idea y más si son versiones viejas (mis compañeros de curro que trabajan con Cobol cada vez que que les pasan códigos de banca de los 70 les corren sudores fríos).

Por ejemplo en Java puedes comprobar cualquier tipo de elemento (un comparador if, un bucle for, un objeto, un método, un grupo de métodos, una capa, varias, etc) de tal forma que tu le dices "si yo te meto esto, tu salida debe ser esta y sino me generas un error y me avisas", lo que viene a ser un aserto. Lo bueno es que puedes programarlo para que una vez tengas el resultado no haga falta investigar de dónde viene el fallo, ya sabes qué parte es la que falla. Conforme más reduzcas el tamaño de los elementos a probar, más concreto será tu error. Por eso digo que hay veces que para tener un código de test paralelo, hay que plantear un buen diseño desde el principio para que todo sea más sencillo de hacer.

También hay otra cosa que son los "breakpoints", puntos de ruptura que viene a ser "ejecuta el código hasta esta línea . Entonces tu, gracias al compilador puedes revisar el valor de todas las variables hasta ese momento. Puedes poner varios, dentro de un bucle, o todo el código con breakpoints que esto viene a ser casi como compilar en los 60 línea por línea.

Sí, el tema de breakpoints sí que lo manejo y lo utilizo: es la única herramienta -que yo conocía hasta la fecha- para depurar bien un error o un funcionamiento anómalo. O simplemente para asegurarme de que hace lo que quiero.

Hoy he estado hablando con unos compañeros (distinta empresa, mismo grupo) que se dedican a desarrollo de software... y ha sido como si me viniera Dios a ver. Me han prestado un libro (Clean Code, dicen que de todos los que han leído es el mejor, y que no conocen a nadie que le ponga pegas serias), me han instalado Eclipse+Photran (FORTRAN en eclipse)+Subeclipse (SVN en Eclipse) de manera que casi todos los temas que estaba haciendo mal o en los que tenía carencias se me han solucionado: la posibilidad de comparar con el repositorio desde el propio entorno de programación me ha dejado . Aparte de que la interfaz, la ordenación, los múltiples plugins que admite (FRUIT, que es como jUnit pero para FORTRAN), etc. me han abierto todo un mundo de posibilidades.

Tardaré un tiempo en tenerlo todo funcionando pero joder, cómo he agradecido su ayuda. Además que saben un huevo de esto ("de lo suyo") y es una gozada hablar con ellos, es algo que echaba de menos. Cuando les he dicho que programaba en FORTRAN y, despué de preguntarme si era "FORTRAN 95" les he dicho que no, la versión del 77... su cara ha sido un poema jajaja.

En fin, que soy un panoli en el tema "programar 'bien'" y "programar en equipo", pero veo que se puede ir aprendiendo poco a poco.

Por cierto, que este chico que os comentaba que me estuvo echando un cable, me instaló Eclipse+Photran... y estoy ahora instalándolo en casa y mirando a ver cómo es... y joder, esto es otro mundo. En cuanto he activado el modo "refactor"... ¡casi se me saltan las lágrimas! Y luego tiene un montón de utilidades que tienen pinta muy interesante.

Lo único que necesito es afinar el tema del compilador, que me gustaría poder usar el de VQF por eso de compatibilidad/coherencia de resultados, pero tendré que investigar si es posible o no.

Lamento no haberos hecho caso antes, que se que, por lo menos Gangrena, ya me lo había dicho antes.