- madExceptViewer doesn't obey to ReportLeaksNow
Re: - madExceptViewer doesn't obey to ReportLeaksNow
$1508 = 5384. I'm pretty sure that you misread the thread ID in the debugger. It's probably straight decimal there, not hex. So the thread ID matches. How about the callstack? Does it match the forced leak? I don't know why the leak is only reported once, though. And no, there's no debug log or anything else that would help to get to the bottom of the problem. I would have to debug what's happening in the Delphi debugger, with the madExcept32.dll being the debugged process.
-
- Posts: 14
- Joined: Sun Dec 28, 2014 12:30 pm
Re: - madExceptViewer doesn't obey to ReportLeaksNow
Sure, you are right, I'm very glad.$1508 = 5384. I'm pretty sure that you misread the thread ID in the debugger. It's probably straight decimal there, not hex. So the thread ID matches.
The forced leak is in "GwIbUdf_L.dll" (alias MyUdfs.dll), in unit "LwIbUdf.pas", in function "MakePLongwordResult". So the callstack of the unique reported TStringList leak doesn't match at all. It rather matches initialization of "System" used by my dll.How about the callstack? Does it match the forced leak?
Before considering how the phenomenon could be reproduced by you, I think about coherence between madExcept I use and Delphi XE8 installed recently, on May 26, 2015. Of course, after XE8 install madCollection was uninstalled and reinstalled.
I notice that my
"C:\Program Files (x86)\madCollection\madExcept\Dlls\madExcept32.dll" has:
- version 4.0.5.0,
- last Modified on 20 April 2015, 20:50:59,
- with Size, not "Size on Disk", 1.07MB (1 131 992 bytes)
Meanwhile, your site mentions madExcept version 4.0.12 as XE8 enabled. Is that all right?
The madCollection.exe installed on my system has version 2.7.11.1
Re: - madExceptViewer doesn't obey to ReportLeaksNow
The madExcept32.dll has its own version number, so that's alright. The size and version number is correct.