Has enviado, obtienes una falla seg rara. ¿Comprobación del puntero o dejarlo ir?

9

Ha enviado, las afirmaciones están desactivadas, recibe un informe de bloqueo raro que indica que se produjo una violación de puntero nulo en su código. En un entorno de desarrollo, el problema habría sido atrapado por una afirmación.

Todo lo que tiene es un informe de bloqueo, por lo que reproducir el problema es casi imposible. Seguir la traza inversa no da ninguna pista de por qué ocurrió el accidente en primer lugar.

Opciones: - Agregar comprobación de puntero para evitar el bloqueo. Esto evitará el bloqueo, pero probablemente ni siquiera descubrirá por qué sucedió en primer lugar. - déjalo volar, espero que vuelva a suceder con un escenario de repro

Digamos que la aplicación no está diseñada para un misil guiado o un sistema de frenado automático ...

¿Cuál escogerías?

bug pointers

— MM01
fuente

A menos que esto sea retórico, puede ser útil publicar el informe de bloqueo junto con los archivos de código correspondientes (tal vez en Pastebin.com) en el sitio de Stack Overflow si desea que esto se resuelva ...

— Tamara Wijsman

2

@TomWij: No lo creo ... lo más probable es que se cierre como "demasiado localizado"

— Naveen

@Naveen: Tal vez ... no soy un visitante habitual de SO, así que este fue un comentario de SU-mind.

— Tamara Wijsman

1

@Naveen: Demasiado localizado significa demasiado regional, se trata de geografía y no de especialización del tema. Pero esta pregunta probablemente se cerraría en SO por subjetividad.

— Maniero

7

Elegí el segundo enfoque. No tiene sentido ocultar el bloqueo si el puntero NULL fue inesperado en el punto donde se produjo el bloqueo. Este puntero NULL en la mayoría de los casos sería solo uno de los síntomas de que algo más está mal. Si lo ocultamos con un puntero NULL, es casi seguro que algo más se romperá. Siento que tienes una mejor oportunidad de atrapar el escenario si conoces el punto donde se bloquea cada vez en algún lugar al azar.

— Naveen
fuente

1

Me estoy inclinando hacia esta opinión yo mismo. La percepción del usuario es lo que me preocupa. Un choque claramente parece que algo salió mal. Sin embargo, si una función obtiene un cálculo completamente incorrecto, esto también se notará.

— MM01

2

En mi opinión, aunque el usuario puede irritarse por el accidente ocasional, se molestará mucho si proporciona un resultado incorrecto, ya que podría pasar desapercibido.

— Naveen

bloquearse lo antes posible, lo ayuda a encontrar el problema y ayuda al usuario a perder menos datos

— Spudd86

también usaría valgrind para averiguar qué estoy haciendo mal (o al menos lo intentaría, en cualquier caso, podría encontrar algunos problemas que debería solucionar) Agregaría afirmaciones adicionales para intentar atrapar el puntero NULL antes y solicite al usuario que intente ejecutar una compilación que tenga activadas las

— afirmaciones

3

¿Con qué frecuencia ocurre el choque? ¿Sucede solo para uno de muchos clientes en algún caso oscuro? ¿Cuáles son las consecuencias (pérdida de datos, bloqueo del sistema)? Si ocurre cada 1 en un millón de casos y solo tienen que reiniciar la aplicación y no se pierden datos, entonces probablemente no necesite arreglarlo, déjelo así.
¿Qué tan costoso (dinero y tiempo) es agregar las afirmaciones y enviarlas a todos los clientes (si solo una parte de los clientes obtiene la nueva versión, el resto podría entrar en el problema nulo no verificado)? ¿Cuáles son las posibilidades de encontrar el problema? Si solo pone controles aleatorios en el código con la esperanza de detectar el error, entonces es una mala práctica ...
¿Se puede reproducir el problema en la máquina del cliente? ¿Puedes acceder a esa máquina? Esto puede ser realmente valioso
Revise sus informes de fallas y asegúrese de que la información provista sea útil y pueda ayudarlo a diagnosticar el problema

— Victor Hurdugaci
fuente

2

_{En un entorno de desarrollo, el problema habría sido atrapado por una afirmación.}

_{En un orden específico, se habría detectado y reparado, pero la traza actual nunca se ha detectado.

Debería poder ver qué salió mal con el volcado de memoria, ¿ha verificado los parámetros, etc.?}

Los extras que se pueden hacer en función de la cantidad de tiempo que desea dedicar a esto:

Archive el volcado de memoria y refiérase a él en el código con un comentario en la línea que bloqueó,
esto permite que uno que examina un volcado de descarga muy similar sepa que ha sucedido antes ...
[tiempo empleado: corto]
Verificaciones adicionales, registro, ... Desea evitarlo y obtener más información la próxima vez.
[tiempo empleado: medio]

Se produjo una infracción de puntero nulo en su código.
Compruebe que es imposible llamar a la aplicación de tal manera para que ocurra esta violación.
[tiempo empleado: largo]

— Tamara Wijsman
fuente

1

Esta publicación no se trata tanto del enfoque para resolver el problema, sino más bien del curso de acción en una situación hipotética (es decir, en el marco de tiempo asignado, no se pudo deducir la fuente del problema).

— MM01

2

En estos días, envío con afirmar () activado. No cuesta mucho y puede hacer la vida mucho más fácil en situaciones hostiles (es decir, los entornos de sus clientes a menudo son más hostiles que sus entornos de desarrollo o control de calidad).

— Mitch Haile
fuente