Bus Error en C, Sous OS X dans le terminal

[mackintosh]

Bonsoir,

j'utilise depuis peu mon imac pour compiler des sources C pour différents tp ...
les exemples de base, boucles etc ... marchent très bien mais je rencontre un souci avec un petit programme qui est sensé lire puis restituer un fichier sur l'ecran du shell

J'obtiens le message suivant : Bus error ....
voici ci dessous la source du programme, si quelqu'un pourrait m'éclairer un peu sur ce problème ?

CODE

#include <stdio.h>
int main()
{
FILE *f;
char c;
char saisie;

printf("saisissez le fichier a lire");

scanf("%c", &saisie);
f=fopen("saisie", "r");


while (! feof(f))
{
c=fgetc(f);
printf("%c", c);
}


}



"lecture.c" 21L, 211C

Ce message a été modifié par mackintosh - 4 Oct 2006, 22:17.

[Cochonou]

Salut,
à vue d'oeil, tu alloues des char (c et saisie), soit un (et un seul) caractère à chaque fois. Quand tu vas écrire dessus un mot avec ton scanf, il va y avoir plus d'un caractère de longueur, du dépassement de buffer.... et crash.

Il faut (enfin, une solution est de...) utiliser des appels malloc pour allouer une taille de buffer plus grande.
Par exemple :

CODE

char *saisie = (char*) malloc(32*sizeof(char));
scanf("%c", saisie);

Ou directement avec une allocation sur la pile,

CODE

char saisie[32];
scanf("%c", &saisie);

Ce message a été modifié par Cochonou - 4 Oct 2006, 22:24.

[schlum]

Yeah ! Buffer overflow
Le truc qui est adoré des hackers quand c'est dans un exécutable avec setuid root

[mackintosh]

un Bus Error correspondrait donc à un BufferOverflow ... toujours bon à savoir .


Merci pour les pistes je regarderais çà dès demain.

[Cochonou]

Normalement, quand tu accèdes à une zone mémoire non autorisée, tu t'attends à recevoir une erreur de segmentation (segmentation fault).
Pour les erreurs de bus, c'est un peu plus particulier... c'est en général un accès à une adresse invalide. Et là, il y a une autre erreur dans le programme qui doit causer ça:

CODE

f=fopen("saisie", "r");

à la place de

CODE

f=fopen(saisie, "r");

[mackintosh]

J'ai testé les solutions, à priori c'est encore un autre souci ...

actuellement je teste avec le code suivant

CODE

#include <stdio.h>
int main()
{      FILE *f;
        char c;
        char saisie[32];
        
        printf("saissisez le fichier a lire !!!");

        scanf("%c", &saisie);
        f=fopen(saisie, "r");

                while (! feof(f))
                        {
                        c=fgetc(f);
                        printf("%c", c);
                        }
}      

J'ai modifié le code source comme tu me l'as conseillé, avec un tableau saisie[32], et saisie sans les " " ...
toujours un message d'erreur "Bus error"
Puis j'ai tenté avec

CODE

{      FILE *f;
        char c;
        char *saisie = (char*) malloc(32*sizeof(char));

        printf("saissisez le fichier a lire !!!");

        scanf("%c", saisie);

etc ...

Toujours la même erreur..
Si tu as une autre idée ? merci bien.

[mpergand]

http://www.lri.fr/~aze/page_c/aide_c/scanf.html

[schlum]

1 - scanf %c c'est pour récupérer 1 caractère
2 - Tu appelles fopen sur une chaîne sans savoir si elle a un "terminateur" '\0'
3 - Tu ne testes pas la validité de ton fichier ouvert

Au moins 3 bonnes raisons d'avoir un giga-plantage !

[mackintosh]

En effet çà fait pas mal de choses qui peuvent provoquer un énorme plantage ... je vais continuer sur la lancée ... merci pour les conseils

[Doom Hammer]

Le programme crash (probablement sur feof ou fgetc) parce que fopen renvoie NULL car le fichier n'est pas trouvé (je crois pas qu'il y ait de buffer overflow possible sur ton premier code vu le "%c").
Dans tous les cas (comme le précise schlum) tu devrais vérifier le retour :
FILE *f = fopen(...

if (f != NULL)
{
/* process file */
}
else
{
/* file was not found */
}

Ce message a été modifié par Doom Hammer - 5 Oct 2006, 21:52.

[Cochonou]

Doom Hammer a certainement raison, parce qu'un copier/coller direct de ton code (après les deux corrections que tu as effectuées) marche chez moi... pour autant que le nom du fichier ait un seul caractère .

Donc, en plus des ajouts de Doom Hammer, utilise scanf avec %s pour récupérer une chaîne.

Ce message a été modifié par Cochonou - 5 Oct 2006, 21:27.

[mackintosh]

au final c'était tout simplement un problème avec %c ... j'ai remplacé avec %s et tout fonctionne, merci pour votre aide !

[schlum]

au final c'était tout simplement un problème avec %c ... j'ai remplacé avec %s et tout fonctionne, merci pour votre aide !

Tu ferais quand même mieux de tester l'existence du fichier

[franklinchef]

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

Ce message a été modifié par franklinchef - 9 Oct 2006, 21:19.

[noop]

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()

C'est la grande question: doit t'on vérifier tous les malloc. Dans le cas que tu cite, si le system n'a pas pu t'allouer 32 * sizeof(char) octets, c'est que tu es dans un position délicate. Il y a de forte probabilité que même le test suivant plante car ta machine ne pourra plus rien faire. Et même a supposer que tu arrive a faire le test, tu va devoir générer une erreur (log, message....) qui va nécessiter beaucoup plus de mémoire ce qui va encore planter.

Je penses qu'il faut vérifier que les grosses allocations, le reste il faut s'en passer celà permet une meilleur lisibilité du code et diminue sa complexité

[franklinchef]

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()

C'est la grande question: doit t'on vérifier tous les malloc. Dans le cas que tu cite, si le system n'a pas pu t'allouer 32 * sizeof(char) octets, c'est que tu es dans un position délicate. Il y a de forte probabilité que même le test suivant plante car ta machine ne pourra plus rien faire. Et même a supposer que tu arrive a faire le test, tu va devoir générer une erreur (log, message....) qui va nécessiter beaucoup plus de mémoire ce qui va encore planter.

Je penses qu'il faut vérifier que les grosses allocations, le reste il faut s'en passer celà permet une meilleur lisibilité du code et diminue sa complexité

Je ne suis pas daccord avec toi. Le problème avec les alloc failed, c'est qu'il te retourne un null pointer. Si tu fais un test/acces/modif à ce pointeur, l'OS tue ton process sans aucune chance de sauvegarde de données.

Prenons par exemple un logiciel critique: voir MySQL. Est-ce que tu accepterais de perdre toutes tes données en transaction parce qu'un call d'alloc à échoué? Ceci est tout à fait innacceptable. Peut-être qu'en effet ça diminue la complexité et la lisibilité, mais le but est de garder un programme consistant et efficace.

Il ne faut pas prendre en considération que ta fonction va toujours réussir, c'est une très mauvaise notion de programmation qui amène à des plantages non voulu.Par contre, je t'accorde le fait que ce n'est pas nécessaire pour un petit programme pour apprendre le language. Je ne fais qu'avertir mackintosh aux joies de la famille alloc, vaut mieux ne pas prendre de faux plis dès le départ.

Et pour ce qui est de la complexité... Il suffit de créer son propre call de malloc voir getmem() avec les mêmes params. Cette fonction est un wrap arround de malloc et fait les checks (null pointer?) sinon elle apelle une fonction définie par nous pour flusher les données importants. Tout ça en quittant sans avoir de Bus Error

[noop]

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()

C'est la grande question: doit t'on vérifier tous les malloc. Dans le cas que tu cite, si le system n'a pas pu t'allouer 32 * sizeof(char) octets, c'est que tu es dans un position délicate. Il y a de forte probabilité que même le test suivant plante car ta machine ne pourra plus rien faire. Et même a supposer que tu arrive a faire le test, tu va devoir générer une erreur (log, message....) qui va nécessiter beaucoup plus de mémoire ce qui va encore planter.

Je penses qu'il faut vérifier que les grosses allocations, le reste il faut s'en passer celà permet une meilleur lisibilité du code et diminue sa complexité

Je ne suis pas daccord avec toi. Le problème avec les alloc failed, c'est qu'il te retourne un null pointer. Si tu fais un test/acces/modif à ce pointeur, l'OS tue ton process sans aucune chance de sauvegarde de données.

Prenons par exemple un logiciel critique: voir MySQL. Est-ce que tu accepterais de perdre toutes tes données en transaction parce qu'un call d'alloc à échoué? Ceci est tout à fait innacceptable. Peut-être qu'en effet ça diminue la complexité et la lisibilité, mais le but est de garder un programme consistant et efficace.

Il ne faut pas prendre en considération que ta fonction va toujours réussir, c'est une très mauvaise notion de programmation qui amène à des plantages non voulu.Par contre, je t'accorde le fait que ce n'est pas nécessaire pour un petit programme pour apprendre le language. Je ne fais qu'avertir mackintosh aux joies de la famille alloc, vaut mieux ne pas prendre de faux plis dès le départ.

Et pour ce qui est de la complexité... Il suffit de créer son propre call de malloc voir getmem() avec les mêmes params. Cette fonction est un wrap arround de malloc et fait les checks (null pointer?) sinon elle apelle une fonction définie par nous pour flusher les données importants. Tout ça en quittant sans avoir de Bus Error

Dans les conditions limites tu n'es jamais sur de sauver correctement. Si tes données sont importantes, elles sont aussi surement importante en taille. Or tu viens d'avoir une erreur sur un malloc, tout le code qui va suivre va aussi allouer de la mémoire....donc aussi planter.

Ce message a été modifié par noop - 10 Oct 2006, 13:50.

[franklinchef]

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()

C'est la grande question: doit t'on vérifier tous les malloc. Dans le cas que tu cite, si le system n'a pas pu t'allouer 32 * sizeof(char) octets, c'est que tu es dans un position délicate. Il y a de forte probabilité que même le test suivant plante car ta machine ne pourra plus rien faire. Et même a supposer que tu arrive a faire le test, tu va devoir générer une erreur (log, message....) qui va nécessiter beaucoup plus de mémoire ce qui va encore planter.

Je penses qu'il faut vérifier que les grosses allocations, le reste il faut s'en passer celà permet une meilleur lisibilité du code et diminue sa complexité

Je ne suis pas daccord avec toi. Le problème avec les alloc failed, c'est qu'il te retourne un null pointer. Si tu fais un test/acces/modif à ce pointeur, l'OS tue ton process sans aucune chance de sauvegarde de données.

Prenons par exemple un logiciel critique: voir MySQL. Est-ce que tu accepterais de perdre toutes tes données en transaction parce qu'un call d'alloc à échoué? Ceci est tout à fait innacceptable. Peut-être qu'en effet ça diminue la complexité et la lisibilité, mais le but est de garder un programme consistant et efficace.

Il ne faut pas prendre en considération que ta fonction va toujours réussir, c'est une très mauvaise notion de programmation qui amène à des plantages non voulu.Par contre, je t'accorde le fait que ce n'est pas nécessaire pour un petit programme pour apprendre le language. Je ne fais qu'avertir mackintosh aux joies de la famille alloc, vaut mieux ne pas prendre de faux plis dès le départ.

Et pour ce qui est de la complexité... Il suffit de créer son propre call de malloc voir getmem() avec les mêmes params. Cette fonction est un wrap arround de malloc et fait les checks (null pointer?) sinon elle apelle une fonction définie par nous pour flusher les données importants. Tout ça en quittant sans avoir de Bus Error

Dans les conditions limites tu n'es jamais sur de sauver correctement. Si tes données sont importantes, elles sont aussi surement importante en taille. Or tu viens d'avoir une erreur sur un malloc, tout le code qui va suivre va aussi allouer de la mémoire....donc aussi planter.

Si tu utilises des buffers static pour dumper ton data, tu t'en sors vainceur parce qu'ils sont déjà alloués

[noop]

Si tu utilises des buffers static pour dumper ton data, tu t'en sors vainceur parce qu'ils sont déjà alloués

Dans ton code oui (bien que des buffers static c'est limite programmation à la sauvage !). Mais tes données tu va les passer à un autre process (base de données par exemple) qui lui va devoir allouer de la mémoire. Que fais tu ? Tu penses que celà va marcher et que miraculeusement de la mémoire va être libérée ?

[chombier]

Si tu utilises des buffers static pour dumper ton data, tu t'en sors vainceur parce qu'ils sont déjà alloués

Dans ton code oui (bien que des buffers static c'est limite programmation à la sauvage !).

Il existe des tas de cas de figure où, si tu veux que ton code s'exécute correctement, les allocations sont faites à l'initialisation, et plus aucune lors de l'exécution. Dans les device drivers en particulier, où toute erreur d'allocation devient vite critique.

Mais tes données tu va les passer à un autre process (base de données par exemple) qui lui va devoir allouer de la mémoire. Que fais tu ? Tu penses que celà va marcher et que miraculeusement de la mémoire va être libérée ?

Tu programmes depuis longtemps noop ?
Les rares fois où j'ai vu un bout de code open-source qui ne vérifiait pas le résultat d'un malloc(), j'ai envoyé un bug report à l'auteur, et la correction ne s'est pas faite attendre.
Comme le dit franklinchef, il faut systématiquement vérifier le résultat d'une allocation mémoire.

[noop]

Tu programmes depuis longtemps noop ?
Les rares fois où j'ai vu un bout de code open-source qui ne vérifiait pas le résultat d'un malloc(), j'ai envoyé un bug report à l'auteur, et la correction ne s'est pas faite attendre.
Comme le dit franklinchef, il faut systématiquement vérifier le résultat d'une allocation mémoire.

Oui assez +de 20ans. Et je n'ai jamais eu de problèmes dans mes programmes. Les seules vérif que je fais c'est quand j'ai besoin de + de 4K. Et j'ai développé dans toutes sortes de programmes comm, drivers et middleware. Désolé, je n'y crois pas regarde les logiciels middleware et autres, dans les conditions extremes telles que décrites plus haut ils génèrent des dump ou se crash tout bonnement. Quand au code open source linux et autre je veux bien voir comment ils se comportent quand ils ne peuvent pas allouer 32 octets

[chombier]

Oui assez +de 20ans. Et je n'ai jamais eu de problèmes dans mes programmes. Les seules vérif que je fais c'est quand j'ai besoin de + de 4K. Et j'ai développé dans toutes sortes de programmes comm, drivers et middleware.

Tu as une idée des conséquences d'un accès à un pointeur NULL dans un device driver ? Ça donne un Kernel Panic.
Pour moi, la programmation à la sauvage comme tu l''appelles, c'est bien plutôt de croire qu'aucune allocation de taille inférieure à 4k (plutôt arbitraire d'ailleurs comme valeur) n'échouera.

Désolé, je n'y crois pas regarde les logiciels middleware et autres, dans les conditions extremes telles que décrites plus haut ils génèrent des dump ou se crash tout bonnement. Quand au code open source linux et autre je veux bien voir comment ils se comportent quand ils ne peuvent pas allouer 32 octets

Et bien il suffit de lire le code source...

[noop]

Oui assez +de 20ans. Et je n'ai jamais eu de problèmes dans mes programmes. Les seules vérif que je fais c'est quand j'ai besoin de + de 4K. Et j'ai développé dans toutes sortes de programmes comm, drivers et middleware.

Tu as une idée des conséquences d'un accès à un pointeur NULL dans un device driver ? Ça donne un Kernel Panic.
Pour moi, la programmation à la sauvage comme tu l''appelles, c'est bien plutôt de croire qu'aucune allocation de taille inférieure à 4k (plutôt arbitraire d'ailleurs comme valeur) n'échouera.

Désolé, je n'y crois pas regarde les logiciels middleware et autres, dans les conditions extremes telles que décrites plus haut ils génèrent des dump ou se crash tout bonnement. Quand au code open source linux et autre je veux bien voir comment ils se comportent quand ils ne peuvent pas allouer 32 octets

Et bien il suffit de lire le code source...

Ben je suis désolé moi je vois ca tous les jours....a moins que tu sois dans un environnement embarqué ou militaire, on n'est plus au temps du Dos. Compte le nombre de malloc() et autres dans un programme et ajoute au minimum 10 lignes pour traiter l'erreur, ton programme devient illisible et immaintenable.

Quant a ton device driver, s'il rencontre un pointer null,il y a belle lurette que ta machine est a genoux et quelle soit déjà plantée ! alors un crash de plus ou de moins ca change pas grand chose.

D'autre part, tout bon développeur doit aussi maitriser le multi threading. Alors la si tu commence a gérer les problèmes de mémoire pour 32 malheureux octets, je suis curieux de voir la tête de tes programmes. Il y a d'autres techniques pour gérer ce problèmes c'est d'installer des exit routines sur les signaux. La tu peux terminer proprement si le système n'est pas a genoux. Le code est plus lisible, tu ecrit moins de code et tout le monde est content

[chombier]

Ben je suis désolé moi je vois ca tous les jours....a moins que tu sois dans un environnement embarqué ou militaire,

Comment dans un programme fais tu la différence entre un Linux embarqué et un Linux Desktop ? Comment sais tu, si tu fais une librairie, à quelle utilisation elle sera destinée ? On code proprement ou pas, c'est tout.

on n'est plus au temps du Dos.

Je ne vois pas le rapport avec le schmilblick.

Compte le nombre de malloc() et autres dans un programme et ajoute au minimum 10 lignes pour traiter l'erreur, ton programme devient illisible et immaintenable.

Pfff. Tant qu'à faire, ne teste aucun retour de fonction, ça améliorera encore la lisibilité...

Quant a ton device driver, s'il rencontre un pointer null,il y a belle lurette que ta machine est a genoux et quelle soit déjà plantée ! alors un crash de plus ou de moins ca change pas grand chose.

Pure supposition. Ce qui est certain, c'est qu'avec ta méthode, la machine plantera.

D'autre part, tout bon développeur doit aussi maitriser le multi threading. Alors la si tu commence a gérer les problèmes de mémoire pour 32 malheureux octets, je suis curieux de voir la tête de tes programmes. Il y a d'autres techniques pour gérer ce problèmes c'est d'installer des exit routines sur les signaux. La tu peux terminer proprement si le système n'est pas a genoux. Le code est plus lisible, tu ecrit moins de code et tout le monde est content

Quel est le rapport entre des threads et un test d'allocation mémoire ? Tes 'exit routines' ne seront d'aucune utilité si tu plantes ton programme en accèdant à NULL. Et toutes les threads en cours seront plantées.

Tu aurais des noms de logiciels sur lesquels tu as bossé, que j'évite de m'en servir ?

[noop]

Tu aurais des noms de logiciels sur lesquels tu as bossé, que j'évite de m'en servir ?

emacs ! (non je plaisante), mais voici un petit bout de code trouvé dans emacs (5 minutes de recherche...) et déjà Oh Horreur un malloc non testé !!!

exemple de code:

CODE

  lca = (struct load_command **) malloc (nlc * sizeof (struct load_command *));

  for (i = 0; i < nlc; i++)
    {
      struct load_command lc;
      /* Load commands are variable-size: so read the command type and
     size first and then read the rest.  */
      if (!unexec_read (&lc, sizeof (struct load_command)))
        unexec_error ("cannot read load command");
      lca[i] = (struct load_command *) malloc (lc.cmdsize);

A remarquer, l'utilisation périlleuse de la variable lca

[schlum]

Vous exagérez quand même
Dans les sources de zsh par exemple, on peut trouver :

CODE

    struct lexstack *ls;

    ls = (struct lexstack *)malloc(sizeof(struct lexstack));

    ls->incmdpos = incmdpos;
    ls->incond = incond;
    ls->incasepat = incasepat;
    ls->dbparens = dbparens;
    ls->isfirstln = isfirstln;
    ls->isfirstch = isfirstch;
    ls->histactive = histactive;
    ls->histdone = histdone;
    ls->stophist = stophist;
    ls->hline = chline;
    ls->hptr = hptr;
    ls->hlinesz = hlinesz;
    ls->cstack = cmdstack;
    ls->csp = cmdsp;

[chombier]

Et ? emacs est sensé être LA référence en matière de programmation, et ne contient aucun bug ?

Etrangement, dans les sources du noyau Linux, toutes les allocations sont testées.

CODE

    struct belkin_sa_private *priv;

    /* allocate the private data structure */
    priv = kmalloc(sizeof(struct belkin_sa_private), GFP_KERNEL);
    if (!priv)
        return (-1); /* error */

    /* Setup private data for serial driver */
    s_priv = kmalloc(sizeof(struct keyspan_serial_private), GFP_KERNEL);
    if (!s_priv) {
        dbg("%s - kmalloc for keyspan_serial_private failed.", __FUNCTION__);
        return -ENOMEM;
    }

[schlum]

Avec "kmalloc", il vaut mieux (sinon c'est Kernel Panic !)

Mais en général, si le "kmalloc" échoue, le Kernel Panic n'est pas loin de toute manière...

[noop]

Et ? emacs est sensé être LA référence en matière de programmation, et ne contient aucun bug ?

Etrangement, dans les sources du noyau Linux, toutes les allocations sont testées.

Les sources Linux ne sont pas un modèle de programmation. Les {} sont la plupart du temps omis (je sais, je sais....ca ne sert a rien allez vous me dire !). Sur 1 ligne ou une condition tu trouve deux ou trois affectations/appels de fonction etc...

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 )

[chombier]

Avec "kmalloc", il vaut mieux (sinon c'est Kernel Panic !)

Mais en général, si le "kmalloc" échoue, le Kernel Panic n'est pas loin de toute manière...

Ce n'est pas parcequ'une allocation échoue à un instant t que toute la machine va planter. Surtout si toutes les allocations sont vérifiées. On libère proprement ce qui a été alloué, et seule la dernière tâche échoue.

C'est un peu comme se dire qu'on ne va pas traiter telle section critique parce que de toutes façons, ça n'arrive qu'une fois sur un million, ça reste exceptionnel