Well, I hope anyone can exploit this information (I believe I found out the cause) :
if I use only MemCheck, without EurekaLog, the units finalization sequence is changed with respect to the units initialization sequence. Similarly if I use only EurekaLog without MemCheck. So, when I use both of them, each of them changes the sequence without knowing the other one does it and so the result is a bad finalization sequence, with SysUtils AFTER System . However, thanks to everyone. ----- Original Message ----- From: mauro russo To: [email protected] Sent: Thursday, June 11, 2009 7:39 PM Subject: Re: [delphi-en] Units finalization sequence Dear, I found out, the initialization unit sequence is SysInit System Types Windows ELeaks SysConsts SysUtils Messages ActiveX VarUtils Variants ..... MemCheck ... but the finalization unit sequence is : ... VarUtils ActiveX Messages SysConsts Windows Types SysInit MemCheck System Variants SysUtils ELeaks Note that I use the MemCheck code unit and also EurekaLog. Do using together generate known problems? Regards, Mauro. ----- Original Message ----- From: "mauro russo" <[email protected]> To: "delphi-en" <[email protected]> Sent: Thursday, June 11, 2009 3:23 PM Subject: [delphi-en] Units finalization sequence Dear all, I use Delphi 7.0 [Version 8.1]. I am having a problem: A my multi-thread application which worked for long time, sometimes had some fault and in the last period I could clearly note a memory corruption in a particular simple condition [I can replay it but I still did not find the cause]. Now, my application is having the following behavior: I just open it and then close it quite soon, just closing the main and only one generated form, so before any thread, except the main one, starts. On closing, I found out the following finalization units sequence [the last three] System [third last] Variant [second last] SysUtils [last] On finalization of SysUtils, the last call DoneExceptions generates an exception. It is on trying to execute the code OutOfMemory.AllowFree := True; I noted, since after starting the Application, that the address of variable OutOfMemory [EOutOfMemory type] is $511277D8, containing the pointer-value $0112042C. In fact, in the memory around [after] $0112042C I can note the string 'Out of memory'. Well, I found out that when the finalization of the unit System calls UninitAllocator, its code bd := spaceRoot.next; while bd <> @spaceRoot do begin VirtualFree(bd.addr, 0, MEM_RELEASE); bd := bd.next; end; is such that the memory-address $0112042C is ruled out from the memory space of my Application [in fact also the watch expression PInteger($112042C) switches to return 'Inaccessible value']. So, when the instruction "OutOfMemory.AllowFree := True;" tries to access to the bytes around $0112042C, it fails determining an access violation [really, also the function ntdll.KiUserExceptionDispatcher fails to work]. So, the question is: 1) Do you believe it is normal the finalization sequence System/Variants/SysUtils ? 2) If yes, do you believe the code calling VirtualFree should not rule out the memory of OutOfMemory variable? While I wait your answers, I will try to check if there is some previous corruption on spaceRoot chain. Thansk for any help. ---------- Questa email è stata verificata dal sistema centralizzato antivirus della UniPlan Software [Non-text portions of this message have been removed] ------------------------------------ ----------------------------------------------------- Home page: http://groups.yahoo.com/group/delphi-en/ To unsubscribe: [email protected]! Groups Links ---------- Questa email è stata verificata dal sistema centralizzato antivirus della UniPlan Software [Non-text portions of this message have been removed] ---------- Questa email è stata verificata dal sistema centralizzato antivirus della UniPlan Software [Non-text portions of this message have been removed]
