Dlaczego funkcja _CrtSetBreakAlloc nie może wywołać punktu przerwania?

Question

Używam procedur wykrywania wycieków pamięci Visual CRT od <crtdbg.h>; gdy zgłoszę _CrtDumpMemoryLeaks jeden przydział jest zgłaszane konsekwentnie na każdym wywołaniu programu:

{133} normal block at 0x04F85628, 56 bytes long. 
Data: <    > B0 81 F8 04 B0 81 F8 04 B0 81 F8 04 CD CD CD CD 

Adres zmienia ale {133} jest zawsze taka sama.

Według instrukcji MSDN dotyczących How to set breakpoints on memory allocation number, powinienem być w stanie ustawić punkt przerwania na 133. alokacji z tej rozmowy:

_CrtSetBreakAlloc(133); 

i mogę też sprawdzić w oknie zegarka że {,,msvcr90d.dll}_crtBreakAlloc rzeczywiście jest ustawiony na 133 Po zakończeniu programu raport o wycieku nadal zawiera numer 133 (wraz z pewnymi wyższymi liczbami), ale nie występuje punkt przerwania. Dlaczego może to być i jak uzyskać punkt przerwania?

Potencjalnie istotne informacje:

1. VS2008, przy użyciu „wielowątkowe debugowania DLL” CRT
2. Moje kodu jest DLL, który jest ładowany przez produkt innej firmy
3. „normalne” wartości graniczne działa dobrze; krok po kroku działa dobrze; __asm int 3 też działa dobrze.
4. Żadna inna wartość dla _crtBreakAlloc powoduje przerwania albo (nie te Próbowałem tak)

5. 133 jest najniższy numer w raporcie szczelności

Answer 1

Główne czoło bicie ... One „oczywiste "powodem jest to, że przydział nr 133 wystąpił przed punkt przerwania został ustawiony ...

Po prostu pierwszy wyciek wystąpi zanim moja biblioteka DLL zostanie wywołana. W rzeczywistości niekoniecznie jest to wyciek, ponieważ nazywam się _CrtDumpMemoryLeaks, gdy biblioteka DLL jest rozładowywana - nie wtedy, gdy aplikacja nadrzędna jest deinicjalizowana.

chodzi o „potencjalnie istotnych informacji # 4” w moim oryginalne pytanie - dobrze zrobiłem spróbować kilka wartości, ale jakoś żadna nie była wyższa niż 133 ...

Answer 2

Brzmi to może być kompilowania aplikacji z biblioteka bez debugowania, np. jeśli używasz wersji Release biblioteki, która powinna uszkodzić twoją aplikację, nie zrobi tego. Możliwe, że tak się dzieje, ponieważ używasz aplikacji innej firmy. Jest również możliwe, że biblioteka debugowania bez debugowania zostanie załadowana zamiast debugera w środowisku wykonawczym.

Postaraj się sprawdzić, czy odpowiednie biblioteki DLL są załadowane do Twojej aplikacji podczas debugowania, a także czy aplikacja lub biblioteka DLL jest rzeczywiście debugowana. (Czasami jawnie trzeba załadować DLL i EXE do debuggera.)

To wszystko, co mogę myśleć, nie widząc więcej szczegółów na ten temat ...