.\" -*- coding: UTF-8 -*- .\" Copyright (c) 2006, 2008 by Michael Kerrisk .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH core 5 "3 mai 2023" "Pages du manuel de Linux 6.05.01" .SH NOM core — Fichier image de la mémoire .SH DESCRIPTION L'action par défaut de certains signaux consiste à faire se terminer un processus et à produire un \fIfichier image de la mémoire\fP («\ core dump file\ »). C'est un fichier qui contient l'image mémoire du processus au moment où il s'est terminé. Cette image peut être utilisée dans un débogueur (par exemple, \fBgdb\fP(1)) pour étudier l'état du programme au moment où il s'est terminé. Une liste des signaux provoquant la création de cette image mémoire se trouve dans \fBsignal\fP(7). .PP Un processus peut définir sa propre limite de ressource souple \fBRLIMIT_CORE\fP afin de définir une limite supérieure à la taille du fichier image de la mémoire qui sera créé s'il reçoit un signal «\ core dump\ »\ ; consultez \fBgetrlimit\fP(2) pour davantage d'informations. .PP Il y a diverses circonstances dans lesquelles un fichier image de la mémoire («\ core dump\ ») n'est pas produit\ : .IP \- 3 Le processus ne possède pas les droits pour écrire le fichier image de la mémoire (par défaut, le fichier image de la mémoire s'appelle \fIcore\fP ou \fIcore.pid\fP, où \fIpid\fP est l'identifiant du processus qui a généré une image de la mémoire. Il est créé dans le répertoire de travail en cours. Voir ci\-dessous pour davantage d'informations sur les règles de nommage). L'écriture du fichier image de la mémoire échouera si le répertoire dans lequel il devrait être écrit n'est pas accessible en écriture ou si un fichier avec le même nom existe et n'est pas accessible en écriture ou n'est pas un fichier ordinaire (par exemple, si c'est un répertoire ou un lien symbolique). .IP \- Un fichier (ordinaire et accessible en écriture) avec le même nom que celui qui serait utilisé pour l'image de la mémoire existe déjà, mais il y a plusieurs liens physiques vers ce fichier. .IP \- Le système de fichiers dans lequel serait écrit le fichier image de la mémoire est plein, il n'a plus d'inœud, il est monté en lecture seule ou l'utilisateur a atteint son quota pour le système de fichiers. .IP \- Le répertoire dans lequel le fichier image de la mémoire doit être créé n'existe pas. .IP \- Les limites de ressources \fBRLIMIT_CORE\fP (taille des fichiers «\ core\ ») ou \fBRLIMIT_FSIZE\fP (taille des fichiers) pour un processus sont définies à zéro\ ; consultez \fBgetrlimit\fP(2) et la documentation de la commande \fIulimit\fP de l'interpréteur de commande (\fIlimit\fP dans \fBcsh\fP(1)). \fBRLIMIT_CORE\fP sera cependant ignorée si le système est configuré pour tuber les vidages mémoire vers un programme. .IP \- Le binaire actuellement exécuté par le processus n'est pas accessible en lecture. Il s'agit d'une mesure de sécurité pour s'assurer qu'un exécutable dont le contenu n'est pas accessible en lecture ne produira pas de vidage mémoire \[em]\ éventuellement lisible\ \[em] contenant une image de l'exécutable. .IP \- .\" FIXME . Perhaps relocate discussion of /proc/sys/fs/suid_dumpable .\" and PR_SET_DUMPABLE to this page? Le processus exécute un programme set\-user\-ID (ou set\-group\-ID) dont le propriétaire (ou le groupe) est différent de l'identifiant d'utilisateur (ou de groupe) réel du processus, ou le processus exécute un programme qui possède des capacités de fichier (voir \fBcapabilities\fP(7)). Consultez cependant la description de l'opération \fBPR_SET_DUMPABLE\fP de \fBprctl\fP(2), et la description du fichier \fI/proc/sys/fs/suid_dumpable\fP dans \fBproc\fP(5). .IP \- \fI/proc/sys/kernel/core_pattern\fP est vide et \fI/proc/sys/kernel/core_uses_pid\fP contient la valeur\ \fB0\fP (ces fichiers sont décrits plus loin). Notez que si \fI/proc/sys/kernel/core_pattern\fP est vide et si \fI/proc/sys/kernel/core_uses_pid\fP contient la valeur\ \fB1\fP, les fichiers image de la mémoire posséderont des noms de la forme \fI.pid\fP, et que ces fichiers sont cachés, à moins d'utiliser l'option \fI\-a\fP de \fBls\fP(1). .IP \- .\" commit 046d662f481830e652ac34cd112249adde16452a (Depuis Linux\ 3.7) Le noyau a été compilé sans l'option \fBCONFIG_COREDUMP\fP. .PP De plus, le vidage mémoire peut exclure des portions de l'espace d'adressage du processus si l'attribut \fBMADV_DONTDUMP\fP de \fBmadvise\fP(2) est utilisé. .PP .\" Sur les systèmes qui utilisent \fBsystemd\fP(1) comme cadriciel pour \fIinit\fP, les vidages mémoire peuvent être écrits à un emplacement déterminé par \fBsystemd\fP(1). Voir plus loin pour plus de détails. .SS "Nommage des fichiers image de la mémoire" Par défaut, un fichier image de la mémoire s'appelle \fIcore\fP, mais le fichier \fI/proc/sys/kernel/core_pattern\fP (depuis Linux\ 2.6 et 2.4.21) peut être configuré de manière à définir un motif qui sera utilisé pour le nommage des fichiers image de la mémoire. Le motif peut contenir des spécificateurs % qui sont remplacés par les valeurs suivantes lorsqu'une image de la mémoire est créée\ : .PP .RS 4 .PD 0 .TP 4 %% Caractère % unique .TP %c Limite de ressource souple de la taille du fichier image de la mémoire créé lors du plantage d'un processus (depuis Linux\ 2.6.24). .TP %d .\" Added in git commit 12a2b4b2241e318b4f6df31228e4272d2c2968a1 Mode vidage («\ dump mode\ ») \(em\ identique à la valeur renvoyée par \fBPR_GET_DUMPABLE\fP de \fBprctl\fP(2) (depuis Linux\ 3.7). .TP %e La valeur de \fIcomm\fP du processus ou du thread, qui correspond en général au nom de l'exécutable (sans le chemin et tronqué à un maximum de 15\ caractères), mais qui peut avoir été modifiée en quelque chose de différent\ ; voir les explications à propos de \fI/proc/\fPpid\fI/comm\fP et \fI/proc/\fPpid\fI/task/\fPtid\fI/comm\fP dans \fBproc\fP(5). .TP %E Chemin d'accès de l'exécutable, où les barres obliques «\ /\ » sont remplacées par des points d'exclamation «\ !\ » (depuis Linux\ 3.0). .TP %g GID numérique réel du processus dont l'image mémoire a été vidée. .TP %h Nom d'hôte (identique à \fInodename\fP renvoyé par \fBuname\fP(2)). .TP %i .\" commit b03023ecbdb76c1dec86b41ed80b123c22783220 TID du thread qui a déclenché le vidage mémoire, tel qu'il est vu dans l'espace de noms du PID dans lequel le thread se trouve (depuis Linux\ 3.18). .TP %I .\" commit b03023ecbdb76c1dec86b41ed80b123c22783220 TID du thread qui a déclenché le vidage mémoire, tel qu'il est vu dans l'espace de noms du PID initial (depuis Linux\ 3.18). .TP %p PID du processus dont l'image mémoire a été vidée, tel qu'il est vu dans l'espace de noms du PID dans lequel le processus se trouve. .TP %P .\" Added in git commit 65aafb1e7484b7434a0c1d4c593191ebe5776a2f PID du processus dont l'image mémoire a été vidée, tel qu'il est vu dans l'espace des noms du PID initial (depuis Linux\ 3.12). .TP %s Numéro du signal ayant provoqué le vidage mémoire .TP %t Heure du vidage mémoire exprimée en secondes depuis l'Époque, 1er\ janvier 1970 à 00:00:00 +0000 (UTC). .TP %u UID numérique réel du processus «\ vidé\ ». .PD .RE .PP Un % isolé à la fin du motif est éliminé du nom de fichier de l'image mémoire, et il en sera de même pour un % suivi d'un caractère autre que ceux de la liste ci\-dessus. Tous les autres caractères du motif conservent leur valeur littérale dans le nom de fichier de l'image mémoire. Un motif peut contenir des caractères «\ /\ », ils sont interprétés comme des délimiteurs pour les noms de répertoire. La taille maximale du nom de fichier de l'image mémoire résultant est de 128 octets (64\ octets avant Linux\ 2.6.19). La valeur par défaut de ce nom de fichier est «\ core\ ». Afin d'assurer une rétrocompatibilité, si \fI/proc/sys/kernel/core_pattern\fP ne contient pas «\ %p\ » et si \fI/proc/sys/kernel/core_uses_pid\fP (voir ci\-dessous) est différent de zéro, «\ .PID\ » est ajouté au nom de fichier de l'image mémoire. .PP Les chemins sont interprétés en tenant compte des paramètres actifs pour le processus qui a planté. Ces paramètres comprennent l'espace de noms montage du processus qui a planté (voir \fBmount_namespaces\fP(7)), son répertoire de travail actuel (déterminé à l'aide de \fBgetcwd\fP(2)) et son répertoire racine (voir \fBchroot\fP(2)). .PP Depuis Linux\ 2.4, Linux procure aussi une méthode plus primitive pour contrôler le nom du fichier image de la mémoire. Si le fichier \fI/proc/sys/kernel/core_uses_pid\fP contient la valeur\ 0, le fichier image de la mémoire est tout simplement appelé \fIcore\fP. Si ce fichier contient une valeur différente de zéro, le fichier image de la mémoire intégrera dans son nom le numéro d'identification du processus sous la forme \fIcore.PID\fP. .PP .\" 9520628e8ceb69fa9a4aee6b57f22675d9e1b709 À partir de Linux\ 3.6, si \fI/proc/sys/fs/suid_dumpable\fP a pour valeur\ 2 («\ suidsafe\ »), le motif doit être soit un chemin absolu (commençant par le caractère «\ /\ », soit un tube, comme indiqué plus bas. .SS "Tuber les vidages mémoire vers un programme" Depuis le noyau\ 2.6.19, Linux prend en charge une syntaxe alternative pour le fichier \fI/proc/sys/kernel/core_pattern\fP. Si le premier caractère de ce fichier est le symbole du tube (\fB|\fP), le reste de la ligne est interprété comme une ligne de commande pour un programme de l'espace utilisateur (ou un script) à exécuter. .PP .\" commit 315c69261dd3fa12dbc830d4fa00d1fad98d3b03 Depuis Linux\ 5.3.0, le modèle de tube est divisé en tenant compte des espaces en une liste d'arguments \fIavant\fP l'interprétation des paramètres du modèle. Avec les noyaux plus anciens, les paramètres du modèle sont interprétés en premier et la chaîne résultante est divisée en tenant compte des espaces en une liste d'arguments. Cela signifie qu'avec les noyaux plus anciens, les noms d'exécutable ajoutés par les paramètres de modèle \fI%e\fP et \fI%E\fP pouvaient être divisés en plusieurs arguments. Le gestionnaire de vidage mémoire doit donc définir le dernier argument avec les noms d'exécutable et s'assurer de «\ recoller\ » toutes les parties du nom de l'exécutable en tenant compte des espaces. Les noms d'exécutable qui contiennent plusieurs espaces ne sont pas correctement représentés dans les noyaux plus anciens, et dans ce cas, le gestionnaire de vidage mémoire devra utiliser des mécanismes permettant de déterminer le nom de l'exécutable. .PP Au lieu d'être écrit dans un fichier, le vidage mémoire est envoyé sur l'entrée standard du programme. Notez les points suivants\ : .IP \- 3 Le programme doit être indiqué avec un chemin d'accès absolu (ou un chemin relatif par rapport au répertoire racine, \fI/\fP) et doit immédiatement suivre le caractère «\ |\ ». .IP \- Les arguments de la ligne de commande peuvent inclure tout spécificateur % indiqué plus haut. Par exemple, pour transmettre le PID du processus vidé, indiquez \fI%p\fP dans un argument. .IP \- Le processus créé pour exécuter le programme s'exécute avec les utilisateur et groupe \fIroot\fP. .IP \- L'exécution en tant que \fIroot\fP ne permet pas de contournement de sécurité exceptionnel. À ce titre, les LSM (comme SELinux) sont toujours actifs et peuvent empêcher le gestionnaire d'accéder aux détails du processus ayant planté à l'aide de \fI/proc/\fPpid. .IP \- Le nom de chemin du programme est interprété en respectant l'espace de noms montage initial, car il est toujours exécuté dans ce contexte. Il n'est pas affecté par les paramètres du processus ayant planté (par exemple le répertoire racine, l'espace de noms montage et le répertoire de travail actuel). .IP \- Le processus s'exécute dans les espaces de noms initiaux (PID, montage, utilisateur, etc.) et non dans les espaces de noms du processus ayant planté. On peut utiliser des spécificateurs comme \fI%P\fP pour trouver le répertoire \fI/proc/\fPpid correct et sonder/entrer les espaces de noms du processus ayant planté si nécessaire. .IP \- Le processus démarre avec son répertoire de travail courant comme répertoire racine. Il est cependant possible de passer au répertoire de travail du processus de vidage en utilisant la valeur fournie par le spécificateur \fI%P\fP pour passer à l'emplacement du processus de vidage à l'aide de \fI/proc/\fPpid\fI/cwd\fP. .IP \- Depuis Linux\ 2.6.24, il est possible de fournir au programme des arguments séparés par des espaces dans la ligne de commande (jusqu'à une longueur de ligne de 128\ octets). .IP \- .\" La limite \fBRLIMIT_CORE\fP ne s'applique pas aux vidages mémoire tubés vers un programme à l'aide de ce mécanisme. .SS /proc/sys/kernel/core_pipe_limit Lorsqu'on collecte des vidages mémoire à l'aide d'un tube vers un programme de l'espace utilisateur, il peut s'avérer utile pour le programme collecteur d'extraire les données à propos du processus ayant planté depuis le répertoire \fI/proc/\fPpid de ce dernier. Pour ce faire en toute sécurité, le noyau doit attendre que le programme collecteur de vidage mémoire se termine, de façon à ne pas supprimer prématurément les fichiers contenus dans le répertoire \fI/proc/\fPpid du processus ayant planté, ce qui a pour inconvénient de donner la possibilité à un programme de collecte défectueux de bloquer le vidage d’un processus planté en ne se terminant jamais. .PP .\" commit a293980c2e261bd5b0d2a77340dd04f684caff58 Depuis Linux\ 2.6.32, on peut utiliser \fI/proc/sys/kernel/core_pipe_limit\fP pour limiter cette possibilité. La valeur contenue dans ce fichier définit le nombre de processus plantés simultanés qui peuvent être tubés en parallèle vers des programmes de l'espace utilisateur. Si cette valeur est dépassée, les processus plantés concernés seront consignés dans le journal du noyau et leurs vidages mémoires omis. .PP .\" Une valeur de \fB0\fP dans ce fichier a une signification particulière. Elle indique qu'il n'y a pas de limite au nombre de processus qui peuvent être interceptés en parallèle, mais qu'aucune attente ne sera observée (autrement dit, le programme collecteur n'a aucune garantie d'accéder à \fI/proc/\fP). Par défaut, ce fichier contient la valeur \fB0\fP. .SS "Contrôler quelles projections seront écrites dans le vidage mémoire" Depuis Linux\ 2.6.23, le fichier \fI/proc/\fPpid\fI/coredump_filter\fP spécifique à Linux permet de contrôler quels segments de mémoire seront écrits dans le fichier image de la mémoire si un vidage mémoire est effectué pour le processus avec le PID correspondant. .PP La valeur dans ce fichier est un masque de bits des types de projection mémoire (consultez \fBmmap\fP(2)). Si un bit est positionné dans le masque, les projections mémoire du type correspondant sont vidées\ ; dans le cas contraire, elles ne le sont pas. Les bits dans ce fichier ont la signification suivante\ : .PP .PD 0 .RS 4 .TP bit 0 Vider les projections privées anonymes. .TP bit 1 Vider les projections partagées anonymes. .TP bit 2 Vider les projections privées sauvegardées sur fichier. .TP bit 3 .\" file-backed shared mappings of course also update the underlying .\" mapped file. Vider les projections partagées sauvegardées sur fichier. .TP bit 4 (depuis Linux\ 2.6.24) Vider les en\-têtes ELF. .TP bit 5 (depuis Linux\ 2.6.28) Vider les pages privées volumineuses. .TP bit 6 (depuis Linux\ 2.6.28) Vider les pages partagées volumineuses. .TP bit 7 (depuis Linux\ 4.4) .\" commit ab27a8d04b32b6ee8c30c14c4afd1058e8addc82 Vider les pages DAX privées. .TP bit 8 (depuis Linux\ 4.4) .\" commit ab27a8d04b32b6ee8c30c14c4afd1058e8addc82 Vider les pages DAX partagées. .RE .PD .PP Par défaut, les bits suivants sont positionnés\ : 0, 1, 4 (si l'option de configuration du noyau \fICONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS\fP est activée) et 5. L'option d'amorçage \fIcoredump_filter\fP permet de modifier ce réglage par défaut. .PP La valeur dans ce fichier est enregistrée en hexadécimal (la valeur par défaut est donc\ \fB33\fP). .PP Les pages d'entrées\-sorties projetées en mémoire telles que les tampons de trame ne sont jamais vidées, et les pages DSO virtuelles (\fBvdso\fP(7)) le sont toujours, quelle que soit la valeur de \fIcoredump_filter\fP. .PP Un processus enfant créé avec \fBfork\fP(2) hérite de la valeur de \fIcoredump_filter\fP de son parent\ ; la valeur de \fIcoredump_filter\fP est préservée au travers d'un \fBexecve\fP(2). .PP Il peut être utile de définir \fIcoredump_filter\fP dans l'interpréteur de commande parent avant d'exécuter le programme\ ; par exemple\ : .PP .in +4n .EX $\fB echo 0x7 > /proc/self/coredump_filter\fP $\fB ./un_programme\fP .EE .in .PP .\" Ce fichier n'existe que si le noyau a été compilé avec l'option de configuration \fBCONFIG_ELF_CORE\fP. .SS "Vidages mémoire et systemd" Sur les systèmes qui utilisent \fBsystemd\fP(1) comme cadriciel pour \fIinit\fP, les vidages mémoire peuvent être écrits à un emplacement déterminé par \fBsystemd\fP(1). À cet effet, \fBsystemd\fP(1) utilise la fonctionnalité \fIcore_pattern\fP qui permet de tuber les vidages mémoire vers un programme. Cela peut être vérifié en regardant si les vidages mémoires sont tubés vers le programme \fBsystemd\-coredump\fP(8)\ : .PP .in +4n .EX $ \fBcat /proc/sys/kernel/core_pattern\fP |/usr/lib/systemd/systemd\-coredump %P %u %g %s %t %c %e .EE .in .PP Dans ce cas, les vidages mémoire seront enregistrés à l'emplacement configuré pour \fBsystemd\-coredump\fP(8), en général sous la forme de fichiers compressés \fBlz4\fP(1) dans le répertoire \fI/var/lib/systemd/coredump/\fP. Pour lister les vidages mémoires qui ont été enregistrés par \fBsystemd\-coredump\fP(8), on peut utiliser \fBcoredumpctl\fP(1)\ : .PP .EX $ \fBcoredumpctl list | tail \-5\fP Wed 2017\-10\-11 22:25:30 CEST 2748 1000 1000 3 present /usr/bin/sleep Thu 2017\-10\-12 06:29:10 CEST 2716 1000 1000 3 present /usr/bin/sleep Thu 2017\-10\-12 06:30:50 CEST 2767 1000 1000 3 present /usr/bin/sleep Thu 2017\-10\-12 06:37:40 CEST 2918 1000 1000 3 present /usr/bin/cat Thu 2017\-10\-12 08:13:07 CEST 2955 1000 1000 3 present /usr/bin/cat .EE .PP Les informations contenues dans tout vidage mémoire comprennent la date et l'heure du vidage, les PID, UID et GID du processus de vidage, le numéro du signal qui a déclenché le vidage et le chemin de l'exécutable qui était exécuté par le processus vidé. Plusieurs options de \fBcoredumpctl\fP(1) permettent de déplacer le fichier image de la mémoire donné depuis l'emplacement de \fBsystemd\fP(1) vers le fichier spécifié. Par exemple, pour extraire le vidage mémoire du PID 2955 montré plus haut dans un fichier nommé \fIcore\fP dans le répertoire actuel, on peut utiliser\ : .PP .in +4n .EX $ \fBcoredumpctl dump 2955 \-o core\fP .EE .in .PP Pour des détails plus exhaustifs, voir la page de manuel de \fBcoredumpctl\fP(1). .PP Pour désactiver de manière permanente le mécanisme de \fBsystemd\fP(1) qui archive les vidages mémoire et rétablir un fonctionnement plus proche du comportement traditionnel de Linux, on peut définir un contournement du mécanisme de \fBsystemd\fP(1) en utilisant quelque chose du genre\ : .PP .in +4n .EX # \fBecho "kernel.core_pattern=core.%p" > \e\fP \fB/etc/sysctl.d/50\-coredump.conf\fP # \fB/lib/systemd/systemd\-sysctl\fP .EE .in .PP On peut aussi modifier le \fIcore_pattern\fP temporairement (jusqu'au prochain redémarrage) en utilisant par exemple la commande suivante (qui inclut dans le nom des fichiers image de la mémoire le nom de l'exécutable et le numéro du signal qui a déclenché le vidage mémoire)\ : .PP .in +4n .EX # \fBsysctl \-w kernel.core_pattern="%e\-%s.core"\fP .EE .in .\" .SH NOTES La commande \fBgdb\fP(1) \fIgcore\fP permet d'obtenir une image mémoire d'un processus en cours d'exécution. .PP .\" Changed with commit 6409324b385f3f63a03645b4422e3be67348d922 .\" Always including the PID in the name of the core file made .\" sense for LinuxThreads, where each thread had a unique PID, .\" but doesn't seem to serve any purpose with NPTL, where all the .\" threads in a process share the same PID (as POSIX.1 requires). .\" Probably the behavior is maintained so that applications using .\" LinuxThreads continue appending the PID (the kernel has no easy .\" way of telling which threading implementation the user-space .\" application is using). -- mtk, April 2006 Jusqu'à Linux\ 2.6.27 inclus, si un processus multithreadé (ou plus précisément, un processus qui partage son espace mémoire avec un autre processus parce que créé avec l'indicateur \fBCLONE_VM\fP de \fBclone\fP(2)) crée une image mémoire, l'identifiant du processus (PID) est toujours ajouté au nom du fichier image de la mémoire, à moins que l'identifiant du processus ne fasse déjà partie du nom de fichier de par la présence d'une spécification \fI%p\fP dans \fI/proc/sys/kernel/core_pattern\fP (cela s'avère principalement utile lors de l'utilisation de l'implémentation obsolète LinuxThreads pour laquelle chaque thread d'un processus a son propre PID). .SH EXEMPLES Le programme ci\-dessous montre l'utilisation de la syntaxe de tubage dans le fichier \fI/proc/sys/kernel/core_pattern\fP. La session de l'interpréteur de commande suivante montre l'utilisation de ce programme (compilé pour créer un exécutable nommé \fIcore_pattern_pipe_test\fP)\ : .PP .in +4n .EX $\fB cc \-o core_pattern_pipe_test core_pattern_pipe_test.c\fP $\fB su\fP Password: #\fB echo \[dq]|$PWD/core_pattern_pipe_test %p UID=%u GID=%g sig=%s\[dq] > \e\fP \fB/proc/sys/kernel/core_pattern\fP #\fB exit\fP $\fB sleep 100\fP \fB\[ha]\e\fP # taper control\-backslash Quit (core dumped) $\fB cat core.info\fP argc=5 argc[0]= argc[1]=<20575> argc[2]= argc[3]= argc[4]= Total bytes in core dump: 282624 .EE .in .SS "Source du programme" \& .EX /* core_pattern_pipe_test.c */ \& #define _GNU_SOURCE #include #include #include #include #include #include \& #define BUF_SIZE 1024 \& int main(int argc, char *argv[]) { ssize_t nread, tot; char buf[BUF_SIZE]; FILE *fp; char cwd[PATH_MAX]; \& /* Changer le répertoire de travail actuel pour celui du processus qui a planté. */ \& snprintf(cwd, PATH_MAX, "/proc/%s/cwd", argv[1]); chdir(cwd); \& /* Écrire la sortie dans le fichier "core.info" dans ce répertoire. */ \& fp = fopen("core.info", "w+"); if (fp == NULL) exit(EXIT_FAILURE); \& /* Afficher les arguments de ligne de commande passés au programme cible du tube configuré dans core_pattern. */ \& fprintf(fp, "argc=%d\en", argc); for (size_t j = 0; j < argc; j++) fprintf(fp, "argc[%zu]=<%s>\en", j, argv[j]); \& /* Compter les octets sur l'entrée standard (le vidage mémoire). */ \& tot = 0; while ((nread = read(STDIN_FILENO, buf, BUF_SIZE)) > 0) tot += nread; fprintf(fp, "Taille en octets du vidage mémoire : %zd\en", tot); \& fclose(fp); exit(EXIT_SUCCESS); } .EE .SH "VOIR AUSSI" \fBbash\fP(1), \fBcoredumpctl\fP(1), \fBgdb\fP(1), \fBgetrlimit\fP(2), \fBmmap\fP(2), \fBprctl\fP(2), \fBsigaction\fP(2), \fBelf\fP(5), \fBproc\fP(5), \fBpthreads\fP(7), \fBsignal\fP(7), \fBsystemd\-coredump\fP(8) .PP .SH TRADUCTION La traduction française de cette page de manuel a été créée par Christophe Blaess , Stéphan Rafin , Thierry Vignaud , François Micaux, Alain Portal , Jean-Philippe Guérard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas François , Florentin Duneau , Simon Paillard , Denis Barbier , David Prévot , Cédric Boutillier , Frédéric Hantrais et Lucien Gentis . .PP Cette traduction est une documentation libre ; veuillez vous reporter à la .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License version 3 .UE concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE. .PP Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à .MT debian-l10n-french@lists.debian.org .ME .