Discussion :

[nicolas.sitbon]

Si tu veux. En attendant, intercepter un signal juste pour r��crire diff�remment ce que l'OS aurait tr�s bien �crit tout seul, je n'en vois pas l'int�r�t pour ma part.

C'est un peu comme avec malloc(), � la fin de ton programme, tu peux lib�rer toi m�me ta m�moire avec free() ou laisser ton OS moderne le faire pour toi. Mais cela n'est pas garanti sur tous les OS, et n'est pas propre � mon sens. L� c'est la m�me chose. Il n'y a plus grand chose � sauver (je parle dans le cas de signaux comme SIGBUS ou SIGSEGV), mais on peut au moins journaliser un maximum d'information afin de corriger le bug.

[Mac LAK]

Il n'y a plus grand chose � sauver (je parle dans le cas de signaux comme SIGBUS ou SIGSEGV), mais on peut au moins journaliser un maximum d'information afin de corriger le bug.

Tu veux journaliser quoi de plus, que le core ne fournirait pas ?

EDIT : Bien s�r, on parle bien de signaux critiques l�, pas d'un SIGUSR.

[nicolas.sitbon]

Tu veux journaliser quoi de plus, que le core ne fournirait pas ?

en admettant que le bug est pass� la phase de test, je ne g�n�re jamais de core en production, donc j'aimerais au moins avoir une id�e de ce qu'il s'est pass�.

[Mac LAK]

en admettant que le bug est pass� la phase de test, je ne g�n�re jamais de core en production, donc j'aimerais au moins avoir une id�e de ce qu'il s'est pass�.

C'est plut�t le contraire pour ma part : rarement de core en phase de test, et syst�matiquement activ� chez le client, ne serait-ce que pour deux raisons :

• Les tests effectu�s ayant conduit � l'erreur ne sont pas toujours reproductibles � volont� (loin de l�, m�me...).
• Avoir le core permet aussi de ne pas paralyser la machine du client, et de travailler dans des environnements un peu plus outill�s que la machine-cible finale.

Cela reste un choix, bien s�r, mais pour moi le core n'a d'int�r�t que dans ce genre de cas vicieux plus ou moins reproductibles / al�atoires : ne pas l'activer en prod, c'est risquer de devoir dire au client "D�sol�s, on ne sait pas par o� commencer nos recherches pour r�soudre le bug".

Et dans cette optique, l'interception de signaux critiques n'a aucun int�r�t (au contraire, d'ailleurs). Et si c'est pour juste afficher diff�remment l'erreur affich�e nativement par l'OS, l� non plus je n'en vois pas l'int�r�t...

[nicolas.sitbon]

C'est plut�t le contraire pour ma part : rarement de core en phase de test, et syst�matiquement activ� chez le client

L� je t'arr�te tout de suite, je ne sais pas dans quoi tu travailles, mais personnellement, je n'ai pas le droit d'avoir les coredumps de mes clients �tant donn� que ceux ci contiennent des donn�es confidentielles, je dois faire avec les moyens du bord. J'ai un fichier de log et un seul, � moi de ne pas me rater sur ce que je journalise, Et je n'ai aucune id�e de ce que le syst�me a pu pondre comme sortie relative � l'erreur puisque je n'ai pas d'acc�s � la b�cane.

[Mac LAK]

L� je t'arr�te tout de suite, je ne sais pas dans quoi tu travailles, mais personnellement, je n'ai pas le droit d'avoir les coredumps de mes clients �tant donn� que ceux ci contiennent des donn�es confidentielles, je dois faire avec les moyens du bord.

Industrie, on r�gle le probl�me via des habilitations (du simple droit de visite sur site jusqu'au SD), c'est nettement plus simple en fait... On peut du coup aller sur les sites, avoir acc�s aux zones prot�g�es et aux donn�es (m�me sensibles) librement. De plus, le core ne contient qu'une partie infime des donn�es dans notre cas, le "gros" �tant d�j� sauv� depuis longtemps et, surtout, totalement inutile pour ce genre d'investigation.

J'ai un fichier de log et un seul, � moi de ne pas me rater sur ce que je journalise, Et je n'ai aucune id�e de ce que le syst�me a pu pondre comme sortie relative � l'erreur puisque je n'ai pas d'acc�s � la b�cane.

Ou comment doubler la complexit� d'un programme via les logs, voire provoquer des erreurs li�es aux logs eux-m�mes (cas v�cu)... Rien contre toi personnellement, bien entendu, les ordres sont les ordres, m�me s'ils sont idiots.

Mais � la version suivante, � ta place, je leur proposerais la boule de cristal et les menottes dans le dos pour les d�vs, en phase d'analyse de bug, ce serait s�rement plus rentable.

[nicolas.sitbon]

A chacun ses imp�ratifs, bref, on s'�carte du sujet (et on pollue le post).