Connexion avec TiEmu - Page 9

Relâchez alt avant de faire alt-tab

Désolé, mais le backtrace du post ./244 est inutilisable, étant donné que 1. il n'y a pas d'informations de débogage, 2. le backtrace s'arrête à l'intérieur de GTK+/glib et 3. tu ne sais plus comment tu l'as eu.

Quant au plantage dans exec_build_section_table, je suis déjà au courant que ça se passe parfois, j'ai même pris un backtrace avec infos de débogage une fois, ça m'a donné exactement la ligne du plantage, mais ça n'a quand-même pas expliqué pourquoi ça plante. Le workaround est de redémarrer TiEmu entre 2 sessions de débogage, le plantage ne se produit que quand on envoit le deuxième programme (ou la deuxième version du même programme) à déboguer (et pas avec tous les programmes non plus, ça dépend du contenu du programme).

Oui, envoie-le, ça peut peut-être servir.

Bah, tu peux installer ktigcc-debuginfo et mettre des breakpoints avec GDB. Mais ça risque de changer le timing et donc de faire magiquement disparaître le problème.
Sinon il faut que je compile une version spéciale de KTIGCC avec des messages de débogage sur la console. Il n'y a rien du tout prévu pour logguer parce que c'est censé toujours marcher.

Kevin Kofler (./249) :
Il n'y a rien du tout prévu pour logguer parce que c'est censé toujours marcher.

Je peux te compiler une version avec des logs rajoutés, avec laquelle tu peux remplacer ton /usr/bin/ktigcc. (Tu peux d'ailleurs faire ça toi-même aussi, la source est disponible. )

Sinon, comme déjà dit, la manière prévue de déboguer, c'est de prendre ktigcc-debuginfo et GDB.

Quant au plantage du ./243, en fait ce n'est pas celui auquel je pensais, mais c'est qu'il voulait déboguer un exécutable sans infos de débogage. Évidemment, il devrait y avoir un message d'erreur plus agréable que KCrash , mais c'est quand-même un truc à ne pas faire.

Oh génial, on plante en plein dans du Tcl...
Est-ce reproduisible? Parce qu'il faudra probablement travailler avec un débogueur Tcl (tcldebugger) là, le backtrace ne me dit pas grand chose.
Le problème principal avec les plantages dans Insight, c'est qu'ils sont souvent assez aléatoires.

Non, il faut lancer TiEmu explicitement dedans pour que tcldebugger soit utile (cf. http://svn.tilp.info/cgi-bin/viewcvs.cgi/tiemu/trunk/docs/Debugging_TiEmu.txt?rev=2337&root=tiemu&view=markup), donc pour les bogues aléatoires comme celui-ci, ça ne va pas servir à grand chose.
(C'est tclpro qui a l'exécutable prodebug qu'il faut d'ailleurs, tcldebugger est utilisé en interne par prodebug.)

Je viens de penser à une feature qui m'aiderait peut-être à debugger un problème avec un programme, qui ne se manifeste que quand -freg-relative-a5 est activé (cause inconnue, peut-être une fonction qui détruit a5 et ne le restaure pas ?): un nouveau type de breakpoints, qui se déclenche quand un registre change de valeur.
Bon, je ne vais pas mourir si cette feature n'est pas implémentée, surtout que ce type de feature s'utilise très rarement...

Martial Demolins (./260) :
Existe-t-il un moyen d'envoyer un fichier à TiEmu en ligne de commande?

via TILP, non ?

> t'installes un handler sur le vecteur trace, qui vérifie a5 et qui te fait un bra . quand il change
Ah ouais... il y a de l'idée
Merci, je vais essayer ça.

squale92 (./263) :

Martial Demolins (./260) :
Existe-t-il un moyen d'envoyer un fichier à TiEmu en ligne de commande?

via TILP, non ?

Oui, il suffit de lui passer en paramètre.

Ah je sais pas, je développe sous Windows.

à tout hasard, est-ce qu'il ne faut pas autoriser le cable virtuel (ou dans le genre dans TIEmu - je n'ai ni tilp ni tiemu sous la main sur ce PC) dans TIEmu ?