Discussion :

[death_style]

Bonjour,
voilà j'essai de catcher les seg fault en utilisant le header SUGNAL.H.

j'utilise un code que j'ai trouvé sur le net.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <string.h>
 
void printstats(void){
 printf("stats!\n");
 _exit(0);
}
 
int main(void){
 /* gonna round up some signals to catch */
 signal(SIGSEGV, printstats); /* '(sig_t) printstats' for freebsd :P */
 
  char p;
  strcpy(p,"jdjfj");
  printf("%s",p);
  printf("holahola");
}

l'application arrive à catcher l'erreur de segmentation, mais par contre elle s'arrete (puisque il y a un exit()) dans ma fonction catch.
probleme si j'enlève exit(), il catch plus l'erreur et bien le programme bug.
comment faire pour retablir l'etat du signal d'origine, pour que le programme saute l'erreur et continue quan même a tourné.
en gros, dans mon code je veux bien que "holahola" soit affichée.
merci et bonne journé

[nicolas.sitbon]

Tu ne peux pas.

[death_style]

Je te remercie pour ta réponse, même si elle vient de me faire plongé dans les ténèbres les plus profonde .

Par contre ça sert à quoi alors? si mon application quitte avec ou sans, je préfère ne pas géré ça.

enfin bref, ... y a t il un autre moyen pour détourner cette satané erreur? par ce que mon application plante après plus de 36 heurs. et ce sont les même tache qui ce répète chaque 15 minute. donc si ça palante pas dans les premières 15 minute, je voi pas pourquoi cette erreur surgie après 36 heurs, defois plus.

merci,

[nicolas.sitbon]

Par contre ça sert à quoi alors?

Tu pourrais éventuellement logger quelque chose dans le cas d'un serveur, en prenant la précaution d'utiliser les bonnes fonctions pour cela, mais en aucun cas tu ne dois revenir de ton gestionnaire de signal dans ce cas.

enfin bref, ... y a t il un autre moyen pour détourner cette satané erreur?

Non, tout ce que tu feras après le retour de ton gestionnaire de signal invoquera un comportement indéterminé.

par ce que mon application plante après plus de 36 heurs. et ce sont les même tache qui ce répète chaque 15 minute. donc si ça palante pas dans les premières 15 minute, je voi pas pourquoi cette erreur surgie après 36 heurs, defois plus.

La solution se trouve là à mon sens, l'erreur de segmentation dans ton client démontre clairement une erreur de programmation. Si tu veux tu peux poster ton code et on verra ça ensemble.
Cordialement.

[jabbounet]

Ce n'est pas parce que ton programme tourne 15 minutes et fait plusieurs itération qu'il durera éternellement.

Sur la durée plein de problèmes peuvent survenir:
- fuite mémoire (memory fault en général)
- Calcul dépassant les limites de tableaux (seg fault en général)
- Connexion tcp se coupant sans prévenir parce que quelqu'un se prend les pied dans les câbles réseau (broken pipe)
- ...

En général il vaux mieux rechercher l'origine de ces problèmes plutôt que d'essayer de se récupérer après, la la rigueur tu peux essayer de sauver quelques trucs mais ils risquent d'être foireux aussi....

Si tu es sous linux / Unix tu as la possibilité de faire des debug post mortem sur des fichiers coredump (il doit y avoir un équivalent sous windows mais je ne connais pas dr watson peu être).
http://www.cmi.univ-mrs.fr/~contensi...=env&page=deb5

Ensuite tu peux vérifier si tu as des fuites mémoires en utilisant un programme genre valgrind.

[death_style]

Ah merci, je vois plus claire,
je travaille sous linux embarqué, et mes programme je les compile pour un processeur arm. tous ça dans une carte de developpement la AT91SAM2960-EK.
Donc, pour le gdb, y en a pas sur ma carte de embarqué. et du coup je peux pas lancé mon application en mode debug. mais si ça existe un truc de debugage pour le linux embarqué , je suis là.

en fait mon programme manipule des fichier. donc l'itération consiste à copier deplacer créer supprimer et envoyer des fichier par FTP. via un cable réseaux. j'en suis sur que ça a une rapport avec mes pointeurs. je les ai initialisé tous , et j'ai affecté une valeur pour chaque pointeurs pour qu'il ne soit pas nul. j'ai relancé mon application, j'espère que ça plantera pas d'ici demain.
merci pour vos réponses

[jabbounet]

Tu utilise un compilateur croisé? ou tu génère tes exe sur ta carte?

normalement tu peux générer des core sur ta cible en tapant
ulimit -c unlimited
avant d'exécuter ton programme.


après si tu est chanceux gdb saura lire tes symboles sur hôte.

[death_style]

oui j'utilise un cross, je génère mon application et je l'envoi à la carte via minicom ou telnet. après je l'execute.

[jabbounet]

et autrement ton prog peu tourner sur hôte ou il y'a trop de truc spécifique qui font qu'il doit obligatoirement tourner sur ta cible?

il y'a la solution d'essayer de faire du cross debugging
http://www.linux.com/archive/feature/121735

[death_style]

j'ai jeté un coup d'oeil sur le dernier lien,
si j'ai bien compris, je peu simulé mon application qui est compilé pour l'architecture ARM, sur mon intel ?
bon j'ai installé et tout configuré, par contre quand je fait run dans gdb, il me dit don't know how to run"

Code X :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
debian:/home/adm/Desktop#arm-none-linux-gnueabi-gcc -g app.c -o app
debian:/home/adm/Desktop# arm-none-linux-gnueabi-gdb app
GNU gdb (Sourcery G++ Lite 2008q3-41) 6.8.50.20080821-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi".
For bug reporting instructions, please see:
<https://support.codesourcery.com/GNUToolchain/>...
(gdb) run
Starting program: /home/adm/Desktop/app
Don't know how to run.  Try "help target".

Que faut il spécifer? est ce que j'ai oublié un truc?
Merci pour votre temps.
pour mon application elle s'est arreté après plus de 30 heures comme d'hab.

[jabbounet]

j'ai jeté un coup d'oeil sur le dernier lien,
si j'ai bien compris, je peu simulé mon application qui est compilé pour l'architecture ARM, sur mon intel ?
bon j'ai installé et tout configuré, par contre quand je fait run dans gdb, il me dit don't know how to run"

Code X :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
debian:/home/adm/Desktop#arm-none-linux-gnueabi-gcc -g app.c -o app
debian:/home/adm/Desktop# arm-none-linux-gnueabi-gdb app
GNU gdb (Sourcery G++ Lite 2008q3-41) 6.8.50.20080821-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi".
For bug reporting instructions, please see:
<https://support.codesourcery.com/GNUToolchain/>...
(gdb) run
Starting program: /home/adm/Desktop/app
Don't know how to run.  Try "help target".

Que faut il spécifer? est ce que j'ai oublié un truc?
Merci pour votre temps.
pour mon application elle s'est arreté après plus de 30 heures comme d'hab.

oui il faut lancer le gdb serveur sur la cible

Code X :

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

1
2
3
4
Remote debugging is rather straightforward: on the target platform, launch the application with GDBserver, while specifying the host and port for listening to an incoming TCP connection:

  gdbserver HOST:PORT PROG [ARGS ...]

[death_style]

OK, mais c'est un petit peu louche.

oui il faut lancer le gdb serveur sur la cible

depuis la carte ??????
quand je fais:

Code :

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

1
2
3
4
5
6
7
8
(...)/Desktop# gdbserver /dev/ttyS0 app
 Process app created; pid = 13942
Cannot exec app: Exec format error.

Child exited with retcode = 7f
Remote debugging using /dev/ttyS0

l'application est compilé pour le proc ARM, est ce pour ça qu'il me retourne Exec format error ?
just une petite question, avec ça je peux m'empassé de ma carte, je veux dire, j'ai rien a faire au niveau de ma carte. je fait tout sur mon ordinateur.

[jabbounet]

OK, mais c'est un petit peu louche.

depuis la carte ??????
quand je fais:

Code :

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

1
2
3
4
5
6
7
8
(...)/Desktop# gdbserver /dev/ttyS0 app
 Process app created; pid = 13942
Cannot exec app: Exec format error.

Child exited with retcode = 7f
Remote debugging using /dev/ttyS0

l'application est compilé pour le proc ARM, est ce pour ça qu'il me retourne Exec format error ?
just une petite question, avec ça je peux m'empassé de ma carte, je veux dire, j'ai rien a faire au niveau de ma carte. je fait tout sur mon ordinateur.

non je pense que tu as besoin de la carte quoi qu'il arrive. cependant je crois qu'il attend plus un nom d'hote et un port au vu de

Remote debugging is rather straightforward: on the target platform, launch the application with GDBserver, while specifying the host and port for listening to an incoming TCP connection:

gdbserver HOSTORT PROG [ARGS ...]

plutot qu'un device

[JeitEmgie]

Tu ne peux pas.

http://libsigsegv.sourceforge.net/

[nicolas.sitbon]

http://libsigsegv.sourceforge.net/

et je maintiens ce que j'ai dis, je connais libsigsegv et c'est de la connerie, pardonne moi l'expression.

About stack overflow handlers.

In some applications, the stack overflow handler performs some cleanup or
notifies the user and then immediately terminates the application. In
other applications, the stack overflow handler longjmps back to a central
point in the application. This library supports both uses. In the second
case, the handler must ensure to restore the normal signal mask (because
many signals are blocked while the handler is executed), and must also
call sigsegv_leave_handler() to transfer control; then only it can longjmp
away.

La première méthode est celle que j'ai donné et ne change donc rien au problème du PO, la seconde invoque encore un autre comportement indéterminé, il est interdit d'appeler longjmp() depuis un gestionnaire de signal.

Voici ce que dit la norme pour t'en convaincre:

If and when the function returns, if the
value of sig is SIGFPE, SIGILL, SIGSEGV, or any other implementation-defined
value corresponding to a computational exception, the behavior is undefined; otherwise
the program will resume execution at the point it was interrupted.

et pour longjmp:

If the signal occurs other than as the result of calling the abort or raise function, the
behavior is undefined if the signal handler refers to any object with static storage duration
other than by assigning a value to an object declared as volatile sig_atomic_t, or
the signal handler calls any function in the standard library other than the abort
function, the _Exit function, or the signal function with the first argument equal to
the signal number corresponding to the signal that caused the invocation of the handler.

[JeitEmgie]

et je maintiens ce que j'ai dis, je connais libsigsegv et c'est de la connerie, pardonne moi l'expression.

libsigsegv existe et peut intéresser certains qui suivent le forum et ne le connaissent pas encore, ne fusse que pour comprendre ce qu'il fait et comment (c'est open source) et donc pourquoi c'est loin de tout résoudre et certainement pas de permettre à un programme bogué de continuer à fonctionner comme si de rien n'était..

Par contre cela permet de faire des choses amusantes… (un "crash report" customisé plus directement lisible qu'un coredump par exemple…) mais ce n'est pas à mettre entre toutes les mains…

Quant à l'expression "the behavior is undefined" dans une spécification, cela veut simplement dire qu'il ne faut pas extrapoler les résultats obtenus dans un environnement dans un autre… pas que le comportement soit aléatoire…
Quand on maîtrise bien un environnement précis rien n'interdit d'explorer ce qui se passe dans ces fameux cas au comportement non défini et d'en tirer parti pour résoudre un problème particulier…

Pour ceux que çà intéresse :
GNU M4, GNU SmallTalk, CLisp, … utilisent libsigsegv…
tous sont OpenSource… il est donc possible de voir pourquoi et comment ils l'utilisent…

[nicolas.sitbon]

libsigsegv existe et peut intéresser certains qui suivent le forum et ne le connaissent pas encore, ne fusse que pour comprendre ce qu'il fait et comment (c'est open source) et donc pourquoi c'est loin de tout résoudre et certainement pas de permettre à un programme bogué de continuer à fonctionner comme si de rien n'était..

Alors à quoi ça peut bien servir...

Par contre cela permet de faire des choses amusantes… (un "crash report" customisé plus directement lisible qu'un coredump par exemple…) mais ce n'est pas à mettre entre toutes les mains…

Pourquoi? on peut déjà le faire normalement, c'est ce que j'ai expliqué au début. Donc jusqu'ici rien ne justifie son utilisation.

Quant à l'expression "the behavior is undefined" dans une spécification, cela veut simplement dire qu'il ne faut pas extrapoler les résultats obtenus dans un environnement dans un autre… pas que le comportement soit aléatoire…
Quand on maîtrise bien un environnement précis rien n'interdit d'explorer ce qui se passe dans ces fameux cas au comportement non défini et d'en tirer parti pour résoudre un problème particulier…

Bien sûr, c'est toi qui va refaire la définition du comportement indéterminé!
Plutôt que de dire des bétises, apprend la norme et à coder correctement.

3.4.3 undefined behavior
1 behavior,upon use of a nonportable or erroneous program construct or of erroneous data,
for which this International Standard imposes no requirements
2 NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable
results, to behaving during translation or program execution in a documented manner characteristic of the
environment (with or without the issuance of a diagnostic message), to terminating a translation or
execution (with the issuance of a diagnostic message).
3 EXAMPLE An example of undefined behavior is the behavior on integer overflow

[death_style]

salut, et merci pour vos réponses
j'ai vu libsigsegv, apparement quand je l'implant sur mon code, ça marche pas.

je crois que je vais mettre mes codes, j'espère que vous saurez corriger mes erreur sils existent:
je le cache pas j'ai deux warning dans ma fonction lsDirectory
functions.h:548: warning: assignment from incompatible pointer type
functions.h:556: warning: assignment from incompatible pointer type

Code :

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

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
41
42
43
44
45
 
char** lsDirectory(char folder[150])
{
  DIR           *d;
	d=(char*) malloc(sizeof(char*)*10);
  struct dirent *dir;
 
 
  int i=0;
  int j=0;
  char **filesList,vfilesList;
 
filesList=&vfilesList;
 
  d = opendir(folder);
  if (d)
  {
    while ((dir = readdir(d)) != NULL)
    {
      i++;
    }
   }
   closedir(d);
    if (i!=0)
    {
  	d = opendir(folder);
 	if (d)
  	{
		filesList = (char**) malloc(sizeof(char*) * i);
   		while ((dir = readdir(d)) != NULL)
   		{
			if(strcmp(dir->d_name,".")!=0 & strcmp(dir->d_name,"..")!=0)
			{
				printf("                  %s\n", dir->d_name);
      				filesList[j] = dir->d_name;
				j++;
			}
    		}
	closedir(d);
	}
    }
 
  return filesList;
  //si pas de resultat : return null
}

merci d'avance

[nicolas.sitbon]

Je n'ai pas tout lu mais:

La fonction lsDirectory() est complètement buggé et à revoir incluant:
- la gestion des chaines de caractères
- l'opérateur &
- l'indentation (valable pour tout ton code)

Mon conseil, revoir les bases du C avant de te lancer dans de l'embarqué. Pour information, un des hauts intervenants(Emmanuel Delahaye) de ce site, qui possède une certaine expérience en la matière (17 ans je crois), à développer un bibliothèque de fonction (clib) qui a fait ses preuves, ainsi qu'un site sur le langage C que je t'invite à parcourir :
http://emmanuel-delahaye.developpez.com/
Cordialement.

[death_style]

Merci pour le lien, je crois que je vais le visiter plus souvent.
Mais y a un facteur qu'on appelle facteur temps, et qui n'est pas à notre faveur, donc je préfère résoudre mon probleme que de réapprendre le C depuis le début. bref j'ai trouvé une solution, et ça marche.

Code :

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

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
 
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <string.h>
#include <setjmp.h>
 
static jmp_buf buf;
 
void cth()
{
    printf("\nsegmention error found");
    longjmp(buf,1);
}
int main()
{
    //printf("%i",setjmp(buf));
    signal(SIGSEGV,cth);
    if (!setjmp(buf) )
    {
        char p;
        strcpy(p,"jdjfj");
        printf("%s",p);               
    }
 
    printf("\nmon holahola");
 
}

merci et aplus