Bug Timer sur appel IntToStr ?

Bonjour,

Dans un projet FireMonkey Win32, je tente d'appeler IntToStr dans l'évènement Tick d'un timer (affichage d'un compte à rebours).

L'appli plante que ce soit en mode débogage ou en exécution directe de l'exe.

Mieux, il suffit que l'appel à IntToStr se trouve dans l'évènement, même s'il n'est pas exécuté...

Cette simple ligne, même si vl_test vaut false fait planter le programme.

Code:

---

1 2	if vl_test then system.sysutils.inttostr(0);

---

En fait le programme semble planter non pas au moment de l'évènement Tick du timer, mais au moment du Application.Run.

Même problème avec FloatToStr.

Si le projet est compilé pour Win 64, aucun problème.

Quelqu'un sait-il reproduire ? (Delphi XE2 Update 4)

Merci
André.

plait-il ?

donc je lance XE2 Update4
je crée un nouveau projet Firemonkey HD
je place un Timer
sur le onTimer j'ajoute le code suivant

Code:

---

1 2 3 4 5

procedure TForm3.Timer1Timer(Sender: TObject); begin System.SysUtils.IntToStr(0); end;

---

je lance

il ne se passe rien.

Au passage, l'optimisation par le compilateur ne supprime-t-elle pas une telle ligne qui ne sert à rien ?

Ton timer est-il bien enable ? Valeur du tick ? (sur mon exemple 1000 ) Car je reproduis la chose sans probleme. D'ailleurs le simple fait que le programme 32 plante et pas le 64 pose question.

Precision : delphi installe sur un pc sous seven 64.

Quelqu'un d'autre ?

pour voir ce que ça donne en win32

Cordialement

André

PS je viens d’écrire une bêtise, le type integer est identique en 32 ou 64 bit

Pour info, l'appli utilise des composants tiers, normalement tout fmx. Mais je viens de voir qu'un de ces composants a une methode qui me renvoie un vcl.graphics.tbitmap au lieu d'un fmx.type.tbitmap. Ce qui pourrait expliquer le comportement curieux si on a du vcl dans du fmx. Cela dit si je supprime ce composant, j'ai le meme souci. J'ai contacte le support a ce sujet et j'attends leur retour.

Citation:

---

Envoyé par sinfoni

Ton timer est-il bien enable ? Valeur du tick ? (sur mon exemple 1000 ) Car je reproduis la chose sans probleme. D'ailleurs le simple fait que le programme 32 plante et pas le 64 pose question.

Precision : delphi installe sur un pc sous seven 64.

Quelqu'un d'autre ?

---

Seven 64,

mais tu parles d'un projet qui plante et incrimine l'appel d'une fonction standard dans un Timer, à moins de pouvoir reproduire le bug dans une manip aussi simple que celle que j'ai donné, le support ne te sera d'aucun secours ou t'invitera a supprimer tous les composants tiers.

de plus tu parles d'un plantage au lancement de l'appli, ce qui n'a aucun rapport avec le code placé dans l'évènement d'un timer, lequel timer n'est pas encore créé !

J'ai contacte le support du composant tiers, pas de Delphi.
Et effectivement, l'appli plante non pas a l'execution du code inttostr mais sur le application.run. Il suffit que je mette le inttostr en commentaire et la plus de souci.

Bonjour,

Citation:

---

Envoyé par sinfoni

Et effectivement, l'appli plante non pas a l'execution du code inttostr mais sur le application.run.

---

Avez tenté un débugage pas à pas approfondi pour voir jusqu'où l'application fonctionne ?
Ou placer des points d'arrêts à différents endroits de la fiche impliquée dans le plantage ?
--
Philippe.

Bonjour,

Je viens de faire le test avec s:=inttostr(50) dans l'évènement timer.
Je n'ai constaté aucun problème de compilation (W7 32 bits).

Citation:

---

Envoyé par Ph. B.

Bonjour,
Avez tenté un débugage pas à pas approfondi pour voir jusqu'où l'application fonctionne ?
Ou placer des points d'arrêts à différents endroits de la fiche impliquée dans le plantage ?
--
Philippe.

---

Bien sûr. Mais là encore, comportement étrange, la ligne où le plantage intervient est aléatoire. Le plus souvent le programme s'arrête sur application.run.... Jamais sur la ligne en question.

Bonjour,

Citation:

---

Envoyé par sinfoni

Bien sûr. Mais là encore, comportement étrange, la ligne où le plantage intervient est aléatoire. Le plus souvent le programme s'arrête sur application.run.... Jamais sur la ligne en question.

---

Y-a-t-il un message d'erreur ou est ce un plantage au sens blocage de l'application sans message ?
J'ai réalisé une application simple sous XE2 Update 4 sans constater le moindre dysfonctionnement. (Windows XP Home SP3 32 bits, Pentium 4 2,3Ghz).
Peut-être un des composants FMX tiers que vous avez mentionnées ? à découvrir par élimination ?
Ou alors placer des informations de débogage un peu partout dans les unités pour voir jusqu'où fonctionne l'application, voire procéder par raffinage successif ?
--
Philippe.

Si l'application plante sur run alors c'est très certainement le chargement des unités externes d'une unité du programme qui pose problème. Essaie de prefixer les unités qui peuvent l'être avec "fmx.". Supprime les ".dcu" et autres de ton projet

Finalement, le problème est causé par cet appel au niveau du timer:

Code:

---

1 2	SetThreadExecutionState(ES_CONTINUOUS or ES_SYSTEM_REQUIRED);

---

dont la déclaration est :

Code:

---

function SetThreadExecutionState(State: integer): bool; external 'kernel32.dll'; // Contrôle mise en veille

---

Vous pouvez donc sans doute maintenant reproduire facilement le problème.

Mais attention, le plantage n'intervient pas quand cette fonction est appelée, en tout cas au niveau du debbuger. Le comportement reste curieux, à savoir qu'il suffit que le IntToStr soit présent, même si jamais appelé, et que cette fonction soit, elle, appelée. Mais le plantage (Le projet a déclenché la classe d'exception $C0000005 Access violation at 0x0000000000: read of address 0x0000000000) ne se produit ni sur l'appel de la fonction, ni sur l'exécution du IntToStr.

André.

l'ajout d'un "stdcall" corrigerait sans doute le problème :)

Absolument ! :)

Le nombre de zéro dans 0x0000000000 est un peu élevé, fait gaffe tout de même, si 8 zéros c'est 32bits, et 16 zéros c'est du 64Bits, comme ton bug est lié à l'archi, autant être précis

Pour "stdcall", effectivement, si totalement inutile en 64bits, la convention d'appel doit être spécifié en 32Bits !

Oui effectivement, d'où l'absence de problème en compilant en 64Bits...