Discussion :

[poloDD]

Bonjour,

Comme le signale l'intitulé du message j'ai un souci de SIGBUS que je ne comprends pas . En effet, quand je compile et j'exécute mon programme sous CentOS 6.5 il fonctionne correctement alors que sous Ubuntu 14.04 le code compile mais à l'exécution j'obtiens le message d'erreur mentionné dans le titre.

L'erreur arrive quand j'utilise un malloc :

Code :

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

1
2
3
4
5
 
Program received signal SIGBUS, Bus error.
0x0000000000401dcf in Automatique::automatique (argc=6, argv=0x7fffffffdf78)
    at automatique.cpp:157
157		m_infos = (INFOS*) malloc(sizeof(*m_infos));

Avec disass :

Code :

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

1
2
3
4
 
     0x0000000000401dca <+282>:	mov    $0x24,%edi
=> 0x0000000000401dcf <+287>:	callq  0x401580 <malloc@plt>
     0x0000000000401dd4 <+292>:	mov    %rax,-0xb8(%rbp)

Voilà si quelqu'un comprend ce qu'il se passe je suis à l'écoute.

[Obsidian]

Bonjour,

Ton code est un mélange de C et de C++. Ce sont deux langages distincts. Choisis l'un ou l'autre.

Ensuite, « bus error » est en réalité, la plupart du temps, le reflet d'une segfault. Le fait que cela plante sur une architecture et pas sur une autre indique qu'il s'agit d'un bug aléatoire, provenant en général d'un programme congénitalement incorrect mais qui, par chance (ou pas), tombe dans une zone mémoire appartenant au programme dans le premier cas. Le développeur ignore alors que son application est buguée.

Dans le cas de malloc() cependant, il est difficile d'attribuer cela à un pointeur fou. C'est souvent dû, alors, au fait que ton programme se lie à la mauvaise bibliothèque dynamique (j'avais eu le problème avec l'OpenClient Sybase et FreeTDS à l'époque). Il faudrait que tu nous donnes le résultat de ldd sur les deux architectures, en nous précisant également si elles sont 32 ou 64 bits (la machine sous Ubuntu a l'air de compiler en 64).

[poloDD]

Ton code est un mélange de C et de C++. Ce sont deux langages distincts. Choisis l'un ou l'autre.

Tu veux parler du malloc que j'utilise dans du code C++ ?

Ensuite, « bus error » est en réalité, la plupart du temps, le reflet d'une segfault. Le fait que cela plante sur une architecture et pas sur une autre indique qu'il s'agit d'un bug aléatoire, provenant en général d'un programme congénitalement incorrect mais qui, par chance (ou pas), tombe dans une zone mémoire appartenant au programme dans le premier cas. Le développeur ignore alors que son application est buguée.

Mais comment alors j'aurais pu savoir que mon code était bogué sous CentOS alors qu'il s'exécute correctement dans cet environnement?

Dans le cas de malloc() cependant, il est difficile d'attribuer cela à un pointeur fou. C'est souvent dû, alors, au fait que ton programme se lie à la mauvaise bibliothèque dynamique (j'avais eu le problème avec l'OpenClient Sybase et FreeTDS à l'époque). Il faudrait que tu nous donnes le résultat de ldd sur les deux architectures, en nous précisant également si elles sont 32 ou 64 bits (la machine sous Ubuntu a l'air de compiler en 64).

Voilà les deux ldd :

Ubuntu :

Code :

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

1
2
3
4
5
6
7
8
 
    linux-vdso.so.1 =>  (0x00007fff17bfe000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f0f496e7000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f0f494d1000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0f492b2000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0f48eec000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0f48be6000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f0f49a03000)

CentOS :

Code :

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

1
2
3
4
5
6
7
8
 
    linux-vdso.so.1 =>  (0x00007ffff4334000)
    libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003d21000000)
    libm.so.6 => /lib64/libm.so.6 (0x0000003d15800000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003d20400000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003d15000000)
    libc.so.6 => /lib64/libc.so.6 (0x0000003d14c00000)
    /lib64/ld-linux-x86-64.so.2 (0x0000003d14400000)

Et c'est en effet du 64 bits pour les deux OS. Tu le vois à la taille des adresses ?

[Bktero]

Mais comment alors j'aurais pu savoir que mon code était bogué sous CentOS alors qu'il s'exécute correctement dans cet environnement?

Probablement avec valgrind (memcheck) ou drmemory

[Obsidian]

+1 à Bktero pour valgrind. C'est effectivement par là qu'il faut commencer.

Pour le reste, ton extrait de code est trop court pour que l'on puisse statuer. Le C++ a des mécanismes qui permettent d'initialiser des objets implicitement et/ou avec du retard, en particulier quand on déclare des variables ailleurs qu'en début de bloc et que celles-ci sont soumises au RAII. Il faudrait au minimum qu'on voie la fonction entière, sinon le programme *.c++.

Tu le vois à la taille des adresses ?

À ça et au registre RAX entre autres.