Появилась в моем приложении утечка.... Помогите пожалуйста с ней разобратся: один кусочек из лога fastMM: Code: A memory block has been leaked. The size is: 10660 This block was allocated by thread 0x1038, and the stack trace (return addresses) at the time was: 402E80 [jpeg][jpeg][@GetMem] 405551 [acZLibEx][acZLibEx][@NewAnsiString] 40557C [acZLibEx][acZLibEx][@LStrFromPCharLen] 54CC9B [IdGlobal.pas][IdGlobal][BytesToString][5579] 54CDB6 [IdGlobal.pas][IdGlobal][ReadStringFromStream][5639] 55D4C8 [IdGlobalProtocols.pas][IdGlobalProtocols][ReadStringAsCharset][4271] 582786 [IdHTTP.pas][IdHTTP][TIdCustomHTTP.Post][820] 5A7582 [ThreadsUnit.pas][ThreadsUnit][FThread.LoginToSite][432] 5A8A5A [ThreadsUnit.pas][ThreadsUnit][FThread.Execute][792] 409DFF [JclCharsets][JclCharsets][FastFreeMem][4613] 40A495 [JclSysInfo][JclSysInfo][UpdateHeaderAndFooterCheckSums][6341] The block is currently used for an object of class: AnsiString The allocation number is: 485875 Current memory dump of 256 bytes starting at pointer address 7F621100: 01 00 00 00 A7 27 00 00 3C 21 44 4F 43 54 59 50 45 20 68 74 6D 6C 3E 0A 3C 68 74 6D 6C 20 6C 61 6E 67 3D 22 65 6E 22 3E 0A 20 20 20 20 3C 68 65 61 64 20 64 61 74 61 2D 6C 61 79 6F 75 74 2D 76 69 65 77 3D 22 73 69 6D 70 6C 65 22 3E 0A 20 20 20 20 20 20 20 20 20 20 20 20 3C 6D 65 74 61 20 68 74 74 70 2D 65 71 75 69 76 3D 22 43 6F 6E 74 65 6E 74 2D 54 79 70 65 22 20 63 6F 6E 74 65 6E 74 3D 22 74 65 78 74 2F 68 74 6D 6C 3B 20 63 68 61 72 73 65 74 3D 75 74 66 2D 38 22 20 2F 3E 0A 20 20 20 20 3C 74 69 74 6C 65 3E 54 72 61 66 66 69 63 20 45 78 63 68 61 6E 67 65 20 4C 69 76 65 3C 2F 74 69 74 6C 65 3E 0A 20 20 20 20 3C 6C 69 6E 6B 20 72 65 6C 3D 22 69 63 6F 6E 22 20 68 72 65 66 3D 22 2F 66 61 76 69 63 6F 6E 2E 69 63 6F 22 20 74 79 70 65 3D 22 69 6D 61 67 65 2F 78 2D . . . . § ' . . < ! D O C T Y P E h t m l > . < h t m l l a n g = " e n " > . < h e a d d a t a - l a y o u t - v i e w = " s i m p l e " > . < m e t a h t t p - e q u i v = " C o n t e n t - T y p e " c o n t e n t = " t e x t / h t m l ; c h a r s e t = u t f - 8 " / > . < t i t l e > T r a f f i c E x c h a n g e L i v e < / t i t l e > . < l i n k r e l = " i c o n " h r e f = " / f a v i c o n . i c o " t y p e = " i m a g e / x - idhttp создаются и убиваются в потоке то, что видно в memory dump'e это судя по всему ответ сайта, но непонятно откуда он там взялся, ведь я делаю примерно следующее Code: try http:=idhttp.create(nil); http.post(.....); finally freeandnil(http); end; т.е. память вроде бы освобождаю!
EurekaLog поможет найти точное место именно в твоем коде FreeAndNil вызывает тот же Free + ставит указатель в nil
402E80 [jpeg][jpeg][@GetMem] А это что? Я больше чем уверен что в блоке try ... finally end; еще что то выделяется или вне, в этом потоке.
Это выделяется память под результат запроса idhttp.post. я это делаю "не ручками", а это сам компонент делает. Читать нужно этот лог снизу вверх, мои (то, что я писал) действия только в файле ThreadsUnit.pas все остальное - готовое до меня и лезть туда не стоит Уже думаю может Indy переставить... у меня 10.5.2
Проблема решена! Возникала ситуация, когда менеджер потоков освобождал потоки, не делая "terminate", и тогда idhttp и все прочие компоненты не освобождались, а просто оставались висеть
По твоим словам TIdHTTP потока освобождался в его деструкторе и видимо ты забыл поставить потоку "FreeOnTerminate = true;" ...тогда причем тут это : Code: try http:=idhttp.create(nil); http.post(.....); finally freeandnil(http); end;
1) потоки использую TgsvThread, у них нету свойства FreeOnTerminate 2) все так и есть try...finally end;, не знаю почему, но память в этом месте не освобождалась. Убрал их "убийство" и все стало на свои места. 3) try..finally end; Это то место, куда меня вывели логи fastMM'a, я его и привел. Я действительно до сих пор не понимаю, почему память не освобождалась, но такое было