FR 2927434 A1 20090814 FR 0800655 A 20080207 1 La présente invention concerne un procédé de gestion d'une interruption d'exécution d'une application exécutable dans au moins un répertoire d'un système informatique. E[ e concerne également un système et un produit programme d'ordinateur correspondants. Plus précisérnent, l'invention concerne un procédé du type précité comportant une étape de génération d'un fichier de type cliché-mémoire, communément appelé fichier � Core � et comprenant une copie de la mémoire utilisée par l'application au moment de l'interruption d'exécution, dans un répertoire courant d'exécution de l'application. Sachant que l'application peut être exécutée par un processeur du système informatique dans un ou plusieurs répertoire(s), on entend par � répertoire courant � dans lequel est généré le fichier Core, celui dans lequel l'application s'exécute ou interrompt son exécution au moment de la génération du fichier Core. Toutes les interruptions d'exécution d'une application ne donnent pas lieu à la génération d'un fichier Core. En général, ce sont des interruptions dues à une erreur grave d'exécution, telle qu'une tentative d'accès à une zone de mémoire non allouée, une division par zéro, ou toute autre erreur dite fatale, qui sont suivies de la génération de ce type de fichier. Une analyse du fichier Core, c'est-à-dire de l'état de la mémoire utilisée par l'application au moment de l'interruption de son exécution, permet généralement de comprendre la véritable cause de l'interruption et le contexte dans lequel l'erreur grave s'est produite. Au cours du développement logiciel d'une application notamment, ce fichier Core peut donc s'avérer très utile pour le déboguage de l'application. Malheureusement, le fichier Core est généralement créé dans le répertoire courant d'exécution de l'application au moment de son interruption. Il est donc destiné à être créé dans un répertoire non maîtrisé par l'utilisateur de l'application. Ainsi par exemple, si l'application s'exécute dans un répertoire accessible en écriture uniquement par un administrateur prédéterminé, mais pas par l'utilisateur du système informatique, au moment de son interruption, le fichier Core ne pourra tout simplement pas être créé. Il faudrait pour cela que l'utilisateur possède les droits d'accès de l'administrateur, ce qui n'est souvent pas le cas. En outre, quand bien même l'utilisateur posséderait les droits d'accès de l'administrateur, certains répertoires peuvent n'être pas du tout accessibles en écriture du fait qu'ils sont virtuels. C'est par exemple le cas du répertoire � /proc � du système d'exploitation GNU/Linux (marque déposée) qui est en fait un pseudo système de fichiers utilisé pour accéder en lecture et/ou écriture de données à partir 2 de et/ou sur le noyau Linux. Si l'application s'exécute dans ce répertoire au moment de l'interruption de son exécution, le fichier Core ne pourra pas non plus être créé. Par ailleurs, si plusieurs applications sont amenées à interrompre leur exécution provoquant la génération de plusieurs fichiers Core, les répertoires courants dans lesquels elles s'exécutent n'étant pas maîtrisés par les utilisateurs du système informatique, cela crée un saupoudrage de fichiers Core, qui peuvent parfois prendre beaucoup de place dans les moyens de stockage du système informatique. Cela conduit généralement l'administrateur du système informatique à interdire purement et simplement la génération de fichiers Core et à priver ainsi les utilisateurs de leur utilité potentielle. Enfin, le répertoire courant dans lequel s'exécute l'application au moment de l'interruption de son exécution peut être limité en taille, de sorte que si le fichier Core est amené à dépasser cette taille, il ne peut pas être généré. De plus, un utilisateur ne peut pas disposer d'un répertoire spécifique pour le stockage des fichiers Core qu'il est susceptible de générer. Sous Linux, il existe aujourd'hui une solution pour imposer un répertoire d'écriture du fichier Core qui ne soit pas nécessairement le répertoire courant dans lequel s'exécute l'application au moment de l'interruption de son exécution. Cette solution consiste à paramétrer la variable de configuration /proc/sys/kernel/core_pattern du noyau Linux, à l'aide de la commande de haut niveau �sysctl �. En effet, il est prévu par défaut qu'un fichier Core soit généré dans le répertoire courant d'exécution de l'application et qu'il soit nommé � core �, la variable de configuration étant par défaut égale à "core". Mais grâce à la commande sysctl, il est par exemple possible d'imposer core_pattern = /var/core. Dans ce cas, le fichier Core généré sera nommé � core � et se trouvera dans le répertoire /var du système informatique. En outre, des spécificateurs peuvent être ajoutés pour identifier plus précisément le fichier Core généré et permettre la génération de plusieurs fichiers Core différents dans un même répertoire ou dans plusieurs répertoires différents. Ces spécificateurs (%p, %u, %g, %s, %t, %h, %e) sont remplacés par les valeurs qu'ils désignent au moment de la création du fichier Core. Ainsi, le spécificateur %p désigne l'identifiant PID (de l'anglais � Process IDentifier �) du processus en cours d'exécution. Par conséquent, en imposant core_pattern = /var/core- %p, tous les fichiers Core seront générés dans le répertoire /var et porteront un nom différent : le fichier Core du processus PID1 3 sera nommé � core-PID1 �, celui du processus PID2 sera nommé � core-PID2 �, etc. Le spécificateur %u désigne l'identifiant UID (de l'anglais � User IDentifier �) de l'utilisateur à l'origine du processus en cours d'exécution. Par conséquent, en imposant core_pattern = /var/ %u /core-%p, le fichier Core du processus PID1 de l'utilisateur UID1 sera nommé spécifiquement � corePID1 � dans un répertoire dédié à l'utilisateur UIC1 et nommé /var/UID1. Cette solution permet de résoudre certains des problèmes précités, mais comporte l'inconvénient de n'être accessible qu'à l'administrateur du système informatique, de façon générale, via la commande sysctl. Un utilisateur autre que l'administrateur ne peut pas configurer la variable d'environnement core_pattern selon ses besoins spécifiques, cette dernière étant la même pour tous. Or, sur un même système informatique, des utilisateurs développeurs peuvent souhaiter conserver les fichiers Core dans leur arborescence de développement pour faciliter le déboguage de leur application, alors que des utilisateurs faisant de l'exploitation d'applications peuvent souhaiter stocker les fichiers Core dans un emplacement commun, accessible à l'analyse d'un problème ayant généré un fichier Core pour la maintenance d'un produit, et pas dans leur propre compte pour des raisons de volume de données et de droits d'accès. En effet, les fichiers Core générés en exploitation sont généralement beaucoup plus gros que ceux générés en développement. Il peut ainsi être souhaité de prévoir un dispositif et/ou un procédé de gestion d'une interruption d'exécution d'une application qui permette de s'affranchir des problèmes et contraintes de l'état de la technique précité. L'invention a donc pour objet un procédé de gestion d'une interruption d'exécution d'une application exécutable dans au moins un répertoire d'un système informatique, comportant une étape de génération d'un fichier de type cliché-mémoire, ce fichier comprenant une copie de la mémoire utilisée par l'application au moment de l'interruption d'exécution, dans le répertoire courant d'exécution de l'application, caractérisé en ce qu'il comporte, suite à l'interruption d'exécution de l'application et avant la génération du fichier de type cliché-mémoire, l'exécution par le système informatique d'une commande de changement de répertoire courant d'exécution de l'application, vers un répertoire défini par une valeur paramétrable par un utilisateur. Grâce à ce procédé, il est ainsi possible pour un utilisateur de choisir le répertoire dans lequel doit être stocké le fichier Core sans pour autant imposer un 4 paramétrage de variable de configuration accessible uniquement à un administrateur ou contraindre l'application à s'exécuter sur certains répertoires prédéterminés. De façon optionnelle, la commande de changement de répertoire courant et la valeur paramétrable sont définies dans une librairie informatique spécifique de gestion de fichier de type cliché-mémoire, appelée par l'application exécutable au cours de son exécution. De façon optionnelle également, l'interruption d'exécution de l'application exécutable provoquant la génération d'un signal d'interruption détectable par un système d'exploitation du système informatique et issu d'une liste prédéterminée de signaux de référence susceptibles de provoquer la génération d'un fichier de type cliché-mémoire, la commande de changement de répertoire courant est définie dans une fonction de la librairie informatique spécifique, cette fonction étant associée au signal d'interruption, lors d'une étape d'initialisation au cours de laquelle la librairie informatique spécifique est appelée par l'application pendant son exécution, et destinée à être exécutée par le système d'exploitation sur détection du signal d'interruption. De façon optionnelle également, la librairie informatique spécifique comporte en outre des fonctions de base correspondant à des fonctions de base d'une librairie informatique standard destinée à être appelée par l'application exécutable, chaque fonction de base de la librairie informatique spécifique comportant : - une première instruction pour associer les signaux de la liste prédéterminée de signaux de référence à la fonction de la librairie informatique spécifique destinée à être exécutée par le système d'exploitation sur détection du signal d'interruption, et - une seconde instruction pour exécuter la fonction de base correspondante de la librairie informatique standard. De façoi optionnelle également, la première instruction est exécutée uniquement lors de l'étape d'initialisation, cette étape d'initialisation consistant à, lors du premier appel par l'application exécutable d'une fonction de base de la librairie informatique standard définie également dans la librairie informatique spécifique, exécuter la fonction de base correspondante de la librairie informatique spécifique. De façon optionnelle également, les fonctions de base de la librairie informatique spécifique correspondant aux fonctions de base de la librairie informatique standard comportent au moins l'une des fonctions suivantes : - une fonction de changement de répertoire d'exécution de l'application exécutable, une fonction d'association de l'un des signaux de la liste prédéterminée de signaux de référence à une fonction destinée à être exécutée par le 5 système d'exploitation du système informatique sur détection de ce signal, - une fonction d'allocation dynamique de mémoire, - une fonction d'arrêt de l'application en cours d'exécution. De façon optionnelle également, la fonction de la librairie informatique spécifique destinée à être exécutée par le système d'exploitation sur détection du signal d'interruption prévoit l'exécution des étapes suivantes : lors d'une première étape, une fonction de changement de répertoire courant d'exécution de l'application exécutable est appelée, le nouveau répertoire courant d'exécution étant déterminé soit selon une valeur par défaut soit selon une variable d'environnement, la valeur par défaut et la variable d'environnement étant paramétrables dans la librairie informatique spécifique, - lors d'une seconde étape, le signal d'interruption détecté, initialement associé à la fonction de la librairie informatique spécifique destinée à être exécutée par le système d'exploitation, est dissocié de cette fonction, de manière à permettre la génération effective d'un fichier de type cliché-mémoire. De façon optionnelle également, la librairie informatique spécifique est pré-chargée auprès de l'application exécutable, par pointage prioritaire vers cette librairie informatique spécifique dans une variable d'environnement de pré-chargement de librairies informatiques d'un système d'exploitation du système informatique. L'invention a également pour objet un système informatique de gestion d'une interruption d'execution d'une application exécutable dans au moins un répertoire de ce système informatique, comportant des moyens de stockage et d'exécution de l'application, des moyens de génération d'un fichier de type cliché-mémoire dans un répertoire courant d'exécution de l'application, ce fichier comprenant une copie de la mémoire utilisée par l'application au moment de l'interruption d'exécution, caractérisé en ce qu'il comporte en outre des moyens d'exécution d'une commande de changement 'Je répertoire courant d'exécution de l'application, vers un répertoire défini par une valeur paramétrable par un utilisateur, ces moyens d'exécution étant 6 activables suite à l'interruption d'exécution de l'application et avant la génération du fichier de type cliché-mémoire. Enfin, l'invention a également pour objet un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en œuvre d'un procédé de gestion d'une interruption d'exécution d'une application selon tel que décrit précédemment. L'inventioi sera mieux comprise à l'aide de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant aux dessins annexés dans lesquels : la figure 1 représente schématiquement la structure générale d'un système informatique de gestion d'une interruption d'exécution d'une application, selon un mode de réalisation de l'invention, et - la figure 2 illustre les étapes successives d'un procédé de gestion d'une interru )tion d'exécution d'une application, selon un mode de réalisation de l'invention. Sur la figure 1, une installation informatique est schématiquement et partiellement représentée par la référence 10. Cette installation comporte un microprocesseur 12, une mémoire morte de type ROM 14 (de l'anglais � Read Only Memory �) pour le stockage, notamment, d'un système élémentaire d'entrée/sortie, appelé communément BIOS (de l'anglais � Basic Input Output System �), et une mémoire vive de type RAM 16 (de l'anglais � Read Access Memory �) pour, en combinaison avec le microprocesseur 12, l'exécution de programmes informatiques. Elle comporte en outre des moyens de stockage, amovibles ou non, tels qu'un disque dure interne 18 et un bus de transmission de données classique pour relier entre eux le microprocesseur 12, les mémoires ROM 14 et RAM 16, et le disque dure interne 18. Cette installation est appropriée pour la mise en oeuvre de l'invention, mais d'autres configurations possibles d'installations informatiques conviennent aussi. En effet, l'invention s'applique, de façon non limitative, à des installations informatiques telles que des ordinateurs de type PC fixes ou portables, des serveurs, des installations multiprocesseurs, des réseaux locaux d'ordinateurs, etc. Le disque dur interne 18 stocke plusieurs applications, parmi lesquelles le noyau 22 du système d'exploitation de l'installation informatique 10 et au moins une 7 application exécutable d'utilisateur 24, prise à titre d'exemple non limitatif pour la description d'un mode de réalisation de l'invention. De façon classique, l'espace de mémoire que constitue le disque dur interne 18 est organisé en une ou plusieurs partitions, chaque partition étant elle-même organisée en une arborescence 26 de répertoires dans lesquels sont répartis les fichiers informatiques stockés par le disque dur. Sur la figure 1, on a représenté de façon non limitative une organisation possible d'une partition dans laquelle l'application 24 est susceptible de s'exécuter. Comme indiqué précédemment, l'application 24 peut être destinée à s'exécuter successivement dans une pluralité de répertoires de l'arborescence 26, certains pouvant n'être accessibles en lecture et/ou écriture que par un administrateur authentifié. De façon classique également, l'application exécutable 24 fait appel à des fichiers d'ensembles de fonctions utilitaires, indifféremment appelés � librairies informatiques � ou 8 Sous l'environnement Linux, il est possible de � pré-charger � la librairie informatique spécifique 30 auprès de l'application exécutable 24 sans nécessiter de modification de cette dernière. Pour ce faire, la variable d'environnement LDPRELOAD de la librairie partagée Id-linux.so peut pointer prioritairement sur la librairie informatique spécifique 30. Cette variable d'environnement est définie indépendamment du code de l'application exécutable 24 et son accès ne nécessite pas de droit d'administrateur. On notera que les librairies informatiques 28 et 30 sont stockées dans le disque dur interne 18. Les fonctions reprises par la librairie informatique spécifique 30 sont par exemple les fonctions précitées chdir, signal, malloc, raise, kill et abort. Pour une fonction donnée, reprise par la librairie informatique spécifique 30, il est prévu de : - lier chacun d'une liste prédéterminée de signaux susceptibles de générer un fichier Core à un handler défini par la librairie informatique spécifique 30 grâce à la fonction signal, si cela n'a pas déjà été fait (i.e. étape d'initiaiisation du handler de la librairie informatique spécifique 30), - appeler la fonction correspondante de la librairie informatique standard 28. Les fonctions précitées chdir, signal, malloc, raise, kill et abort sont intéressantes à intercepter par la librairie informatique spécifique 30 pour les raisons suivantes : la fonction chdir est la fonction destinée à être utilisée par l'application exécutable 24 pour placer son exécution dans un répertoire susceptible de poser un problème pour l'écriture de fichier Core ; la fonction signal est la fonction qui permet d'associer un handler à un signal, donc il peut être intéressant pour la librairie informatique spécifique 30 de préempter une telle instruction ; la fonction malloc est une fonction appelée par une immense majorité d'applications exécutables et permet donc d'assurer l'initialisation du handler de la librairie informatique spécifique 30 ; les fonctions raise, kill et abort présentent la particularité de pouvoir terminer l'exécution en cours de l'application 24 en générant éventuellement un fichier Core. La liste prédéterminée de signaux susceptibles de générer un fichier Core comporte par exemple les signaux suivants (selon leur identification sous l'environnement Linux) : - SIGQUIT (= 3) : ce signal est généré et repéré par le noyau 22 du système d'exploitation lorsqu'un utilisateur arrête l'exécution de l'application 24, par exemple lorsque celle-ci s'exécute en boucle sans pouvoir s'arrêter d'elle- même, 9 - SIGILL (= 4) : ce signal est généré et repéré par le noyau 22 du système d'exploitation lorsque le microprocesseur 12 exécute une instruction de l'application 24 qu'il ne comprend pas, révélant éventuellement un problème dans la mémoire RAM 16, - SIGAERT (= 6) : ce signal est généré et repéré par le noyau 22 du système d'exploitation lorsque l'application 24 est bloquée dans son exécution, par exemple lorsqu'elle cherche un fichier de configuration qui n'existe pas, - SIGBUS (= 7) : ce signal est généré et repéré par le noyau 22 du système d'exploitation lors d'une erreur d'accès à une zone de mémoire, par exemple pour inexistence de cette zone de mémoire au niveau matériel, -SIGFPE (_: 8) : ce signal est généré et repéré par le noyau 22 du système d'exploitation lorsque le microprocesseur se trouve confronté à un calcul mathématique impossible à réaliser, tel qu'une division par zéro, SIGSEGV (= 11) : ce signal est généré et repéré par le noyau 22 du système d'exploitation lors d'une erreur d'accès à une zone de mémoire, pour un problème de violation de droits d'accès ou de segmentation. Lors de l'étape d'initialisation du handler de la librairie informatique spécifique 30, chacun des signaux précités est lié, grâce à un appel de la fonction standard signal, à une fonction exécutable par le noyau 22 du système d'exploitation (i.e. le handler de la librairie informatique spécifique 30) définie de la façon suivante : lors d'une première étape, la fonction standard chdir est appelée pour changer le répertoire courant d'exécution de l'application 24, soit selon une valeur par défaut définie dans la librairie informatique spécifique 30 (par exemple le répertoire � /var/core �), soit selon une valeur définie explicitement par un utilisateur dans une variable d'environnement de la librairie informatique spécifique 30, la valeur de cette variable d'environnement (par exemple appelée LIBCORE_PATH) étant prioritaire sur la valeur par défaut, si elle est définie, - lors d'une seconde étape, le signal initialement associé à ce handler est dissocié de ce handler, de manière à permettre la génération d'un fichier Core. Ainsi, lors de l'émission d'un des signaux précités susceptibles de générer un fichier Core, sa détection par le noyau 22 du système d'exploitation du système informatique 10 déclenche l'une des actions suivantes : 10 si l'étape d'initialisation du handler de la librairie informatique spécifique 30 n'a pas été exécutée, faute d'appel à l'une des fonctions interceptée par la librairie informatique spécifique 30 (peu probable) ou de pré-chargement de cette librairie informatique spécifique 30 auprès de l'application exécutable 24, le fichier Core est généré dans le répertoire courant de l'application 24, quel qu'il soit, - si l'étape d'initialisation du handler de la librairie informatique spécifique 30 a été exécutée mais que la variable d'environnement LIBCORE_PATH n'est pas définie, le fichier Core est généré dans le répertoire /var/core défini par défaut, - si l'étape d'initialisation du handler de la librairie informatique spécifique 30 a été exécutée et que la variable d'environnement LIBCORE_PATH a été définie par un utilisateur, le fichier Core est généré dans le répertoire défini par LIBCORE_PATH. Par ailleurs, comme indiqué précédemment, des spécificateurs (%p, %u, %g, %s, %t, %h, %e) peuvent être définis par un administrateur via la commande privilégiée sysctl pour identifier plus précisément le fichier Core généré et permettre la génération de plusieurs fichiers Core différents dans un même répertoire. D'autres signaux que ceux précités et ne générant pas de fichier Core par défaut peuvent être générés en cours d'exécution de l'application exécutable 24 : sous Linux, il s'agit par exemple des signaux SIGHUP, SIGINT, SIGTERM. La gestion de ces signaux n'est alors pas modifiée par la librairie informatique spécifique 30, par souci de transparence. Par ailleurs, il se peut que l'application exécutable 24 prévoie de lier, à un handler applicatif spécifique, au moins l'un des signaux de la liste prédéterminée de signaux susceptibles de générer un fichier Core et gérés par la librairie informatique spécifique 30. Dans ce cas, ce handler applicatif est détecté par la librairie informatique spécifique 30. Ainsi, lors de l'émission d'un des signaux associés au handler de la librairie informatique spécifique 30, si ce signal est également lié à un handler applicati spécifique, sa détection par le noyau 22 du système d'exploitation du système informatique 10 déclenche les actions suivantes : - exécution du handler de la librairie informatique spécifique 30, - appel du handler applicatif spécifique par le handler de la librairie informatique spécifique 30 pour exécuter ses instructions spécifiques prévues par l'application 24, 11 génération du fichier Core, uniquement si le handler applicatif spécifique le prévoit explicitement. Ceci permet de rester cohérent avec l'environnement Linux qui prévoit généralement de ne pas générer de fichier Core si un handler applicatif spécifique est lié par l'application 24 à un signal susceptible a priori de provoquer la génération d'un fichier Core. Un procédé de gestion d'une interruption d'exécution d'une application exécutable dans au moins un répertoire d'un système informatique, mis en oeuvre dans le système informatique décrit précédemment, va maintenant être détaillé en référence à la figure 2, dans le cas purement illustratif et non limitatif d'une interruption d'exécution de l'application exécutable 24. Lors d'une première étape 100, l'application 24 est lancée dans l'un des répertoires du système informatique 10. Ensuite, lors d'une étape 102 intervenant en cours d'exécution, l'application 24 appelle pour la première fois l'une des fonctions de base de la librairie informatique standard 28 destinée à être interceptée par la librairie informatique spécifique 30, en d'autres termes l'une des fonctions précitées chdir, signal, malloc, raise, kill ou abort. Ainsi, comme prévu par la variable d'environnement LD_PRELOAD, c'est la fonction correspondante de la librairie informatique spécifique 30 qui est exécutée lors de cette étape 102. Comme indiqué précédemment, pour une fonction donnée, reprise par la librairie informatique spécifique 30, il est prévu de lier chacun des signaux précités susceptibles de générer un fichier Core (SIGQUIT, SIGILL, SIGABRT, SIGBUS, SIGFPE, SIGSEGV) au handler défini par la librairie informatique spécifique 30, cet ensemble de liens étant représenté sur la figure 2 par la référence T conservée en mémoire par le noyau 22 du système d'exploitation (étape d'initialisation du handler de la librairie informatique spécifique 30). II est également prévu d'appeler la fonction correspondante de la librairie informatique standard 28. Ainsi, lors d'une étape suivante 104, de façon transparente pour l'application 24, c'est la fonction de base de la librairie informatique standard 28 appelée par l'application lors de l'étape 102 qui s'exécute. Suite à cette étape, l'application 24 poursuit son exécution. Au cours de cette exécution, elle peut être amenée à changer de répertoire courant d'exécution et à appeler de nouveau des fonctions de base comptant parmi celles qui sont interceptées par la librairie informatique spécifique 30. Lors de ces appels, l'étape 12 d'initialisation du handler de la librairie informatique spécifique 30 n'est pas réitérée et les fonctions de base appelées sont directement exécutées à l'aide de la librairie informatique standard 28. Lors d'une étape 106, suite à une erreur d'exécution, l'application 24 s'interrompt et génère un signal S. Si ce signal S est l'un des signaux susceptibles de générer un fichier Core, le noyau 22 du système d'exploitation fait le lien entre ce signal S et le handler de la librairie informatique spécifique 30 grâce à l'ensemble de liens T conservé en mémoire, puis il exécute l'étape 108 suivante. Lors de cette étape 108, le noyau 22 du système d'exploitation exécute le handler associé au signal S : il change le répertoire courant d'exécution de l'application 24, soit selon une valeur par défaut définie dans la librairie informatique spécifique 30, soit selon une valeur définie explicitement par un utilisateur dans la variable d'environnement LIBCORE_PATH. II supprime ensuite l'association du handler de la librairie informatique spécifique 30 au signal S, de sorte qu'un fichier Core puisse être généré dans le répertoire courant, qui est maintenant défini soit par la valeur par défaut soit par la variable d'environnement LIBCORE_PATH, sauf si le signal S est associé à un handler applicatif spécifique comme cela a été envisagé précédemment. Le cas échéant, le fichier Core est généré dans le répertoire courant lors d'une dernière étape 110. Il apparaît clairement que le procédé décrit précédemment, mis en oeuvre par le système informatique de la figure 1, permet une meilleure maîtrise de l'endroit ou un fichier Core peut être généré dans une arborescence de répertoires. Selon ce procédé, un utilisateur peut obtenir la génération de fichiers Core dans un ou plusieurs répertoire(s) qu'il a lui-même choisi(s), sans nécessiter pour autant de droits d'accès d'un administrateur et sans imposer une règle unique s'imposant à tous les utilisateurs par la commande sysctl. En outre, l'utilisation d'une librairie informatique spécifiquement dédiée à la gestion de fichier Core et s'interposant de façon transparente entre une application exécutable et une librairie informatique standard utilisée par cette application, permet de concevoir un mode de réalisation ne nécessitant pas de modifications de l'application exécutable susceptible d'être à l'origine d'un fichier Core. Enfin, on notera que l'invention n'est pas limitée au mode de réalisation décrit précédemment. Notamment, l'invention a été décrite dans le contexte du système d'exploitation GNU/Linux mais peut aussi bien être mise en oeuvre dans le contexte 13 d'un autre système d'exploitation en transposant les structures, variables et fonctions utilisées. REVENDICATIONS 1. Procédé de gestion d'une interruption (106) d'exécution d'une application (24) exécutable dans au moins un répertoire (26) d'un système informatique (10), comportant une étape (110) de génération d'un fichier de type cliché-mémoire dans un répertoire courant d'exécution de l'application, ce fichier comprenant une copie de la mémoire utilisée par l'application (24) au moment de l'interruption d'exécution (106), caractérisé en ce qu'il comporte, suite à l'interruption (106) d'exécution de l'application (24) et avant la génération (110) du fichier de type cliché-mémoire, l'exécution (108) par le système informatique (10) d'une commande de changement de répertoire courant d'exécution de l'application (24), vers un répertoire défini par une valeur paramétrable par un utilisateur. 2. Procédé de gestion d'une interruption (106) d'exécution d'une application (24) selon la revendication 1, dans lequel la commande de changement de répertoire courant et la valeur paramétrable sont définies dans une librairie informatique spécifique (30) de gestion de fichier de type cliché-mémoire, appelée par l'application exécutable (24) au cours de son exécution. 3. Procédé de gestion d'une interruption (106) d'exécution d'une application (24) selon la revendication 2, dans lequel, l'interruption (106) d'exécution de l'application exécutable (24) provoquant la génération d'un signal d'interruption (S) détectable par un système d'exploitation (22) du système informatique (10) et issu d'une liste prédéterminée de signaux de référence susceptibles de provoquer la génération d'un fichier de type cliché-mémoire, la commande de changement de répertoire courant est définie dans une fonction de la librairie informatique spécifique (30), cette fonction étant associée au signal d'interruption (S), lors d'une étape d'initialisation (102) au cours de laquelle la librairie informatique spécifique (30) est appelée par l'application (24) pendant son exécution, et destinée à être exécutée par le système d'exploitation (22) sur détection du signal d'interruption (S). 4. Procédé de gestion d'une interruption (106) d'exécution d'une application (24) selon la revendication 3, dans lequel la librairie informatique spécifique (30) comporte en outre des fonctions de base correspondant à des fonctions de base d'une librairie in'''ormatique standard (28) destinée à être appelée par l'application exécutable (24), chaque fonction de base de la librairie informatique spécifique (30) comportant : 15 une première instruction pour associer les signaux de la liste prédéterminée de signaux de référence à la fonction de la librairie informatique spécifique (30) destinée à être exécutée par le système d'exploitation (22) sur détection du signal d'interruption (S), et - une seconde instruction pour exécuter la fonction de base correspondante de la librairie informatique standard (28). 5. Procédé de gestion d'une interruption (106) d'exécution d'une application (24) selon la revendication 4, dans lequel la première instruction est exécutée uniquement lors de l'étape d'initialisation (102), cette étape d'initialisation consistant à, lors du premier appel par l'application exécutable (24) d'une fonction de base de la librairie informatique standard (28) définie également dans la librairie informatique spécifique (30), exécuter la fonction de base correspondante de la librairie informatique spécifique (30). 6. Procédé de gestion d'une interruption (106) d'exécution d'une application (24) selon la revendication 4 ou 5, dans lequel les fonctions de base de la librairie informatique spécifique (30) correspondant aux fonctions de base de la librairie informatique standard (28) comportent au moins l'une des fonctions suivantes : - une fonction de changement de répertoire d'exécution de l'application exécutable (24), - une fonction d'association de l'un des signaux de la liste prédéterminée de signaux de référence à une fonction destinée à être exécutée par le système d'exploitation (22) du système informatique (10) sur détection de ce signal, - une fonction d'allocation dynamique de mémoire, - une fonction d'arrêt de l'application (24) en cours d'exécution. 7. Procédé de gestion d'une interruption (106) d'exécution d'une application (24) selon l'une quelconque des revendications 4 à 6, dans lequel la fonction de la librairie informatique spécifique (30) destinée à être exécutée par le système d'exploitation (22) sur détection du signal d'interruption (S) prévoit l'exécution des 30 étapes suivantes : - lors d'une première étape, une fonction de changement de répertoire courant d'exécution de l'application exécutable (24) est appelée, le nouveau répertoire courant d'exécution étant déterminé soit selon une valeur par défaut soit selon une variable d'environnement, la valeur par 25défaut et la variable d'environnement étant paramétrables dans la librairie informatique spécifique (30), lors d'une seconde étape, le signal d'interruption détecté (S), initialement associé à la fonction de la librairie informatique spécifique (30) destinée à être exécutée par le système d'exploitation (22), est dissocié de cette fonction, de manière à permettre la génération effective d'un fichier de type cliché-mémoire. 8. Procédé de gestion d'une interruption (106) d'exécution d'une application (24) selon l'une quelconque des revendications 2 à 7, dans lequel la librairie informatique spécifique (30) est pré-chargée auprès de l'application exécutable (24), par pointage prioritaire vers cette librairie informatique spécifique (30) dans une variable d'environnement de pré-chargement de librairies informatiques d'un système d'exploitation (22) du système informatique (24). 9. Système informatique (10) de gestion d'une interruption (106) d'exécution d'une application (24) exécutable dans au moins un répertoire (26) de ce système informatique, comportant des moyens de stockage (18) et d'exécution (12) de l'application (24), des moyens (22) de génération d'un fichier de type cliché-mémoire dans un répertoire courant d'exécution de l'application (24), ce fichier comprenant une copie de la mémoire utilisée par l'application (24) au moment de l'interruption d'exécution, caractérisé en ce qu'il comporte en outre des moyens (12, 22) d'exécution d'une commande de changement de répertoire courant d'exécution de l'application (24), vers un répertoire défini par une valeur paramétrable par un utilisateur, ces moyens d'exécution étant activables suite à l'interruption (106) d'exécution de l'application et avant la génération (110) du fichier de type cliché- mémoire. 10. Programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution des étapes d'un procédé de gestion d'une interruption (106) d'exécution d'une application (24) selon l'une quelconque des revendications 1 à 8 lorsque ledit programme est exécuté sur un ordinateur.