Вобщем нашел я причину и место утечки, и что самое хорошее в этой ситуации, так это то, что зная про это место утечки, этой утечки легко избежать. Детальная трассировка в отладчике выявила следующее:
При объявлении функции
- Код: Выделить всё
Declare Function FindFirst Lib "kernel32.dll" Alias "FindFirstFileW" _
(ByVal lpFileName As WString, ByRef lpFindFileData As WIN32_FIND_DATAW) As Long
И последующем вызове объявленной функции
- Код: Выделить всё
sTemp = swDirectory & "*"
hSearch = FindFirst(sTemp, DirInfo)
Происходит следующее: Так как передача параметра объявлена ByVal, компилятор делает копию строки, получает указатель на эту копию и упаковывает его в стек. В дальнейшем вызывается фукция WinApi, после возврата из которой, процесс как ни в чем не бывало продолжает свое выполнение, при этом совершенно забывая, про существование копии строки в памяти и совершенно естественно, что благополучно про неё забыв, функцию SysFreeString для нею не вызывает. Таким образом строка так и остается висеть в памяти. И повторяясь раз за разом эта ситуация накапливает уйму висячих (по чем совершенно зря) в памяти строк, тем самым расходуя эту память снова и снова.
Потестил и VB, который в принципе делает то же самое, только в отличии от PB, не забывает о произведенной копии, и после вызова функции своевременно освобождает память не вызывая утечек.
Таким образом зная про это обстоятельство избежать утечки можно, но при этом надо строить вызов так, что-бы избежать образования копии. Таким образом если в объявлении, объявить передачу аргумента
ByRef, а при вызове вызывать так
ByVal StrPtr(sTemp), то безымянной копии не образуется, WinApi, получает указатель на существующую строку sTemp, про которую компилятор всегда помнит и не забывает вставить для неё вызов SysFreeString и таким образом все в ажуре
Тест на утечку.rar
