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

yop, du boulot pour Lionel et Kevin ^^ (mais pas de troll ici)

Application : TiLP (tilp), signal SIGABRT
0x000000375b4a3e30 in __nanosleep_nocancel () from /lib64/libc.so.6
[Current thread is 1 (Thread 0x7f8fc4cd8800 (LWP 6759))]

Thread 1 (Thread 0x7f8fc4cd8800 (LWP 6759)):
[KCrash Handler]
#5  0x000000375b4332f5 in raise () from /lib64/libc.so.6
#6  0x000000375b434b20 in abort () from /lib64/libc.so.6
#7  0x0000003633841d27 in g_logv () from /lib64/libglib-2.0.so.0
#8  0x0000003637e1963c in tifiles_error (format=0x6 <Address 0x6 out of bounds>) at logging.c:73
#9  0x0000003637e1a1f8 in fwrite_n_chars (f=0xb6f0f0, n=8, s=0x7fff2e73ccf0 "system\font") at rwfile.c:201
#10 0x0000003637e15979 in ti9x_file_write_regular (fname=<value optimized out>, content=0x8aef50, real_fname=<value optimized out>) at files9x.c:503
#11 0x0000003634435d40 in ticalcs_calc_recv_var2 (handle=0x8119f0, mode=MODE_NORMAL, filename=0xb14220 "/tmp/tilp.group.89g", vr=0xb4e860) at calc_xx.c:1020
#12 0x000000000040dc5e in tilp_calc_recv_var1 () at tilp_calcs.c:686
#13 tilp_calc_recv_var () at tilp_calcs.c:897
#14 0x0000000000414a63 in on_tilp_recv () at tilp.c:411
#15 0x000000000041af38 in on_treeview2_drag_data_received (widget=<value optimized out>, drag_context=0xa94410, x=<value optimized out>, y=<value optimized out>, data=<value optimized out>, 
    info=<value optimized out>, time=36706378, user_data=0x0) at dnd.c:307
#16 0x00000038c072abaa in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#17 0x000000363400b83e in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#18 0x0000003634020b83 in ?? () from /lib64/libgobject-2.0.so.0
#19 0x0000003634021f49 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#20 0x00000036340222b4 in g_signal_emit_by_name () from /lib64/libgobject-2.0.so.0
#21 0x00000038c0852b92 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#22 0x000000363400b83e in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#23 0x0000003634020b83 in ?? () from /lib64/libgobject-2.0.so.0
#24 0x0000003634021f49 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#25 0x00000036340222b4 in g_signal_emit_by_name () from /lib64/libgobject-2.0.so.0
#26 0x00000038c07881b3 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#27 0x00000038c078a5b0 in gtk_selection_convert () from /usr/lib64/libgtk-x11-2.0.so.0
#28 0x00000038c0852852 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#29 0x00000038c085108e in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#30 0x00000038c0851210 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#31 0x00000038c0851210 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#32 0x00000038c0851210 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#33 0x00000038c0851210 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#34 0x00000038c0851210 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#35 0x00000038c0851210 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#36 0x00000038c0852623 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#37 0x00000038c07276ec in gtk_main_do_event () from /usr/lib64/libgtk-x11-2.0.so.0
#38 0x00000038c024e17c in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#39 0x0000003633837abe in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#40 0x000000363383b278 in ?? () from /lib64/libglib-2.0.so.0
#41 0x000000363383b6d5 in g_main_loop_run () from /lib64/libglib-2.0.so.0
#42 0x00000038c07279c7 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#43 0x000000000041558f in main (argc=1, argv=0x7fff2e73eed8) at main.c:152

J'obtiens ça quand je veux transférer un simple fichier depuis la calc vers le PC. TiLP renvoie un timeout, PedroM une erreur, puis TiLP crash.
J'ai le dernier TiLP à jour de calcforge.org sur ma F11 x86_64

J'ai installé tous les paquets debuginfo que j'ai trouvé, et gtk2 qui contient les fichiers pour /lib64/libgtk. Par contre, j'arrive pas à mettre la main sur ce qui me donnera les fonctions de /usr/lib64/libgtk-x11... je reste preneur d'une solution. Idem pour libglib2 (yum whatprovides me dit glib2-2.20, et j'ai le debuginfo...

Merci pour le report

format=0x6 <Address 0x6 out of bounds> semble bizarre, puisque rwfile.c:201 est
tifiles_error("string passed in 'write_string8' is too long (>n chars).\n");
qui n'est certainement pas à l'adresse 6...
Ca pourrait être un effet de l'optimisation, ou d'infos de debug incomplètes.

Ah ben demande à GDB veux-tu ? Non, j'en ai aucune idée, Kevin te sera certainement plus d'utilité que ça à ce niveau. ^^

J'ai édité mon précédent message.

Je ne vois pas trop comment je pourrais reproduire le problème que tu rencontres, parce que je ne dispose que d'un câble parallèle ("$5 cable"), et la seule machine 64 bits dont je dispose n'a pas de port parallèle :'(

J'imagine que tu n'as pas spécialement envie de t'amuser à compiler libti* et tilp2 depuis SVN (cf. http://lpg.ticalc.org/prj_tilp/involve.html ) ?
Il faudra pourtant le faire (), pour tester des patches...

Tu peux donner le log link de PedroM. Pas besoin de tout donner (c'est trop long).
Il suffit de donner tout sauf les données (ie. CID= $15) que tu peux sauter. Ca donnera pas mal d'infos.
A noter que j'ai souvent eu cette erreur...

Très bien !

PpHd -> t'as eu ça avec un i386 ? C'est pour Lionel

Folco (./6) :
PpHd -> t'as eu ça avec un i386 ? C'est pour Lionel

Avec un pentium 233 même

Ah ben là ça devait être plus la calc qui faisait un timeout

Le backtrace du post de départ n'est pas un timeout, c'est que la libtifiles2 essaie d'écrire un nom de fichier avec dossier avec une fonction qui ne prend que 8 caractères. C'est au moment de l'écriture dans le fichier sur PC que ça foire. Visiblement, on a oublié de séparer le chemin en dossier et fichier à cet endroit.

Tu veux dire qu'il manque un appel à tifiles_get_varname() et/ou tifiles_get_fldname() au milieu de

      if(fwrite_long(f, offset) < 0) goto tfwr;
	  ticonv_varname_to_tifile_s(content->model, entry->name, varname, entry->type);
      if(fwrite_8_chars(f, varname) < 0) goto tfwr;

?

Peut-être que PedroM, contrairement à AMS, envoie un fldname alors que libtifiles ne s'y attend pas ? Voir les quelques dizaines de lignes qui précèdent, dans files9x.c.

Si c'est ça qui se passe, la paire TIEmu/TILP avec câble virtuel TIEmu sera peut-être assez sympa pour me permettre de reproduire le problème (je n'écris pas "bug", il faut investiguer plus profondément avant d'écrire que c'est PedroM, et pas libti*, qui nécessite la correction ).
[EDIT: oui, je peux reproduire le problème]

#7  0x00007fd088fc746e in g_logv () from /usr/lib/libglib-2.0.so.0
#8  0x00007fd08b19a01c in tifiles_error (format=<value optimized out>)
    at logging.c:73
#9  0x00007fd08b19ace7 in fwrite_n_chars (f=0x13b73a0, n=8, 
    s=0x7fff8cc8d6a0 "system\stdlib") at rwfile.c:201
#10 0x00007fd08b195449 in ti9x_file_write_regular (
    fname=<value optimized out>, content=0x13c9f70, 
    real_fname=<value optimized out>) at files9x.c:503
#11 0x00007fd08b19b277 in tifiles_file_write_tigroup (
    filename=0x13b8760 "/tmp/tilp.tigroup", content=0x13c76a0)
    at tigroup.c:1089
#12 0x00007fd08b5f5d02 in ticalcs_calc_recv_tigroup2 (handle=0x15c1f40, 
    filename=0x13b8760 "/tmp/tilp.tigroup", mode=TIG_ALL) at calc_xx.c:1428
#13 0x000000000040e4d4 in tilp_calc_recv_tigroup (mode=TIG_ALL)
    at tilp_calcs.c:1328

Heureusement, sinon il aurait fallu que je transfère un PedroM sur ma 89 HW2, et surtout que je m'amuse à compiler et tester tout ça sur mon vieux portable, qui dispose encore d'un port 25 broches...
Le système de ventilation n'étant manifestement pas fait pour que la machine tourne pendant des années 24/7 à faire du BOINC, ça fait déjà un certain temps que ce P4 2.6 GHz alterne entre 1.3 GHz et 975 MHz (!) pour limiter la température aux alentours de 65°C (d'après ACPI), malgré un nettoyage régulier à l'air comprimé et un changement de transfert thermique entre le processeur et le barreau de cuivre. Sale bête.

Je confirme, par l'ajout d'une trace à la ligne 199 de dans rwfile.c de libtifiles
fprintf(stderr,"BOUH s = %s, len(s) = %i\n", s, l);
qu'un backup sous AMS (un très ancien dump de ma 89 AMS 2.05, dans lequel j'ai rajouté avec un éditeur hexa le contenu de la certificate memory obtenu grâce à un programme d'ExtendeD):

...
BOUH s = **TI89**, len(s) = 8
BOUH s = mathtool, len(s) = 8
BOUH s = varlist, len(s) = 7
BOUH s = **TI89**, len(s) = 8
BOUH s = mathtool, len(s) = 8
BOUH s = wynn, len(s) = 4
BOUH s = **TI89**, len(s) = 8
BOUH s = mathtool, len(s) = 8
BOUH s = zeta, len(s) = 4
BOUH s = **TIFL**, len(s) = 8
BOUH s = CMDPOST, len(s) = 7
BOUH s = , len(s) = 0
BOUH s = , len(s) = 0
BOUH s = **TIFL**, len(s) = 8
BOUH s = sstart, len(s) = 6
BOUH s = , len(s) = 0
BOUH s = , len(s) = 0

et un backup sous PedroM vierge

BOUH s = **TI89**, len(s) = 8
BOUH s = system, len(s) = 6
BOUH s = system\stdlib, len(s) = 13

tifiles-ERROR **: string passed in 'write_string8' is too long (>n chars).

aborting...
KCrash: Application 'tilp' crashing... (SIGABRT)

ne se comportent pas de la même façon.

Je suis en train d'essayer de remonter, dans TILP, pourquoi VarEntry.name contient le fldname sous PedroM mais pas sous AMS. Doxygen est en train d'extraire les infos de libti*, tilp, gfm et tfdocgen, vive Doxygen !
Une fois qu'on aura trouvé ce qui se passe, ou bien on change le comportement de PedroM pour qu'il suive celui d'AMS, ou bien on modifie le code de libti* pour tolérer le comportement de PedroM.

[plusieurs EDITs au cours de la journée]

Lionel Debroux (./11) :
Une fois qu'on aura trouvé ce qui se passe, ou bien on change le comportement de PedroM pour qu'il suive celui d'AMS, ou bien on modifie le code de libti* pour tolérer le comportement de PedroM.

Dans tous les cas, il faudrait mieux éviter que tilp ne plante pour çà.

AMHA c'est un bogue de PedroM, il ne suit pas le protocole.

Kevin Kofler (./13) :
AMHA c'est un bogue de PedroM, il ne suit pas le protocole.

MDR. Si tu veux. Peut-être même.
Mais perso, un crash appli c'est quand même un bogue.

J'ai ajouté d'autres traces, merci Doxygen pour m'avoir fait trouver plus rapidement ti89_recv_VAR_h.
Sous AMS, on a:

ticalcs-INFO:  PC->TI: RDY?
ticalcs-INFO:  TI->PC: ACK
ticalcs_calc_recv_tigroup fldname = main varname = dissolve
ticalcs_calc_recv_tigroup ve->folder = main ve->name = dissolve
ticalcs-INFO:  PC->TI: REQ (size=0x00000000=0, id=21, name=main\dissolve)
ticalcs-INFO:  TI->PC: ACK
ti89_recv_VAR_h varname = dissolve
ti89_recv_VAR_h varname = dissolve
ticalcs-INFO:  TI->PC: VAR (size=0x00000C5D=3165, id=21, name=dissolve, flag=3)
ticalcs-INFO:  PC->TI: ACK
ticalcs-INFO:  PC->TI: CTS
ticalcs-INFO:  TI->PC: ACK
ticalcs-INFO:  TI->PC: XDP (0C61=3169 bytes)
ticalcs-INFO:  PC->TI: ACK
ticalcs-INFO:  TI->PC: EOT
ticalcs-INFO:  PC->TI: ACK

(idem si la variable n'est pas dans main)

Sous PedroM, on a:

ticalcs-INFO:  PC->TI: RDY?
ticalcs-INFO:  TI->PC: ACK
ticalcs_calc_recv_tigroup fldname = system varname = stdlib
ticalcs_calc_recv_tigroup ve->folder = system ve->name = stdlib
ticalcs-INFO:  PC->TI: REQ (size=0x00000000=0, id=21, name=system\stdlib)
ticalcs-INFO:  TI->PC: ACK
ti89_recv_VAR_h varname = stdlib
ti89_recv_VAR_h varname = system\stdlib
ticalcs-INFO:  TI->PC: VAR (size=0x00005B79=23417, id=21, name=system\stdlib, flag=100)
ticalcs-INFO:  PC->TI: ACK
ticalcs-INFO:  PC->TI: CTS
ticalcs-INFO:  TI->PC: ACK
ticalcs-INFO:  TI->PC: XDP (5B7D=23421 bytes)
ticalcs-INFO:  PC->TI: ACK
ticalcs-INFO:  TI->PC: EOT
ticalcs-INFO:  PC->TI: ACK

Au fait, que veut dire cette valeur "100" pour flag ?

Lionel Debroux (./15) :
Au fait, que veut dire cette valeur "100" pour flag ?

Locké, archivé, et autre truc. Sans intérêt pour le problème.

Le "bug" est que PedroM envoie le folder\varname pour un silent request of file (Commande sendcalc).
A noter que c'est nécessaire pour un send variable manuel...

A noter que je suis sûr que ca marchait avec TI Graph Link : j'avais testé.

PpHd (./14) :
Mais perso, un crash appli c'est quand même un bogue.

300% d'accord. Peut-être que Lionel prendra en compte la liste de crash bug de TiLP que j'ai recensés. Ok, il faut du temps, et certaines manières d'obtenir un crash sont tordues. On se contentera des priorités pour les utilisations normales, ça sera déjà très bien.

Contrairement à d'autres crashes de TILP et TIEmu corrigés par le passé, celui-ci est un crash volontaire (SIGABRT) de la classe "détecté un problème interne, peut-être dû à un protocole que je n'ai pas bien compris... j'arrête plutôt que de faire des conneries"
Mais c'est un crash en utilisation courante du programme, on est d'accord.

Ah tiens, je savais pas qu'un programme pouvait crasher volontairement, c'est pas con du tout comme principe. Mais oui, ça fait bizare au niveau de l'utilisateur final quoi.

Je ne suis pas du tout d'accord. Une application qui s'amuse à faire du protocole ne doit pas faire de ABORT dans le cas où la machine avec laquelle elle parle fait n'importe quoi !
Dans le pire cas, elle affiche un message d'erreur à l'utilisateur pour dire que TILP ne comprend pas le protocole utilisait et s'arrête, mais c'est tout!

Avec votre raisonnement, on ferrait planter les calculateurs des commandes de vols des avions si un autre calculateur de l'avion se met à lui parler "mal" !

Les ABORT ne sont que pour les erreurs provenant et qui sont sous le contrôle total et absolue de l'application, et donc indique une erreur interne.
Une donnée externe du link ou un utilisateur qui clique n'importe où, c'est une erreur externe, et ca doit être robuste !!!!!!! Ce n'est absolument pas géré de la même façon!

Je suis parfaitement d'accord qu'abort() est excessif (tout comme il l'était dans le packer des pack archives, je crois ), j'expliquais juste ce qu'il en était à Martial.

Lionel Debroux (./21) :
tout comme il l'était dans le packer des pack archives, je crois

En effet. Ca a été corrigé depuis.

Oui je suis d'accord aussi, je me suis mal exprimé. Ce n'est pas le genre d'erreur à envoyer au end-user. Cependant sur un outil de dev, ça me dérangerait pas plus que ça, de la même manière que PedroM est très fragile en cas de crash (j'ai toujours des 'panic' après un crash récupéré). Un outil de dev spartiate dans une certaine mesure, je m'en fous. ^^

A mon niveau, j'essaye toujours de faire mes programmes pour qu'ils ne puissent pas crasher, quelles que soit ce qu'on peut leur balancer comme arguments ou fichiers corrompus.

Code de ti89_recv_VAR_h:

int ti89_recv_VAR_h(CalcHandle* handle, uint32_t * varsize, uint8_t * vartype, char *varname)
{
  uint8_t host, cmd;
  uint8_t *buffer = (uint8_t *)handle->priv2;
  uint16_t length;
  uint8_t strl;
  uint8_t flag;

  fprintf(stderr,"%s varname = %s\n", __FUNCTION__, varname);
  TRYF(dbus_recv(handle, &host, &cmd, &length, buffer));

  if (cmd == CMD_EOT)
    return ERR_EOT;		// not really an error

  if (cmd == CMD_SKP)
    return ERR_CALC_ERROR1 + err_code(buffer);

  if (cmd != CMD_VAR)
    return ERR_INVALID_CMD;

  *varsize = buffer[0] | (buffer[1] << 8) |
      (buffer[2] << 16) | (buffer[3] << 24);
  *vartype = buffer[4];
  strl = buffer[5];
  memcpy(varname, buffer + 6, strl);
  varname[strl] = '\0';
  flag = buffer[6 + strl];
  fprintf(stderr,"%s varname = %s strl=%hu\n", __FUNCTION__, varname, (unsigned short)strl); 

  if ((length != (6 + strlen(varname))) &&
      (length != (7 + strlen(varname))))
    return ERR_INVALID_PACKET;

  ticalcs_info(" TI->PC: VAR (size=0x%08X=%i, id=%02X, name=%s, flag=%i)",
	  *varsize, *varsize, *vartype, varname, flag);

  return 0;
}

dbus_recv est la fonction de réception sur le link, elle écrit dans handle->priv2 qui est un buffer de 64 KB + 4 ou 6 octets.
Sur AMS, les deux fprintf affichent le même varname, quel que soit le répertoire d'origine de la variable.
Sur PedroM, le deuxième fprintf affiche, contrairement au premier, un varname comportant le répertoire d'origine de la variable (par exemple "system\stdlib").

Même si le comportement de PedroM est changé (je pense qu'il devrait l'être), ça n'empêche naturellement pas de limiter l'utilisation par libti* de fonctions qui déclenchent abort(). Ca consiste par exemple en le remplacement des appels à ti*_error (qui appellent g_logv(..., G_LOG_LEVEL_ERROR, ...);, toujours fatal) par des appels ti*_critical.

Tiens, au fait: je viens de voir qu'un Directory Listing fait apparaître stdlib dans la ligne "RAM utilisée", pas dans la ligne "Flash utilisée".

Il serait assez facile de contourner le bogue qui cause le plantage, il suffit de virer le nom du dossier si la calculatrice envoie un nom de fichier avec dossier à cet endroit.

Tiens, je viens seulement de voir l'edit de ./16. Si ça a fonctionné avec TI-GraphLink, alors on peut considérer que c'est un comportement valide...
(même si, dans le cas où ça raccourcirait le code de PedroM, tu devrais à mon avis le changer: Link.asm est manifestement dans la section 24K qui était trop pleine l'autre jour).

Un patch simple du genre

diff --git a/libticalcs/trunk/src/cmd89.c b/libticalcs/trunk/src/cmd89.c
index 6565a71..b2559f9 100644
--- a/libticalcs/trunk/src/cmd89.c
+++ b/libticalcs/trunk/src/cmd89.c
@@ -308,6 +308,7 @@ int ti89_recv_VAR_h(CalcHandle* handle, uint32_t * varsize, uint8_t * vartype, c
   uint16_t length;
   uint8_t strl;
   uint8_t flag;
+  char * varname_nofldname;

   TRYF(dbus_recv(handle, &host, &cmd, &length, buffer));

@@ -334,6 +335,13 @@ int ti89_recv_VAR_h(CalcHandle* handle, uint32_t * varsize, uint8_t * vartype, c

   ticalcs_info(" TI->PC: VAR (size=0x%08X=%i, id=%02X, name=%s, flag=%i)",
          *varsize, *varsize, *vartype, varname, flag);
+  varname_nofldname = tifiles_get_varname(varname);
+  if (varname_nofldname != varname)
+  {
+    // This variable name contains a folder name. Erase it.
+    ticalcs_info(" TI->PC: VAR: the variable name contains a folder name, stripping it.");
+    memmove(varname, varname_nofldname, strlen(varname_nofldname)+1);
+  }

   return 0;
 }

fonctionne pour moi.
J'ai déjà committé le remplacement de ti*_error par ti*_critical, que j'ai mentionné en ./24.

Il faut que je regarde pourquoi system\stdlib est comptabilisé comme étant en RAM.

Merci pour la correction de Tilp.

Lionel Debroux (./27) :
(même si, dans le cas où ça raccourcirait le code de PedroM, tu devrais à mon avis le changer: Link.asm est manifestement dans la section 24K qui était trop pleine l'autre jour).

J'ai corrigé pour PedroM:

--- a/src/Link.asm
+++ b/src/Link.asm
@@ -909,8 +909,9 @@ TranslatePacket                                     ; Translate Packet
                jsr     FreePacket
                ; Send var to the calc
                clr.b   (a2)                    ; NULL string
-               pea     (a2)                    ; Push SYM Name
-               jsr     sendcalc                ; Send var
+               move.l  a2,a0                   ; SYM Name to transfert
+               lea     HSYMtoNameWithoutFolder,a1 ; Convertion function (without folder)
+               jsr     sendcalc_reg            ; Send variable
                bra     LinkCmdSuccess          
 
 \RequestIDListing:
@@ -1054,15 +1055,16 @@ cmd_sendcalc:
        moveq   #1,d0
        unlk    a6
        rts
-       
+
 ;unsigned short sendcalc (SYM_STR SymName, short allowSysVars, unsigned short DevType, unsigned char *compat); 
 sendcalc:
        move.l  4(a7),a0                ; SymName
-       move.w  10(a7),d0               ; DevType
-       movem.l d3-d4/a2-a3,-(a7)
+       lea     HSYMtoName,a1           ; Convertion function void *convert (HSYM , Buffer) / Return in a1 the end of the buffer.
+sendcalc_reg:
+       movem.l d3-d4/a2-a5,-(a7)
        lea     -60(a7),a7
        move.l  a7,a3                   ; Temp usage for sending
-       move.w  d0,d3                   ; DevType (Not used yet :()
+       move.l  a1,a5                   ; Convertion function
        pea     (a0)                    ; SymStr
        jsr     SymFindPtr
        addq.l  #4,a7
@@ -1082,7 +1084,7 @@ sendcalc:
                move.w  #$21*256,(a1)+  ; Asm Type ;) Name Size = 0
                pea     (a1)            ; Convert 
                move.l  d0,-(a7)        ; HSym
-               jsr     HSYMtoName      ; Convert HSYM into folder\name
+               jsr     (a5)            ; Convert HSYM into folder\name
                addq.l  #4,a7
                sub.l   (a7)+,a1        ; Use side effet of HSYMtoName: a1 was the end of the buffer. Now a1.l = Size
                move.w  a1,d1
@@ -1124,7 +1126,7 @@ sendcalc:
        bra.s   \Done
 \Error:        moveq   #1,d0
 \Done: lea     60(a7),a7
-       movem.l (a7)+,d3-d4/a2-a3
+       movem.l (a7)+,d3-d4/a2-a5
        rts
        
 ;void getcalc (SYM_STR SymName); 


--- a/src/Vat.asm
+++ b/src/Vat.asm
@@ -905,6 +905,23 @@ HSYMtoName:
 \End:  rts
 
 
+;short HSYMtoName (HSym Sym, char *buffer);
+; Side Effect:
+;      Return in a1 the end of the buffer.
+HSYMtoNameWithoutFolder:
+       move.l  4(a7),d0        ; Get HSYM
+       jsr     DerefSym_Reg    ; Convert it to SYM_ENTRY *
+       move.l  8(a7),a1        ; Read buffer
+       move.l  a0,d0           ; Check if convertion was successfull
+       beq.s   \End            ; If not, end
+               moveq   #8-1,d0 ; Copy at most 8 characters
+\loopFile              move.b  (a0)+,d1
+                       beq.s   \EndFile
+                       move.b  d1,(a1)+
+                       dbf     d0,\loopFile
+\EndFile       clr.b   (a1)
+\End:  rts
+
 ; *** FInd a SYM ***
 
 ; Find a ANSI str file.

Même si je trouve bizarre de ne pas donner le folder (et on peut voir que le patch casse le naturel de la fonction).

Hmm, ça complique plutôt PedroM... ça n'est pas le but que je recherchais

Lionel Debroux (./29) :
Hmm, ça complique plutôt PedroM... ça n'est pas le but que je recherchais

Il est fort possible que ticonnect ait les mêmes limitations.