TiEmu : crash sous Fedora 8 ? - Page 1

Quelle version de tiemu ?

Clairement un bogue quelque part. Si tu lances TiEmu à partir d'une console, y'a-t-il un message? Parce que normalement g_assert_warning devrait en afficher un.

Cet assert a été rajouté ici:
http://svn.gnome.org/viewvc/glib/tags/GLIB_2_14_3/glib/gmain.c?r1=5139&r2=5407
à l'intérieur d'un patch visant à améliorer les performances:
http://bugzilla.gnome.org/show_bug.cgi?id=416094

Je dois regarder si c'est l'assert qui est foireux ou si TiEmu fait quelque chose d'incorrect.

J'ai une idée de ce que pourrait être le problème (mon utilisation abusive de longjmp pour quitter un gtk_main dans sim_exception au lieu de gtk_main_quit), je vais essayer de réécrire ça sans le longjmp et je te filerai un RPM pour que tu testes si ça marche mieux.

Peux-tu vérifier que le RPM suivant corrige ton plantage s'il te plaît?
[supprimé, le RPM se trouve régulièrement dans le dépôt Fedora sur CalcForge maintenant]

Attention, il se pourrait que TiEmu plante toujours avec une assertion comme celle que tu as rencontrée quand tu quittes TiEmu et/ou quand tu changes la ROM émulée (après en avoir déjà chargé une). (Est-ce le cas?) C'est le même problème que celui que je viens de corriger, mais il est plus difficile à corriger à cet endroit, donc je veux d'abord savoir si le correctif a fonctionné avant de me plonger là-dessus.

EDIT (05:42): J'ai corrigé aussi le problème d'offset d'infos de débogage pour les programmes kernel maintenant.

Joey Adams a aussi reporté que changer la ROM et quitter fonctionne sans planter, donc a priori c'est bon. Bizarre parce qu'il y a là aussi un longjmp abusif, je vais le corriger un de ces jours, mais si ça ne plante pas sous F8, ça ne presse pas.

Je vais lancer la compilation de la version 64 bits, ça va me prendre toute la nuit de toute façon (QEMU rame... il me faut vraiment une vraie machine 64 bits).

tiemu3-3.01-2 qui corrige ce problème est disponible dans le dépôt maintenant.

Le backtrace est déjà complet, donc tu n'as pas besoin de debuginfo supplémentaire normalement. C'est la libération de pclog_buf qui plante. Ce n'est pas encore corrigé. Je pense savoir d'où vient le bogue:
logger.pclog_buf[logger.pclog_ptr++ % logger.pclog_size] = m68k_getpc();
et logger.pclog_ptr est un int n'est jamais remis à 0, du coup quand on a exécuté 2^31 instructions (ce qui se passe en quelques minutes), ça devient négatif et donc le modulo aussi, boum!

La bonne solution est de ne pas utiliser un modulo, mais:
logger.pclog_buf[logger.pclog_ptr++] = m68k_getpc();
if (logger.pclog_ptr >= logger.pclog_size) logger.pclog_ptr=0;

Je vais corriger ça.

Ok, vu.