Quizz! Trouvez l'erreur.

Bonjour, j'ai un Exercice ou je dois trouver les erreurs dans des bouts de codes, j'aimerais avoir votre avis sur mes choix. Il y à 13 code je ne l'ai ai pas encore tous fait donc je mettrais à jour au fur et a mesure.

Code:

---

1 2 3 4 5 6 7 8

Code 1 : main (int argc, char **argv) { int i; if (argc ==1) i = atoi(argv[1]); if (i = 0) printf(“0 is not valid!\n”); }

---

ERREUR : L'instruction (i=0) doit être une condition et non une affectation donc (i==0). De plus si argc == 1 alors on à pas accès à argv[1] il faudrait argc == 2. Et enfin i doit être initialisé.

Code 2 :

Code:

---

1 2 3 4 5 6 7 8 9 10

#define IS_VALID_NUM(x) (((x)>='0' && (x)<='9')?1:0) void ma_fonction(char* chaine) { int lg = 0; while(IS_VALID_NUM(*chaine++)) { lg++; } printf(“Cette chaine commence par %d digits\n”, lg); }

---

ERREUR : Celui-ci m'as posé quelques soucis
La fonction is_valid_num ne fait pas ce que l'on attendrait d'elle, elle n'évalue que les indice pair de la chaine. Il aurait falut faire *chaine plutot que *chaine++ car il incrémente directement et n'évalue que les nombres paires.

CODE 3 :

Code:

---

1 2 3 4 5 6 7 8 9 10

int res; long start_usecs, stop_usecs, delta2_usecs; struct timeval t1, t2; res = gettimeofday(&t1, NULL); my_func(); res = gettimeofday(&t2, NULL); stop_usecs= (t2.tv_sec * 1000000) + t2.tv_usec; start_usecs= (t1.tv_sec * 1000000) + t1.tv_usec; delta2_usecs = stop_usecs – start_usecs;

---

Ces lignes se comportent-elles de la même manière sur une machine 32 bits et sur une machine 64
bits?
Je pense que sur 64 bits le temps évalué sera plus court, et de plus c'est "long long start_usecs" et non pas "long".

CODE 4 :

Code:

---

1 2 3 4 5 6 7 8 9 10

void * myfunc(void *myarg) { printf("Myfunc\n"); } main() { pthread_t *th; int res; res = pthread_create(th, NULL, myfunc, NULL); ...blah...blah... }

---

ERREUR : Ici je ne sais pas trop, d'après l'utilisation des threads que je fais habituellement je déclare toujours en premier le prototype de la fonction et apres mon main j'y met le corps. Donc cela donnerai :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

void * myfunc(void *myarg); main() { pthread_t *th; int res; res = pthread_create(th, NULL, myfunc, NULL); ...blah...blah... } void * myfunc(void *myarg) { printf("Myfunc\n"); }

---

Mais est-ce vraiment cela et pourquoi ?

CODE 5 :

Code:

---

1 2 3 4 5 6 7 8

#define MAX_LEN 32 main(int argc, char* argv[1]) { char *my_str; my_str= malloc(MAX_LEN); if ((argv[1] != NULL) & (my_str != NULL)) strcpy(my_str, argv[1]); }

---

ERREUR : Le malloc fait une allocation de taille fixe! Mais l'argument n'est pas de taille fixe! Il aurait fallu écrire malloc(strlen(argv[1]+1);

CODE 6 :

Code:

---

1 2 3 4 5

int res, i; for (i =0; i < 20; i++){ res = fork(); ....blah blah... }

---

ERREUR : Ici c'est le principe même d'un fork bomb j'imagine. Rappel : "Une fork bomb fonctionne en créant un grand nombre de processus très rapidement afin de saturer l'espace disponible dans la liste des processus gardée par le système d'exploitation. Si la table des processus se met à saturer, aucun nouveau programme ne peut démarrer tant qu'aucun autre ne termine". Donc il n'y à pas d'erreur mais un danger ...

CODE 7 :

Code:

---

1 2 3 4 5 6 7 8

void * my_func(void* arg) { int res; .... for (int i =0; i < 20; i++){ res = pthread_create(...., NULL, my_func, NULL); }

---

ERREUR : Aucude idée.

Les autres code sont d'un niveau bien plus élevé et je ne les ai pas encore commencé donc je les publierai au moment voulu.

Voila si vous avez des suggestions, des modifications, si j'ai faux ou quoi que se soit faites moi savoir. Merci.

Code 1 et 5 > ok.

Code 3 > aucune idée, j'ai toujours été mauvais dans la gestion du temps...

Code 2 : d'accord avec toi, il ne faut jamais utiliser une variable incrémentée dans les paramètres d'un macro. cF FAQ C

Code 4 : non, ce n'est pas une erreur.
Je pencherais plutôt vers le pthread_t *th. Pourquoi déclarer un pointeur ?

En effet, un coup de valgrind :

Code:

---

1 2 3 4 5 6 7 8 9

Use of uninitialised value of size 4 ==8372== at 0x404A454: pthread_create@@GLIBC_2.1 (pthread_create.c:558) ==8372== by 0x804851F: main (in /home/lucas/Documents/Programmation/SDZ/Essai/a.out) ==8372== ==8372== ==8372== Process terminating with default action of signal 11 (SIGSEGV) ==8372== Bad permissions for mapped region at address 0x41B7FF4 ==8372== at 0x404A454: pthread_create@@GLIBC_2.1 (pthread_create.c:558) ==8372== by 0x804851F: main (in /home/lucas/Documents/Programmation/SDZ/Essai/a.out)

---

Montre qu'on se trouve face à un pointeur qui n'est pas initialisé.

Code:

---

1 2	pthread_t th; pthread_create (&th, NULL, foo, NULL);

---

Est à utiliser.
Après, à toi de formuler, je suis mauvais à ce jeu. :mouarf:

Code 5 : on dirait qu'il y a un problème dans le deuxième argument du main aussi « argv[1] » ?

Code 7 : En effet, petit problème : même principe que la fork bomb mais avec les threads.
A chaque appel de la fonction, my_fun va créer 20 threads exécutant my_fun, et cela jusqu'à ce que le système dise stop. ^^

Tout d'abord merci pour t'es réponses.

Citation:

---

Envoyé par lucas-84

Code 6 > ça me paraît un peu bizarre comme fork bomb, normalement on boucle infiniment. Je me demande si créer 20 processus est dangereux.

---

Il est vrai que la question exacte était :
"Expliquez, ce qui se passe avec le code ci-dessus. Y a-t-il une différence de comportement suivant que l'utilisateur exécutant ce programme est le super utilisateur de la machine ou un utilisateur quelconque? Si nécessaire, ré-écrivez le code, pour obtenir le résultat souhaité."

J'ai fait un test sur un pc sous unix à ma fac et le pc à planter, je n'étais pas en super-utilisateur.

Sur wikipedia il est dit : "Les systèmes de type Unix permettent de limiter le nombre de processus via la commande ulimit. Dans un noyau Linux, cette limite peut être indiquée via RLIMIT_NPROC. Si un processus appelle fork et que l'utilisateur possède déjà plus de RLIMIT_NPROC processus alors le fork échoue." J'imagine que cette limite ne peut-être levée que par un super-utilisateur et que la limite est justement une boucle allant jusqu'à 20, je vais vérifier.

CODE 4 : Merci très bonne remarque je n'avais pas prêter attention ! Pourtant j'utilise souvent les Threads ...

Citation:

---

Code 5 : on dirait qu'il y a un problème dans le deuxième argument du main aussi « argv[1] » ?

---

Je ne pense pas que se soit une erreur voila pourquoi :
"Since we already figured that an array parameter is not existant but instead any array parameter is a pointer, the array's size doesn't matter. That means, the compiler will translate all of the following, and all are the same thing:

int main(int c, char **argv);
int main(int c, char *argv[]);
int main(int c, char *argv[1]);
int main(int c, char *argv[42]);

Of course, it doesn't make much sense to be able to put any size in it, and it's just thrown away. For that reason, C99 came up with a new meaning for those numbers, and allows other things to appear betweenthe brackets:"

Je publie le Code 8 au cas ou sa vous intéresserai, mais je n'ai pas encore chercher et je ne pourrais pas avant demain.

CODE 8 :
Enoncé :
"L'extrait N°8 est un programme complet qui compile normalement sans erreur et sans warning (option -Wall).
Le problème ici est en fait dépendant des options utilisées pour la compilation.
Quand vous aurez trouvé la manifestation de ce problème, vous proposerez une
correction qui permette à ce programme de se comporter normalement. Vous
expliquerez aussi pourquoi les options de compilations influent sur le comportement
de ce programme avant votre correction."

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <signal.h> int check; struct sigaction act; void wakeup(int signb) { check++; if (check == 11){ printf("received 11 SIGALRM, Erreur, Stop!\n"); exit(1); } if (alarm(1) < 0) { perror("cannot set alarm"); exit(1); } }   int main(int argc, char** argv) { int cur; act.sa_handler=wakeup; if ( sigaction(SIGALRM, &act, NULL) <0) { perror("sigaction failed"); exit(1); } if (alarm(1) < 0) { perror("cannot set alarm"); exit(1); } for(cur=check; cur!=10;){ if (check > cur) { printf("Recu %d ticks\n", check-cur); cur = check; } } return 0; }

---

Il faut utiliser la balise CODE du forum pour y mettre le code source, car c'est vraiment illisible. :cry:

C'est fait :)

Extrait 8 : ça n'a peut-être aucun rapport, mais d'après mon man alarm() a pour prototype :

Code:

---

unsigned int alarm(unsigned int seconds);

---

Or le test :

Code:

---

if (alarm(1) < 0)

---

Ne sera jamais vrai, car la valeur renvoyée est toujours positive.
Par contre :

Code:

---

if (alarm(1) != 0)

---

Devrait être correct car :

Citation:

---

alarm() returns the number of seconds remaining until any previously scheduled alarm was due to be delivered, or zero if there was no previously scheduled alarm.

---

Sinon, je ne vois pas que viennent faire les options de compilation là-dedans. Si aucune information supplémentaire ne parvient, je donne ma langue au chat. :mouarf:

CODE 8 :

Compilé simplement par le compilateur g++ (et sans doute la plupart des compilateurs), ce programme semble fonctionner comme prévu. On dirait "qu'il est juste"... Cependant, si on ajoute l'option -O, qui demande une compilation optimisée, le programme ne réagit plus au signal SIGINT. La raison en est très simple : la variable "check" est une variable globale, donc stockée dans la zone statique de la mémoire virtuelle réservée aux variables globales initialisées. Le compilateur s'aperçoit que cette variable "check" est fréquemment utilisée dans une boucle, sans être modifiée, et considère qu'il est plus rapide d'en faire une copie stockée dans un registre du processeur, d'accès beaucoup plus rapide que la mémoire principale.

Dès lors, le traitant du signal et la fonction main() n'utilisent plus le même objet physique et le programme est faux.

Pour éviter cet inconvénient, le langage C a prévu le qualifieur volatile qui interdit au compilateur de dupliquer une variable lors d'une éventuelle optimisation de la compilation. Il garantit ainsi l'unicité de la variable.

Donc

Code:

---

1 2	volatile int check;

---

Concernant le ALARM je pense que tu as raison, j'ai vérifié et j'en déduis la même chose que toi.

CODE 9:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

void * my_func(void* arg) { pthread_exit(0); } int main (int argc, char **argv; char **envp) { pthread_t th; int res; res= pthread_create (&th, NULL, my_func(), NULL); printf("pthread_create %d\n", res); }

---

J'imagine que le problème viens du EXIT, je vais chercher.

Bonjour à tous

Citation:

---

Pour éviter cet inconvénient, le langage C a prévu le qualifieur volatile qui interdit au compilateur de dupliquer une variable lors d'une éventuelle optimisation de la compilation. Il garantit ainsi l'unicité de la variable.

---

En c embarqué le mot clef volatile est utilisé pour interdire les optimisations du compilateur. On l'utilise toujours lorsque l'on assimile un registre du micro contrôleur comme une variable.

un cas typique de bug que l'on peut rencontrer

Code:

---

1 2 3 4 5

volatile unsigned char PORTA;   PORTA = 0; PORTA = 1; // génération d'un front montant sur le port A PORTA = 0;

---

Sans le volatile, le compilateur va se dire qu'il est bête de mettre à 1 une variable pour la remettre aussitôt à 0. Il va donc ignorer ces lignes de codes. du coup pas de front montant et bug assuré.

Bonne soirée

Citation:

---

Envoyé par bpy1401

Bonjour à tous



En c embarqué le mot clef volatile est utilisé pour interdire les optimisations du compilateur. On l'utilise toujours lorsque l'on assimile un registre du micro contrôleur comme une variable.

un cas typique de bug que l'on peut rencontrer

Code:

---

1 2 3 4 5

volatile unsigned char PORTA;   PORTA = 0; PORTA = 1; // génération d'un front montant sur le port A PORTA = 0;

---

Sans le volatile, le compilateur va se dire qu'il est bête de mettre à 1 une variable pour la remettre aussitôt à 0. Il va donc ignorer ces lignes de codes. du coup pas de front montant et bug assuré.

Bonne soirée

---

Merci beaucoup pour cette information. Des idées pour le Code 9 ?

J'ai juste une question : si c'est des exercices, tu devrais d'abord essayer de les faire toi-même non ? :)

Pour le code 9, regarde simplement le prototype de la fonction pthread_create et les arguments envoyés.

Citation:

---

Envoyé par Pouet_forever

J'ai juste une question : si c'est des exercices, tu devrais d'abord essayer de les faire toi-même non ? :)

Pour le code 9, regarde simplement le prototype de la fonction pthread_create et les arguments envoyés.

---

Eh jusqu'ici, à quel moment quelqu'un m'as donné une réponse sans que j'en donne une avant ? Donc soit tu post sans n'avoir rien lu des discussions .. soit je ne sais pas. Ce sont les réponses typique des forum "on va pas faire le devoir à ta place". Jusqu'ici je n'ai demandé que correction.

Bref, le prototype de la fonction pthread_create est respecté à l'exception de my_func, ici on à "my_func()" au lieu de "my_func" cela va invoqué la fonction et provoqué l'arrêt de la seule thread du processus avant même la creation de la nouvelle thread! Donc le printf ne s'affichera pas j'imagine.

J’envoie le 10 pour les intéressés:

CODE 10 :
Cet extrait ne fonctionne pas toujours comme attendu!
1. Est-il possible que ce soit parce que « les signaux ne sont pas fiables »?
2. Quelle commande super-utilisateur sur un Linux récent faudrait-il entrer
pour qu'il s'exécute toujours comme espéré?
3. En l'absence de la possibilité offerte par la réponse à la 2ème question cidessus
(10.2), quelle solution apporteriez vous à ce problème?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

void sig_handler(int sig){ gettimeofday(&end, NULL); } int main(void){ int rc; struct sigaction action; action.sa_handler = sig_handler; sigemptyset(&(action.sa_mask)); action.sa_flags = 0; rc = sigaction(SIGCHLD, &action, NULL); switch(fork()){ case 0: return EXIT_SUCCESS; case -1: return EXIT_FAILURE; default: pause(); } }

---

Citation:

---

Envoyé par heazen

B
CODE 6 :

Code:

---

1 2 3 4 5

int res, i; for (i =0; i < 20; i++){ res = fork(); ....blah blah... }

---

ERREUR : Ici c'est le principe même d'un fork bomb j'imagine. [...] Donc il n'y à pas d'erreur mais un danger ...

---

La vraie question qu'il faut se poser ici est : Combien de processus vas-tu creer ?
Aide : deroule le processus a la main, avec un papier et un crayon pour compter le nombre de processus.

Si tu ne vois pas, dis-le, je t'expliquerai.

Citation:

---

Envoyé par gangsoleil

La vraie question qu'il faut se poser ici est : Combien de processus vas-tu creer ?
Aide : deroule le processus a la main, avec un papier et un crayon pour compter le nombre de processus.

Si tu ne vois pas, dis-le, je t'expliquerai.

---

Dans le cas présent on créer 2^20-1 processus. Est-ce la limite pour un non super-utilisateur ?

Rebonsoir, j'ai fini tous mes codes, à l'exception d'un !

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

int main (int argc, char **argv; char **envp) { unsigned long delta; int i; struct timeval *t1 struct timeval *t2; start = malloc(sizeof(struct timeval *)); end = malloc(sizeof(struct timeval *)); if ((start == NULL) || (end == NULL)) exit(1); gettimeofay(&t1,NULL); for (i=0; i < 5; i++) { my_func(); } gettimeofay(&t2,NULL); delta = (t2.tv_sec – t1.tv_sec) * 1000000; delta += (t2.tv_usec – t1.tv_usec); printf("my_func %d dure %d microsecs\n", i, delta/i); }

---

Le problème vient des pointeur timeval, mais pourquoi et comment ?

Citation:

---

Envoyé par heazen

Dans le cas présent on créer 2^20-1 processus. Est-ce la limite pour un non super-utilisateur ?

---

2^20, c'est un peu plus d'un million (1 048 576 pour etre precis). Maintenant, je te conseille de poser ton exercice, et de prendre un peu de recul par rapport a ce chiffre, tu devrais trouver toi-meme la solution.

Ensuite, tu pourras aller voir quelles sont les limites utilisateurs en nombre de processus.

Bonjour,
l’étoile dans le sizeof me parait bizarre, non ?

Citation:

---

Envoyé par gangsoleil

2^20, c'est un peu plus d'un million (1 048 576 pour etre precis). Maintenant, je te conseille de poser ton exercice, et de prendre un peu de recul par rapport a ce chiffre, tu devrais trouver toi-meme la solution.

Ensuite, tu pourras aller voir quelles sont les limites utilisateurs en nombre de processus.

---

Bonjour,

Je voulais juste signalé que j'ai obtenu ma note a ce TP, et pour cette question le nombre de processus était bien de 2^20-1.