Memory fault à l'exécution

Bonjour,

Voilà mon problème :

Mon programme est exécuté sous linux et compilé via un makefile.

Le programme fonctionnait jusqu'à présent en Oracle V8 (il y a du proC).

Le moment est venu de passer à Oracle V10, donc je reprend mes soucres le makefile et je recompile. Après plusieurs essaie, le programme se compile sans erreur, mais voilà que quand je l'exécute il me met Memory Fault et sans le coredump entre parenthèse.

J'ai lu par ci par là que cela pourrait être due a une erreur de programmation, je ne pense pas puisque ce programme fonctionnait avant.

je compile avec ceci :

Code:

---

$(CPLUSPLUS) -o truc.exe $(USR_OBJ) -L$(LIBHOME) ${PROLDLIBS}

---

$(USR_OBJ) étant les .o.

Je ne sais pas de ou çà vient peut-être de la compilation?

Pourriez-vous m'aider svp, je rame sur çà depuis des jours...

Bonjour,

Citation:

---

Le moment est venu de passer à Oracle V10

---

Avez vous sous la main la documentation qui explique les différences entre les version V8 et V10 ?
Certaines functions/méthodes peuvent avoir un peu changé de comportement

Citation:

---

je compile avec ceci :

Code:

---

$(CPLUSPLUS) -o truc.exe $(USR_OBJ) -L$(LIBHOME) ${PROLDLIBS}

---

$(USR_OBJ) étant les .o.

---

Les fichiers objets (.o) sont ils recompilés ?

Citation:

---

Après plusieurs essais, le programme se compile sans erreur, mais voilà que quand je l'exécute il me met Memory Fault et sans le coredump entre parenthèse.

---

Avez vous intrumenté votre code pour savoir quelle(s) instruction(s) posai(en)t problème ?

Merci pour votre réponse

Citation:

---

Avez vous sous la main la documentation qui explique les différences entre les version V8 et V10 ?
Certaines functions/méthodes peuvent avoir un peu changé de comportement

---

Malheureusement non, je n'ai pas cette documentation...

Citation:

---

Les fichiers objets (.o) sont ils recompilés ?

---

Oui le objets sont recompilé, il y a du c++ et du ProC et c'est à mon avis la compilation du ProC qui pose problème voici commen je le compile :

Code:

---

1 2 3 4 5

$(OBJ_DIR)/proc.o : $(SRC_DIR)/proc.pc $(USR_INC) @echo "" @$(PROC) $(PROCFLAGS) iname=$(SRC_DIR)/proc.pc @echo "Compilation proc" @$(CPLUSPLUS) -c -D_DEBUG -D__hpux -g $(CCFLAGS) $(INCLUDE) -o $(OBJ_DIR)/proc.o $(SRC_DIR)/proc.c

---

avec :

Code:

---

1 2	PROCFLAGS=code=CPP mode=oracle parse=PARTIAL SQLCHECK=FULL release_cursor=yes userid=$(USERID) sys_include='($(SYS_INCLUDE))' include=\(/usr/include,$(INC_DIR)\) lines=true ireclen=256 oreclen=256 DEFINE=VERSIONPROC21 CCFLAGS = -g $(CPLUS_CFLAGS)

---

Citation:

---

Avez vous intrumenté votre code pour savoir quelle(s) instruction(s) posai(en)t problème ?

---

C'est-a-dire? Qu'entendez-vous par instrumenté?

débogué

Citation:

---

Envoyé par miketidy

Qu'entendez-vous par instrumenté?

---

Vous pouvez commencer par ajouter des commentaires aux endroits susceptibles de poser problème.

par exemple

Code:

---

1 2 3 4 5 6 7 8 9

#ifndef NDEBUG cout << "avant création de pfoo" << endl; #endif   Foo * pfoo = new Foo(bar);   #ifndef NDEBUG cout << "si on lit ceci, c'est que le construction s'est bien déroulée" << endl; #endif

---

Le problème est que le programme ne s'exécute pas donc comment fait pour voir ce qu'il ne fonctionne pas, j'enleve des fonctions et je vois si le programme s'exécute ou non?

Citation:

---

Envoyé par miketidy

Le problème est que le programme ne s'exécute pas donc comment fait pour voir ce qu'il ne fonctionne pas, j'enleve des fonctions et je vois si le programme s'exécute ou non?

---

C'est l'idée : trouver où ça coince.

Par contre, un programme s'exécute toujours. Il n'a pas toujours accès à une console, mais il est toujours possible de conserver une trace de l'exécution dans un fichier log.

Justement j'ai la trace de l'exécution dans un fichier de log mais il est ecrit Memory fault.

Le plus suprenant ce que quand j'ai compilé en Oracle V8, j'ai eu des erreurs de coredump qui ont été résolu à la compilation des fichiers.
A noté qu'a chaque foi que j'avait un coredump, j'avai mon exécutable qui ne faisait pas le bonne taille et là en Oracle V10 j'ai la taille de mon exe différente mais l'erreur est Memory fault.

Citation:

---

Envoyé par miketidy

J'ai lu par ci par là que cela pourrait être due a une erreur de programmation, je ne pense pas puisque ce programme fonctionnait avant.

---

Un bug était peut-être masqué avec la version antérieure d'Oracle et resurgit maintenant. Que le programme ait marché ne veut surtout pas dire qu'il était exempt de bug mais seulement que soit tu n'es pas tombé dessus, soit ses conséquences n'étaient pas immédiatement visibles.

Dans ce genre de cas, effectivement, l'instrumentation est une bonne méthode. Commence par le début:

Code:

---

1 2 3

main(){ cout<<"ouf! ca démarre";

---

En fait, pour être exact, le début, ce sont les constructeurs de tes variables globales qui seront appelés avant le main. Donc une petite instrumentation de ceux-ci est aussi indispensable. Attention à bien instrumenter les classes parents, ainsi que les membres.
Ensuite, tu raffines. Si ca démarre, ben, tu commence à instrumenter plus bas: "construction de mon premier objet", "initialisation de l'appli", "ouverture de l'IHM", etc.. jusqu'à découvrir le nœud du problème.
Enfin, si tu le peux, la meilleure instrumentation, ce sont les point d'arrêts et un bon debugger.
Bon courage.

J'ai peut-être trouvé de où çà vient.

Tout d'abord j'ai augmentait la taille du coredump pour avoir fichier core.

Grace à ceci, il me donne une erreur de segmentation, voici la fonction qui est en erreur :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

void CRequeteSql::GereCurseur() { if (numcursor) { short *toto; toto = (short *)sqlcud0 + 8 ; *toto = numcursor ; toto =(short *) sqlcud0 + 27 ; *toto = numcursor ; toto =(short *)sqlcud0 + 46 ; *toto = numcursor ; toto = (short *)sqlcud0 + 65 ; *toto = numcursor ; toto = (short *)sqlcud0 + 84 ; *toto = numcursor ; toto = (short *)sqlcud0 + 99 ; *toto = numcursor ; toto = (short *)sqlcud0 + 118 ; *toto = numcursor ; } }

---

Je ne suis pas très fort en c++ et je n'ai pas fait ce programme donc je ne sais pas pourquoi il y a une erreur apperement une erreur d'allocation mémoire voici l'erreur donné dans le fichier core :

Code:

---

1 2	CRequeteSql::GereCurseur (this=0xfeff7bd4) at /devl/sap1/unix/src/psreq.pc:176 176 *toto = numcursor ;

---

Merci de m'aider :)

Ce bout de code n'est pas très élégant...

Que fait il ?

on peut écrire

Code:

---

1 2 3 4 5 6 7

short *toto; toto = (short *)sqlcud0 + 8 ; *toto = numcursor ; toto =(short *) sqlcud0 + 27 ; *toto = numcursor ; toto =(short *)sqlcud0 + 46 ; *toto = numcursor ;

---

De cette facon :

Code:

---

1 2 3 4

short * toto = sqlcud0; toto[8] = numcursor; toto[27] = numcursor; toto[46] = numcursor;

---

En fait, on un modifie les données d'un tableau qu'on sait être de type short[]. Ce tableau est pointé par sqlcud0.

Ce qu'il faudrait savoir c'est ce qui se cache réellement derrière sqlcud0.

Dès que y'a des casts de pointeurs de type reinterpret_cast, ça sent mauvais, forcément...

Ce n'est pas moi qui l'est programmé :)

Je sais qu'il n'est pas très élégant,

Je ne sais pas ce qu'est réelment sqlcud0, au début de la fonction, il y a tout de même un commentaire :

Code:

---

1 2	/* modifie la structure sqlcud0 creer par la precompilation pour   faire correspondre le numero de curseur de l'instance */

---

Cela vous parle ou non?

Merci mabu je vais essayé ce que tu as mis.

J'ai modifié la fonction, voici ce qu'il me met comme erreur :

Code:

---

1 2	/devl/sap1/unix/src/psreq.pc: In member function `void CRequeteSql::GereCurseur()': /devl/sap1/unix/src/psreq.pc:189: error: invalid conversion from `const short int*' to `short int*'

---

Merci de votre aide

Citation:

---

Envoyé par miketidy

Merci mabu je vais essayé ce que tu as mis.

---

Hou là, j'avais juste écrit ça pour expliquer plus clairement ce que le code faisait, mais s'il y a un problème dans le code, avec la réécriture donnée, il y sera toujours.

Il faut vraiment savoir ce qu'est sqlcud0, quel est sa taille, quelle partie du code s'occupe de sa création, quels modules y ont accès en lecture...

Code:

---

error: invalid conversion from `const short int*' to `short int*'

---

Hum, cela nous indique au moins un fait intéressant : cette fonction modifie des données déclarés comme constantes. Ça sent mauvais.

Je ne la trouve déclaré nulle part dans les sources, je ne comprends pas ce que fait sqlcud0...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

/* cud (compilation unit data) array */ static const short sqlcud0[] = {8,4128, 2,0,0,1,64,0,9,44,0,1,1,0,1,0,1,9,0,0, 20,0,0,1,0,0,13,50,0,1,0,0,1,0,2,9,0,0, 38,0,0,1,0,0,15,65,0,0,0,0,1,0, 52,0,0,2,0,0,29,72,0,0,0,0,1,0, 66,0,0,3,51,0,9,83,0,0,0,0,1,0, 80,0,0,3,0,0,13,85,0,1,0,0,1,0,2,3,0,0, 98,0,0,4,72,0,4,86,0,3,1,0,1,0,2,9,0,0,2,9,0,0,1,3,0,0, 124,0,0,5,42,0,47,93,0,0,0,0,1,0, 138,0,0,3,0,0,15,96,0,0,0,0,1,0, 152,0,0,6,0,0,29,97,0,0,0,0,1,0, 166,0,0,7,0,0,29,103,0,0,0,0,1,0, 180,0,0,8,0,0,31,111,0,0,0,0,1,0, 194,0,0,9,0,0,27,163,0,3,3,0,1,0,1,9,0,0,1,10,0,0,1,10,0,0, 220,0,0,10,121,0,6,169,0,2,2,0,1,0,2,9,0,0,2,3,0,0, };

---

si tu trouves ce tableau, change le const en pas const. Il est probable que ce tableau est placé en memoire read only, enfin ca peut arriver. Le probleme, c'est que peut etre ce tableau est generé par le precompilateur

Une autre solution est de compiler en rajoutant le flag "-fwritable-strings" ou "-fwritable-string"

en dernier recours, modifie le makefile :

Code:

---

1 2 3 4 5 6 7

$(OBJ_DIR)/proc.o : $(SRC_DIR)/proc.pc $(USR_INC) @echo "" @$(PROC) $(PROCFLAGS) iname=$(SRC_DIR)/proc.pc @echo "Bug Fixing" @sed --in-place=.bak -e "s/static const short sqlcud0/static short sqlcud0/" $(SRC_DIR)/proc.c @echo "Compilation proc" @$(CPLUSPLUS) -c -D_DEBUG -D__hpux -g $(CCFLAGS) $(INCLUDE) -o $(OBJ_DIR)/proc.o $(SRC_DIR)/proc.c

---

j'ai pas testé mais tu vois le genre

dernier point, envoie un mail a l'andouille qui a ecrit ce code, car une variable toto qui pointe sur un truc const et en plus de maniere tordue, c'est a la limite de la faute professionnelle.

Merci screetch!

Citation:

---

si tu trouves ce tableau, change le const en pas const. Il est probable que ce tableau est placé en memoire read only, enfin ca peut arriver. Le probleme, c'est que peut etre ce tableau est generé par le precompilateur

Une autre solution est de compiler en rajoutant le flag "-fwritable-strings" ou "-fwritable-string"

---

Apperement ce tableau est généré par le précompilateur.
Je vais tester ce que tu propose, j'espere que ca va fonctionner cette fois-ci...

Citation:

---

dernier point, envoie un mail a l'andouille qui a ecrit ce code, car une variable toto qui pointe sur un truc const et en plus de maniere tordue, c'est a la limite de la faute professionnelle.

---

:lol: C'est sur et il y a pire comme variable : un exemple : onsecasssedelavitefaitbienfait alors tu vois on dirait que le mec a fait çà pour lui...

En tout cas merci pour ces infos, je vais essayé le makefile...

Merci çà fonctionne nickel :king:

cool! euh, laquelle de mes trois propositions ? :)
le flag -fwritable-strings a été deprécié a partir de gcc 4.0 ou 4.1 et sans doute eliminé a partir de gcc 4.3 ou 4.4 donc c'est un peu dangereux :)

Pourquoi ne pas tout simplement virer le const du code source ?
Ou bien, si plus approprié, faire une copie de ces données et ne modifier que la copie ?

Citation:

---

cool! euh, laquelle de mes trois propositions ?

---

J'ai utilisé la derniere avec le makefile...

Citation:

---

Pourquoi ne pas tout simplement virer le const du code source ?
Ou bien, si plus approprié, faire une copie de ces données et ne modifier que la copie ?

---

Tout simplement parce que dans le code source la déclaration n'y est pas, elle est déclaré par la precompilation.

Citation:

---

Envoyé par miketidy

:lol: C'est sur et il y a pire comme variable : un exemple : onsecasssedelavitefaitbienfait alors tu vois on dirait que le mec a fait çà pour lui...

---

Ou encore celle-ci, tirée de là : http://quadaemon.free.fr/tribune.fortune

Citation:

---

16:39 on m'a demander de debugger un prog C qui marche pas, pour faire
simple j'ai remplacé tous les malloc( x) par des mallox( x * 100 )
... et bien maintenant ça marche ... aller Zou ! au suivant !

---

C'est qu'on se dit qu'il y en a plein dans la nature, des comme çà ! :-)

Citation:

---

Envoyé par miketidy

J'ai utilisé la derniere avec le makefile...

---

mon dieu c'est ce que je craignais, je suis capable d'ecrire des commandes "sed" sans les tester... et dans un makefile en plus... quel monstre suis-je devenu.....

Citation:

---

mon dieu c'est ce que je craignais, je suis capable d'ecrire des commandes "sed" sans les tester... et dans un makefile en plus... quel monstre suis-je devenu.....

---

Et j'ai meme modifié ce que tu as écrit :lol:

encore merci!!

Citation:

---

C'est qu'on se dit qu'il y en a plein dans la nature, des comme çà ! :-)

---

Et oui! et encore cette variable un collegue l'a retrouvé dans une autre appli
Serieux!:aie:

Es-tu sûr au moins qu'il est normal qu'une telle variable globale soit modifiée ?

PS: Utilise explicitement un const_cast<> plutôt que ces horribles casts C-Style: Cela t'évitera bien des migraines à l'avenir...