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.

[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