Erreur de segmentation sur malloc

Version imprimable

Bonjour,

Dans un programme C compilé et lancé sur du Linux je me retrouve avec une erreur de segmentation pendant l’exécution :

Avec des messages de log, j'ai identifié la ligne en cause

Citation:

Envoyé par Trace console

TRACE : 506 ...181746
TRACE debug_pko : start malloc ...
TRACE debug_pko : end malloc ...
TRACE debug_pko : end add tab ...
TRACE debug_pko : start malloc ...
TRACE debug_pko : end malloc ...
TRACE debug_pko : end add tab ...
TRACE debug_pko : start malloc ...
TRACE debug_pko : end malloc ...
TRACE debug_pko : end add tab ...
TRACE debug_pko : start malloc ...
TRACE debug_pko : end malloc ...
TRACE debug_pko : end add tab ...
TRACE debug_pko : start malloc ...
TRACE debug_pko : end malloc ...
TRACE debug_pko : end add tab ...
TRACE debug_pko : start malloc ...

Voici le code correspondant
Code:

1 2 3 4 5 6 fprintf(stderr,"TRACE debug_pko : start malloc ...\n"); pRejet = malloc(sizeof(struct TABNOETTTAS)); fprintf(stderr,"TRACE debug_pko : end malloc ...\n"); C_XLI_AddToTab_BC(pXliRej,(void *)pRejet); fprintf(stderr,"TRACE debug_pko : end add tab ...\n"); iCptInit++;
Je sais que ce malloc est utilisé environ 181746 * 10 fois avant de planter. Le moment du plantage étant fixe dans l'exécution.

La structure TABNOETTTAS contient deux tableaux de char d'une taille cumulé de 91 char.

Après diverses recherches, j'ai réalisé des vmstat, pendant le traitement pour me rendre compte que l'espace mémoire libre de la machine devient dangereusement bas juste avant de planté.

Citation:

Envoyé par Juste avant le plantage

kthr memory page faults cpu
----- ----------- ------------------------ ------------ -----------------------
r b avm fre re pi po fr sr cy in sy cs us sy id wa pc ec
2 2 2660588 2730 0 0 0 704 3052 0 238 2669046 6233 17 10 72 1 0.34 33.8
frtlr205.soltim@(7.5.1.00_ABO): /disk4/avtxl/7.5.1.00_ABO/srcbcx/devbatchs/bcx/prjbcx/bcxas202/libprv> vms

Citation:

Envoyé par Juste après le plantage

kthr memory page faults cpu
----- ----------- ------------------------ ------------ -----------------------
r b avm fre re pi po fr sr cy in sy cs us sy id wa pc ec
2 2 2592307 71527 0 0 0 704 3052 0 238 2669048 6233 17 10 72 1 0.34 33.8

Une personne peut-il me confirmer que le malloc sort une erreur de segmentation sur un problème de mémoire disponible ? Histoire que je sois sûr de mon diagnostic, à savoir que l'application en question n'a pas assez d'espace mémoire par rapport à ce qu'elle veux faire. Donc deux solutions :
1. Avoir plus de mémoire disponible pour le programme.
2. Revoir l'application pour utiliser moins de mémoire.

Cordialement,
Patrick Kolodziejczyk.

25/03/2015, 12h16
ternel

En fait, il n'y a pas d'erreur de segmentation dans malloc, mais dans C_XLI_AddToTab_BC(pXliRej,(void *)pRejet);.
En effet, malloc peut retourner NULL s'il n'a plus de mémoire.

La raison pour laquelle tu ne vois pas le message end malloc, c'est parce qu'il y a un buffer dans fprintf, et qu'il faudrait utiliser fflush(stderr).

D'un autre coté, quelle idée de stocker 1,8 millions de paires de chaines de caractères
Ne pourrais-pas tu les traiter par lot (une dizaine, une centaine)?

Tu veux vraiment calculer une formule contenant 3,6 millions de chaines de caractères?
25/03/2015, 13h32
kolodz

Merci pour le retour ! Je me note le fflush(stderr); , cela me sera très probablement utile un jour.

Citation:

Envoyé par leternel

D'un autre coté, quelle idée de stocker 1,8 millions de paires de chaines de caractères
Ne pourrais-pas tu les traiter par lot (une dizaine, une centaine)?

Tu veux vraiment calculer une formule contenant 3,6 millions de chaines de caractères?

La problématique se trouve sur un batch relativement complexe et ancien (>15 ans), dont je n'ai aucune connaissance métier pour le moment. Et l'ensemble du traitement est basé sur ce stockage. Ce qui implique de tout revoir. Sachant que la problématique se pose seulement quand ce traitement attaque des fichiers particulièrement grand (>200 Mo). Il est plus simple de découper ce fichier, ou obtenir plus de mémoire sur la machine, que de revoir le traitement.

Pour moi, il faudrait revoir ce batch et faire un traitement à la volé et stocker le stricte minimum en mémoire, mais les 4000 lignes du traitements me font penser que cela n'est pas prudent. En particulier, pour un plantage que survient une fois tout les 10 ans !

Cordialement,
Patrick Kolodziejczyk.
25/03/2015, 13h51
ternel

D'un autre coté, faire tomber la machine à genou à chaque exécution, ca ralenti la machine.
Et ce genre de batch n'a jamais intérêt à être lent.

fflush purge le tampon d'un flux de sortie, c'est utile par moment, mais mal utilisé, ca détruira les performances.

Bon courage.
26/03/2015, 09h06
gangsoleil
Bonjour,

En général, un code qui utilise correctement une allocation dynamique ressemble à ça :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 var = malloc (taille); if (var == NULL) { /* traitement de l'erreur */ } else { /* traitement normal */ } return ...
Bien sur, dans certains cas, l'échec d'une allocation n'empêche pas l'exécution, et dans ce cas on passe toujours dans le traitement normal, mais il faut s'assurer que les sous-fonctions sont codées en conséquences.