Qué va en un Informe de Problema

• Recomendaciones generales
• Cuando se informa de un Kernel Panic

Una base de datos solo es buena si la información que contiene lo es también. En general, el sentido común (suponiendo que dicho animal existe) marca el tipo de información que sería más util cuando se intenta seguir y se busca una solución al problema.

Recomendaciones generales

• Incluya cualquier cosa que usted querría saber si usted tuviese que analizar el informe en el otro lado. No es necesario incluir todo tipo de detalles acerca del entorno, aunque cualquier cosa que pudiera ser diferente del entorno de cualquier otro usuario debería ser includia (su PATH, por ejemplo).
• Los relatos son normalmente útiles, dándoles un cierto grado de limitación. Si una persona responsable del bug puede ver que A se ejecutó, luego B y luego C, sabiendo esta secuéncia será más sencillo buscar una solución ya que el entorno puede cambiar dependiendo de su orden. Otra vez, se limita siempre al orden ("Dejé la compilación en funcionamiento, me fuí a tomar un café (Colombiano, sin azúcar), hablé con Sheila por teléfono, y luego ESTO sucedió...") pero asegúrese de incluir cualquier cosa importante.
• Richard Stallman dice:

  El principio fundamental del reporte de bugs es simplemente: informar de todos los hechos. Si no está seguro de si decir una cosa o no, ¡dígala!

  Esto se mantiene verdadero en cualquier sistema de informe de problemas, para software o injusticia social o mantenimiento de las motocicletas. Es especialmente importante en el campo del software debido a las diferencias que pueden causar las grandes diferencias, aunque parezcan insignificantes (una variable cambiada, un punto y coma inexistente, etc.).
• Envie solo un problema en cada informe. Si tiene varios problemas, use múltiples PRs. Esto permite seguir cada problema independientemente y además permite analizar los problemas asociados a un único programa.
• Nunca está de mas investigar un poco para buscar si el problema que ha encontrado ya ha sido reportado. Muchas versiones del software se distribuyen con listas de bugs conocidos en las notas de la versión. Además, siempre es una buena idea buscar en la base de datos de problemas de NetBSD para ver si alguien ya ha reportado el problema que tiene (¿quién sabe? talvez ya haya una solución en la base de datos).
• Cuanto más se acerce el PR al formato estándar, se necesita menos intervención por el administrador de la base de datos para dirigir la información a buen puerto. Recuerde que cualquier cosa que necesite intervención humana tambien necesita tiempo que se puede gastar mejor reparando problemas. Así pues es mejor para todos que la información contenida en un PR sea lo más correcta posible (en formato y contenido) a la hora del envío. Vea la descripción de los campos que puden ir en un informe de problema para más detalles.

Cuando se informa de un Kernel Panic

Así que el kernel ha soltado un panic, le dio un montón de numeros hexadecimales y se paró. Es importante informar de este suceso, ya que el sistema operativo no debería nunca producir ningun panic, a menos que el hardware del ordenador falle (normalmente el sistema operativo no puede hacer nada para solucionar problemas del hardware). Esto nos lleva a que la causa de los panic's puedan ser bugs en el kernel y necesitamos seguir y reparar dichos bugs para hacer de NetBSD un sistema más estable y robusto que ahora.

El problema estriba en que el volcado de la pila que el kernel imprimió es específico a su kernel, y los numeros mostrados deber ser re-convertidos otra vez en referencias a la tabla de símbolos de modo que otra persona que no tiene su kernel pueda conseguir imagiarse por qué falló.

Como mínimo, anote los números del "PC" y conviertalos a referéncias simbólicas - esto es, el Program Counter (Contador de programa) para el ordenador; donde estaba ejecutando. Idealmente, si pudiese copiar y pegar todos los datos sería lo mejor.

Cuando el kernel le dé algo así (normalmente muchas líneas):

El número del PC es específico al kernel que estaba ejecutando y no es posible que sea igual al kernel de cualquier otro, así que tiene que ser convertido en una referencia a la tabla de símbolos. Para convertir un número hexadecimal a una referencia, utilize gdb(1), del modo siguiente:

	gdb -k /netbsd
	x 0xf80ff430

	0xf80ff430 <cpu_reboot+196>:     0x40000093

El resultado "<cpureboot+196>" que devulete gdb(1) es lo que la gente que mire a su problema va a necesitar, de modo que póngalo (preferentemente junto a la línea "args") en su informe de problema.

Consulte el informe de problema #3765 para ver un ejempo exhaustivo de un panic del kernel.

Página principal