[RÉSOLU] Plantage pas commun en C...

talrasha · Le 20/05/2008, à 02:29

Salut à tous,

Je suis en plein codage d'un projet en C, qui consiste principalement à un calcul du plus court chemin dans un graphe. J'ai inclu dans le projet une interface graphique codé en GTK.

Je me retrouve de temps en temps confronté à un plantage bizzard. En général, en C, quand on fait un code pourri, on a droit à un "Segmentation fault" hyper courant. Mais la, je ne sais pas exactement quoi penser...

*** glibc detected *** ./graphe: munmap_chunk(): invalid pointer: 0x082127f8 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(cfree+0x1bb)[0xb782661b]
/usr/lib/libglib-2.0.so.0(g_free+0x31)[0xb79458b1]
/usr/lib/libpango-1.0.so.0(pango_parse_markup+0x28e)[0xb7a7e92e]
/usr/lib/libgtk-x11-2.0.so.0[0xb7cb3f40]
/usr/lib/libgtk-x11-2.0.so.0(gtk_label_set_markup+0x81)[0xb7cb4871]
./graphe[0x8049fb2]
./graphe[0x804aea1]
/usr/lib/libgtk-x11-2.0.so.0[0xb7ccc8d4]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x129)[0xb79c9759]
/usr/lib/libgobject-2.0.so.0[0xb79ddd1d]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x5fe)[0xb79df64e]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0xb79dfc59]
/usr/lib/libgtk-x11-2.0.so.0[0xb7deb667]
/usr/lib/libgtk-x11-2.0.so.0(gtk_propagate_event+0xc1)[0xb7cc5b21]
/usr/lib/libgtk-x11-2.0.so.0(gtk_main_do_event+0x3c2)[0xb7cc6e92]
/usr/lib/libgdk-x11-2.0.so.0[0xb7b3fa9a]
/usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x178)[0xb793dbf8]
/usr/lib/libglib-2.0.so.0[0xb7940e5e]
/usr/lib/libglib-2.0.so.0(g_main_loop_run+0x1e7)[0xb79411e7]
/usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xb4)[0xb7cc7264]
./graphe[0x804a537]
./graphe[0x804af65]
/usr/lib/libgtk-x11-2.0.so.0[0xb7ccc8d4]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x129)[0xb79c9759]
/usr/lib/libgobject-2.0.so.0[0xb79ddd1d]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x5fe)[0xb79df64e]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0xb79dfc59]
/usr/lib/libgtk-x11-2.0.so.0[0xb7deb667]
/usr/lib/libgtk-x11-2.0.so.0(gtk_propagate_event+0xc1)[0xb7cc5b21]
/usr/lib/libgtk-x11-2.0.so.0(gtk_main_do_event+0x3c2)[0xb7cc6e92]
/usr/lib/libgdk-x11-2.0.so.0[0xb7b3fa9a]
/usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x178)[0xb793dbf8]
/usr/lib/libglib-2.0.so.0[0xb7940e5e]
/usr/lib/libglib-2.0.so.0(g_main_loop_run+0x1e7)[0xb79411e7]
/usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xb4)[0xb7cc7264]
./graphe[0x80499b9]
./graphe[0x80495c5]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb77cd450]
./graphe[0x80494b1]
======= Memory map: ========
08048000-0804e000 r-xp 00000000 08:03 672978     /home/talrashha/jetest/graphe
0804e000-0804f000 rw-p 00005000 08:03 672978     /home/talrashha/jetest/graphe
0804f000-0822f000 rw-p 0804f000 00:00 0          [heap]
b6e8a000-b6f8e000 rw-p b6e8a000 00:00 0 
b6f8e000-b7015000 r--p 00000000 08:03 2123287    /usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-Bold.ttf
b7015000-b7119000 rw-p b7015000 00:00 0 
b7119000-b71aa000 r--p 00000000 08:03 2123288    /usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf
b71aa000-b71ac000 r-xp 00000000 08:03 2064483    /usr/lib/pango/1.6.0/modules/pango-basic-fc.so
b71ac000-b71ad000 rw-p 00001000 08:03 2064483    /usr/lib/pango/1.6.0/modules/pango-basic-fc.so
b71ad000-b71b3000 r--s 00000000 08:03 999488     /var/cache/fontconfig/945677eb7aeaf62f1d50efc3fb3ec7d8-x86.cache-2
b71b3000-b71b6000 r--s 00000000 08:03 999498     /var/cache/fontconfig/e383d7ea5fbe662a33d9b44caf393297-x86.cache-2
b71b6000-b71b7000 r--s 00000000 08:03 999490     /var/cache/fontconfig/c69f04ab05004e31a6d5e715764f16d8-x86.cache-2
b71b7000-b71b8000 r--s 00000000 08:03 999483     /var/cache/fontconfig/4c73fe0c47614734b17d736dbde7580a-x86.cache-2
b71b8000-b71bb000 r--s 00000000 08:03 999489     /var/cache/fontconfig/a755afe4a08bf5b97852ceb7400b47bc-x86.cache-2
b71bb000-b71c2000 r--s 00000000 08:03 1005993    /var/cache/fontconfig/6d41288fd70b0be22e8c3a91e032eec0-x86.cache-2
b71c2000-b71c5000 r--s 00000000 08:03 999495     /var/cache/fontconfig/de156ccd2eddbdc19d37a45b8b2aac9c-x86.cache-2
b71c5000-b71cd000 r--s 00000000 08:03 999499     /var/cache/fontconfig/e3de0de479f42330eadf588a55fb5bf4-x86.cache-2
b71cd000-b71d5000 r--s 00000000 08:03 999478     /var/cache/fontconfig/0f34bcd4b6ee430af32735b75db7f02b-x86.cache-2
b71d5000-b71d6000 r--s 00000000 08:03 999481     /var/cache/fontconfig/4794a0821666d79190d59a36cb4f44b5-x86.cache-2
b71d6000-b71d9000 r--s 00000000 08:03 999496     /var/cache/fontconfig/de9486f0b47a4d768a594cb4198cb1c6-x86.cache-2
b71d9000-b71e0000 r--s 00000000 08:03 999493     /var/cache/fontconfig/d52a8644073d54c13679302ca1180695-x86.cache-2
b71e0000-b71e6000 r--s 00000000 08:03 999477     /var/cache/fontconfig/089dead882dea3570ffc31a9898cfb69-x86.cache-2
b71e6000-b71e8000 r--s 00000000 08:03 999715     /var/cache/fontconfig/e13b20fdb08344e0e664864cc2ede53d-x86.cache-2
b71e8000-b7210000 r-xp 00000000 08:03 2024123    /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so
b7210000-b7211000 rw-p 00028000 08:03 2024123    /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so
b7211000-b7233000 r--p 00000000 08:03 2261180    /usr/share/locale-langpack/fr/LC_MESSAGES/libc.mo
b7233000-b7258000 r--p 00000000 08:03 2261148    /usr/share/locale-langpack/fr/LC_MESSAGES/gtk20-properties.mo
b7258000-b7261000 r-xp 00000000 08:03 378216     /lib/tls/i686/cmov/libnss_files-2.7.so
b7261000-b7263000 rw-p 00008000 08:03 378216     /lib/tls/i686/cmov/libnss_files-2.7.so
b7263000-b726b000 r-xp 00000000 08:03 378220     /lib/tls/i686/cmov/libnss_nis-2.7.so
b726b000-b726d000 rw-p 00007000 08:03 378220     /lib/tls/i686/cmov/libnss_nis-2.7.so
b726d000-b7281000 r-xp 00000000 08:03 378210     /lib/tls/i686/cmov/libnsl-2.7.so
b7281000-b7283000 rw-p 00013000 08:03 378210     /lib/tls/i686/cmov/libnsl-2.7.so
b7283000-b7285000 rw-p b7283000 00:00 0 
b7285000-b728c000 r-xp 00000000 08:03 378212     /lib/tls/i686/cmov/libnss_compat-2.7.so
b728c000-b728e000 rw-p 00006000 08:03 378212     /lib/tls/i686/cmov/libnss_compat-2.7.so
b728f000-b7299000 r--p 00000000 08:03 2261101    /usr/share/locale-langpack/fr/LC_MESSAGES/glib20.mo
b7299000-b72a0000 r-xp 00000000 08:03 2460018    /usr/lib/gtk-2.0/2.10.0/engines/libpixmap.so
b72a0000-b72a1000 rw-p 00007000 08:03 2460018    /usr/lib/gtk-2.0/2.10.0/engines/libpixmap.so
b72a1000-b72b2000 r--p 00000000 08:03 2261149    /usr/share/locale-langpack/fr/LC_MESSAGES/gtk20.mo
b72b2000-b72f1000 r--p 00000000 08:03 2024768    /usr/lib/locale/fr_FR.utf8/LC_CTYPE
b72f1000-b73d2000 r--p 00000000 08:03 2024899    /usr/lib/locale/fr_FR.utf8/LC_COLLATE
b73d2000-b73d4000 rw-p b73d2000 00:00 0 
b73d4000-b73e8000 r-xp 00000000 08:03 378225     /lib/tls/i686/cmov/libpthread-2.7.so
b73e8000-b73ea000 rw-p 00013000 08:03 378225     /lib/tls/i686/cmov/libpthread-2.7.so
b73ea000-b73ed000 rw-p b73ea000 00:00 0 
b73ed000-b73f1000 r-xp 00000000 08:03 2000187    /usr/lib/libXdmcp.so.6.0.0
b73f1000-b73f2000 rw-p 00003000 08:03 2000187    /usr/lib/libXdmcp.so.6.0.0
b73f2000-b73f4000 r-xp 00000000 08:03 2000176    /usr/lib/libXau.so.6.0.0
b73f4000-b73f5000 rw-p 00001000 08:03 2000176    /usr/lib/libXau.so.6.0.0
b73f5000-b7414000 r-xp 00000000 08:03 2000413    /usr/lib/libexpat.so.1.5.2
b7414000-b7416000 rw-p 0001e000 08:03 2000413    /usr/lib/libexpat.so.1.5.2
b7416000-b742d000 r-xp 00000000 08:03 2001017    /usr/lib/libxcb.so.1.0.0
b742d000-b742e000 rw-p 00016000 08:03 2001017    /usr/lib/libxcb.so.1.0.0
b742e000-b742f000 rw-p b742e000 00:00 0 
b742f000-b7430000 r-xp 00000000 08:03 2001015    /usr/lib/libxcb-xlib.so.0.0.0
b7430000-b7431000 rw-p 00000000 08:03 2001015    /usr/lib/libxcb-xlib.so.0.0.0
b7431000-b7457000 r-xp 00000000 08:03 2000835    /usr/lib/libpcre.so.3.12.1
b7457000-b7458000 rw-p 00026000 08:03 2000835    /usr/lib/libpcre.so.3.12.1
b7458000-b746f000 r-xp 00000000 08:03 360573     /lib/libselinux.so.1
b746f000-b7471000 rw-p 00016000 08:03 360573     /lib/libselinux.so.1
b7471000-b747b000 r-xp 00000000 08:03 360512     /lib/libgcc_s.so.1
b747b000-b747c000 rw-p 0000a000 08:03 360512     /lib/libgcc_s.so.1
b747c000-b7564000 r-xp 00000000 08:03 2000954    /usr/lib/libstdc++.so.6.0.9
b7564000-b7567000 r--p 000e8000 08:03 2000954    /usr/lib/libstdc++.so.6.0.9
b7567000-b7569000 rw-p 000eb000 08:03 2000954    /usr/lib/libstdc++.so.6.0.9
b7569000-b7570000 rw-p b7569000 00:00 0 
b7570000-b7598000 r-xp 00000000 08:03 2000845    /usr/lib/libpixman-1.so.0.10.0
b7598000-b7599000 rw-p 00027000 08:03 2000845    /usr/lib/libpixman-1.so.0.10.0
b7599000-b75bb000 r-xp 00000000 08:03 2000849    /usr/lib/libpng12.so.0.15.0
b75bb000-b75bc000 rw-p 00022000 08:03 2000849    /usr/lib/libpng12.so.0.15.0
b75bc000./prg: line 7: 11555 Abandon                 ./graphe reseau_urbain.txt

Je ne demande pas de débugger mon code, je voudrais juste savoir ce qui en général peut provoquer ce genre de rapport d'erreur...

Merci

Dernière modification par talrasha (Le 21/05/2008, à 15:43)

UgM · Le 20/05/2008, à 02:43

Bonsoir,

Je pense que tu as essayé de libérer une mémoire (avec la fonction free ou g_free) sur laquelle tu ne devrais pas. En fait, il y a certaines fonctions que retournent par exemple un pointeur vers une chaine de caractère mais tu ne dois pas libérer la mémoire occupée par la chaine de caractère.
Je ne suis pas un pro. Espérant qu'un pro passe sur ce post.

@+

talrasha · Le 20/05/2008, à 03:30

Hum, interessant.
J'ai viré tous les "free" que je fesais dans le programme et l'execution avance un peu plus... mais c'est loin d'être réglé.
En fait, lorsque je fait j'ai eu une seg fault au gtk_widget_show_all();
Et je pense que cà a un rapport avec le fait que de temps en temps, j'ai le même genre d'erreur, mais qui commence par le ligne

*** glibc detected *** ./graphe: free(): invalid next size (fast): 0x082127e0 ***

J'ai l'impression que ces problèmes sont liés...
En règle général, qu'est ce qui peut faire planter un malloc ?

(Je sais que l'espace disque ou mémoire peut être une raison... mais sachant qu'il me reste de la place sur mon disque, comment pourrais-je contrôler une telle chose...)

Merci

nicolas.sitbon · Le 20/05/2008, à 08:06

Déjà, vérifies tu le retour de malloc dans ton code?
Ensuite comme dit plus haut, ce message est là pour t'indiquer que tu appliques free() sur de la mémoire non alloué par malloc().
Enfin, la moindre des choses serait de poster un minimum de code compilable que l'on puisse reproduire l'erreur et t'en dire plus.
Cordialement.

Ultandir · Le 20/05/2008, à 08:23

Bonjour,
Il est vrai qu'un peu de code nous aiderait a t'aider.

Sinon, en effet, l'erreur me parait un free appliqué sur une adresse mémoire non alloué.
Est tu sur que l'adresse a laquelle tu applique le free est alloué a quelque chose?

Si tu as un sefault au gtk_widget_show_all, il y a un problème dans tes widgets, est tu sur qu'ils sont tous "initialisé" si je puis dire?

rniamo · Le 20/05/2008, à 12:24

je l'ai eu celle-ci, ça vient bien d'un problème de malloc/free. Aprés sans code c'est dur de trouver...

ogaby · Le 20/05/2008, à 13:21

invalid next size

A mon avis, il y a un problème de reallocation. Un exemple d'erreur: allouer une taille à une variable, affecter un pointeur sur la variable puis changer la taille du pointeur puis libérer la variable... -> ca fait prout.

Debug soigneusement entre le malloc et le free en faisant attention aux sous fonctions.

talrasha · Le 20/05/2008, à 14:31

Bon, ok, je met un peu de code...
Les scrupules que j'ai face à ca, c'est que j'ai un gros paquet de ligne et que pas mal de partie ont l'air de fonctionné indépendament.

La fonction "corrige" est une appelle une fonction "correction" qui renvoie un tableau d'entier. En fonction de la taille du tableau d'entier, elle doit appeller l'une ou l'autre des fonction fenêtre GTK.

void corrige(GtkWidget *pWidget, GdkEventButton *event, gpointer pData) {
  GtkWidget ** pEntry;
  int nb_pos1, nb_pos2;
  int ** l_pos;
  int gare[2];
  char * str;

  l_pos=malloc(4*sizeof(int *));
  pEntry=(GtkWidget **)pData;  

  sprintf(str,"%s",(char *)gtk_entry_get_text(GTK_ENTRY(pEntry[0])));
  l_pos[0]=correction(str, indexx, l_pos[0], &nb_pos1);
  sprintf(str,"%s",(char *)gtk_entry_get_text(GTK_ENTRY(pEntry[1])));
  l_pos[1]=correction(str, indexx, l_pos[1], &nb_pos2);  
  
  if(nb_pos1==1 && nb_pos2 == 1) {
    printf("\n\n1 solution\n\n");
    gare[0]=l_pos[0][0];
    gare[1]=l_pos[1][0];
    param=(void *)gare;
    fenAfficheChemin(pWindow, NULL);
  }
  else {
    printf("\n\nn solutions\n\n");
    l_pos[2]=malloc(sizeof(int));
    l_pos[3]=malloc(sizeof(int));
    l_pos[2][0]=nb_pos1;
    l_pos[3][0]=nb_pos2;
    param=malloc(sizeof(void *));
    param=(void *)l_pos;
    fenListeGare(pWindow, NULL);
  }
}

La fonction correction ne fait pas d'allocation ou désallocation mémoire jusqu'a l'appel de la fonction Levenstein, qui elle, finit par planter la plupart du temps

int levenshtein(char* s1, char* s2) {
  int n1=strlen(s1); // longueur des mots
  int n2=strlen(s2);

  int ** matrix; // matrice de calcul
  int ret;

/****************c'est generalement ce malloc qui plante...***********/
  matrix=malloc((n1+1)*sizeof(int));
  printf("apres le mallco\n");
  int i;
  for(i=0;i<n1+1;i++) {
    matrix[i]=malloc((n2+2)*sizeof(int));
  }
  int j,cout;

  for (i=0 ; i<n1+1 ; i++){
    matrix[i][0] = i;
  }
  
  for (i=0 ; i<n2+1 ; i++){
    matrix[0][i] = i;
  }
  
  for (i=1 ; i<n1+1 ; i++){
    for (j=1 ; j<n2+1 ; j++){
      if ( s1[i-1]==s2[j-1] ){
	cout=0;
      }
      else {
	cout=1;
      }
      matrix[i][j]=
	min3(
	     matrix[i][j-1]+1,  /*Insertion*/ 
  	     matrix[i-1][j]+1,  /*Suppression*/
	     matrix[i-1][j-1]+cout  /*Substitution*/ 
	     );
    }
  }
  //affiche_matrice(matrix, n1+1, n2+1);
  ret=matrix[n1][n2];
  //  free(matrix);
  return matrix[n1][n2];
  
  //  return 0;
}

Voila en gros. Je ne sais pas vraiment ce dont vous pourriez avoir besoin... Je sais juste que la fonction correction a été développé indépendament, et fonctionne indépendament. C'est au moment ou je l'ai intégré dans la fonction corrige que ca à pété...

Merci à tous

zonyxt · Le 20/05/2008, à 23:16

matrix=malloc((n1+1)*sizeof(int));

Moi j'aurais plutôt mis un :

matrix=malloc((n1+1)*sizeof(int [b]*[/b]));

Car matrix est de type int**. Du coup tu alloues d'abord un tableau de pointeur vers des tableaux de int .

talrasha · Le 20/05/2008, à 23:45

Oui, en effet, je me suis aperçu de ça tout à l'heure... J'ai eu une lueur d'espoir, j'ai testé et... ça n'a rien changé -_-

Je déprime....

Marabout · Le 21/05/2008, à 01:05

Salut,

il faudrait un code compilable...

UgM · Le 21/05/2008, à 01:25

Peut être que tu veux garder secret son code (?).
C'est difficile de t'aider sans code qu'on pourras tester.
Sinon, utilise gdb. Met des break sur les fonctions que tu suspectes. Tu lances l'appli après pas à pas pour trouver quel ligne qui merde.

@+

PS : man gdb pour plus de détail.

abetsic · Le 21/05/2008, à 01:52

Compiles ton code avec l'option -g et lances ton programme avec la commande valgrind.

valgrind ton_executable

Il te donnera la ligne fautive du segfault.

Marabout · Le 21/05/2008, à 02:20

abetsic a écrit :

Compiles ton code avec l'option -g et lances ton programme avec la commande valgrind.
valgrind ton_executable
Il te donnera la ligne fautive du segfault.

La ligne où se produit le segfault n'est pas nécessairement celle qui en est responsable

talrasha · Le 21/05/2008, à 03:07

Salut,

En fait, la raison pour laquelle je ne donne pas tous le code est simple, il fait 3500 ligne . A la rigueur, pour celui qui serait vraiment motivé, il est integralement disponible sur : http://projetipi2008/doc/mise_en_commun

Si une telle personne existe, il peut aussi me contacter sur mon mail talrashha@free.fr ...

Je vais tester l'appli dont on vient de parler. Je ne la connais pas, mais avec des printf judicieusement placé, j'ai constaté que le plantage se produit soit sur des malloc, soit sur des fonctions gtk_widget_destroy() ou gtk_widget_show_all()...

talrasha · Le 21/05/2008, à 03:22

Euh, je viens de compiler avec l'option -g et executé en utilisant valgrind...

Etrangement, l'execution va plus loin dans le programme lorsque je lance avec valgrind, mais finit tout de même par planter...

Mais... que dois-je comprendre dans l'erreur suivante :

==7638== ERROR SUMMARY: 16374 errors from 120 contexts (suppressed: 113 from 1)
==7638== malloc/free: in use at exit: 3,887,037 bytes in 17,268 blocks.
==7638== malloc/free: 159,524 allocs, 142,256 frees, 49,762,136 bytes allocated.
==7638== For counts of detected errors, rerun with: -v
==7638== searching for pointers to 17,268 not-freed blocks.
==7638== checked 4,118,992 bytes.
==7638== 
==7638== LEAK SUMMARY:
==7638==    definitely lost: 76,002 bytes in 3,114 blocks.
==7638==      possibly lost: 117,980 bytes in 128 blocks.
==7638==    still reachable: 3,693,055 bytes in 14,026 blocks.
==7638==         suppressed: 0 bytes in 0 blocks.
==7638== Rerun with --leak-check=full to see details of leaked memory.
Erreur de segmentation

(peut être faut-il que je poste plus que ce morceau d'erreur? )

ogaby · Le 21/05/2008, à 10:45

Dans un projet qui utilise malloc, on doit avoir le même nombre d'appel de malloc() que de free().
Pour vérifier, tu peux faire un grep de ton projet:
find . -name "*.c" -follow | xargs grep malloc | wc- l
find . -name "*.c" -follow | xargs grep free | wc- l

Dans ta fonction levenshtein, il y a un malloc sur matrix mais il faut que dans une fonction de niveau supérieur un free sur matrix.
Dans ta fonction corrige, il y a 4 malloc mais aucun free.
Donc t'as des dépassements de mémoire:
==7638== definitely lost: 76,002 bytes in 3,114 blocks.

Dans ta fonction corrige, tu peux éviter des malloc -> changer int **l_pos en l_pos[4] et enlever le malloc

UgM · Le 21/05/2008, à 11:04

ogaby a écrit :

Dans un projet qui utilise malloc, on doit avoir le même nombre d'appel de malloc() que de free().
Pour vérifier, tu peux faire un grep de ton projet:
find . -name "*.c" -follow | xargs grep malloc | wc- l
find . -name "*.c" -follow | xargs grep free | wc- l
Dans ta fonction levenshtein, il y a un malloc sur matrix mais il faut que dans une fonction de niveau supérieur un free sur matrix.
Dans ta fonction corrige, il y a 4 malloc mais aucun free.
Donc t'as des dépassements de mémoire:
==7638== definitely lost: 76,002 bytes in 3,114 blocks.

Dans ta fonction corrige, tu peux éviter des malloc -> changer int **l_pos en l_pos[4] et enlever le malloc

Je ne suis pas trop d'accord car on peux avoir plus de free que de malloc (car le malloc a été fait dans une librairie par exemple la fonction g_strdup_printf que j'aime bien). Par contre, je ne pense pas qu'on peut avoir plus de malloc que de free.
En tout cas, intéressant tes commandes

@+

nicolas.sitbon · Le 21/05/2008, à 12:23

talrasha a écrit :

http://projetipi2008/doc/mise_en_commun

The requested URL could not be retrieved

Ultandir · Le 21/05/2008, à 13:44

Si tu est vraiment pret a faire le suicidaire : compile avec l'option -Wall de gcc.
Il va te mettre TOUS les warnings en plus ( pour les gens tatasse comme moi ^^ )

Dernière modification par Ultandir (Le 21/05/2008, à 13:44)

talrasha · Le 21/05/2008, à 14:13

Alors, 1 : correction de l'adresse que je vous ai donnée : http://projetipi2008.free.fr/doc/mise_en_commun/
Ensuite, je compile déjà avec le -Wall, rien n'est détécté à la compil.
Enfin, en effet il est clair que je n'ai aucun free dans tous le programme. Je vais les rajouter et voir ce que ca donne.

Merci

Dernière modification par talrasha (Le 21/05/2008, à 14:18)

nicolas.sitbon · Le 21/05/2008, à 14:46

Généralement, quand on fait un dépot sur un site comme ça, on ajoute un tar.gz (plus facile à télécharger) et un Makefile.

talrasha · Le 21/05/2008, à 15:42

Oui, je sais, mais bon, pour l'instant, c'est encore en développement, je ferai tout ca à la fin. Je me sert juste d'un petit script pour lancer la compil.

Quoi qu'il en soit, j'ai mis des free proprement partout ou je fait des malloc et... CA MARCHE

Je vous aime les gens

Ca fait 1 semaine que je debugge ca !

Voila, merci beaucoup

ogaby · Le 21/05/2008, à 17:50

UgM a écrit :

ogaby a écrit :
Dans un projet qui utilise malloc, on doit avoir le même nombre d'appel de malloc() que de free().
Pour vérifier, tu peux faire un grep de ton projet:
find . -name "*.c" -follow | xargs grep malloc | wc- l
find . -name "*.c" -follow | xargs grep free | wc- l
Dans ta fonction levenshtein, il y a un malloc sur matrix mais il faut que dans une fonction de niveau supérieur un free sur matrix.
Dans ta fonction corrige, il y a 4 malloc mais aucun free.
Donc t'as des dépassements de mémoire:
==7638== definitely lost: 76,002 bytes in 3,114 blocks.

Dans ta fonction corrige, tu peux éviter des malloc -> changer int **l_pos en l_pos[4] et enlever le malloc
Je ne suis pas trop d'accord car on peux avoir plus de free que de malloc (car le malloc a été fait dans une librairie par exemple la fonction g_strdup_printf que j'aime bien). Par contre, je ne pense pas qu'on peut avoir plus de malloc que de free.
En tout cas, intéressant tes commandes
@+

vi t'as raison. Si il y a plus de free que de malloc, ca fait juste du code en trop et peut-être quelques warnings.
Le contraire fait que le programme devient irrationnel: il a du caca en mémoire.

ogaby · Le 21/05/2008, à 17:54

talrasha a écrit :

Oui, je sais, mais bon, pour l'instant, c'est encore en développement, je ferai tout ca à la fin. Je me sert juste d'un petit script pour lancer la compil.
Quoi qu'il en soit, j'ai mis des free proprement partout ou je fait des malloc et... CA MARCHE
Je vous aime les gens
Ca fait 1 semaine que je debugge ca !
Voila, merci beaucoup

Encore un truc:
éviter au maximum le malloc. Un oubli de free, un free trop tot, une taille incorrecte dans malloc, etc... et ca devient vite problématique. L'emploi de tableau à taille fixe, si possible, est beaucoup mieux.

L'emploi du malloc est bien quand on travaille sur des données à taille variable. Donc malloc puis realloc... puis free

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 20/05/2008, à 02:29

[RÉSOLU] Plantage pas commun en C...

#2 Le 20/05/2008, à 02:43

Re : [RÉSOLU] Plantage pas commun en C...

#3 Le 20/05/2008, à 03:30

Re : [RÉSOLU] Plantage pas commun en C...

#4 Le 20/05/2008, à 08:06

Re : [RÉSOLU] Plantage pas commun en C...

#5 Le 20/05/2008, à 08:23

Re : [RÉSOLU] Plantage pas commun en C...

#6 Le 20/05/2008, à 12:24

Re : [RÉSOLU] Plantage pas commun en C...

#7 Le 20/05/2008, à 13:21

Re : [RÉSOLU] Plantage pas commun en C...

#8 Le 20/05/2008, à 14:31

Re : [RÉSOLU] Plantage pas commun en C...

#9 Le 20/05/2008, à 23:16

Re : [RÉSOLU] Plantage pas commun en C...

#10 Le 20/05/2008, à 23:45

Re : [RÉSOLU] Plantage pas commun en C...

#11 Le 21/05/2008, à 01:05

Re : [RÉSOLU] Plantage pas commun en C...

#12 Le 21/05/2008, à 01:25

Re : [RÉSOLU] Plantage pas commun en C...

#13 Le 21/05/2008, à 01:52

Re : [RÉSOLU] Plantage pas commun en C...

#14 Le 21/05/2008, à 02:20

Re : [RÉSOLU] Plantage pas commun en C...

#15 Le 21/05/2008, à 03:07

Re : [RÉSOLU] Plantage pas commun en C...

#16 Le 21/05/2008, à 03:22

Re : [RÉSOLU] Plantage pas commun en C...

#17 Le 21/05/2008, à 10:45

Re : [RÉSOLU] Plantage pas commun en C...

#18 Le 21/05/2008, à 11:04

Re : [RÉSOLU] Plantage pas commun en C...

#19 Le 21/05/2008, à 12:23

Re : [RÉSOLU] Plantage pas commun en C...

#20 Le 21/05/2008, à 13:44

Re : [RÉSOLU] Plantage pas commun en C...

#21 Le 21/05/2008, à 14:13

Re : [RÉSOLU] Plantage pas commun en C...

#22 Le 21/05/2008, à 14:46

Re : [RÉSOLU] Plantage pas commun en C...

#23 Le 21/05/2008, à 15:42

Re : [RÉSOLU] Plantage pas commun en C...

#24 Le 21/05/2008, à 17:50

Re : [RÉSOLU] Plantage pas commun en C...

#25 Le 21/05/2008, à 17:54

Re : [RÉSOLU] Plantage pas commun en C...

Pied de page des forums