Discussion :

[miketidy]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

$(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...

[Invité(e)]

Bonjour,

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

je compile avec ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

$(USR_OBJ) étant les .o.

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

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 ?

[miketidy]

Merci pour votre réponse

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...

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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)

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é?

[loufoque]

débogué

[Invité(e)]

Qu'entendez-vous par instrumenté?

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

par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[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?

[Invité(e)]

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.

[3DArchi]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[miketidy]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Merci de m'aider

[Invité(e)]

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

Que fait il ?

on peut écrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[loufoque]

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

[miketidy]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.