bus error sur une machine SUN

**mhtrinh** · 05/07/2006, 20h19

Bonjour,

J'ai developpez un code sur des machine Linux (Suse et Fedora)
Tout marche bien, ca compile bien.

La je dois basculer sur une machine SUN :

Code :

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

1
2
3
 
pbil:subtil uname -a
SunOS pbil 5.9 Generic_117171-07 sun4u sparc SUNW,Sun-Fire-880

Ca compile bien mais a l'execution j'ai un "Bus error"

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
pbil:subtil make
g++ -Wall -I. -g -O2 -c Chabot.cxx -o Chabot.o
g++ -Wall -I. -g -O2 -c libChabot.cxx -o libChabot.o
g++ -Wall -I. -g -O2 -c GereChabot.cxx -o GereChabot.o
g++ -Wall -I. -g -O2 -c constantes.cxx -o constantes.o
g++ -Wall -I. -g -O2 -c Environnement.cxx -o Environnement.o
g++ -Wall -I. -g -O2 -c main.cxx -o main.o
main.cxx: In function `int main(int, char**)':
main.cxx:28: warning: unused variable `Chabot*unChabot'
g++ -Wall -I. -g -O2 -o exe Chabot.o libChabot.o GereChabot.o constantes.o Environnement.o main.o
pbil:subtil ./exe
Bus error

Ce qui est bisare c'est que sur ma machine Fedora, ca s'execute sans probleme.
Le pire c'est que je n'arrive pas a debugger avec gdb sur la machine SUN, il me dis quasiment tout le temps "Cannot access memory at address"

Pourriez me donner une piste ?

mat.M · 05/07/2006, 21h55

Fedora/Linux et Sun ce sont 2 choses différentes ;
Linux est peut-être + souple et permissif sur les allocations et ...fuites mémoires
En d'autres termes si fuite mémoire ou faute de protection mémoire sous SUN alors blocage de l'OS

donc vérifier tous les malloc, free et autres

**Jean-Marc.Bourguet** · 05/07/2006, 22h05

Envoyé par mhtrinh

Le pire c'est que je n'arrive pas a debugger avec gdb sur la machine SUN, il me dis quasiment tout le temps "Cannot access memory at address"

Pourriez me donner une piste ?

Les deux différences qui me semblent pertinentes sont:
- sparc est big endian, x86 little endian
- sparc a besoin que les accès mémoires soient correctement alignés

Quelle est donc cette adresse à laquelle tu ne peux pas accèder, et comment la formes-tu?

**mhtrinh** · 05/07/2006, 23h24

Pour les fuites de memoires je vais essayer de les trouver. Ca va etre dur

(et encore plus sans gdb

)

Pour ce qui conserne gdb ... en fait je n'arrive pas a acceder a aucune variable. Exemple concret :
dans le main :

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
 
int main(int argc,char **argv)
{
    int test = 0;
    // Seed pour la fonction rand
    srand(time(NULL));
 
 
    GereChabot *pop;
    Chabot *unChabot;
 
    Environnement *env;
    Param opt;
    charger(CONFIG_FILE,&opt);
    //printf("apres charger(): %d\n",opt.taille_souspatch);
    env = new Environnement(&opt);
 
    //    printObstacle(stderr,&env,&opt);
    env->chargerEnvironnement();
 
...

dans gdb :

Code :

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

1
2
3
4
(gdb) p test
No symbol "test" in current context.
(gdb) p opt
Cannot access memory at address 0xffbfc648

Pourtant dans le make il y a bien le -g.

**PRomu@ld** · 06/07/2006, 07h38

Attention ceci est du C++, tu n'es pas sur le bon forum ...

Pour les fuites de memoires je vais essayer de les trouver. Ca va etre dur (et encore plus sans gdb )

Pas besoin de gdb, des fprintf (ou cerr pour le C++) un peu partout, et vérifie toutes les allocations mémoire

**joellel** · 06/07/2006, 09h27

Bus error arrive quand tu essaies d'accéder à une adresse inexistante (par exemple valeur d'adresse supérieure à la taille de l'espace d'adressage du processus). Celà explique que d'un système à l'autre, il peut y avoir des différences.
Cherche dans quelle portion de code ça se produit, avec des printf() si gbd ne veut rien savoir

La plupart du temps (d'après mon expérience sous Solaris

), il s'agit de l'utilisation d'un pointeur non initialisé.

mat.M · 06/07/2006, 14h57

>>charger(CONFIG_FILE,&opt);

Est-ce que l'utilisateur a tous les droits pour écrire , lire des fichiers ?

mat.M · 06/07/2006, 15h02

Envoyé par Jean-Marc.Bourguet

Les deux différences qui me semblent pertinentes sont:
- sparc est big endian, x86 little endian
- sparc a besoin que les accès mémoires soient correctement alignés

Quelle est donc cette adresse à laquelle tu ne peux pas accèder, et comment la formes-tu?

Il me semble que c'est transparent pour le programmeur en C à moins de manipuler des données bit à bit par exemple

**Médinoc** · 06/07/2006, 15h07

Non, ce n'est pas transparent non plus si tu charges un fichier de données binaires sans conversion alors qu'il vient d'une autre machine.

Ce n'est pas transparent non plus si tu fais des trafics entre int * et char *.

Bref, ça foire dès que tu veux manipuler des données octet par octet en utilisant les mauvaises fonctions "pour gagner du temps"...

mat.M · 06/07/2006, 17h37

Envoyé par Médinoc

Non, ce n'est pas transparent non plus si tu charges un fichier de données binaires sans conversion alors qu'il vient d'une autre machine.

Ce n'est pas transparent non plus si tu fais des trafics entre int * et char *.

Bref, ça foire dès que tu veux manipuler des données octet par octet en utilisant les mauvaises fonctions "pour gagner du temps"...

Oui tout a fait

**mhtrinh** · 08/07/2006, 18h22

Bonjour,

J'ai verifie les droits d'ecriture et lecture de fichier. Pas de probleme de ce point vu.

Par contre, j'aurai besoin de votre aide pour faire du deboggage avec des printf :
Avec gdb, j'ai trouve que le probleme est au niveau de ma liste chainee, dans une fonction, ca plante sur un if :

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
void GereChabot::ajout(Chabot *src,Chabot *nouveau)
{
    // Si src est vide, on considere que c'est le premier chabot de la liste a creer
    if (src == NULL)
    {
	premChabot = nouveau;
	return;
    }
    nouveau->apres = src->apres;
    nouveau->avant = src;
    if (src->apres !=NULL) // <====== Ca fait SIGSEGV ici !!!
      src->apres->avant = nouveau;
    src->apres = nouveau;
 
}

Et :

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
22
23
 
typedef struct Chabot
{
  unsigned int cid; 
  int stade; 
  int patch; 
  int souspatch; 
  int position; 
  int age; 
  int fecondite;
  bool ismale; 
  float taille; 
  float a;
  float survie_avant;
  float K;
 
  //! pointeur vers le Chabot avant lui dans la liste chainee
  struct Chabot *avant; 
 
  //! pointeur vers le Chabot apres lui dans la liste chainee
  struct Chabot *apres; 
 
} Chabot;

Ma question est : comment savoir ce qu'il y a dans src->apres avec un printf ? D'habitude j'utilise gdb mais la ... il veut pas me l'afficher.

**PRomu@ld** · 08/07/2006, 18h30

Si tu veux afficher le pointeur, un %p (histoire de voir s'il n'est pas nul), sinon, tu utilises les formateurs par défaut pour les différentes variables.

Utilise fprintf et non pas printf, ainsi tu peux envoyer ça vers la sortie d'erreur non bufferisée :

Code :

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

1
2
 
fprintf(stderr,"%p", src->apres );

De plus, fait attention à ça :

Code :

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

1
2
3
4
5
6
 
    nouveau->apres = src->apres;
    nouveau->avant = src;
    if (src->apres !=NULL) // <====== Ca fait SIGSEGV ici !!!
      src->apres->avant = nouveau;
    src->apres = nouveau;

Tu fais l'hypothèse que ton erreur est sur le if or elle est peut être avant. Est tu sur que nouveau n'est pas NULL ?

**mhtrinh** · 09/07/2006, 11h53

J'ai trouve le bug. Le pointeur n'etait pas null mais il etait pas bon. J'avais oublie d'initialiser les pointeur avant et apres a NULL lors de leur creation. Sur Linux, ca doit le faire automatiquement , mais pas sur SUN, ca expliquerait le probleme que j'ai eu.
Je pensais pas faire une telle connerie de debutant ...

En tout cas, merci beaucoup tout le monde

Ya d'autres bugs

... mais je pense pouvoir continuer mtn

**Emmanuel Delahaye** · 10/07/2006, 14h04

Envoyé par mhtrinh

J'ai trouve le bug. Le pointeur n'etait pas null mais il etait pas bon. J'avais oublie d'initialiser les pointeur avant et apres a NULL lors de leur creation.

http://emmanuel-delahaye.developpez.com/goret.htm
Force 10 ! Bravo !