Je ne trouve pas ça bizarre, au contraire. Qu'un fichier occupe beaucoup moins de place sur le disque que n'en affiche la commande ls, c'est normal : c'est le principe des fichiers à trous. L'inverse est possible aussi : une utilisation du disque plus élevée que la somme de toutes les tailles affichées : données fragmentées, beaucoup de fichiers de petites tailles, etc.
Mais le problème ici est plus étrange : "du" compabilise les blocs utilisés et vérifie l'unicité des inodes dans le total (liens physiques), le total devrait dans une certaine mesure correspondre avec la sortie de df. Genre chez moi :
# du /home -s
8,4G .
# df /home
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/hda7 24G 8,4G 16G 36% /home
La seule fois où j'ai eu une différence c'est avec une partition ext2 qui n'avait pas été fscheckée suite à plusieurs crash d'affilés.
24 threads au démarrage, tu n'as peur de rien toi ;-) Ton problème est trivial, et n'a rien à voir avec un problème de threads en fait.
Le problème se situe dans la fonction ServerAlloc() : tu analyses ton fichier de configuration (mm.conf) qui positionne iPluginCount et iSocketCount puis quelques lignes après (toujours dans ServerAlloc) tu remets ces 2 variables à 0.
J'ai essayé de remonter l'affectation des variables, mais ça segfault.
PS: gdb est ton ami dans ces cas là (et un bon stock d'aspirine aussi).
> Dans mon thread serveur
Déjà la programmation multi-threadée, ce n'est pas marrant à débugger lorsqu'on a les sources, alors quand on ne les a pas, difficile de dire ce qui ne va pas.
A priori, vérifie encore l'adresse de "this" dans les deux modules. Ils ne devraient pas différer, mais puisque tu obtiens deux valeurs différentes, ce me semble être la seule explication possible. Et le seul cas où ça peut arriver, c'est lorsqu'on utilise des processus et non des threads.
[^] # Re: Dans le même genre
Posté par pierthi . En réponse au message du / df, qui a raison ?. Évalué à 2.
Mais le problème ici est plus étrange : "du" compabilise les blocs utilisés et vérifie l'unicité des inodes dans le total (liens physiques), le total devrait dans une certaine mesure correspondre avec la sortie de df. Genre chez moi :
# du /home -s
8,4G .
# df /home
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/hda7 24G 8,4G 16G 36% /home
La seule fois où j'ai eu une différence c'est avec une partition ext2 qui n'avait pas été fscheckée suite à plusieurs crash d'affilés.
[^] # Mouais ...
Posté par pierthi . En réponse au message Le mystère du pointeur global. Évalué à 3.
Le problème se situe dans la fonction ServerAlloc() : tu analyses ton fichier de configuration (mm.conf) qui positionne iPluginCount et iSocketCount puis quelques lignes après (toujours dans ServerAlloc) tu remets ces 2 variables à 0.
J'ai essayé de remonter l'affectation des variables, mais ça segfault.
PS: gdb est ton ami dans ces cas là (et un bon stock d'aspirine aussi).
# Thread ou processus ?
Posté par pierthi . En réponse au message Le mystère du pointeur global. Évalué à 2.
Déjà la programmation multi-threadée, ce n'est pas marrant à débugger lorsqu'on a les sources, alors quand on ne les a pas, difficile de dire ce qui ne va pas.
A priori, vérifie encore l'adresse de "this" dans les deux modules. Ils ne devraient pas différer, mais puisque tu obtiens deux valeurs différentes, ce me semble être la seule explication possible. Et le seul cas où ça peut arriver, c'est lorsqu'on utilise des processus et non des threads.
Tu n'aurais pas un lien sur tes sources ?