TiLP2 Crash dans la réception des fichiers - Page 5

Folco (./118) :
J'ai un fichier texte de ~ 7 ko sur la calc, TiLP crash quand j'essaye de le transférer :

[Thread debugging using libthread_db enabled]
[New Thread 0xb5fda6c0 (LWP 3097)]
[KCrash handler]
#6  0xb7f8d424 in __kernel_vsyscall ()
#7  0xb62e7640 in raise () from /lib/i686/cmov/libc.so.6
#8  0xb62e9018 in abort () from /lib/i686/cmov/libc.so.6
#9  0xb632434d in ?? () from /lib/i686/cmov/libc.so.6
#10 0x0000000c in ?? ()
#11 0xbfaa6e90 in ?? ()
#12 0x00000400 in ?? ()
#13 0x00000000 in ?? ()

PedroM fait une erreur "reset".

L'erreur du crash de Tilp vient que ti89_recv_XDP ne vérifie pas les débordements de buffer (ce qu'il recoit vs ce qu'il attend).

Sinon j'expliques:
Martial a fait un "log" STO system\log
qui demande à PedroM de logguer tout ce qui se passe dans le link.
Il a fait un listing de fichiers. Le fichier fait environ 700 octets.
Là il veut le récupérer. Lors de la requète que PedroM envoie sur la taille à tilp du fichier
on a une taille de 1000, puis lors des données, on a 1200.
tilp n'avait alloué qu'un buffer de 1000, d'où débordement et crash (nombres donnés de tête).

En fait, le simple fait de transférer le fichier log, fait que le fichier log est lui même modifié pendant le transfert (car PedroM loggue son transfert) : donc sa taille augmente lorsqu'on veut le transférer. tilp n'est pas robuste et aurait du renvoyer une erreur à l'utilisateur dans ce cas là.

Martial: désactive le link log avant de transférer ce fichier

PpHd (./121) :
En fait, le simple fait de transférer le fichier log, fait que le fichier log est lui même modifié pendant le transfert (car PedroM loggue son transfert) : donc sa taille augmente lorsqu'on veut le transférer.

J'ai fini par comprendre ça ya 5 minutes, mais ça explique pas pourquoi j'arrive pas à transférer stdlib avec le log activé ... (ok je mélange un peu, on parle alors de timeout, plus de crash)

Folco (./122) :

PpHd (./121) :
En fait, le simple fait de transférer le fichier log, fait que le fichier log est lui même modifié pendant le transfert (car PedroM loggue son transfert) : donc sa taille augmente lorsqu'on veut le transférer.

J'ai fini par comprendre ça ya 5 minutes, mais ça explique pas pourquoi j'arrive pas à transférer stdlib avec le log activé ... (ok je mélange un peu, on parle alors de timeout, plus de crash)

Le fichier de log atteint alors 64K je crois... Et après je ne sais pas ce qui se passe.

Nouveau bug de tilp: Si on fait "Création de nouveau dossier" avant d'avoir "obtention du listing de la calculatrice". Pouf tilp. Sef fault:

TiLP2 - Version 1.13, (C) 1999-2008 Romain Lievin
THIS PROGRAM COMES WITH ABSOLUTELY NO WARRANTY
PLEASE READ THE DOCUMENTATION FOR DETAILS
built on Sep 14 2009 17:41:39
tilp-INFO: setlocale: fr_FR.UTF-8
tilp-INFO: bindtextdomain: /home/pphd/Apps/tilp/share/locale/
tilp-INFO: textdomain: tilp2
ticables-INFO: ticables library version 1.3.0
ticables-INFO: setlocale: fr_FR.UTF-8
ticables-INFO: bindtextdomain: /home/pphd/Apps/tilp/share/locale
ticables-INFO: textdomain: libticables2
ticables-INFO: kernel: 2.6.30-1-amd64
tifiles-INFO: tifiles library version 1.1.2
tifiles-INFO: setlocale: fr_FR.UTF-8
tifiles-INFO: bindtextdomain: /home/pphd/Apps/tilp/share/locale
tifiles-INFO: textdomain: libtifiles2
ticalcs-INFO: ticalcs library version 1.1.3
ticalcs-INFO: setlocale: fr_FR.UTF-8
ticalcs-INFO: bindtextdomain: /home/pphd/Apps/tilp/share/locale
ticalcs-INFO: textdomain: libticalcs2
ticalcs-INFO: Vérification du status:
ticalcs-INFO:  PC->TI: RDY?
ticalcs-INFO:  TI->PC: ACK
ticalcs-INFO: Création du dossier 'system':
ticalcs-INFO:  PC->TI: RTS (size=0x00000010=16, id=00, name=system\a1234567)
ticalcs-INFO:  TI->PC: ACK
ticalcs-INFO:  TI->PC: CTS
ticalcs-INFO:  PC->TI: ACK
ticalcs-INFO:  PC->TI: XDP (0x0010 = 16)
ticalcs-INFO:  TI->PC: ACK
ticalcs-INFO:  PC->TI: EOT
ticalcs-INFO:  TI->PC: ACK
ticalcs-INFO:  PC->TI: DEL (size=0x00000000=0, id=00, name=system\a1234567)
ticalcs-INFO:  TI->PC: ACK
ticalcs-INFO:  TI->PC: ACK
Erreur de segmentation

A mon avis, ca ne doit pas être très dur de trouver où ca plante... Un tableau contenant la liste des dossiers non initialisés mais pourtant utilisé

(t'inquiète pas, Lionel m'a confié qu'il était en vacances )

Bah, si j'essaie de reproduire ça avec ma TI-89 HW1 AMS 2.05 et tilp2-1.11-1.i386 sous Fedora 10, j'ai:

Msg: timeout occured while reading to the device.
Cause: check that link cable is plugged and/or the calculator is ready. System: Die Ressource ist zur Zeit nicht verfügbar (errno = 11)

et pas de plantage (mais la variable bidon a1234567 reste dans le dossier). On dirait que c'est un autre bogue: si j'essaie de supprimer une variable dans l'interface, il me dit qu'il faut AMS 2.09 minimum, donc cette méthode pour créer un dossier nécessite aussi AMS >= 2.09, l'option ne devrait pas être présente avec AMS 2.05.

Oui, il faut que la suppression se passe bien pour avoir le plantage. Si la calc ne supporte pas la suppression de fichier, rien ne se passe. (PedroM supporte la suppression de fichiers).

Comment fait-on pour détecter de manière portable (AMS et PedroM) le support de la suppression de fichiers ?

Vu pour les divers bug reports.

Lionel Debroux (./128) :
Comment fait-on pour détecter de manière portable (AMS et PedroM) le support de la suppression de fichiers ?

Je ne sais pas. Envoyer la commande et regarder si on se prend un time out ?

Ca pourrait être une solution... mais question suivante: est-ce qu'on peut envoyer avec succès une commande de suppression pour un fichier de nom invalide (qui ne passe pas la validation de path), et recevoir un timeout si la commande n'est pas supportée, ou une erreur si la commande est supportée ?

Je vais voir s'il ne vaudrait pas mieux que j'envoie comme OS 2.09 à la commande version pour PedroM, et ajouter la dernière commande non supportée (set/get clock)...