pb ac l'expression stack - Page 1

j'utilise cette routine plusieurs fois:

push_parse_text((const char *)(pvc));
push_simplify(top_estack); // Simplification
strcpy(p->pname,GetStrnArg(top_estack));

et apres 3 secondes a cause je pense d'une surcharge de l'expression stack, le programme plante et je c pa pqoi

t((const char *)(pvc)); push_simplify(top_estack); // Simplification strcpy(p->pname,GetStrnArg(top_estack)); }

Effectivement. Il faut sauver l'estack avant de commencer ta boucle et la restaurer avant de la recommencer... En clair:ESI ptrsauve=top_estack;
while(1)    {
  top_estack=ptrsauve;
  push_parse_tex

Mais je ne suis pas certain.

ca marhce po, apres 4 appels a cette fonction, ca plante

c bizarre des fois ca bugue a 4 a peine et des fois ca va jusqu'a 32 :s

Bizarre... j'avais le même problème avec text walker (au bout d'une cinquantaine d'expressions pretty print, ça devenait n'importe quoi, mais il ne plantait pas, c'est ça le pire! [tu pouvais le quitter avec ESC sans problème])
J'ai fait:

ESI argptr;
[...]
argptr=top_estack;
[utilisation du top_estack pour afficher mon expression -> attention: ne pas utiliser argptr, il doit rester INTACT!]
top_estack=argptr;

et ça marche. Tu es sûr que tu as fait juste? Tu peux reposter le code que tu as à présent?

mon code la fonction qui met du txt est:
command=command+5;
strncpy (pvc, command, strlen(command)-1);
push_parse_text((const char *)(pvc));
push_simplify(top_estack); // Simplification
strncpy(pvc,GetStrnArg(top_estack),99);
DrawGrayStr2B( 2, 20, pvc, A_REPLACE,p->buffers.p0_b1, p->buffers.p1_b1);
return np+1;

et avant l'appel y'a:
ESI psav=top_estack;
et apres:
top_estack=psav;
et ca change rien

A quoi te sert la valeur np+1 retournée?
%lx",top_estack);Tu peux faire un:printf("à chaque tour pour voir si ça se modifie...

non je suis en niveaux de gris ac graphx le return np+1 permet de renvoyer la commande suivante a interpréter

[HS]à propos de graphx, ou peut-on le trouver svp [/HS]

http://alineasofts.free.fr (quand free n'est pas mort)

[HS][PUB]ExtGraph 2 est mieux. [/PUB][/HS]

Tu as essayé
printf("%lx",top_estack);
à chaque itération de la boucle?

Kevin Kofler :
[HS][PUB]ExtGraph 2 est mieux. [/PUB][/HS]

Le genre de commentaire stupide qui a à peu près autant de valeur que : ExtGraph 2 Sux

En plus, tu n'as même pas pris le temps de répondre sérieusement au topic, tu as juste trollé

Pour le problème, essaye:
*(volatile ESI *)&top_estack = argptr;
C'est peut-être l'optimiseur qui supprime les assignements "inutiles".

mouarf, gcc est quand même pas si buggé que ça, si ?

Si. PR 10021. Il va falloir que je passe au snapshot/release le plus récent, ça a déjà été corrigé.

L'optimiseur fait beaucoup de conneries. Tiens, pas plus tard qu'avant hier j'ai du mettre -O0 dans un de mes projets sinon il ne fonctionnait pas correctement dans certains cas (un truc très bizarre).

Maile-moi la source en question s'il te plaît (complète et compilable, ou alors un testcase réduit (mais compilable à lui seul) avec le même problème), pour que je puisse déboguer le problème.

ça a déjà
été corrigé.

, c'est vrai qu'ils sont rapides :

Opened: 2003-03-10 18:26

(ouvert en mars 2003 [pas en octobre, hein] )

Kevin Kofler :
*(volatile ESI *)&top_estack = argptr;

argptr correspond à quoi?

je t'ai envoyé les source de win2k3 par mail, le pb est dans multitask.h dans Exec_One() et ca le fait des que j'utilise en boucle une fonction qui utilise la stack

limmt
:

Kevin Kofler :
*(volatile ESI *)&top_estack = argptr;

argptr correspond à quoi?

ptrsauve dans ton code.

Maile-moi la source en question s'il te plaît (complète et compilable, ou alors un testcase réduit (mais compilable à lui seul) avec le même problème), pour que je puisse déboguer le problème.

Mince alors j'ai modifié le code entre temps (d'ailleurs maintenant je peux réactiver -Os sans problème mais bon je laisse -O0 au cas où).
nt il assumait qu'une variable avait une valeur prédéfinie alors qu'elle était modifiée quelque part. Si j'ajoute un printf entre deux par exemple, ça marche. Mais là, il devait faire un:for (i=0;i<j;i++)En fait apparemmeet j avait beau valoir quatre, il me faisait dix fois la boucle. Et bien sûr dès que j'essayais de déboguer le problème partait.

Brunni
:

Maile-moi la source en question s'il te plaît (complète et compilable, ou alors un testcase réduit (mais compilable à lui seul) avec le même problème), pour que je puisse déboguer le problème.

Mince alors j'ai modifié le code entre temps

J'en ai marre des gens qui ne reportent pas les bogues qu'ils rencontrent!!! Ça devrait être automatique!!!
Et puis tu es censé garder une copie de toutes tes anciennes versions, au cas où il y a un problème avec un de tes changements! Moi, je peux encore t'envoyer AutoClBr 1.00 si tu le veux! Et même quelques pré-alphas jamais sorties.
Et enfin, tu n'as pas à te plaindre qu'il y a un bogue si tu ne l'as pas reporté. C'est normal qu'il soit là si tu ne nous permets pas de le corriger.

nt il assumait qu'une variable avait une valeur prédéfinie alors qu'elle était modifiée quelque part. Si j'ajoute un printf entre deux par exemple, ça marche. Mais là, il devait faire un:for (i=0;i<j;i++)En fait apparemmeet j avait beau valoir quatre, il me faisait dix fois la boucle. Et bien sûr dès que j'essayais de déboguer le problème partait.

Ça ne me sert strictement à rien pour corriger le problème.

Et pour finir, vu qu'il n'y a pas de testcase, je vais partir du principe que c'est une erreur d'utilisateur, parce que de toute façon la plupart des "bogues" le sont. À toi de prouver le contraire.

g fait ce que tu m'a dit et ca marche tjs po

Et pour finir, vu qu'il n'y a pas de testcase, je vais partir du principe que c'est une erreur d'utilisateur, parce que de toute façon la plupart des "bogues" le sont. À toi de prouver le contraire.

Effectivement j'ai oublié de garder une copie...
De toutes façons si j'ai un bug complètement aléatoire (pourquoi ma boucle se ferait dix fois alors que je mets un printf("%i",j) et ça m'affiche 4? En plus, si quand j'enlève l'optimisation ça marche, il y a de quoi se demander...)
Bon, je vais essayer de reproduire l'erreur, pour voir...

En plus, si quand j'enlève l'optimisation ça marche, il y a de quoi se demander...

A priori ça peut tout aussi bien être une instabilité de ton prog, sauf si toi (ou Kevin) arrive à créer un testcase réduit.

A priori ça peut tout aussi bien être une instabilité de ton prog, sauf si toi (ou Kevin) arrive à créer un testcase réduit.

Ben j'y arrive pas. Je ferai un bug report la prochaine fois ou bien s'il réapparaît...
Limmt>Ben poste la source... (n'oublie pas les balises [pre] parce que c'est moche sinon) Et puis console-toi Kevin, j'utilise la version 0.94, donc ça aura peut-être déjà été corrigé entre deux! ;)

Pollux
:

En plus, si quand j'enlève l'optimisation ça marche, il y a de quoi se demander...

A priori ça peut tout aussi bien être une instabilité de ton prog, sauf si toi (ou Kevin) arrive à créer un testcase réduit.

En effet, voilà pourquoi je dis que c'est à lui de prouver que c'est un bogue du compilateur...

Ensuite, si c'est un bogue de l'optimisation, c'est normal que ça marche en -O0, c'est toujours le cas pour les bogues d'optimisateur (mais la réciproque est fausse, pas mal d'erreurs de programmes utilisateurs ne se manifestent également qu'en optimisant, surtout si elles sont dans la catégorie "aléatoire")! Il n'y a pas de quoi s'étonner!

Et enfin, compiler un programme en -O0 n'est jamais une solution raisonnable. -O0 est de la merde. Il n'est là que pour déboguer le compilateur, ou à la limite pour déboguer ton programme. Ou si vraiment tu n'acceptes pas d'attendre 3 secondes pour une compilation. Mais ce n'est clairement pas fait pour compiler les releases avec, le code généré est totalement pourri! Si le programme ne marche pas avec autre chose que -O0 (et encore, je parie qu'il aurait suffi de mettre le bon -fno-foo-optimization), il faut me mailer le programme et surtout pas le compiler en -O0.

limmt
: g fait ce que tu m'a dit et ca marche tjs po

Je vais regarder ton problème de plus près.