LOS CODE DUMPS SIRVEN

Archivado
Veo que mucha gente por aquí habla de que si tal app da un CODE DUMP, etc... y luego no veo pantallazos. Esas pantallas sí sirven para que encontremos el fallo (por lo menos a los devs que sepan usarlas). En concreto, la sección que tiene esta pinta es de lo más util, ya que nos da la cadena de llamadas de función que lleva al error (backtrace):
12345678 -> 9abcdef0 -> 12345678 -> ....

Además, las últimas líneas de la sección anterior (DAR, etc) también sirven, y también la primera línea (tipo de excepción). Esa sección entera es útil para ver que posibles datos han causado el error, una vez tengamos el backtrace.
Y la sección de GPRs (o por lo menos parte de ella, pero eso depende) es útil una vez sepamos donde han ocurrido los errores, para saber que datos los han causado.

Resumiendo, que si quieres que los fallos se arreglen, lo mejor que puedes hacer es cojer los datos/archivos que causen el error y/o una foto del pantallazo de error (preferiblemente las dos cosas, por si cualquiera de las dos no sirve) y mandárselo al desarrollador. Si no tienes cámara, como mínimo es indudablemente valioso que transcribas manualmente los primeros (4 o 5 por lo menos) elementos del backtrace (a -> b -> c...), el tipo de excepción (DSI, ISI, etc) y el valor DAR. Lo mejor es postear estos errores en el lugar adecuado para que les llegue a los devs. Por ejemplo, en el caso del Canal Homebrew, me los puedes enviar a mi e-mail (marcan@marcansoft.com) o al tema oficial del canal (no puedo garantizar que si los pones aquí los veré, y devs no españoles dudo que conozcan EOL).

Gracias a un pantallazo reciente, por ejemplo, hemos encontrado un fallo que causa CODE DUMPs cuando hay mas varias aplicaciones que no tienen un meta.xml o no lo tienen completo y resultan estar en cierto orden físico, según las circunstancias (esto no estaba en beta7 porque el fallo es en el código de ordenar las apps).

Saludos y gracias de antemano. A ver si entre todos mejoramos las apps de Wii ;)
Oks, pues ya sabemos lo que hacer.
y en el caso de ser uno de los devs, como podemos aprender a interpretarlos? Es que vi el tutorial ese que hay en wiibrew pero solo es para c++, para C no hay nada?
Lo que pasa es que si no sabes ensamblador no puedes aprobechar esa información. Si tu haces un juego y te da este fallo, en el caso de la mayor parte de los desarrolladores, simplemente intentarás modificar el programa a ver si se arregla sin saber muy bien que haces. En el caso de que el homebrew channel de fallos, pues se puede enviar la información, ya que vosotros si sabeis usarla.

Un saludo.
Incluso sin saber ensamblador, por el nombre de las funciones, sacas rápidamente donde esta el problema.

Yo uso:
powerpc-gekko-objdump -d boot.elf

y luego busco en el código las direcciones del backtrace. Sí, es ensamblador, pero si lees los nombres de las llamadas de función y buscas la etiqueta de función un poco mas arriba de donde esta el problema, no hay ni que leer el asm - rápidamente encontrarás, por lo menos, en que función y en que parte de ella está el problema. Otra opción es usar gdb:
powerpc-gekko-gdb boot.elf
(gdb) info symbol 0x89ABCDEF

y directamente te saca la función donde está el problema.

Además, si has compilado el programa con símbolos de debug (-g), puedes usar powerpc-gekko-addr2line y te da el fuente y además la línea de código que falla.
No sabía que hubiera formas para hacer eso relativamente facil, jeje.
Realmente si ayuda saber ensamblador en mi caso no es problema, sé algo de ensamblador en x86 y en PICs como los que usan los drivechips de Wii, no será muy distinto.
Gracias por la información, seguro que me será útil.
Vamos a ver, ahora si que no lo entiendo. Hay aplicaciones que me dan code dump unas veces si y otras no, es decir, uso una aplicacion (que siempre hace exactamente lo mismo, no depende del usuario en ningun sentido) y me da code dump, reinicio, vuelvo a cargar la aplicacion y no lo da xD, y si fuese una vez pase, pero es que no es la primera vez. Ahora estoy pensando: ¿puede tener algo que ver con que la ultima aplicacion ejecutada no limpiase adecuadamente toda la memoria que usó?
technik escribió:Vamos a ver, ahora si que no lo entiendo. Hay aplicaciones que me dan code dump unas veces si y otras no, es decir, uso una aplicacion (que siempre hace exactamente lo mismo, no depende del usuario en ningun sentido) y me da code dump, reinicio, vuelvo a cargar la aplicacion y no lo da xD, y si fuese una vez pase, pero es que no es la primera vez. Ahora estoy pensando: ¿puede tener algo que ver con que la ultima aplicacion ejecutada no limpiase adecuadamente toda la memoria que usó?


es posible que sea que haya algo residente en memoria y se pise?
marcan: ¿Hay alguna posibilidad, aunque sea remota, de que el problema que comenta technik se deba al uso del HBC?

technik: ¿Has probado a cargar esas aplicaciones problemáticas desde el Twilight Hack?
Pues en eso no habia caido, la verdad. Si tengo tiempo luego lo probare (Ahora mismo la wii esta ocupada por mis hermanos xD)
Pero la verdad es que veo razonable que el fallo sea de la ultima aplicacion usada antes, que deje cierta memoria sin liberar y la aplicacion nueva la pise o algo asi. Como estoy en continuo desarrollo siempre es probable que la ultima pruaba hecha tenga fallos en la reserva de memoria y su limpieza, por tanto si la ejecuto despues de un code dump (y su consiguiente apagado de consola y por tanto limieza de memoria volatil) la memoria estara limpia y el nuevo programa no pisara nada. Creeis que puede ser por eso?
technik escribió:Pues en eso no habia caido, la verdad. Si tengo tiempo luego lo probare (Ahora mismo la wii esta ocupada por mis hermanos xD)
Pero la verdad es que veo razonable que el fallo sea de la ultima aplicacion usada antes, que deje cierta memoria sin liberar y la aplicacion nueva la pise o algo asi. Como estoy en continuo desarrollo siempre es probable que la ultima pruaba hecha tenga fallos en la reserva de memoria y su limpieza, por tanto si la ejecuto despues de un code dump (y su consiguiente apagado de consola y por tanto limieza de memoria volatil) la memoria estara limpia y el nuevo programa no pisara nada. Creeis que puede ser por eso?


A mi en la facultad, en C me insistieron bastante en la gestion optima de memoria y su liberación.

Suerte y saludos
technik escribió:Pues en eso no habia caido, la verdad. Si tengo tiempo luego lo probare (Ahora mismo la wii esta ocupada por mis hermanos xD) Pero la verdad es que veo razonable que el fallo sea de la ultima aplicacion usada antes, que deje cierta memoria sin liberar y la aplicacion nueva la pise o algo asi. Como estoy en continuo desarrollo siempre es probable que la ultima pruaba hecha tenga fallos en la reserva de memoria y su limpieza, por tanto si la ejecuto despues de un code dump (y su consiguiente apagado de consola y por tanto limieza de memoria volatil) la memoria estara limpia y el nuevo programa no pisara nada. Creeis que puede ser por eso?

hehe, yo también soy partidario de que incluyas un reset entre prueba y prueba [oki]
Lo de la memoria no tiene nada que ver. Al cargar una aplicación, se reinicializa el manejo de memoria y da absolutamente igual lo que esté liberado o no de la aplicación anterior.

Los problemas más comunes son:
1. La aplicación cargada no reinicializa los recursos que necesita ha usado la aplicación anterior. Así, si HBC deja algo configurado de forma distinta a los valores "por defecto", y la aplicación cargada asume los valores por defecto sin reconfigurarlos explícitamente, entonces va a fallar. Esto es culpa de la aplicación cargada, no de HBC, pero como HBC es, por ejemplo, bastante mas complejo que el Twilight Hack, es mas probable que ocurran este tipo de problemas, ya que HBC usa más recursos de la Wii y toca más cosas.
2. El cargador se deja algunos eventos de IOS abiertos, que saltan despues de la carga y peta todo porque son eventos "ajenos" que ya no son válidos. Para esto está el reset de IOS que hace libogc por defecto al iniciarse, pero es posible que salte algo justo durante la incialización de libogc causando estos problemas. En cualquier caso, esto es culpa de HBC, que debería cerrar todo (y, que nosotros sepamos, lo hacemos, pero siempre se nos puede escapar algo). Son fáciles de identificar porque salen direcciones 0x8133xxxx y superiores en la zona del backtrace (0x8133xxxx y superiores corresponden al cargador).

Por cierto, se puede volver al cargador después de un CODE DUMP sin reiniciar, pulsando Z en el primer mando de GC. Pero esto sólo funciona si los pads han sido inicializados por la aplicación, y si el sistema no se ha ido totalmente al garate (si todavía sobrevive el stub cargador).
Marcan, pues al final resulta que si son útiles los code dumps. [sonrisa]

Todavía no he hecho nada en Wii, pero me ha dado por hacer lo del test de excepciones en DS y probar el arm-eabi-addr2line.exe y es alucinante, jeje. Muchas gracias por estos consejos, por fin sabré por que se cuelga mi juego cuando le da la gana...

Un saludo. :)
13 respuestas
Archivado
Volver a Scene