Segfault étrange sur un malloc

**|PaRa-BoL** · 11/01/2007, 17h32

Bonjour,

Je developpe en ce moment un server de Tchat compatible avec AJAX, enfin bref

Le server étant fini et encore en beta je le laisse tourner et invite pas mal de monde à venir dessus.
Je laisse donc un "ulimit -c unlimited" en cas d'un eventuel segfault.
Après quelque jour sans problème le server a segfault.

Je lance le fichier core qui a été généré :

"gdb monprog -c core"

Je fait un backtrace (bt) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
 
(gdb) bt
#0  0xb7e8e060 in free () from /lib/tls/libc.so.6
#1  0xb7e8fc4f in malloc () from /lib/tls/libc.so.6
#2  0x0804afb2 in adduser (nick=0x807133e "yobakan", chan=0x8071346 "Ace", fdclient=4, ace_tables=0x804e008) at src/users.c:61
#3  0x0804ab16 in raw_connect (param=0xbf86af30, fdclient=4, call_user=0x0, ace_tables=0x804e008) at src/raw.c:154
#4  0x0804a8b4 in checkraw (cget=0x8070840, ace_tables=0x804e008) at src/raw.c:102
#5  0x0804a417 in checkrecv (pSock=0x8071330 "GET", fdclient=4, ip=0xb7df603c "127.0.0.1", ace_tables=0x804e008) at src/kernel.c:124
#6  0x08049a54 in sockroutine (port=6969, ace_tables=0x804e008) at src/sock.c:262
#7  0x08048d72 in main (argc=1, argv=0xbf8750c4) at src/main.c:131

Donc je me rend à la ligne 61 de users.c :

Code :

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

1
2
 
nuser = (USERS *)malloc(sizeof(*nuser));

Voici ma structure :

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
 
typedef struct USERS
{
	unsigned int fdclient;
	unsigned int state;
	unsigned int nraw;
 
	char nick[MAX_NICK_LEN+1];
	char sessid[33];
	char chan[33];
	char ip[32];
 
	long int idle;
 
	struct USERS *next;
	struct USERS *prev;
 
	struct RAW *rawhead;
	struct RAW *rawfoot;
} USERS;

Qu'est ce qui a pu provoquer un segfault ici ? Un overflow ailleur ?

Merci à vous

**ShootDX** · 11/01/2007, 17h57

Probablement plus de mémoire, ou quelque chose du genre (est-ce que tu as un moyen de voir l'utilisation mémoire de ton programme au fil du temps?). Tu dois revoir tes allocations et essayer de libérer la mémoire le plus tôt possible.

**|PaRa-BoL** · 11/01/2007, 18h04

Envoyé par ShootDX

Probablement plus de mémoire, ou quelque chose du genre (est-ce que tu as un moyen de voir l'utilisation mémoire de ton programme au fil du temps?). Tu dois revoir tes allocations et essayer de libérer la mémoire le plus tôt possible.

Oui j'ai bien regardé la mémoire, tout est libéré, mon programme ne depasse 0.4% de mémoire. (De plus quand il s'agit de mémoire pleine, malloc retourne NULL mais ne segfault pas ?)

Merci

**diogene** · 11/01/2007, 18h08

La connaissance de la ligne 61 est très insuffisante pour te donner un coup de main. Il faudrait quand même un peu plus de code car certainement le problème qui se révèle ici vient d'une erreur ailleurs.

**|PaRa-BoL** · 11/01/2007, 18h11

Envoyé par diogene

La connaissance de la ligne 61 est très insuffisante pour te donner un coup de main. Il faudrait quand même un peu plus de code car certainement le problème qui se révèle ici vient d'une erreur ailleurs.

gdb ne m'a donné que ca. Mon programme fait plusieur milliers de lignes et je n'ai pas réussi à reproduire le segfault :/

Je suppose que si il c'est produit une fois il risque de revenir le fourbe !

Mais la je vois que malloc a appelé free() (qui est celui qui a segfault), dans quel cas il fait ca ?

**Mat.M** · 11/01/2007, 18h13

c'est un peu incomplet ; tu obtients une fault segmentation parce que à un moment tu dois vouloir accéder à user->attribut et que user vaut 0x0000000 ( pointeur nul )
Qu'est ce qui se passe si les connections sont perdues ?

Si un user se déconnecte ?

Envoyé par |PaRa-BoL

gdb ne m'a donné que ca. Mon programme fait plusieur milliers de lignes et je n'ai pas réussi à reproduire le segfault :/

Y-a-til des listes chainées ?
Je suis persuadé que cela vient de pointeurs qui sont nuls et que tu essaies d'adresser.....

**|PaRa-BoL** · 11/01/2007, 18h18

Envoyé par Mat.M

c'est un peu incomplet ; tu obtients une fault segmentation parce que à un moment tu dois vouloir accéder à user->attribut et que user vaut 0x0000000 ( pointeur nul )
Qu'est ce qui se passe si les connections sont perdues ?

Si un user se déconnecte ?

Y-a-til des listes chainées ?
Je suis persuadé que cela vient de pointeurs qui sont nuls et que tu essaies d'adresser.....

Liste chainées, tables de hashages (une 10 aines ><), je teste à chaque fois les pointeurs NULL. Et des 100aines d'users se connects et se deconnects dans la journée. Je n'ai eu ce segfault que une seule fois.
Peut être ai-je fait une erreure d'innatention quelque part.
Mais pourquoi gdb m'indique t'il se malloc ?

Merci

**Mat.M** · 11/01/2007, 18h19

Envoyé par |PaRa-BoL

Oui j'ai bien regardé la mémoire, tout est libéré, mon programme ne depasse 0.4% de mémoire. (De plus quand il s'agit de mémoire pleine, malloc retourne NULL mais ne segfault pas ?)
Merci

malloc sans free ne provoque pas de fault segmentation.
Tu peux très bien déclarer un malloc faire une allocation finir le programme.
C'est intégre au niveau du code machine.
Par contre tu auras des fuites de mémoires....

**|PaRa-BoL** · 11/01/2007, 18h21

Envoyé par Mat.M

malloc sans free ne provoque pas de fault segmentation.
Tu peux très bien déclarer un malloc faire une allocation finir le programme.
C'est intégre au niveau du code machine.
Par contre tu auras des fuites de mémoires....

Je libère tout les malloc que j'utilise à un moment ou un autre :/

**gege2061** · 11/01/2007, 18h22

Envoyé par |PaRa-BoL

Mais la je vois que malloc a appelé free() (qui est celui qui a segfault), dans quel cas il fait ca ?

malloc qui appelle free, à part si la mémoire viens à manquer ça me parrait étrange (même dans ce cas là, comment il peux savoir quoi libérer

)

Donc si tu dis que tu ne déppasse pas les 0.4% d'utilisation (tu étais devant le moniteur système lors du segfault ?) ça viens surement d'une corruption de données. ça peux expliquer :

Le plantage de free
Le fait que malloc semble manquer de mémoire

Envoyé par =|PaRa-BoL

Liste chainées, tables de hashages (une 10 aines ><), je teste à chaque fois les pointeurs NULL. Et des 100aines d'users se connects et se deconnects dans la journée. Je n'ai eu ce segfault que une seule fois.
Peut être ai-je fait une erreure d'innatention quelque part.
Mais pourquoi gdb m'indique t'il se malloc ?

ça s'appel un comportement indéfini, ça porte bien son nom

**Mat.M** · 11/01/2007, 18h23

Mais pourquoi gdb m'indique t'il se malloc ?

Parce que malloc retourne un pointeur semblet-il invalide.
Alors tu n'as pas assez de mémoire dispo à allouer parce que peut-être des désallocations sont mal faites avec free ou bien alors le tas heap n'est pas assez grand.
Donc il faut utiliser les services de l'OS pour des grosses allocs mémoires.
Mais cela ressemble plutot à des pointeurs mal désalloués.
Refaire toute la logique du programme

**Mat.M** · 11/01/2007, 18h24

Envoyé par |PaRa-BoL

Je libère tout les malloc que j'utilise à un moment ou un autre :/

tu as l'impression au niveau du code mais qu'en est-il en réalité ??
Le programme est-il multi processus ?
Dans le cas contraire il faut que cela soit en multithreading sinon cela ne peut pas fonctionner correctement.
C'est peut-être un problème de synchros des processus.

**diogene** · 11/01/2007, 18h26

Une corruption antérieure du tas qui se manifesterait inopinément à cet instant ?

**|PaRa-BoL** · 11/01/2007, 18h29

Envoyé par Mat.M

tu as l'impression au niveau du code mais qu'en est-il en réalité ??
Le programme est-il multi processus ?
Dans le cas contraire il faut que cela soit en multithreading sinon cela ne peut pas fonctionner correctement.
C'est peut-être un problème de synchros des processus.

Non aucun thread ni fork :/

Je vais chercher ailleur. Encore merci

Donc si tu dis que tu ne déppasse pas les 0.4% d'utilisation (tu étais devant le moniteur système lors du segfault ?) ça viens surement d'une corruption de données. ça peux expliquer :

Mon programme n'allou de la mémoire que pour des petites structures, je vois mal remplir 2 giga en 2heures

Mais en effet je pancherai plutôt pour un problème dans le HEAP :/

Je vous colle quand même mes function de Connection/Deconnection (désolé pour la longueur)

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
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
90
91
92
93
94
95
96
97
98
99
100
101
102
 
USERS *adduser(char *nick, char *chan, unsigned int fdclient, acetables *ace_tables)
{
	USERS *nuser, *ghost;
	CHANNEL *channel;
	RAW *newraw;
 
	char fdstr[32];
 
	unsigned int owned = 0;
 
	nuser = (USERS *)malloc(sizeof(*nuser));
	memset(fdstr, '\0', 32);
	memset(nuser->ip, '\0', 32);
 
	nuser->fdclient = fdclient;
	nuser->state = ADIED;
	nuser->idle = time(NULL);
	nuser->next = ace_tables->uHead;
	nuser->prev = NULL;
	nuser->nraw = 0;
 
	nuser->rawhead = NULL;
	nuser->rawfoot = NULL;
 
	if (nuser->next != NULL) {
		nuser->next->prev = nuser;
	}
	memcpy(nuser->nick, nick, strlen(nick)+1);
	memcpy(nuser->chan, chan, strlen(chan)+1);
 
	gen_sessid_new(nuser->sessid, ace_tables);
 
	ace_tables->uHead = nuser;
 
	sprintf(fdstr, "%i", fdclient);
 
	if (!hashtbl_seek(ace_tables->hLusers, chan)) {
		channel = mkchan(chan, ace_tables);
		owned = 1;
	} else {
		channel = (CHANNEL *)hashtbl_seek(ace_tables->hLusers, chan);
	}
 
	if ((ghost = hashtbl_seek(ace_tables->hFdclient, fdstr)) != NULL) {
		ghost->state = ADIED;
		hashtbl_erase(ace_tables->hFdclient, fdstr);
	}
 
	//printf("users : %s\n", getlist(chan, ace_tables)->userinfo->nick);
	hashtbl_append(ace_tables->hLogin, nick, (void *)nuser);
	hashtbl_append(ace_tables->hSessid, nuser->sessid, (void *)nuser);
	hashtbl_append(ace_tables->hFdclient, fdstr, (void *)nuser);
 
	newraw = forge_raw(RAW_LOGIN, 0, nuser->sessid);
	post_raw(newraw, nuser);
 
	join(nuser, channel, ace_tables);
 
	if (owned == 1) {
		setlevel(NULL, nuser, channel, 3);
	}
	return nuser;
 
}
 
void deluser(USERS *user, acetables *ace_tables)
{
 
	char fdstr[32];
 
	if (user == NULL) {
		return;
	}
	memset(fdstr, '\0', 32);
 
	sprintf(fdstr, "%i", user->fdclient);
	do_died(user);
 
	left(user, ace_tables);
	clear_raws(user);
 
	hashtbl_erase_special(ace_tables->hLogin, user->nick, user->chan); // a faire le special !!!
	hashtbl_erase(ace_tables->hSessid, user->sessid);
 
	if (((USERS *)hashtbl_seek(ace_tables->hFdclient, fdstr)) == user) {
		hashtbl_erase(ace_tables->hFdclient, fdstr);		
	}
 
 
	if (user->prev == NULL) { // faire pareil pour les channels
		ace_tables->uHead = user->next;
	} else {
		user->prev->next = user->next;
	}
	if (user->next != NULL) {
		user->next->prev = user->prev;
	}
	free(user);
	user = NULL;
 
}

Merci de votre aide

**Mat.M** · 11/01/2007, 18h35

Envoyé par |PaRa-BoL

Non aucun thread ni fork :/

sans threads cela ne fonctionnera jamais correctement !
Tu peux prendre la biblio P-Thread.
Je regarderais ton code.
Et les memcpy ils fonctionnent bien ?

Tu ne m'as pas répondu : et si un user se déconnecte intempestivement à cause du réseau ( donc un *user qui pointe dans le vide ) ?
Gestion des erreurs ?

**|PaRa-BoL** · 11/01/2007, 18h38

Envoyé par Mat.M

sans threads cela ne fonctionnera jamais correctement !
Tu peux prendre la biblio P-Thread.
Je regarderais ton code.
Et les memcpy ils fonctionnent bien ?

Qu'est ce qui ne fonctionnerai jamais correctement ?
Je n'utilise pas de thread car je n'en ai pas l'utilité.

Oui les memcpy fonctionnent correctement (je suis entrain de regarder si j'ai pas un byte qui met son nez où il faut pas)

Pour le code voici l'url : http://ace.lya.eu/ACE-uChat_beta20.tar.gz et pour venir tester le tchat : http://ace.lya.eu/

Tu ne m'as pas répondu : et si un user se déconnecte intempestivement ( donc un *user qui pointe dans le vide ) ?
Gestion des erreurs ?

Si un utilisateur est deconnecté, je libère sa structure et je l'enleve de la table de hashable + liste chainé. Donc il n'y a plus aucun référence à cette structure nul part.

Merci de ton aide

**JeitEmgie** · 11/01/2007, 18h41

Envoyé par Mat.M

c'est un peu incomplet ; tu obtients une fault segmentation parce que à un moment tu dois vouloir accéder à user->attribut et que user vaut 0x0000000 ( pointeur nul )
Qu'est ce qui se passe si les connections sont perdues ?

Si un user se déconnecte ?

Y-a-til des listes chainées ?
Je suis persuadé que cela vient de pointeurs qui sont nuls et que tu essaies d'adresser.....

si le plantage venait du déréférencement d'un pointeur NULL, il aurait lieu plus près de l'instruction en cause, alors qu'ici il a lieu à l'intérieur de la librairie malloc… (quoique le free(NULL) peut provoquer ce genre de choses …)

autres possibilités :
ou des écritures au-delà de la taille d'un bloc alloué qui corrompent le heap
ou des écritures dans un bloc après qu'il ait été libéré par free()…
ou un double free()…
ou …
les manières de corrompre la mémoire sont infinies…

quant un plantage "dans" free()… : ne pas oublier que gdb rapporte le symbole de la fonction la plus proche en fonction du PC et de la table des symboles… il est plus probable qu'en fait vous êtes dans du code de bas niveau optimisé en assembleur qui se trouve aux alentours de free()… ce qui laisse penser que ce qui se plante est en fait le "crawling" dans la chaîne des blocs libres…

si malloc_debug() est disponible dans votre environnement, activez-le ou si une version debug de libc est disponible, liez votre programme à cette version et activez les checks du heap…
(attention cela va ralentir le programme…)

**|PaRa-BoL** · 11/01/2007, 18h46

Je pour toujours essayer de compiler avec ElectricFence (qui substitue tout les malloc) mais faudrai t-il déjà que j'arrive à reproduire se $$?!! de segfault

**JeitEmgie** · 11/01/2007, 19h00

Envoyé par |PaRa-BoL

Je pour toujours essayer de compiler avec ElectricFence (qui substitue tout les malloc) mais faudrai t-il déjà que j'arrive à reproduire se $$?!! de segfault

l'intérêt premier des versions debug des librairies "malloc" est en général de provoquer le plantage plus vite et donc plus près du code à problème…

**|PaRa-BoL** · 11/01/2007, 19h04

Envoyé par JeitEmgie

l'intérêt premier des versions debug des librairies "malloc" est en général de provoquer le plantage plus vite et donc plus près du code à problème…

Merci pour le "tuyo", je vien de compiler avec eletric-fenze et j'ai déjà un segfault (sur une function que je n'apel pas, enfin du moins pas au moment ou sa segfault)

Segfault étrange sur un malloc

C

Discussions similaires

Partager

Partager