Delphi 2009: W jaki sposób zapobiec wyciekaniu krytycznej sekcji z aplikacji sieciowej?

Question

W ramach certyfikacji Vista, Microsoft chce mieć pewność, że wychodzi aplikacji bez trzymając się zamka (punkt krytyczny):

TEST CASE 31. Verify application does not break into a debugger with the specified AppVerifier checks (Req:3.2)

Jak się okazuje, aplikacje sieciowe zbudowane przy użyciu Delphi 2009 ma włamać się do debugger, który wyświetla pomocny komunikat następująco:

(1214.1f10): Break instruction exception - code 80000003 (first chance) 
eax=00000001 ebx=07b64ff8 ecx=a6450000 edx=0007e578 esi=0017f7e0 edi=80000003 
eip=77280004 esp=0017f780 ebp=0017f7ac iopl=0   nv up ei pl zr na pe nc 
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b    efl=00000246 
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Windows\SysWOW64\ntdll.dll - 
ntdll!DbgBreakPoint: 
77280004 cc    int  3 

Po naciśnięciu przycisku przejść kilka razy, można natknąć się na rzeczywistej błędu:

======================================= 
VERIFIER STOP 00000212: pid 0x18A4: Freeing virtual memory containing an active critical section. 

    076CC5DC : Critical section address. 
    01D0191C : Critical section initialization stack trace. 
    075D0000 : Memory block address. 
    00140000 : Memory block size. 


======================================= 
This verifier stop is continuable. 
After debugging it use `go' to continue. 

======================================= 

Biorąc pod uwagę, że mój kod nie wycieka TCriticalSection, w jaki sposób zapobiec temu Delphi.

Answer 1

Indy10 celowo wycieka krytyczne sekcje po wyjściu.

IdStack.pas:

finalization 
    // Dont Free. If shutdown is from another Init section, it can cause GPF when stack 
    // tries to access it. App will kill it off anyways, so just let it leak 
    {$IFDEF IDFREEONFINAL} 
    FreeAndNil(GStackCriticalSection); 
    {$ENDIF} 

IdThread.pas:

finalization 
    // This call hangs if not all threads have been properly destroyed. 
    // But without this, bad threads can often have worse results. Catch 22. 
// TIdThread.WaitAllThreadsTerminated; 

    {$IFDEF IDFREEONFINAL} 
    //only enable this if you know your code exits thread-clean 
    FreeAndNil(GThreadCount); 
    {$ENDIF} 

1. skopiować te dwa pliki z %delphi_home%\source\Indy\Indy10\System i %delphi_home%\source\Indy\Indy10\Core do swojego projektu lub zawierają je w ścieżce wyszukiwania.
2. Przebuduj z IDFREEONFINAL lub usuń dyrektywy IFDEF.

Answer 2

Skąd wiesz, że Twój kod nie jest coś wycieka, chyba że został uruchomiony z ReportMemoryLeaksOnShutdown := True lub FastMM4 w FullDebugMode złapać wszystkie memoryleaks (kod i biblioteki Delphi)?
Uruchamianie aplikacji w trybie FullDebugMode umożliwiłoby również śledzenie StackTrace dla nieprzydzielonych przydziałów pamięci.
Prawdopodobnie okaże się, że rzeczywiście przeciekasz w Sekcji Krytycznej IdStack.

Możesz rzucić okiem na tę sesję CodeRage 2: Fighting Memory Leaks for Dummies. Pokazuje głównie jak używać FastMM do zapobiegania/wykrywania wycieków pamięci w Delphi. Był dla D2007, ale nadal ma znaczenie dla D2009.