Discussion :

[ZZZzzz2]

Bonjour,


Voici mon problème :

J'ai intégré à notre application un système permettant de récupérer la pile d'appels lorsqu'une exception a lieu. Ce système s'appuie que la lib "FastMM4" et sur la redéfinition du pointeur "System.RaiseExceptionProc".

Cela fonctionne généralement très bien sauf dans certains cas ou alors qu'une exception a lieu (par exemple "violation d'accès") la fonction "System.RaiseExceptionProc" n'est pas appelée.

J'ai essayé de comprendre en déboguant via l'IDE Delphi mais là problème ça marche normalement.

En résumé :
- Dans la majorité des cas "System.RaiseExceptionProc" est toujours appelé (en mode "debug" via Delphi et lors d'une lancement "standalone").
- Dans certains cas (je n'arrive pas à savoir lesquels précisément) "System.RaiseExceptionProc" n'est appelé qu'en mode "debug" via Delphi.


Dans mon cas de figure le problème se pose sur un gestionnaire "OnTimer", un code incorrect génère une violation d'acces qui déclenche une exception "EAccessViolation" sans appeler "System.RaiseExceptionProc" (sauf si en mode debug via l'IDE). Je précise que si je créé une exception "explicitement" avec un "raise Exception.Create(...);" dans ce même gestionnaire "OnTimer" alors "System.RaiseExceptionProc" est bien appelé.


Avez-vous une idée de la cause de ce comportement ?

Merci pour votre aide.

[Franck SORIANO]

Si on en croit l'aide en ligne, RaiseExceptionProc n'est qu'un pointeur sur la fonction de l'API Windows qui sert à déclencher une exception.

En modifiant ce pointeur, tu détournes toutes les fonctions qui passent par ce dernier pour déclencher une exception. Mais uniquement celles qui passent par lui.
Ca semble fonctionner pour tous ce qui vient de la VCL. Mais les exceptions qui sont déclenchées par du code tiers, ou même directement par le système (par exemple, les Access Violation sont détectés directement par le processeur) ne doivent pas être interceptées de cette façon.

Lorsque tu es en debug, Windows déclenche un événement au débogueur chaque fois qu'une exception se produit. De sorte que le débogueur voit toujours toutes les exceptions. Je ne serais pas étonné qu'ensuite il relaie l'exception à l'appli d'une façon qui passe par RaiseExceptionProc.

Si tu veux être notifié du déclenchement de l'exception, est-ce qu'il ne faut pas plutôt utiliser RaiseExceptObjProc ?

Personnellement, je me contente de JclDebug dans la Jcl. Il me semble qu'ils utilisent une autre approche qui consiste à injecter la fonction Windows.
Quoi qu'il en soit, JclDebug fait exactement ce que tu veux : Intercepter les exceptions qui déclenche en capturant la pile d'appel. Si tu disposes des infos de debogage, tu peux également décoder les adresses et connaitre la position correspondante dans les sources.

[ZZZzzz2]

Si on en croit l'aide en ligne, RaiseExceptionProc n'est qu'un pointeur sur la fonction de l'API Windows qui sert à déclencher une exception.

En modifiant ce pointeur, tu détournes toutes les fonctions qui passent par ce dernier pour déclencher une exception. Mais uniquement celles qui passent par lui.
Ca semble fonctionner pour tous ce qui vient de la VCL. Mais les exceptions qui sont déclenchées par du code tiers, ou même directement par le système (par exemple, les Access Violation sont détectés directement par le processeur) ne doivent pas être interceptées de cette façon.

Lorsque tu es en debug, Windows déclenche un événement au débogueur chaque fois qu'une exception se produit. De sorte que le débogueur voit toujours toutes les exceptions. Je ne serais pas étonné qu'ensuite il relaie l'exception à l'appli d'une façon qui passe par RaiseExceptionProc.

Si tu veux être notifié du déclenchement de l'exception, est-ce qu'il ne faut pas plutôt utiliser RaiseExceptObjProc ?

Personnellement, je me contente de JclDebug dans la Jcl. Il me semble qu'ils utilisent une autre approche qui consiste à injecter la fonction Windows.
Quoi qu'il en soit, JclDebug fait exactement ce que tu veux : Intercepter les exceptions qui déclenche en capturant la pile d'appel. Si tu disposes des infos de debogage, tu peux également décoder les adresses et connaitre la position correspondante dans les sources.

Merci pour ta réponse, et excuses-moi de te répondre aussi tardivement.

J'ai essayé également de surcharger "RaiseExceptObjProc" mais là encore la procédure n'est jamais appelé. Je pensais juste que "RaiseExceptProc" permettait d'intercepter tout type d'exception, il y a d'ailleurs un des arguments de son prototype qui détermine le type d'exception concerné... Il va donc falloir que je me rallie à ton explication, et donc me résigner au fait que je n'ai pas de moyen de récupérer la pile d'appels sur certaines exceptions bien particulières... (le cas reste heureusement rare). Je n'ai pas l'intention de modifier tout l'implémentation actuelle car cela prendrais trop de temps ;-).

[ZZZzzz2]

Merci pour ta réponse, et excuses-moi de te répondre aussi tardivement.

J'ai essayé également de surcharger "RaiseExceptObjProc" mais là encore la procédure n'est jamais appelé. Je pensais juste que "RaiseExceptProc" permettait d'intercepter tout type d'exception, il y a d'ailleurs un des arguments de son prototype qui détermine le type d'exception concerné... Il va donc falloir que je me rallie à ton explication, et donc me résigner au fait que je n'ai pas de moyen de récupérer la pile d'appels sur certaines exceptions bien particulières... (le cas reste heureusement rare). Je n'ai pas l'intention de modifier tout l'implémentation actuelle car cela prendrais trop de temps ;-).

Je me réponds à moi-même, bien plus tard car j'ai trouvé une solution qui consiste à utiliser l'API Windows "AddVectoredExceptionHandler". En effet celle-ci permet d'ajouter une gestionnaire d'exception au moment où celle-ci a lieu et fort heureusement ce gestionnaire est appelé pour les exceptions de type "violation d'accès". Je récupère donc la pile d'appels dans ce gestionnaire...
Il existe pas mal de liens sur Internet expliquant comment utiliser cette API avec Delphi donc je ne fournirai pas de détails ici je voulais juste indiquer qu'il existe une solution pour rattraper toutes les exceptions (perso j'ai combiné "RaiseExcepProc" avec "AddVectoredExceptionHandler" même si en définitif je pense que "AddVectoredExceptionHandler" est forcément appelé à partir du moment où on rentre dans "RaiseExcepProc"...)