¿Hay algún problema con la liberación de software en modo de depuración?

Question

Todos sabemos que el "Modo de depuración" se debe usar para el desarrollo porque el compilador produce más información de depuración y el "Modo de publicación" se debe usar para las versiones de producción porque el compilador produce código optimizado.

Sin embargo, digamos que si usted está haciendo un software que se sólo se usa internamente dentro de la organización y el rendimiento del código no es un gran problema porque el software tiene que hacer un montón de archivo de E/S y de bases de datos consultas . Estaré muy tentado de lanzar el software en "Modo de depuración" en este escenario porque esa información de depuración adicional hace que el mantenimiento futuro sea un poco más fácil.

¿Hay alguna razón convincente para liberar el software en este modo?

Answer 1

dos preocupaciones que se me ocurren:

1. versiones de depuración menudo agregar relleno de tampones. Es por eso que a veces obtienes programas que parecen para que funcionen en la depuración pero fallan en la versión. Seem es la palabra clave aquí, ya que los desbordamientos de buffer son solo un accidente esperando a suceder.

2. Suceden cosas extrañas en las compilaciones de depuración. Una vez trabajé en una aplicación de larga ejecución que se bloqueaba cada veinte días más o menos. Resulta que en el tiempo de ejecución C un contador (usado para ayudar a la depuración) se incrementaba cada vez que se realizaba un malloc/free. Si el contador se desbordó, ¡kaboom! Por esta razón, nunca recomendaría a nadie que implemente binarios de depuración; nunca se sabe qué sorpresas podría estar esperando su cliente.

Answer 2

Supongo que hay mucho más código de depuración instalado que el que nosotros (los desarrolladores) estamos dispuestos a admitir.

Personalmente conozco muchos sistemas de producción que se implementan en clientes con código compilado en modo de depuración.

Answer 3

Si se trata de un sitio web o servicio y el rendimiento no es un problema, entonces, de todos modos, libérelo en modo de depuración. Si se trata de una aplicación de escritorio, considere si la versión del modo de depuración es fácil de usar en la forma en que maneja los errores. Si es así, también lanzaría la versión de depuración.

Answer 4

El solo hecho de que pregunte sugiere que hay un beneficio del Modo de depuración que desea aprovechar. Si estos beneficios superan tu culpabilidad moral, entonces digo "adelante" y hazlo. Estos beneficios son probablemente mecánicos e informativos y relevantes para su trabajo, mientras que la falta de culpabilidad realmente no lo ayuda a producir un mejor software. Puede ayudarte a dormir mejor, pero ¿a quién le importa?

Answer 5

depende del usuario

Si el usuario es técnica, el suministro de un paquete de depuración adicional para los símbolos pueden ayudarles a depurar en su nombre o envían información de errores más técnico ... que le ahorra dinero/tiempo.

Si el usuario es un usuario doméstico ... es probable que no les importe si la información de depuración está allí o no. Siempre que elimine toda su traza de cruces :)

Si se trata de una empresa que busca una máquina sin grasa, entonces proporcione una versión despojada.

Depende de dónde se encuentren sus objetivos/limitaciones de comunicación/negocios.

Answer 6

razones posibles:

1. depuración normalmente no se compila para un rendimiento
2. depuración tamaño de la aplicación (normalmente) es mucho mayor que la liberación compila.
3. Si alguien intenta realizar una ingeniería inversa de su aplicación (por el motivo que sea), será mucho más fácil.

ACTUALIZACIÓN: 4.Como se señaló, el rendimiento del enlazador, pero yo hubiera pensado que estaría muy abajo en la lista: p ¿Cuántas veces lanza un producto en comparación con hacer compilaciones de depuración?

Si está dispuesto a renunciar a lo anterior, entonces no hay una razón real de por qué no.

Answer 7

Usted era independiente de la plataforma en la pregunta, pero este consejo sobre por qué no poner el modo de depuración en producción en ASP.Net demuestra algunas de las razones (por cierto relacionadas con el rendimiento) para no hacerlo.

1) La compilación de las páginas ASP.NET lleva más tiempo (ya que algunas optimizaciones lotes están desactivados)

2) Código puede ejecutar más lento (ya que algunos caminos de depuración adicionales están habilitados)

3) Mucho más memoria se utiliza dentro de la aplicación en tiempo de ejecución

4) Secuencias de comandos y las imágenes descargadas desde el controlador WebResources.axd no se almacenan en caché

el último punto es un poco de un asesino Potencia para ciertos tipos de controles que son funcionalidades 'esperadas' en un mundo web2.0, incluso para aplicaciones internas. Vea el artículo ScottGu para obtener más detalles sobre los costos del último punto.

Quizás la mejor manera de resumir el contraargumento sea "depende de cómo se defina el rendimiento del código".

Answer 8

La compilación de cualquier aplicación en modo Depuración agrega código a la aplicación que es utilizada (casi) exclusivamente por el compilador o IDE para depurar, recorrer su código, etc. Estas funciones de depuración prácticamente no tienen uso en la vida real. Si desea lanzar una aplicación al público, su mejor opción es compilarla en modo de lanzamiento. Además, las aplicaciones incorporadas de lanzamiento son ...

• Mucho más rápido y estable
• optimizado para la máquina
• más pequeño en tamaño
• Más seguro (más difícil de descompilar/truco)
• más eficiente y más fácil en el hardware

Si tiene la opción de un modo de lanzamiento, ¿por qué no usarlo? Siempre tendrá la versión de depuración para el desarrollo, o si algo sale mal, y siempre puede empaquetar la aplicación creada con Debug y/o el código fuente con su versión editada.

Además, también puede tener la opción de crear la aplicación para ciertas plataformas. La compilación utilizando el modo de lanzamiento racionalizará la aplicación para dicha plataforma, lo que la hace mucho más estable.

Incluso si la velocidad no es un problema, no hay ninguna razón para no utilizar el modo de liberación al compilar.

Answer 9

Creo que es importante seguir buenos estándares, prácticas y procedimientos. Solo porque la aplicación solo se use internamente no es una buena razón para permitirse ser flojo. Aunque tengo fuertes sentimientos acerca de la "forma correcta" de hacer las cosas, creo que los hábitos de escribir un buen software superan los beneficios, a largo plazo, de hacer trampas mediante el uso de una versión de depuración. Agregue un manejo de excepciones, conozca las trampas de los sistemas contra los que está codificando: hará que todo el código que escriba sea mejor.

Answer 10

información adicional de depuración hace que el mantenimiento futuro sea un poco más fácil.

Depende de lo que quiere decir con "información de depuración adicional".

Si se refiere a los mensajes de depuración, es probable que debe utilizar Trace, no Debug, y el uso de interruptores de rastreo y localizar los oyentes definidos en el archivo de configuración para controlar el comportamiento de conexión en tiempo de ejecución.

Si quiere decir conocer el nombre del miembro y el número de línea cuando hay una excepción, no necesita distribuir compilaciones de depuración para obtener esa información; simplemente distribuya los archivos .pdb con su ejecutable. La clase Exception utiliza información del archivo .pdb, independientemente de si ha establecido o no constantes de compilación.

Answer 11

Recuerdo vagamente que si toma los binarios compilados en Debug en una computadora que no tiene instaladas las bibliotecas de tiempo de ejecución de C (lo que generalmente significa que no tiene un IDE, la mayoría de los usuarios entran en esta categoría), saldrá con un mensaje de error. No sé si eso es específico de Windows y/o C++. También puedo estar recordando mal ... pero ciertamente debes verificar si esto sucede, como si tuviera razón sería una razón importante para compilar en modo de lanzamiento.

Answer 12

Mi árbol de decisión es la siguiente:

es el programa escrito en Java?

Sí - Entonces la liberación en modo de depuración está bien. El JIT se ocupará de las optimizaciones

En caso contrario, ¿el programa CPU es intensivo?

No - Release en modo de depuración está bien.

Sí - A continuación, compile solo el punto caliente en modo de lanzamiento.

Justificación subyacente: es mucho más fácil mantener el código cuando los informes de errores se generan desde el programa exacto como el que está ejecutando en su IDE. En el IDE, utiliza una versión de depuración, por lo que debe esforzarse por liberarla en el modo de depuración.

Answer 13

No tengo ninguna objeción personal al envío interno de la compilación Debug, siempre que funcione (algunas versiones de depuración no funcionarán en máquinas no dev sin instalar también las bibliotecas de depuración correspondientes ... se encontró con eso cuando programé el código C++/MFC).

Un enfoque un poco más sofisticado es utilizar un servidor de símbolos , uno que se actualiza automáticamente con los símbolos por su proceso de compilación.

Si estaba depurando un problema de la máquina de un cliente, apunte el depurador ligero a su servidor de símbolos (asegúrese de que las versiones coinciden), y luego iniciar la depuración.

Answer 14

Utilice el modo de lanzamiento, pero compile con toda la información de depuración habilitada e implemente los archivos pdb con los archivos ejecutables. Puede depurar los archivos binarios de la versión de la misma manera que los de depuración: no hay diferencia, solo tiene que generar los archivos pdb al compilar.

Liberar y ejecutar la compilación de depuración puede ser peligroso porque oculta erros en el código que solo aparecerán en el modo de lanzamiento.

Answer 15

que tienen principalmente dos problemas con la liberación de depuración:

1. información de depuración podría ser un cheque de seguro grande e innecesario para el mantenimiento futuro que puede ser evitado por otros medios.
2. Diagnostics es un aspecto de su aplicación que no debería tener relación o dependencia de la configuración de generación que se está construyendo

Creo que es importante diseñar y mantener la instrumentación de diagnóstico y la lógica en su aplicación como un aspecto o una preocupación transversal. Si confía demasiado en la información proporcionada por la versión de depuración de su código:

• Pueden garantizar que será la versión de depuración que se dará a conocer cada vez que una nueva versión de su aplicación se libera? documentación deficiente, alguien más que lo hace, etc.
• Las aplicaciones tienen una tendencia a crecer en funcionalidad y complejidad. Mientras que el rendimiento y el tamaño de su aplicación debido a la versión de depuración pueden no ser un problema en este momento. Las cosas pueden sumarse y dar lugar a posibles problemas. En caso de problemas de rendimiento, ni siquiera puede atribuirlos a la versión de depuración.

Aún puede recopilar información valiosa en la versión de lanzamiento. El rastreo de pila aún debería estar disponible en caso de excepciones. Es posible que no vea el archivo de origen y los números de línea, pero aún puede ver qué métodos se llaman. Sin embargo, aún debe producir y mantener símbolos de depuración para su versión de lanzamiento. Estos símbolos le permitirán depurar su versión de lanzamiento (incluso puede configurar un servidor de símbolos). Debido a la optimización del código, la información de depuración probablemente no coincidirá con el 100% del código, p. información de depuración que se refiere a una declaración que está optimizada, etc., pero aún debería poder depurar la mayor parte de ella de manera correcta. Para otra información, como datos de entrada de usuario, datos intermedios, código de base de datos ejecutada, etc., la liberación de depuración no le ayudará de todos modos, ya que no captura esa información. Usted necesita mantener un registro de esos por su cuenta.

Si está utilizando .NET, puede echar un vistazo a Tracing and Instrumentation. También puede considerar usar un marco existente como Microsoft Enterprise Library o log4net. Si es a.Aplicación NET, también puede solicitar el compilador JIT para generar información de seguimiento para la versión de lanzamiento de su aplicación como una opción. Consulte this MSDN article.

Answer 16

¿Está liberando el software? (Esta es una pregunta "Sí", "No", "Sí, pero ..." no cuenta)

Si es así, ¿por qué no hacerlo correctamente y convertirlo en un lanzamiento real para que no lo haga? tiene que confiar en que los símbolos de depuración estén disponibles para sus usuarios ...

Answer 17

Esto es lo que suelo hacer con software que necesita tener presente información de depuración (generalmente herramientas de tipo de desarrollo) - compilo mi código optimizado, pero con información de símbolos y enlace de manera que conserve la información del símbolo. De esta forma, cuando el software se cuelga, al menos puedo obtener una stacktrace a la mitad decente y una idea de dónde comenzar a poner información de registro adicional para cuando envíe al cliente una compilación de depuración completa.

A veces el optimizador causa errores, a veces los oscurece, pero al menos tiene la capacidad de reducir su problema. Esto me ha funcionado en entornos de blackbox como Raytheon, donde era imposible obtener un volcado de memoria, y el seguimiento de la pila se enviaba por fax con un gran marcador negro por todas partes.

Answer 18

Aparte de la ya mencionada rendimiento, tamaño y descompilación ...

de seguridad: versiones de depuración y la información de depuración (por ejemplo, archivos PDB) contienen gran cantidad de información sobre el código fuente que no sólo hace mucho descompilación más fácil, pero también puede permitir que los usuarios conozcan detalles internos, como nombres de archivos y rutas de red. Muchas empresas pueden considerar que esta información es muy sensible.

Answer 19

liberación dos versiones, una etiqueta si aparecen errores utilizar este ..

Pero dependiendo de los datos sensibles bloquean la versión de depuración de distancia.

Answer 20

Personalmente, creo en una solución mediana entre la depuración y la versión, es decir, usted registra lo suficiente para que pueda reproducir el error si ocurre. Cuando su aplicación sea lo suficientemente estable, apague su registro adicional picante con un parámetro en su archivo de configuración. Sin embargo, me doy cuenta de que no se puede hacer todo el tiempo. Muy a menudo cuando tienes tu aplicación ejecutándose en un solo lugar.

Además, una regla de oro que he tratado de implementar en mi lugar de trabajo (y aún no lo he logrado del todo): nunca DEJES que se muestre tu código. Si el usuario es conocedor de la tecnología, él sabrá lo que está pasando y lo mal que piense. Si tu usuario no lo está, él pensará que su computadora está poseída por el demonio, y piensa mal de ti.