bonjour,
Je développe une application en utilisant PODS (Palm OS Developper Suite) en
utilisant des routines ARM Natives.
A partir de mes routines natives, je fais des appels d'allocation dynamique
de la mémoire.
Sous le simulateur TX, mon appli fonctionne parfaitement bien.
Mais à partir de mon TX, mon appli provoque un reset dès que j'alloue un
bloc > 60000 octets.
D'où ma question, cette routine est-elle buggée ? Sinon, l'erreur vient
d'ailleurs prélablement à son utilisation ?
Merci
Frédéric
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Frédéric Coste
Non non !!
Cette routine est appelée uniquement à partir du code ARM Natif.
Mais bon, apparemment, le code ne te choque pas...donc le problème doit être ailleurs. D'autant plus qu'il fonctionne parfaitement avec le Simulateur TX.
Je cherche.....
Merci Patrick Frédéric
"Patrick Vuichard" a écrit dans le message de news:
Cette routine est appelée uniquement à partir du code ARM Natif.
Mais bon, apparemment, le code ne te choque pas...donc le problème doit être
ailleurs.
D'autant plus qu'il fonctionne parfaitement avec le Simulateur TX.
Je cherche.....
Merci Patrick
Frédéric
"Patrick Vuichard" <Patrick.Vuichard@wanadoo.fr> a écrit dans le message de
news: 4g9r12F1mh94nU1@individual.net...
Cette routine est appelée uniquement à partir du code ARM Natif.
Mais bon, apparemment, le code ne te choque pas...donc le problème doit être ailleurs. D'autant plus qu'il fonctionne parfaitement avec le Simulateur TX.
Je cherche.....
Merci Patrick Frédéric
"Patrick Vuichard" a écrit dans le message de news:
et j'appele ma routine qui plante de la façon suivante : " ... NativeCPC->pbGPBuffer = (tUChar*)MemPtrNew(SIZETAB_GPBUFFER, NativeCPC->memOwnerID, emulStateP, call68KFuncP); ... "
memOwnerID est un mot 16 bits et est aligné sur une adresse paire que se soit en 68k ou en ARM (si j'ai bien compris).
le OwnerID est passé dans le troisième paramètre : " ... *((tUShort*)(&(args[6]))) = (tUShort)EndianSwap16(OwnerID | memNewChunkFlagNonMovable | memNewChunkFlagAllowLarge); ... "
Je suis d'accord avec toi, j'utilise un FrmAlert pour savoir si j'arrive à mon point :)
Merci Patrick pour le temps que tu me consacre :)
"Patrick Vuichard" a écrit dans le message de news:
[j'espère qu'il n'y aura pas de doublon...]
Frédéric Coste a écrit, le 26/06/2006 18:53 :
Cette routine est appelée uniquement à partir du code ARM Natif.
Ok. Tu es sûr qu'aucun des paramètres ne vient de la partie 68k ?
Mais bon, apparemment, le code ne te choque pas...donc le problème doit être ailleurs.
Moui, enfin, j'ai pu passer au travers. Ah, tiens, pourquoi ne mets-tu pas le ownerId ? Tu le forces à 8 ?
D'autant plus qu'il fonctionne parfaitement avec le Simulateur TX.
Hum, le problème, c'est que tu ne testes pas directement ton PNO avec le Simulateur, mais une DLL Windows.
Je suppose que tu n'as pas de cable série pour utiliser le débugger ? Dans ce cas, il reste le bon vieux WinDrawChars(), pour voir où ça plante...
et j'appele ma routine qui plante de la façon suivante :
"
...
NativeCPC->pbGPBuffer = (tUChar*)MemPtrNew(SIZETAB_GPBUFFER,
NativeCPC->memOwnerID, emulStateP, call68KFuncP);
...
"
memOwnerID est un mot 16 bits et est aligné sur une adresse paire que se
soit en 68k ou en ARM (si j'ai bien compris).
le OwnerID est passé dans le troisième paramètre :
"
...
*((tUShort*)(&(args[6]))) = (tUShort)EndianSwap16(OwnerID |
memNewChunkFlagNonMovable | memNewChunkFlagAllowLarge);
...
"
Je suis d'accord avec toi, j'utilise un FrmAlert pour savoir si j'arrive à
mon point :)
Merci Patrick pour le temps que tu me consacre :)
"Patrick Vuichard" <Patrick.Vuichard@wanadoo.fr> a écrit dans le message de
news: 4gaknnF1jh1hhU1@individual.net...
[j'espère qu'il n'y aura pas de doublon...]
Frédéric Coste a écrit, le 26/06/2006 18:53 :
Cette routine est appelée uniquement à partir du code ARM Natif.
Ok. Tu es sûr qu'aucun des paramètres ne vient de la partie 68k ?
Mais bon, apparemment, le code ne te choque pas...donc le problème doit
être ailleurs.
Moui, enfin, j'ai pu passer au travers. Ah, tiens, pourquoi ne mets-tu
pas le ownerId ? Tu le forces à 8 ?
D'autant plus qu'il fonctionne parfaitement avec le Simulateur TX.
Hum, le problème, c'est que tu ne testes pas directement ton PNO avec le
Simulateur, mais une DLL Windows.
Je suppose que tu n'as pas de cable série pour utiliser le débugger ?
Dans ce cas, il reste le bon vieux WinDrawChars(), pour voir où ça
plante...
et j'appele ma routine qui plante de la façon suivante : " ... NativeCPC->pbGPBuffer = (tUChar*)MemPtrNew(SIZETAB_GPBUFFER, NativeCPC->memOwnerID, emulStateP, call68KFuncP); ... "
memOwnerID est un mot 16 bits et est aligné sur une adresse paire que se soit en 68k ou en ARM (si j'ai bien compris).
le OwnerID est passé dans le troisième paramètre : " ... *((tUShort*)(&(args[6]))) = (tUShort)EndianSwap16(OwnerID | memNewChunkFlagNonMovable | memNewChunkFlagAllowLarge); ... "
Je suis d'accord avec toi, j'utilise un FrmAlert pour savoir si j'arrive à mon point :)
Merci Patrick pour le temps que tu me consacre :)
"Patrick Vuichard" a écrit dans le message de news:
[j'espère qu'il n'y aura pas de doublon...]
Frédéric Coste a écrit, le 26/06/2006 18:53 :
Cette routine est appelée uniquement à partir du code ARM Natif.
Ok. Tu es sûr qu'aucun des paramètres ne vient de la partie 68k ?
Mais bon, apparemment, le code ne te choque pas...donc le problème doit être ailleurs.
Moui, enfin, j'ai pu passer au travers. Ah, tiens, pourquoi ne mets-tu pas le ownerId ? Tu le forces à 8 ?
D'autant plus qu'il fonctionne parfaitement avec le Simulateur TX.
Hum, le problème, c'est que tu ne testes pas directement ton PNO avec le Simulateur, mais une DLL Windows.
Je suppose que tu n'as pas de cable série pour utiliser le débugger ? Dans ce cas, il reste le bon vieux WinDrawChars(), pour voir où ça plante...
Oui, tu as raison pour l'utilisation unique de variables 32bits alloués.
Maintenant, j'exploite une autre possibilité en faisant faire le travail au 68k. Je saurai ce soir si cette méthode est préférable.
Autrement, je sais que j'avais un reset au moment où j'utilisais la partie memchunknew de ma fonction. Mais bon, je vais chercher un peu pour te donner de meilleures infos.
Merci Patrick :)
"Patrick Vuichard" a écrit dans le message de news:
Frédéric Coste a écrit, le 26/06/2006 20:16 :
memOwnerID est un mot 16 bits et est aligné sur une adresse paire que se soit en 68k ou en ARM (si j'ai bien compris).
En théorie, oui, mais par prudence, il vaut mieux n'utiliser que des variables alloués (dans la heap et non dans la stack) ayant des tailles multiples de 32 bits.
Je suis d'accord avec toi, j'utilise un FrmAlert pour savoir si j'arrive à mon point :)
Oui, tu as raison pour l'utilisation unique de variables 32bits alloués.
Maintenant, j'exploite une autre possibilité en faisant faire le travail au
68k.
Je saurai ce soir si cette méthode est préférable.
Autrement, je sais que j'avais un reset au moment où j'utilisais la partie
memchunknew de ma fonction.
Mais bon, je vais chercher un peu pour te donner de meilleures infos.
Merci Patrick :)
"Patrick Vuichard" <Patrick.Vuichard@wanadoo.fr> a écrit dans le message de
news: 4gf59tF1mmq2jU2@individual.net...
Frédéric Coste a écrit, le 26/06/2006 20:16 :
memOwnerID est un mot 16 bits et est aligné sur une adresse paire que se
soit en 68k ou en ARM (si j'ai bien compris).
En théorie, oui, mais par prudence, il vaut mieux n'utiliser que des
variables alloués (dans la heap et non dans la stack) ayant des tailles
multiples de 32 bits.
Je suis d'accord avec toi, j'utilise un FrmAlert pour savoir si j'arrive
à mon point :)
Oui, tu as raison pour l'utilisation unique de variables 32bits alloués.
Maintenant, j'exploite une autre possibilité en faisant faire le travail au 68k. Je saurai ce soir si cette méthode est préférable.
Autrement, je sais que j'avais un reset au moment où j'utilisais la partie memchunknew de ma fonction. Mais bon, je vais chercher un peu pour te donner de meilleures infos.
Merci Patrick :)
"Patrick Vuichard" a écrit dans le message de news:
Frédéric Coste a écrit, le 26/06/2006 20:16 :
memOwnerID est un mot 16 bits et est aligné sur une adresse paire que se soit en 68k ou en ARM (si j'ai bien compris).
En théorie, oui, mais par prudence, il vaut mieux n'utiliser que des variables alloués (dans la heap et non dans la stack) ayant des tailles multiples de 32 bits.
Je suis d'accord avec toi, j'utilise un FrmAlert pour savoir si j'arrive à mon point :)
Bon, hier soir, j'ai séparé les routines d'allocation mémoire. Je laisse en Natif pour l'appel de MemPtrNew, par contre, j'effectue une allocation avec MemChunkNew en passant par une routine 68k qui fait l'appel à MemChunkNew.
De cette façon, mon TX ne reset plus. J'ai l'impression que les allocations sont acceptées.
Merci Patrick ;)
PS : Un problème en cachant tout de suite un autre, je te poserai bientôt une autre question, concernant un autre problème en PNO. Bonne journée :)
"Patrick Vuichard" a écrit dans le message de news:
Frédéric Coste a écrit, le 28/06/2006 20:17 :
Mais bon, je vais chercher un peu pour te donner de meilleures infos.
Merci Patrick :)
De rien, ça me change de mes propres problèmes avec CodeWarrior qui me les brise menu en ce moment (ce qui m'empèche de terminer mes PNO, d'ailleurs).
Bon, hier soir, j'ai séparé les routines d'allocation mémoire.
Je laisse en Natif pour l'appel de MemPtrNew, par contre, j'effectue une
allocation avec MemChunkNew en passant par une routine 68k qui fait l'appel
à MemChunkNew.
De cette façon, mon TX ne reset plus.
J'ai l'impression que les allocations sont acceptées.
Merci Patrick ;)
PS : Un problème en cachant tout de suite un autre, je te poserai bientôt
une autre question, concernant un autre problème en PNO. Bonne journée :)
"Patrick Vuichard" <Patrick.Vuichard@wanadoo.fr> a écrit dans le message de
news: 4gg32dF1mt9c5U1@individual.net...
Frédéric Coste a écrit, le 28/06/2006 20:17 :
Mais bon, je vais chercher un peu pour te donner de meilleures infos.
Merci Patrick :)
De rien, ça me change de mes propres problèmes avec CodeWarrior qui me les
brise menu en ce moment (ce qui m'empèche de terminer mes PNO,
d'ailleurs).
Bon, hier soir, j'ai séparé les routines d'allocation mémoire. Je laisse en Natif pour l'appel de MemPtrNew, par contre, j'effectue une allocation avec MemChunkNew en passant par une routine 68k qui fait l'appel à MemChunkNew.
De cette façon, mon TX ne reset plus. J'ai l'impression que les allocations sont acceptées.
Merci Patrick ;)
PS : Un problème en cachant tout de suite un autre, je te poserai bientôt une autre question, concernant un autre problème en PNO. Bonne journée :)
"Patrick Vuichard" a écrit dans le message de news:
Frédéric Coste a écrit, le 28/06/2006 20:17 :
Mais bon, je vais chercher un peu pour te donner de meilleures infos.
Merci Patrick :)
De rien, ça me change de mes propres problèmes avec CodeWarrior qui me les brise menu en ce moment (ce qui m'empèche de terminer mes PNO, d'ailleurs).
