Problème étrange - Page 1

J'ai un souci, un de plus. Quand je lance un programme de 9 ko, tout se passe bien, ça quitte proprement et je peux le relancer. Un clean sous PedroM ne donne rien et rien ne semble corrompu.

Quand je rajoute 4 ko au bout du programme (des données d'une seule image, qui sera seulement lue), ça ne plante toujours pas en sortie, la pile et bonne et je reviens à l'invite du shell.
Par contre, un clean détecte une corruption du système, donc PedroM reboot, et si j'essaye de relancer le programme, ça ne marche pas, PedroM me renvoie une invite à la ligne suivante.
Je n'adresse cette image qu'à un seul endroit du programme (un simple lea), et c'est genlib qui l'affiche, mais je ne crois pas trop que le problème soit au niveau de l'image proprement dite.

Avez-vous une idée de la direction dans laquelle je devrais chercher ? Là, je suis

Un bug dans genlib ?

Ben je penserais pas, puisque les "bugs de genlib", je les ai toujours trouvés entre ma chaise et mon écran, puis genlib n'a pas la réputation d'être instable. Ceci dit, je viens de relire tout mon code, je n'ai que deux handles (un pour un dscreen et un autre où je ne fais que des copies de 4 octets), je ne fais pas de smc sur mon code, je sais pas trop d'où ça peut venir. Si ça tombe, un truc tout con me crève les yeux...

Probablement un débordement d'un de tes handles qui a corrompu la liste chainée des handles de libre.

Folco (./3) :
puis genlib n'a pas la réputation d'être instable.

Ah bon?

Non.

Pour mon bug, mes BP ne donnent rien, seul PedroM accède à un des handles alloué en mémoire haute lors du free (dans le merge de HeapFree_reg, à la fin, donc ça semble normal).
Je fais des tests. Autre indice, ça fout en l'air le link de PedroM visiblement, j'arrive plus à envoyer de fichier (TiEmu reporte une erreur, mais pas PedroM).

Je vais tester sous AMS, et poster le code du seul endroit où j'écris dans le handle qui ne soit pas celui du DScreen.

Infinite loop sous AMS en sortie, PreOS ne voit rien. J'ai vérifié mes désallocations, ce sont les bons pointeurs qui passent. J'ai vérifié mon frame, tout les offsets sont bons, je sais pas trop ce qui se passer. Je n'ai pourtant aucun algo complexe, deux alocations uniques, un portset , aucun sprite en-dehors de l'écran... Rien qui casse des briques...

Nouvel indice : ça ne se produit pas avec le programme archivé. Ca doit venir de mon loader alors, vu que la partie principale ne peut être modifiée. Encore des BP ...

C'est un peu ça, oui

Bon, mon programme (sans compter le stub et le flag) va de $BE18 à $BEE8. J'ai un frame de variables de $BE68 à $BEC2
J'ai donc deux ranges à tester en écriture :
$BE18-$BE67
$BEC2-$BEE8

En sortie de programme, côté PedroM, j'ai des écritures sur $BE3C, $BE50, $BE30, $BE48. Il y a donc 4 écritures faites dans une partie de mon programme qui ne devrait pas bouger, et elles ne viennent pas de moi (elles proviennent de $41ABFC). L'écriture est faite par la même instruction : add.l d4,0(a5,d0.l). Je vais dans les sources de PedroM, je fais un "grep a5,d0 *.asm", mais ça donne rien ... Après le code auto-modifié, j'ai droit à du code auto-créé ?
Et quand j'ai essayé de mettre un BP dans le stub (le départ devait être vers $BD50, mais je suis pas très sûr, étant donné que c'est un pack archive), j'avais aussi un clr.w et un add.l d0,(a1) dans le stub.

Qui peut me donner une piste ?

C'est la fonction kernel::do_reloc de preos pour info qui fait probablement une dérelocation de ton programme.

Anéfé.

Hmmm, faudrait qu'on trouve un moyen pour importer des infos de débogage pour PedroM à TiEmu. Au moins les infos symboliques produites par A68k (qui peuvent être utilisées par le désassembleur), mais l'idéal serait évidemment d'utiliser GNU as qui crée de vraies informations de débogage.

./7: infinite loop à la sortie sous AMS, c'est souvent à cause d'un heap overflow.

Merci Lionel. J'ai rien vu de ce côté-là malgré tout, même avec des BP après les buffers. Remarque, j'ai oublié d'en mettre avant, mais PedroM a l'air de libérer correctement (HeapFreePtr), donc à moins que j'efface un handle système, ça doit être bon.

Kevin -> Faudrait déjà pouvoir faire du débogage avec TiEmu.

Autre indice : Quand je rajoute, presque au bout de mon code, le BigSprite qui fait fond d'écran sur 89 (juste avant celui pour 92), ça plante. Sans ces ~4 ko de données en plus, rien n'est corrompu. Mes écritures dans les handles (dans un seul en fait, et une seule fois, ça se vérifie encore facilement), n'ont rien à voir avec ce sprite. Je comprends pas pourquoi j'ai constaté ça.

C'est trouducutant cette histoire, trois jours que j'ose plus avancer dans le code sans avoir résoudru ça, c'est démotivant. J'ia changé l'ordre de compilation de mes fichiers, ça déconne toujours quand je rajoute le BGS 89, et ça marche quand il n'y a que celui pour 92...

Désespoir de cause :

|==================================================================
|	ComputeIcons
|==================================================================
|	Calc the coordinate of a list of icons and save them in a table
|
|	input	a0	icon list
|	output	nothing
|	destroy	d0-d2/a0-a1
|==================================================================
ComputeIcons:
	movem.l	%d3-%d6,-(%sp)
	moveq.l	#-1,%d3				|counter of tiles
	move.w	LcdWidth(%fp),%d4
	move.w	LcdHeight(%fp),%d5
	|==================================================================
	|	Read icon data and prepare registers
	|==================================================================
	addq.l	#2,%a0				|skip first index
ComputeIconsLoop:
	move.w	(%a0)+,%d2			|flag
	move.w	(%a0)+,%d0			|x
	move.w	(%a0)+,%d1			|y
	|==================================================================
	|	Check for hz center
	|==================================================================
	btst.l	#2,%d2				|Hz center ?
	beq.s	NoHzCenter			|no
		move.w	%d4,%d6
		lsr.w	#1,%d6			|LCD_WIDTH/2
		add.w	%d6,%d0			|update x
		bra.s	ComputeIcon
NoHzCenter:
	|==================================================================
	|	Check for vert center
	|==================================================================
	btst.l	#3,%d2				|Vert center ?
	beq.s	NoVertCenter			|no
		move.w	%d5,%d6			|else get LCD_Height
		lsr.w	#1,%d6			|LCD_Height/2
		add.w	%d6,%d1			|update x
		bra.s	ComputeIcon
NoVertCenter:
	|==================================================================
	|	Check for abcisse origin
	|==================================================================
	btst.l	#0,%d2				|x org ?
	beq.s	OrgXLeft			|yes
		add.w	%d4,%d0			|and add it
OrgXLeft:
	|==================================================================
	|	Check for ordinate origin
	|==================================================================
	btst.l	#1,%d2				|y org ?
	beq.s	OrgYTop				|yes
		add.w	%d5,%d1			|and add it
OrgYTop:
	|==================================================================
	|	Save coordinates and draw the tile
	|==================================================================
ComputeIcon:
	move.w	%d1,-(%sp)			|save y
	move.w	%d0,-(%sp)			|save x
	addq.l	#1,%d3				|increase counter
	cmpi.w	#0xffff,(%a0)+			|end of list ? (and skip index)
	bne.s	ComputeIconsLoop		|no, compute next one
	|==================================================================
	|	Create coordinates table and quit
	|==================================================================
	move.l	ICONS_COORD_PTR(%fp),-(%sp)	|push previous handle ptr
	beq.s	NotCreated			|not created yet
		RC	HeapFreePtr		|else delete it
NotCreated:
	move.l	%d3,%d4				|counter for copy
	addq.l	#1,%d4				|number of entries
	lsl.l	#2,%d4				|size of handle to create
	addq.l	#2,%d4				|add size of #icons
	move.l	%d4,(%sp)			|push it over old handle ptr
	RC	HeapAllocPtr			|try to alloc and lock
	addq.l	#4,%sp				|pop arg
	move.l	%a0,ICONS_COORD_PTR(%fp)	|test and save it
	bne.s	TableCreated			|ok
		moveq.l	#ERROR_MEMORY,%d0	|error code
		bra	Quit			|and quit
TableCreated:
	move.w	%d3,(%a0)			|save counter at the beginning of the table
	adda.l	%d4,%a0				|end of list
FillTable:
	move.l	(%sp)+,-(%a0)			|get {x,y}, fixing sp
	dbra.w	%d3,FillTable			|loop for each icon
	movem.l	(%sp)+,%d3-%d6
	rts

Surtout su quelqu'un voit une coquille, qu'il n'hésite pas à me faire signe

L'allocation se fait dans la dernière partie (create coordinates table and quit), et le handle est rempli avec son nombre d'éléments (offset 0), puis des longwords. Le compteur est d3, initialisé à -1 aavnt la boucle et incrémenté à chaque fois.

Je vois pas. Désolé.

Merci quand même.

Reboot sous Fedora 8 pour pouvoir déboguer.

Suite du blog :
- Je n'écrase pas les handles enregistrés à HeapAllocPtr - 2. PedroM y accède juste lors du HeapFreePtr
- Lors d'un clean, j'ai un "system corrupted"
- Si je quitte le programme (bra Quit, donc sortie normale) juste après le remplissage du handle cité trois posts avant, ça ne plante pas. Ca ne devrait donc pas venir de mes écritures en RAM, vu que je n'y écris pas ailleurs. (tiens, bonne méthode, on va mettre des bra Quit en avançant progressivement dans le programme )

FOUND !!!

	movea.l	GL_FrameTimer(%fp),%a0
WaitSynchro:
	tst.l	(%a0)				|will be updated next frame
	beq.s	WaitSynchro
	clr.l	(%a0)				|reset it

unsigned short gl_frame_timer    [Global C Variable]
word: genlib::frame_timer     [Global ASM Variable]

(et vive la méthode des bra Quit, j'ai rien fait en trois jours et avec ça j'ai trouvé en 10 minutes )

J'allais donc péter l'adresse de la window d'après les sources. Mais pourquoi ça déconnait ? J'émulais sur HW2, et je ne me sers pas de la window. Genlib l'utilise en interne ?

edit -> ça doit être ça (genlib::quit):

		move.l	genlib@0041(pc),d0
		cmp.l	#LCD_MEM,d0
		beq.s	\no
			move.l	d0,-(a7)
			jsr	tios::HeapFreePtr
			addq.l	#4,a7

Du coup, PedroM devait essayer de libérer un handle inexistant... Et genlib::window sur HW2, c'est pas LCD_MEM... (d'ailleurs sur HW1, ça serait passé, parce que $00004c00. Par contre, comme c'est alloué avec HeapAllocPtr sur HW2, c'est en mémoire haute, et ya toutes les chances que l'adresse tienne pas sur deux octets.

Puis en plus c'est n'importe quoi cette variable sur deux octets. Et si une boucle de mon jeu dépasse en temps les 65535 frames affichées, hein ? Bon, alors

Une fois de plus une erreur qui ne se serait jamais produite si tu codais en C...

D'un autre côté, je me trompe jamais dans mes prototypes hein

("codez en C, il y a jamais de bugs" )

Justement, les prototypes, normalement ce n'est pas toi qui les définis, mais le header de la lib.

Je parle de ceux que j'aurais à écrire si je codais Et puis je code en assembleur et ça ne se discute pas d'un millimètre.

Kevin Kofler (./23) :
Une fois de plus une erreur qui ne se serait jamais produite si tu codais en C...

Et puis bon, si TiEmu n'était pas moins maintenu que VTI, j'aurais peut-être déjà vu le bug depuis longtemps...

Par contre, qui sait pourquoi ça déconnait pas avec un programme de 9 ko et que ça plantait avec un de 13 ? Juste à cause de la taille du opinteur de la window ? mais si le programme était plus grand, la window aurait dû être plus en mémoire basse, et avoir une adresse plus petite ? J'ai peut-être tout faux là ?

Moins maintenu que VTI? Fais gaffe à ce que tu dis, parce que je peux aussi arrêter de toucher à TiEmu dans les 8 années qui viennent, comme ça ton affirmation deviendra vraie. (Et encore, il faudra que tu maintennes VTI pendant ce temps. )

Kevin, tu es encore tombé dans le panneau d'une petite remarque faite par l'un d'entre nous...