You are not logged in.
Pages: 1
I have been using TSynLog with the following Levels:
TSynLog.Family.Level := [sllException,sllExceptionOS];
in a lot of different applications and it has saved me countless hours of debugging when hunting for hard to reproduce errors (so thank you!).
I am now running into an issue in a very large application where most of the code is loaded dynamically through BPLs.
I have narrowed it down to the Exception logger ending up in SynLog.GetInstanceMapFile, which then creates a new TSynMapFile without any parameters.
Therefore in the constructor it will locate the map file (fMapFile) by calling GetModuleName(hInstance).
Since this is always done in the context of the logger and from what I could find online, hInstance refers to the bpl that contains the logger and not the code where the Exception occurred.
Therefore it is never able to find the right map file unless it happens to be an exception located in the same package as the logger (which in my case is never).
Here is the full stack that gets me to TSynMapFile.Create:
Exception -> SynLog.SynRtlUnwind -> SynLog.LogExcept -> SynLog.SynLogException -> SynLog.TSynMapFile.Log -> SynLog.GetInstanceMapFile -> SynLog.TSynMapFile.Create
As a quick hack I changed GetModuleName(hInstance) to GetModuleName(GetModuleHandle(nil)) ensuring it will get the hInstance of the main exe, but that is obviously not a great solution.
Would you have any ideas as to how to tackle this?
Thank you!
Offline
Pages: 1