Ça veut dire quoi « un crash » ? L'OOM tue le process ? Il y a un segfault ? Un abort() ? …
Si une fuite est suspectée, plotter top/ps/proc est effectivement un bon début. Si tu plottes aussi /proc/$pid/maps tu peux commencer à voir plus précisement ce qui fuite à l'intérieur du process (probablement le tas).
S'il s'agit bien d'une fuite sur le tas, il y a plusieurs approches. Si Valgrind est une option, c'est sans doute le moyen le plus rapide de trouver la source du problème mais selon le programme concerné, ça n'est pas forcément faisable.
Une alternative est d'instrumenter le programme en hookant ou wrappant malloc/free « manuellement ».
Une autre approche assez barbare mais qui fonctionne parfois fort bien est d'attacher un debugger (ou dumper un core) et d'examiner des bouts de mémoire plus ou moins au hasard jusqu'à reconnaitre un motif évident.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# idées
Posté par Krunch (courriel, site web personnel) . En réponse au message Monitorer la consomation de ressource d'un process. Évalué à 2.
Ça veut dire quoi « un crash » ? L'OOM tue le process ? Il y a un segfault ? Un abort() ? …
Si une fuite est suspectée, plotter top/ps/proc est effectivement un bon début. Si tu plottes aussi /proc/$pid/maps tu peux commencer à voir plus précisement ce qui fuite à l'intérieur du process (probablement le tas).
S'il s'agit bien d'une fuite sur le tas, il y a plusieurs approches. Si Valgrind est une option, c'est sans doute le moyen le plus rapide de trouver la source du problème mais selon le programme concerné, ça n'est pas forcément faisable.
Une alternative est d'instrumenter le programme en hookant ou wrappant malloc/free « manuellement ».
Une autre approche assez barbare mais qui fonctionne parfois fort bien est d'attacher un debugger (ou dumper un core) et d'examiner des bouts de mémoire plus ou moins au hasard jusqu'à reconnaitre un motif évident.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.