Czy pamięć zarezerwowana może spowodować wyjątek braku pamięci

Question

Mamy 32-bitową usługę Windows, która wycieka z pamięci - generowany jest wyjątek OutOfMemory. Jest to plik wykonywalny .net 4.0 uruchomiony na Windows Server 2003. Podczas debugowania plików zrzutu awaryjnego za pomocą WinDbg, widzę, że większość pamięci jest w rzeczywistości zarezerwowana i nie jest zatwierdzona.

Jak widać z WinDBG zrzucie istnieje 2,5 Gb niesklasyfikowanych zużycie pamięci, a większość z nich jest faktycznie 2,1 Gb zastrzeżone pamięci (MEM_RESERVE). Mam doświadczenie w debugowaniu zgniłych reklam, ale ten scenariusz jest dla mnie czymś nowym. MEM_COMMIT jest rzucić OK - 564,270 Mb udało wielkość sterty jest ABT 82 Mb

Ja również sprawdzone rodzimych stosy, aby zobaczyć, czy są duże ilości danych zakonserwowane, ale nie mógł znaleźć niczego podejrzanego nie bądź

Więc moje pytanie jest - czy to możliwe, że MEM_RESERVED może spowodować wyjątek OOM? Jeśli tak, jak mogę go debugować, zobacz dlaczego/jak ogromna ilość pamięci jest rezerwowana? Gdzie indziej szukać, co może być problemem?

Jeśli wymagane są inne informacje, poproś o to, a zaktualizuję mój wpis.

Answer 1

Tak, rezerwacja pamięci może uruchomić OutOfMemoryException. Spróbuj przydzielić kilka bardzo dużych tablic bajtowych. Pamięć dla nich nie zostanie zatwierdzona, dopóki nie napiszesz do zawartości tablic. Możesz jednak łatwo wyzwolić OOM przez przydzielenie tych tablic.

Nie znam szczegółów implementacji, ale ponieważ VirtualAlloc zawiedzie, jeśli nie może spełnić żądania rezerwy, zakładam, że CLR tłumaczy to na wyjątek. Nie rozumiem, w jaki sposób można przekształcić żądanie braku rezerwy w coś użytecznego, więc wyjątek stanowi rozsądny wybór.

Answer 2

OutOfMemoryException występuje, jeśli system nie może przydzielić więcej pamięci wirtualnej dla aplikacji. Pamięć zarezerwowana jest pamięcią wirtualną i dlatego obsługuje ten limit.

Można spróbować, że w C++ najbardziej prosty sposób:

while(::VirtualAlloc(NULL, 65536, MEM_RESERVE, PAGE_READWRITE) != NULL); 
std::cout << "All memory reserved. Now check with tools." << std::endl; 

Jeśli VirtualAlloc() zwraca NULL, to nie może przeznaczyć więcej memoy. W WinDbg będzie to pokazać

MEM_RESERVE 32307 7f6f2000 (1.991 Gb) 99.59% 99.56% 

Jednak VirtualAlloc() nie przydzielić pamięci na stercie, więc !heap nie jest przydatna w tym przypadku i pokazuje tylko kupa domyślny proces:

0:000> !heap 
Index Address Name  Debugging options enabled 
    1: 00440000 

To w inny sposób: heap mamanger używa VirtualAlloc(), aby uzyskać pamięć. Zauważ też, że .NET również nie używa menedżera sterty. Przydziela również pamięć bezpośrednio za pomocą VirtualAlloc(), a następnie zarządza nią samodzielnie. Tak więc, ponieważ można go zobaczyć na wyjściu z !heap, nie jest to problem .NET, jest to problem z natywną pamięcią.

W moim naiwnym zrozumieniu ustawienie gflags powinno być pomocne przy ustalaniu źródła przydziału sterty. Jednak moje oczekiwanie, że polecenie !heap -t po prostu wyświetli nazwę biblioteki DLL, która alokowała pamięć, nie spełniło się.