Bus Error en C, Sous OS X dans le terminal

[mpergand]

Quand aux tests oui ils font des test sur les malloc() null, mais après c'est le grand flou, ca remonte des -1 ca fait des traces et puis après ca se vautre gentillment comme des grands ! Essaye de pousser un linux aux limites tu va voir de beaux crash comme tout le monde (y compris MacOSX )

noop +1

SomeObject obj=new SomeObject();
if(obj==NULL)
printf("ATTENTION CA VA PLANTER !");

[Cochonou]

a moins que tu sois dans un environnement embarqué ou militaire, on n'est plus au temps du Dos.

Et même dans l'embarqué spatial/militaire, on n'est pas à l'abri de quelques erreurs, comme sur Ariane 501. Je sais que beaucoup d'entre vous connaissent l'histoire, mais elle est toujours intéressante à rappeler:

In the failure scenario, the primary technical causes are the Operand Error when converting the horizontal bias variable BH, and the lack of protection of this conversion which caused the SRI computer to stop.
It has been stated to the Board that not all the conversions were protected because a maximum workload target of 80% had been set for the SRI computer. To determine the vulnerability of unprotected code, an analysis was performed on every operation which could give rise to an exception, including an Operand Error. In particular, the conversion of floating point values to integers was analysed and operations involving seven variables were at risk of leading to an Operand Error. This led to protection being added to four of the variables, evidence of which appears in the Ada code. However, three of the variables were left unprotected. No reference to justification of this decision was found directly in the source code. Given the large amount of documentation associated with any industrial application, the assumption, although agreed, was essentially obscured, though not deliberately, from any external review.

(SRI : Système de Référence Inertiel)
Certaines conversions de valeurs n'étaient pas protégées contre un overflow, qui a provoqué une exception non controlée et l'arrêt du calculateur inertiel - ce dernier a par ailleurs envoyé un code d'erreur sur le bus de communication qui a été interprété comme des données par le calculateur principal. Bref, un bon gros micmac.
Il s'est avéré que ces conversions n'étaient pas protégées parce que le profil de vol d'Ariane 4 ne pouvait pas générer de mesures inertielles assez grandes pour provoquer un overflow... mais sur Ariane 5, ce n'était plus le cas.

[Fotz]

a moins que tu sois dans un environnement embarqué ou militaire, on n'est plus au temps du Dos.

Et même dans l'embarqué spatial/militaire, on n'est pas à l'abri de quelques erreurs, comme sur Ariane 501. Je sais que beaucoup d'entre vous connaissent l'histoire, mais elle est toujours intéressante à rappeler:

In the failure scenario, the primary technical causes are the Operand Error when converting the horizontal bias variable BH, and the lack of protection of this conversion which caused the SRI computer to stop.
It has been stated to the Board that not all the conversions were protected because a maximum workload target of 80% had been set for the SRI computer. To determine the vulnerability of unprotected code, an analysis was performed on every operation which could give rise to an exception, including an Operand Error. In particular, the conversion of floating point values to integers was analysed and operations involving seven variables were at risk of leading to an Operand Error. This led to protection being added to four of the variables, evidence of which appears in the Ada code. However, three of the variables were left unprotected. No reference to justification of this decision was found directly in the source code. Given the large amount of documentation associated with any industrial application, the assumption, although agreed, was essentially obscured, though not deliberately, from any external review.

(SRI : Système de Référence Inertiel)
Certaines conversions de valeurs n'étaient pas protégées contre un overflow, qui a provoqué une exception non controlée et l'arrêt du calculateur inertiel - ce dernier a par ailleurs envoyé un code d'erreur sur le bus de communication qui a été interprété comme des données par le calculateur principal. Bref, un bon gros micmac.
Il s'est avéré que ces conversions n'étaient pas protégées parce que le profil de vol d'Ariane 4 ne pouvait pas générer de mesures inertielles assez grandes pour provoquer un overflow... mais sur Ariane 5, ce n'était plus le cas.

Voilà une histoire intéressante.
En fait, le crash est dû à une panne des systèmes informatiques de bord. La cause de cette panne fut la conversion d'un nombre flottant codé sur 64 bits en une valeur entière signée sur 16 bits provoquant une exception (le nombre flottant en question n'était pas représentable sur 16 bits).
Mais la cause réelle résulte bien d'une spicification insuffisante puisque la valeur était représentable sur 16 bits pour … Ariane 4.
La précondition qui aurait sauvé Ariane 5 :

CODE

require horizontal_bias <= Maximum_horizontal_bias

.

En fait, tout ceci pour dire que réutiliser du code en l'abseence de contrat est une folie !!

Bref, vos petites histoire de malloc … …

[noop]

En fait, tout ceci pour dire que réutiliser du code en l'abseence de contrat est une folie !!
Bref, vos petites histoire de malloc … …

Et oui la réutilisation du code est le serpent de mer de la programmation orienté objet. Ca a fait vendre mais jamais mis en oeuvre (ou presque !)

[mackintosh]

Je vois que le sujet a suscité beaucoup de réactions
En tout cas c'est un sujet plutôt intéressant puisque bon nombre de crashs semblent être le résultat d'un problème d'allocation mémoire d'après vos expériences ...

Donc le mieux est de toujours tester son allocation mémoire quoi qu'il arrive ?

[noop]

Je vois que le sujet a suscité beaucoup de réactions
En tout cas c'est un sujet plutôt intéressant puisque bon nombre de crashs semblent être le résultat d'un problème d'allocation mémoire d'après vos expériences ...

Donc le mieux est de toujours tester son allocation mémoire quoi qu'il arrive ?

La majeure partie des crash sont du a des dépassement de zone mémoire ou d'écrasement de stack. Certe si tu oublie d'allouer de la mémoire ca crash, mais en général les malloc oubliés sont détecté assez tot dans la vie du programme. les autres causes sont quelque fois très dur a trouver surtout les écrasement de pile.

Ce message a été modifié par noop - 12 Oct 2006, 15:57.

[mackintosh]

Petite rectification pour tout le monde:

Bus error n'est ni une erreur d'overflow ou fichier manquant, mais bien un accès à un pointeur non valide (non existant ou permission non accordé). On peut le comparer à un segmentation fault sous linux.

Une autre erreur:

CODE

char *saisie = (char*) malloc(32*sizeof(char));
        printf("saissisez le fichier a lire !!!");
        scanf("%c", saisie);

Et si malloc fail? Tu te tappes un autre Bus error! TOUJOURS TOUJOURS TOUJOURS vérifier la valeur de retour de n'importe [mcr]alloc()

Sans oublier que scanf est la fonction à utiliser par excellence si on veut se faire un buffer overflow
Cette fonction serait mieux et plus sécuritaire dans ton cas:
http://en.wikipedia.org/wiki/Fgets

J'ai lu le contraire sur un autre site qui parle du language C

CODE

E/S de chaînes de caractères avec gets, fgets et puts

gets est une fonction à proscrire absolument (dangers de buffer overflow). Cette fonction lit une ligne de l'entrée standard stdin et le copie dans le buffer passé en argument jusqu'à ce que '\n' ou EOF soit rencontré. fgets permet de limiter le nombre de caractères à lire et à copier dans le tableau passé en argument. puts écrit la chaîne passée en argument et rajoute \n à la fin.

Source => http://inferno.cs.univ-paris8.fr/~am/tutor...C/Cours-11.html

A priori le mieux est de vérifier les entrées avec un simple test et bien gérer son malloc ... ?

[chombier]

J'ai lu le contraire sur un autre site qui parle du language C

CODE

E/S de chaînes de caractères avec gets, fgets et puts

gets est une fonction à proscrire absolument (dangers de buffer overflow). Cette fonction lit une ligne de l'entrée standard stdin et le copie dans le buffer passé en argument jusqu'à ce que '\n' ou EOF soit rencontré. fgets permet de limiter le nombre de caractères à lire et à copier dans le tableau passé en argument. puts écrit la chaîne passée en argument et rajoute \n à la fin.

Source => http://inferno.cs.univ-paris8.fr/~am/tutor...C/Cours-11.html

A priori le mieux est de vérifier les entrées avec un simple test et bien gérer son malloc ... ?

Ce n'est pas le contraire: gets est une fonction dangereuse, parcequ'il n'y a pas de limitation sur la taille des données retournées. fgets est la fonction équivalente, mais avec un paramètre supplémentaire qui limite le nombre d'octets à retourner, ce qui permet de s'assurer qu'il n'y aura jamais de débordement.

[schlum]

CODE

SECURITY CONSIDERATIONS
     The gets() function cannot be used securely.  Because of its lack of
     bounds checking, and the inability for the calling program to reliably
     determine the length of the next incoming line, the use of this function
     enables malicious users to arbitrarily change a running program's func-
     tionality through a buffer overflow attack.  It is strongly suggested
     that the fgets() function be used in all cases.  (See the FSA.)

[mackintosh]

D'accord je comprends mieux maintenant !
merci pour la précision