1

J'ai un bug truoducutant, encore une fois :

J'ai mon loader :
_main:
	nop
	jsr	pexeclib__0000

Data :
Data:	.long	pedrom__printf,pedrom__system	|system calls
	.long	kernel__Exec,pedrom__tmpnam


Et la lib :
pexeclib__0000:
	bra.
	...


Le truc génial c'est que quand je mets le nop du loader, avant le jsr, tout se passe bien. Si je vire le nop, HeapCorruption, Rebooting System. C'est troublant. grin

Je suis en train de faire un test-case minimaliste. Au début, ça marchait, puis j'ai modifié deux trois trucs dans les sources, et maintenant j'ai le résultat attendu triso Je vais y arriver ^^

D'ici là, si quelqu'un avait une piste, je suis preneur. happy

2

trou blanc? trilove

ça peut même pas être un problème d'alignement en plus ^^

3

Ben non, ça compilerait pas.

Par contre, j'ai gardé un snapshot du programme qui fait planter un PedroM tout neuf (et pas compilé par moi) si PpHd le veut ^^

4

Bizarre trifus
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

5

Folco (./3) :
Par contre, j'ai gardé un snapshot du programme qui fait planter un PedroM tout neuf (et pas compilé par moi) si PpHd le veut ^^


Je prend. Tu peux faire aussi un BP sur le trap#6 qui est appelé juste avant d'éxécuter le moindre programme.

6

Sent. Pour info, j'ai réussi à obtenir le crash également en-dehors d'un pack archive.

7

Comme le bug persiste et que j'ai pas trouver de work-around, j'essaye de trouver le bug.

J'en profite pour signaler un détail : il y a un double xdef de KernelExec_redirect dans Library.asm.

8

--- Library.asm~	2009-05-17 19:45:28.000000000 +0200
+++ Library.asm	2009-05-17 19:45:28.000000000 +0200
@@ -43,7 +43,6 @@
         xdef InitGraphSystem_redirect
         xdef printf_redirect	
         xdef SymFindPtr_redirect
-        xdef KernelExec_redirect
 	xdef kernel__Ptr2Hd
 	xdef kernel__clean_up
 	xdef kernel__Hd2Sym


(et testé avec ça. tu parles que ça va aller loin PedroM avec mes contribs tripo)

9

Bon, je trace, on sors donc de System.asm pour exécuter kernel::exec, qui appelle ExtractFromPack, qui appelle LibsExec, qui ne semble pas planter en elle-même (on atteint la fin sans erreur), mais le rts emmène je ne sais pas où...

Ca commence par :
movem.l d0-d2/a0-a1,-(%sp)
pea xxx.l ;"Extracting"
etc...

Donc visiblement ça cherche à extraire. Mais j'ai pas retrouvé cette chaine "Extracting" avec grep confus
Je commence à plus savoir où j'en suis dans le traçage ... couic

Parce que apparemment, on est plus dans sld.asm ...

edit -> ok, on est dans shrinklib, je vais pouvoir continuer à tracer

10

Bon, je me sers de ça comme d'un log :
- après que shrnklib ait été exécutée, on revient à LibsExec, et on déreloge shrinklib.
- passe 2 : tout se passe bien.
- passe 1 : ça plante dans le HeapFree (on en retourne pas, le handle $000A est sur la pile, mais je suis pas encore allé voir plus loin

C'est donc ici que ça partirait en live :
\NoFreeData:	move.l	LIBRARY.code(a4),d0	; Get code section
		andi.l	#$0003FFFF,d0		; Avoid Ghost Space (TODO: Improve for RAM > 256K).
		cmp.l	LIBRARY.org(a4),d0	; Check if it is copy section
		beq.s	\NoFreeCode		
			move.l	d0,a0		; Yes so 
			bsr	kernel::Ptr2Hd	; get the handle of the code section
			move.w	d0,(a7)		; Push handle of code section
			beq.s	\NoFreeCode	

			ROM_THROW HeapFree	; Free code section		

\NoFreeCode	lea	LIBRARY.sizeof(a4),a4	;  Next entry

Mais j'en sais pas plus, je vais voir dans HeapFree... Je ne sais pas à quoi correspond ce handle #10...

11

Bon, l'erreur fatale est bien déclenchée dans HeapFree, mais je ne sais pas pourquoi... C'est visiblement quand PedroM essaie de merger des blocs, mais ne connaissant pas le format de la table, je comprends pas pourquoi ça se passe (et au fait, c'est au troisième appel de HeapFree que ça crash, les deux premiers se terminent normalement et le programme continue. Je n'ai pas vu ce qui était poussé sur la pile pour que HeapFree soit appelé 3 fois à la suite, et je n'ai pas réussi à localiser le code du retour des deux premiers appels...

Le premier HeapFree efface le handle $000a, le second le $000b, et le troisième le $0006. Je n'ai envoyé qu'un pack archive (de deux fichiers, loader + main part) sur un PedroM tout neuf.

\loop		cmp.l	a1,a0
		bhi	HeapCorrupted	;C'est là !!!
		beq.s	\found		; Current Block = New Free bLock ? Yes => Found previous block
		move.l	a0,d2		; Save Previous Block
		add.l	(a0),a0		; Next Block
		bra.s	\loop

PpHd, à toi, j'y arrive pas cry

12

Le double xdef n'a aucun effet (c'est comme s'il n'y en avait qu'un).
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

13

Je sais. Ca pourrait éventuellement poser problème le jour où il croirait le virer, même si ce n'est pas prêt d'arriver. Je l'ai signalé pour la forme.

14

Merci pour le travail.
Je vais regarder en détail. Ca n'a pas l'air simple....
Quelqu'un corromp la Heap semble-t-il... Qui ?

15

Je ne sais pas. Mon programme ne semble pas être commencé à être exécuté, et je n'arrive pas à faire un test case simple qui plante systématiquement... Un loader minimaliste (jmp lib__machin + deux relogements .long kernel__truc,pedrom__bidule) et une lib faite d'un rts ne plantent pas.

Faudrait peut-être vérifier le format du binaire, chose que je connais pas trop (ok, il me faudrait kerneformatvnt à la main). Je vais essayer en compressant la lib appelée, voir si ça fait une différence. Parce qu'entre make et A68k qui marchent pas chez toi comme chez moi, j'espère qu'il n'y a pas de surprise de ce côté-là... sorry

Et on est forcément face à une corruption de la heap tu penses ? Ca peut pas être un problème de linker ? Je crois qu'un PedroM juste booté a 5 handles. Virer le handle #6, c'est revenir à zéro en plein chargement de programme, après avoir dépackagé, c'est normal ?
edit -> connerie, les handle de PedroM sont les 1,2,3,8 et 9.

Re-edit -> Les deux premiers HeapFree viennent de shrinlib (OpenArchive et CloseArchive), je suis con de pas y avoir pensé avant. Donc c'est au premier HeapFree de kernel::unrelocation (le code du ./10) que ça merde.

16

Bon il semblerait que le bug vienne en fait de shrnklib::OpenArchive qui a un débordement de buffer (qui va corrompre la heap):

\HuffTreeEnd:	move.w	d6,(a0)  		;  store root pointer to archive descriptor

	     ;;  free the Table of Unresolved Elements; /
		move.w	d4,-(a7)
		bsr.s	HeapFree

		move.w	d5,d0			;  d0 = handle of archive descriptor
\Error:		movea.l	a6,a7			;  restore stored a7 -- remove all stack elements
		movem.l	(a7)+,d1-d7/a0-a6	;  restore registers
		rts

On a le handle qui fait 224 octets, le début à 0x88AC, soit une fin à 0x898C.
Mais a0 vaut 0x89A6
D'où débordement, d'où crash.

17

18

Attend, c'est pas fini !!!

19

T'as essayé de poser un BP en écriture à partir de HEAP_TABLE, sur une longueur d'une 15aine de handles ? Et sur *HEAP_TABLE pour voir ? Je suis parti 3 jours en déplacement, mais juste avant, après avoir lu l'adresse de la table lue dans HeapAllocPtr, j'ai cru y lire des noms de fichier (system, pexec, jesaisplusquoi). C'était visiblement corrompu, mais il était tard, je me levais tôt, et j'ai pas eu le temps de continuer mes recherches dimanche soir.

20

Je ne crois pas que ca soit çà. J'ai rajouté un controle de la heap après/Avant chaque opération HeapXXXX.
Et ca a laché dans shrnklib::OpenArchive lors de son HeapFree.

21

Tu as fait un patch ou pas stp ? Que je puisse continuer à programmer. grin

22

Voici un patch. Je ne suis pas super satisfait car je n'ai pas vraiment compris d'où vient le problème... mad
--- shrnklib.asm        17 Oct 2007 19:13:54 -0000      1.1.1.1
+++ shrnklib.asm        22 May 2009 11:25:05 -0000
@@ -28,9 +28,9 @@
                xdef    shrnklib@0000
                xdef    shrnklib@0001
                xdef    shrnklib@0002
-               xdef    shrnklib@0003
 
        ifd     CALC_TI92PLUS
+               xdef    shrnklib@0003
                xdef    _ti89
                xdef    _ti89ti
                xdef    _ti92plus
@@ -94,7 +94,7 @@
                movea.l a3,a1                   ;  a1 = output-pointer (is increased whereas a3 points to the table's begin)
                clr.w   d1                      ;  d1.w = one byte (high byte has to be cleared)
                moveq   #-1,d3                  ;  d3.w = number of entries in table - 1
-\ExtrFreqLoop: clr.w   d0                         ;  d0 = RLE repetition length - 1 (0 = ONE character -- no RLE)
+\ExtrFreqLoop: moveq   #0,d0                      ;  d0 = RLE repetition length - 1 (0 = ONE character -- no RLE)
                move.b  (a2)+,d1                   ;  d1 = current byte / RLE ESC byte
                cmpi.w  #$E0,d1                    ;  is it an RLE ESC character ?
                blt.s   \__RLEloop                    ;  (if it isn't: cylcle one time through RLE loop)
@@ -112,8 +112,10 @@
                blt.s   \ExtrFreqLoop
 
             ;;  align input address on even address; /
+            ;; Skip also the stored size of the archive descriptor: it isn't safe and reliable to use it. Instead recompute it
+            ;; It should be (4+2+4*unresNum) with unresNum=d3+1, but it isn't safe to assume it is correct.
                move.l  a2,d1
-               addq.l  #1,d1
+               addq.l  #3,d1
                bclr.b  #0,d1
                movea.l d1,a2
 
@@ -123,8 +125,13 @@
                ;  a2 = aligned pointer directly after the RLE compressed frequency table in the input archive
                ;  a3 = pointer to first entry in Table of Unresolved Elements
             ;;  allocate memory for archive descriptor; /
-               move.w  (a2)+,-(a7)             ;  at the current position in the archive the size of the descriptor is stored
-               clr.w   -(a7)                   ;  it is a long value
+;              move.w  (a2)+,-(a7) ;  at the current position in the archive the size of the descriptor is stored
+;              clr.w   -(a7)                   ;  it is a long value
+               move.w  d3,d0                   ; Compute 6+(d3+1)*4
+               addq.w  #1,d0                   ; The highest bits of d0 are already cleared
+               lsl.w   #2,d0
+               addq.w  #6,d0
+               move.l  d0,-(a7)
                bsr.s   HeapAlloc               ;  (jsr tios::HeapAlloc)                
                move.w  d0,d5                   ;  d5 = handle of archive descriptor
                beq.s   \Error

Dis moi si c'est ok pour toi. Je n'ai pas eu le temps de le tester vraiment à fond. J'ai juste vérifié que 2 programmes (dont le tien) se lance.

23

Ok, merci !

24

Ya des erreurs d'écriture dans shrnklib.asm. Visiblement, ça viendrait pas de là, mais j'ai déjà eu des grosses surprises à cause d'A68k qui acceptait d'assembler ces instruction inavlides (strictement) et qui pondait de la merde. Alors si tu veux bien :
--- shrnklib.asm~	2009-05-23 14:49:00.000000000 +0200
+++ shrnklib.asm	2009-05-23 14:49:00.000000000 +0200
@@ -114,7 +114,7 @@
 	     ;;  align input address on even address; /
 		move.l	a2,d1
 		addq.l	#1,d1
-		bclr.b	#0,d1
+		bclr.l	#0,d1
 		movea.l	d1,a2
 
 	;; ***** Create Archive Descriptor,Containing the Huffman Tree; /
@@ -226,7 +226,7 @@
 		blt.s	\SameByte
 			move.b	(a2)+,d0	;  read new byte,begin again with bit #0
 			clr.b	d1
-\SameByte:	btst.b	d1,d0			;  test bit -- set zero flag accordingly
+\SameByte:	btst.l	d1,d0			;  test bit -- set zero flag accordingly
 		rts
 
 ;; *************************************************************************************************
@@ -246,7 +246,7 @@
 \ReadLoop:	add.l	d6,d6			  ;  create space for a new bit in d6 (initialized to zero)
 		bsr.s	ReadBit		 	  ;  read a bit
 		beq.s	\__ZeroBit		  ;  set new bit in 'd6' accordingly
-			bset.b	#0,d6
+			bset.l	#0,d6
 \__ZeroBit:	dbra	d7,\ReadLoop
 		rts
 		
@@ -311,7 +311,7 @@
 	     ;;  read a Huffman code; /
 		move.w	(a3),d7		;  d7 = relative pointer to root element
 
-\__HuffLoop: 		bclr.w	#15,d7		;  if bit #15 in "address" is set -> it is a leaf; d7 contains the code
+\__HuffLoop: 		bclr.l	#15,d7		;  if bit #15 in "address" is set -> it is a leaf; d7 contains the code
 			bne.s	\__HuffDone	;  d7 points to current element; (d7) = left branch 2(d7) = right branch
 			bsr.s	ReadBit
 			beq.s	\____Left	;  continue with left branch

(puis c'est tellement plus beau l'assembleur bien strict, plutôt que ce genre de cochonneries qui ne veulent en fait rien dire hehe)

25

Ok, ok

26

Je te donne du feedback sur ton patch ce tantôt, mais chez moi, c'est pas rien de recompiler stdlib, preos et pedrom... j'en ai profité pour me faire des patches et accélérer les choses, mais voilà quoi ...

27

Kevin: les changements de shrnklib affectent également le support shrnklib de pstarter.
Ce support est probablement totalement inutilisé en pratique, tout comme le support lzma (pour des raisons différentes).
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

28

Le problème est que ce patch ne corrige que les symptômes et pas le vrai problème...

Je pense que je vais carrément supprimer le support shrnklib de pstarter, il ne sert à rien:[ul][li]pas compilé par défaut,[/li][li]plus gros que ttunpack_small,[/li][li]plus lent que ttunpack_small,[/li][li]compresse moins bien que pucrunch/ttpack,[/li][li]licence plus restrictive que ttunpack_small depuis le changement de licence de ce dernier (LGPL sans exceptions vs. avec exception wxWidgets).[/li][/ul]
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

29

Folco: As-tu pu tester le patch ? Est-ce que ca marche chez toi ?

30

Pas testé, désolé sad Je me suis avancé, j'aurais pas dû. Déménagement le week-end prochain, pris toute la semaine, probablement pas de net pendant 3 semaines à partir de demain... black-out pour moi pendant quelques temps... désolé...
Au fait, j'ai testé sous AMS, ça merde pareil, PedroM n'est pas en cause.