Comment contrer la "segmentation fault" ?

Version imprimable

07/08/2003, 14h04
guillaume_pfr

[RESOLU] Comment contrer la "segmentation fault" ?

(Je vais reprendre un peu l'article sur les pointeurs de Linux Magazine N°52, article "un pointeur sachant pointer" par Yves Mettier)

Citation:

Envoyé par Yves Mettier

Lors de l'allocation d'une zone mémoire, l'OS réserve au prog une page mémoire de 4Ko ou plus suivant les besoins (...) Lors d'une nouvelle allocation de mémoire, l'OS regardera si toutes les pages réservées sont utilisées, réservera les pages nécessaires et dira au prog quelles adresses il peut utiliser (...)
Si on déborde de la page il est probable qu'on essaye d'atteindre une page qui nous est pas réservée. (...)
Si on se contente de déborder ce qui nous a été attribué sans déborder de la page, alors le systeme ne dira rien et vous allez écraser vos propres données
(...)

Il dit aussi plus loin que ce problème n'arrive sous Linux que le programme se servira réellement des variables.
Pas comme sous Windows ... :!:

J'crois que c'est exactement le problème que j'ai:
Le bout de programme que je dois porter sous Windows marche très bien sous Unix, mais pas sous Cygwin.

Mon programme plante aléatoirement, mais plus particulièrement au niveau de 2 malloc qui se suivent. Sinon les autres plantages ont lieu plus loin dans le programme. (à noter que dès fois même ça ne plante pas)
Cela a pour effet de stopper l'exécution du programme :?
07/08/2003, 14h29
Kimael

Bah pour répondre à ta question VALGRIND t'aidera mieux que moi (c'est une machine virtuelle permettant entre autres de gérer les fuites de mémoire.

Bon courage.

PS: en recherchant "valgrind" sur les forums j'ai trouvé 2 sujets.
07/08/2003, 15h30
guillaume_pfr

Le problème c'est que j'ai besoin de tester tout ça sous cygwin moi et ces programmes ont pas l'air de marcher sous cygwin :?

J'ai regarder également pour ElectricFence mais rien du tout non plus :cry:
07/08/2003, 15h45
Kimael

Fais voir le code, mais à mon avis ça sert à rien...

Oui c'est trop gros ...
Cependant je viens de me trouver une machine avec Unix et je viens de tester le programme.
Effectivement il y a des erreurs mais j'arrive pas trop à interpréter le message

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
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
# ./valgrind --leak-check=yes -v --show-reachable=yes /home/.../gestion.exe
 
==18776== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
 
==18776== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
 
==18776== Using valgrind-20030725, a program supervision framework for x86-linux.
 
==18776== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
 
==18776== Startup, with flags:
 
==18776== --suppressions=/home/.../valgrind/lib/valgrind/default.supp
 
==18776== --leak-check=yes
 
==18776== -v
 
==18776== --show-reachable=yes
 
==18776== Reading syms from /home/.../ATHYS/vishyr/bin/gestion.exe
 
==18776== Reading syms from /lib/ld-2.2.5.so
 
==18776== object doesn't have any debug info
 
==18776== Reading syms from /home/.../valgrind/lib/valgrind/vgskin_memcheck.so
 
==18776== Reading syms from /home/.../valgrind/lib/valgrind/valgrind.so
 
==18776== Reading syms from /usr/lib/libtk.so.0
 
==18776== object doesn't have any debug info
 
==18776== Reading syms from /usr/lib/libtcl.so.0
 
==18776== object doesn't have any debug info
 
==18776== Reading syms from /lib/libdl-2.2.5.so
 
==18776== object doesn't have any debug info
 
==18776== Reading syms from /usr/X11R6/lib/libX11.so.6.2
 
==18776== object doesn't have a symbol table
 
==18776== object doesn't have any debug info
 
==18776== Reading syms from /lib/i686/libm-2.2.5.so
 
==18776== object doesn't have any debug info
 
==18776== Reading syms from /lib/i686/libc-2.2.5.so
 
==18776== object doesn't have any debug info
 
==18776== Reading suppressions file: /home/.../valgrind/lib/valgrind/default.supp
 
==18776== Estimated CPU clock rate is 467 MHz
 
==18776==
 
==18776== Reading syms from /usr/X11R6/lib/X11/locale/common/xlcDef.so.2
 
==18776== object doesn't have any debug info
 
==18776== Reading syms from /usr/X11R6/lib/X11/locale/common/ximcp.so.2
 
==18776== object doesn't have any debug info
 
==18776== Reading syms from /usr/lib/gconv/ISO8859-1.so
 
==18776== object doesn't have a symbol table
 
==18776== object doesn't have any debug info
 
==18776== Invalid read of size 1
 
==18776== at 0x804DC33: Tcl_AppInit (tkAppInit.c:144)
 
==18776== by 0x4026F30E: Tk_MainEx (in /usr/lib/libtk.so.0)
 
==18776== by 0x804DBA8: main (tkAppInit.c:66)
 
==18776== by 0x42017498: __libc_start_main (in /lib/i686/libc-2.2.5.so)
 
==18776== Address 0x0 is not stack'd, malloc'd or free'd
 
Incident de segmentation (core dumped)

07/08/2003, 16h44
Kimael

OK, j'avoue, je ne me suis jamais vraiment servi de ValGrind (mes codes étaient parfaits :lol:) !
Je l'ai découvert alors que je me mettais sur un projet Java et là je suis sur du PHP.
J'ai un pote qui pourrait t'aider... je le contact.

Il va falloir finir sans moi... :oops:
PS: juste comme ça, à priori ton problème c'est un "NULL pointer problem" (0x0 = NULL me semble-t-il) :?:
07/08/2003, 16h54
hot metal

Salut

il ta creer un .core Incident de segmentation (core dumped)
tu peut le regarder avec gdb pour plus de renseignement man gdb

J'ai encore moins compris le core de gdb !!!

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# gdb -core=core.18776
 
GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT)
 
Copyright 2001 Free Software Foundation, Inc.
 
GDB is free software, covered by the GNU General Public License, and you are
 
welcome to change it and/or distribute copies of it under certain conditions.
 
Type "show copying" to see the conditions.
 
There is absolutely no warranty for GDB. Type "show warranty" for details.
 
This GDB was configured as "i386-redhat-linux".
 
Core was generated by `/home/.../gestion.exe'.
 
Program terminated with signal 11, Segmentation fault.
 
#0 0x4142708f in ?? ()

07/08/2003, 17h38
hot metal

Salut

tu dois compiller ton programme avec l'option -g de gcc ensuite quand tu as ton .core tu tape gdb programme -c programme.core

je ne suis pas vraiment sur je n'ai pas de .core sous la main pour tester.
08/08/2003, 13h01
guillaume_pfr
C'est bon j'ai trouvé d'où venait le problème ...
Code:

1 2 3 4 chaine = (char*) malloc (strlen(char1) + strlen(char2)); strcpy (chaine , char1); strcat (chaine , char2);
Si je me plante pas quand on fait strlen ça nous renvoie la taille de la chaîne de caractères, mais sans le "\0", non ?
Donc si on concatène les deux chaînes ben il manquera un octet pour le "\0" ... enfin je crois !
Donc j'ai rajouté 1 octet pour le "\0" dans le malloc et ça donne ça :
Code:

1 2 chaine = (char*) malloc (strlen(char1) + strlen(char2)+1);
et là ça marche !

Par contre j'aimerai en être sûr lol ... Histoire que je comprenne bien ce que je fais ! :lol:
Donc si quelqu'un pouvait me confirmer ... ça serait cool ! :ccool:
08/08/2003, 13h09
Kimael
Oui, c'est ça :
Code:

1 2 3 4 char* szToto; szToto = (char*)calloc(10, sizeof(char)); strcpy(szToto, "toto"); strlen(szToto) == 4;
...alors que dans szToto tu as "toto\0".

Un dernière remarque : utilise plutôt calloc que malloc, car le premier initialise les octets à 0 et pas le deuxième (je crois).
De toutes façons, tu aura de plus précises précisions (lol) dans un doc C ;)
08/08/2003, 13h11
guillaume_pfr

Et un grand :merci: pour ton aide
Je foutrai une grand claque aux programmeurs qui ont fait ça ... :kill:
08/08/2003, 13h16
Kimael

Citation:

Envoyé par guillaume_pfr

Je foutrai une grand claque aux programmeurs qui ont fait ça ... :kill:

Euh... pourquoi :?: au contraire, ils ont facilités les choses...
Il suffit d'être AWARE de comment ils ont prévu qu'on s'en serve !

Moralité (belge) : BE AWARE :!: lol

PS: j'ai édité mon post précédent.
08/08/2003, 13h36
guillaume_pfr

Ok Jean-Claude ! :ccool:

Mais pour ce qui est des programmeurs, d'accord je leur foutrait pas une claque... je leur en mettrai deux !!! :sm:

j'en ai marre de rattraper leur c$¤*%?ries !

C'est une grosse appli que je dois porter sous windows et si ça avait été programmé plus proprement et dans les normes y aurait pas eu de problèmes comme j'ai maintenant ! :furieux:

Mais c'est cool de m'avoir aider !
08/08/2003, 13h41
Kimael

AAAaaahhhh :lol:
Je croyais que tu parlais des mecs qui ont écrit les strcpy(), calloc() et autres strlen()...
Ok, désormais je te soutiens pleinement !
Bon courage :?
08/08/2003, 13h43
guillaume_pfr

loooooool non pas eux !

Pour eux c'est plutôt respect :hola: :ave: