Pliki DLL x64

[beherit]

Gdy skompiluję bibliotekę DLL pod 64 bity to sprawdzając plik w Dependency Walker widzę masę błędów (widoczne na zrzucie ekranu):

Sama biblioteka działa, jedynie co zaobserwowałem to wyciek pamięci po stronie aplikacji, gdzie jest ona ładowana. Źródeł nie daję bo nie ma tam praktycznie nic poza DllEntryPoint i 3 pozostałymi widocznymi prockami na zrzucie ekranu (procki puste). Pytanie: co jest nie tak, że Dependency Walker wywala masę błędów? Kompilator praktycznie nie ustawiłem, wyłączyłem tylko 2 opcje umożliwiające uruchamianie plików na maszynach bez RAD Studio. Swoją drogą da się wywalić prockę CPPdebugHook?

[polymorphism]

A z innymi 64-bitowymi DLL-kami też tak jest, czy tylko z Twoimi?

[beherit]

Wyciek nie występuje, gdy biblioteka jest napisana w Delphi, niestety nikt inny nie pisze DLLek w C++ pod tą aplikację. Wyciek to mało ważna sprawa w sumie bo na moim testowym projekcie takowego nie ma. Dziwi mnie tylko to, że Dependency Walker zgłasza błędy - w bibliotekach napisanych w Delphi (też RAD Studio XE3) takiego czegoś nie ma, zamiast np. "KERNEL32" jest "KERNEL32.DLL". Dziwne...

[beherit]

Odświeżam problem, teraz już wiem jak wygląda dokładnie ten wyciek. Plik DLL kompiluję pod x64, jak ładuję i wyładowuję DLLkę to widzę wyciek w w Private Bytes (w Menedżerze zadań to "rozmiar przekazywania") na około ~100-400MB, zużycie w WS Private i Working Set zwalnia się prawidłowo. Poniżej zamieszczam link do źródeł:

http://dl.dropbox.com/u/29031563/Test64.rar

Nie wiem jak rozwiązać ten problem

[polymorphism]

W tej DLL-ce niewiele w sumie jest, więc nie wiem, co tam miałoby wyciekać. Być może z samym komunikatorem lub jego SDK coś jest nie tak. Z drugiej strony wyłapywanie wycieków poprzez menedżera zadań jest średnim pomysłem.

[beherit]

W innej aplikacji ten sam plik DLL też ma wyciek, nawet badając plik DLL w windbg wywala to samo.

[polymorphism]

Tutaj raczej niewiele zrobisz, bo w DLL-ce Twojego kodu praktycznie nie ma - nie tam ma nic, co mogłoby generować wyciek (z tego co widzę API wtyczki jest w C i nic poza definicjami tam nie ma). Jedyna opcja to załączone biblioteki. VCL może, trudno powiedzieć.

[beherit]

Sprawdziłem plik DLL bez SDK komunikatora, po prostu zwykła DLLka z samym DllEntryPoint. Efekt ten sam, jest wyciek. Bez bibliotek VCL jest to samo.

[polymorphism]

Nie chce mi się wierzyć, żeby kompilator generował trefną DLL-kę. Już bardziej prawdopodobne jest to, że wycieku po prostu nie ma.

Po chwili...

Avira krzyczy, że biblioteka ma wirusa (na VirusTotal tylko Avira ma detekcję, więc może to tylko fałszywy alarm).

[beherit]

Jak nie wierzysz to załaduj DLLkę w programie, wystarczy LoadLibrary, potem zwolnienie i ponowne załadowanie... Mi też się nie chce wierzyć ale problem potwierdza również i inna osoba mająca C++Builder XE3.

[polymorphism]

Nie załaduje, bo działam na systemie 32-bitowym, a DLL-ka, jak rozumiem, jest na platformę 64-bitową.

[Cyfrowy Baron]

Avira krzyczy, że biblioteka ma wirusa (na VirusTotal tylko Avira ma detekcję, więc może to tylko fałszywy alarm).

Przeskanowałem ją programem Kaspersky Internet Security 2013 z aktualną bazą danych i antywirus nie wykrył mi żadnego wirusa.

[beherit]

Rozumiem, że nikt nie ma pomysłów dlaczego tak się dzieje

[Cyfrowy Baron]

Systemy 64-bitowe są stosunkowo nowe i jeszcze nie weszły do powszechnego użytku. Ja wciąż pracuję na WinXP 32-bit i póki co nie odczuwam potrzeby przejścia na inny system. Bierze się to z tego, że wciąż uważam WinXP za najlepszy system na PC jaki dotychczas powstał.

Nie jesteś jednak odosobniony z tym problemem i nie występuje on tylko w C++Builder, gdyż wiele osób ma ten sam problem np. w VC++ http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/a23de0ee-e803-455e-b43f-0900b50eb2a3/.

Wpisz w Google hasło: Google: programming dll 64-bit memory leak - zobaczysz ile tego jest

[polymorphism]

Ciekawa sprawa, ale coś nie chce mi się wierzyć, żeby w systemie był taki katastrofalny błąd, tym bardziej że mowa o systemie 64-bitowym, który póki co jest systemem do zastosowań bardziej specjalistycznych, np. serwerowych.