|
|
|
ну уловимые Memory Leaks
|
|||
|---|---|---|---|
|
#18+
TREYКвейд, logs А теперь ищи в логе записи типа авторThis block was allocated by thread 0xXXXX, and the stack trace (return addresses) at the time was: а под ними такой, например, трейс стека автор416DA7 [FastMM4.pas][FastMM4][FastMM4.DebugGetMem][8757] 416DD4 [FastMM4.pas][FastMM4][FastMM4.DebugGetMem][8777] 4DA8C9 [System.Classes][System][System.Classes.{System.Generics.Collections}TList<System.Classes.TCollectionItem>.Create] 4DA852 [System.Classes][System][System.Classes.{System.Generics.Collections}TList<System.Classes.TCollectionItem>.Create] 4BCE25 [System.Classes][System][System.Classes.TCollection.Create] 73ECD3 [uADStanOption.pas][uADStanOption][uADStanOption.TADMapRules.Create] [1170] 73EE52 [uADStanOption.pas][uADStanOption][uADStanOption.TADFormatOptions.Create][1255] который следует читать так: в модуле uADStanOption в 1255 строке твой говнокод создает класс TADFormatOptions, деструктор которого не удаляет список TList, который создает конструктор. Либо деструктор вообще не вызывается. Разберешься, сюда доложишь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 15:00 |
|
||
|
ну уловимые Memory Leaks
|
|||
|---|---|---|---|
|
#18+
Там на самом деле надо у FastMM размер стека увеличить, а то он не влезает полностью. Но что влезло - вот такое есть, к примеру: System.Classes.TStringList.Create uADStanOption.TADTxOptions.Create [5542] uADCompClient.TADCustomTransaction.InternalDeleteTxIntf [5303] uADCompClient.TADCustomTransaction.SetConnection [5218] Unit4.TSync.Execute [1683] System.Classes.ThreadProc Если предположить, кто код написан всё же правильно (т.е. есть очистка созданного TADStringList), то, вероятно, кто-то грохнул поток во время работы. Кстати, при этом также утечёт 1 Мб стека потока. Раз 500 грохнули поток - вот тебе минимум 500 Мб утечки (+ что ещё поток сам навыделял). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 15:05 |
|
||
|
ну уловимые Memory Leaks
|
|||
|---|---|---|---|
|
#18+
Квейд, КвейдuADStanOption в 1255 строке это исходники компонентов доступа к СУБД Разберешься, сюда доложишь. мне проще застрелиться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 15:54 |
|
||
|
ну уловимые Memory Leaks
|
|||
|---|---|---|---|
|
#18+
GunSmokerТам на самом деле надо у FastMM размер стека увеличить, а то он не влезает полностью. Но что влезло - вот такое есть, к примеру: System.Classes.TStringList.Create uADStanOption.TADTxOptions.Create [5542] uADCompClient.TADCustomTransaction.InternalDeleteTxIntf [5303] uADCompClient.TADCustomTransaction.SetConnection [5218] Unit4.TSync.Execute [1683] System.Classes.ThreadProc Если предположить, кто код написан всё же правильно (т.е. есть очистка созданного TADStringList), то, вероятно, кто-то грохнул поток во время работы. Кстати, при этом также утечёт 1 Мб стека потока. Раз 500 грохнули поток - вот тебе минимум 500 Мб утечки (+ что ещё поток сам навыделял). подправил , но поток синхронизации много не жрет DumpAllocationsToFile EurekaLog memory dump report (generated by EMemLeaks.DumpAllocationsToFile) EurekaLog Version : 7.6.6.35 RC 35 Executable : E:\_ISHODNIKI\PT\Win32\Release\ang.exe Counting : True Grouping : True Heuristic : True Filtering : False Sorting : True Custom sort : False Working Set Size : 218.61 MBytes / 229'232'640 bytes Peak Working Set Size : 287.99 MBytes / 301'981'696 bytes Paged Pool Size : 513.25 KBytes / 525'568 bytes Peak Paged Pool : 609.47 KBytes / 624'096 bytes Non-Paged Pool Size : 155.48 KBytes / 159'208 bytes Peak Non-Paged Pool : 436.32 KBytes / 446'796 bytes Pagefile Usage : 175.12 MBytes / 183'631'872 bytes Peak Pagefile Usage : 238.66 MBytes / 250'257'408 bytes Total Physical : 3.94 GBytes / 4'234'768'384 bytes Available Physical : 2.57 GBytes / 2'760'863'744 bytes Total Page File : 889.72 MBytes / 932'941'824 bytes Available Page File : 25.62 MBytes / 26'869'760 bytes Total Virtual : 2.00 GBytes / 2'147'352'576 bytes Available Virtual : 1.47 GBytes / 1'582'821'376 bytes Largest free block : 806.90 MBytes / 846'098'432 bytes ($1E049000) Total heap size : 34.01 MBytes / 35'659'232 bytes Committed heap size : 47.75 MBytes / 50'069'504 bytes ...total process : 16.29 MBytes / 17'079'784 bytes ...committed process: 31.37 MBytes / 32'890'880 bytes Heap-allocated memory blocks are: -= Memory usage statistics =- The below includes only memory allocated through EurekaLog MM-filter AllocSize (w/o overhead) : 7.96 MBytes / 8'347'526 bytes AllocCount (w/o overhead): 88'608 Max AllocSize (w/o o/h) : 13.55 MBytes / 14'208'598 bytes Max AllocCount (w/o o/h) : 88'800 AllocSize native : 11.31 MBytes / 11'863'800 bytes AllocCount native : 88'620 The below includes only memory allocated through EurekaLog MM-filter with registering memory leaks enabled: Allocated : none Named : none ...by block type: Objects : none Components : none Strings : none Arrays : none RAW : none ...by block size: XXSmall (< 10b): none XSmall (< 40b): none Small (< 100b): none Medium (< 1000b): none Large (< 10000b): none XLarge : none Largest allocated block: 0 bytes авторТам на самом деле надо у FastMM размер стека увеличить, а то он не влезает полностью. как это сделать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 15:56 |
|
||
|
ну уловимые Memory Leaks
|
|||
|---|---|---|---|
|
#18+
GunSmokerЕсли предположить, кто код написан всё же правильно (т.е. есть очистка созданного TADStringList), то, вероятно, кто-то грохнул поток во время работы. Кстати, при этом также утечёт 1 Мб стека потока. Раз 500 грохнули поток - вот тебе минимум 500 Мб утечки (+ что ещё поток сам навыделял). исключено я дожидаюсь окончания работы потока и убиваю его , если что то не так (except), у меня error лог пишеться , в нем пусто ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 16:03 |
|
||
|
ну уловимые Memory Leaks
|
|||
|---|---|---|---|
|
#18+
TREYавторТам на самом деле надо у FastMM размер стека увеличить, а то он не влезает полностью. как это сделать Код: pascal 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 16:16 |
|
||
|
ну уловимые Memory Leaks
|
|||
|---|---|---|---|
|
#18+
TREYисключеноGunSmokerUnit4.TSync.Execute [1683]Что за проблема, открыть модуль Unit4, перейти на строку 1683, найти какой объект создается и посмотреть где он должен уничтожиться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 16:17 |
|
||
|
ну уловимые Memory Leaks
|
|||
|---|---|---|---|
|
#18+
TREYDumpAllocationsToFile Не понял, а поиск утечек отключен, что-ли? Тут показывает, что память через EurekaLog не выделяется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 16:17 |
|
||
|
ну уловимые Memory Leaks
|
|||
|---|---|---|---|
|
#18+
_Vasilisk_TREYисключеноGunSmokerUnit4.TSync.Execute [1683]Что за проблема, открыть модуль Unit4, перейти на строку 1683, найти какой объект создается и посмотреть где он должен уничтожиться подправил , да , одна транзакция не убивалась , на суть не повлияло ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 16:22 |
|
||
|
ну уловимые Memory Leaks
|
|||
|---|---|---|---|
|
#18+
TREYподправил , да , одна транзакция не убиваласьНу а теперь тем же методом ищи остальные. Одну утечку мы тебе нашли - дальше сам ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 16:25 |
|
||
|
ну уловимые Memory Leaks
|
|||
|---|---|---|---|
|
#18+
такой вопрос .. если я убиваю/завершаю поток , чисто логически - разве все классы что были в нем созданы - не должны сами высвобождаться из памяти? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 16:35 |
|
||
|
ну уловимые Memory Leaks
|
|||
|---|---|---|---|
|
#18+
TREYтакой вопрос .. если я убиваю/завершаю поток , чисто логически - разве все классы что были в нем созданы - не должны сами высвобождаться из памяти?нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 16:36 |
|
||
|
ну уловимые Memory Leaks
|
|||
|---|---|---|---|
|
#18+
kealon(Ruslan), внезапно .. мне казалось что память в потоках выделяется по принципу [каскадного ключа] , типа дропнул главный класс , все остальное похерилось , или уборщик мусора сам собрал . это же логично , если главного потока больше нет , в созданный класс мертвого потока больше не добраться , зачем (какой смысл) эту срань в памяти держать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 16:48 |
|
||
|
ну уловимые Memory Leaks
|
|||
|---|---|---|---|
|
#18+
_Vasilisk_TREYподправил , да , одна транзакция не убиваласьНу а теперь тем же методом ищи остальные. Одну утечку мы тебе нашли - дальше сам осталось 19 тысяч ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 16:49 |
|
||
|
ну уловимые Memory Leaks
|
|||
|---|---|---|---|
|
#18+
GunSmokerTREYDumpAllocationsToFile Не понял, а поиск утечек отключен, что-ли? Тут показывает, что память через EurekaLog не выделяется. работает , я изучу логи несколько дней , дам свежую инфу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 16:50 |
|
||
|
ну уловимые Memory Leaks
|
|||
|---|---|---|---|
|
#18+
TREYэто же логично , если главного потока больше нет , в созданный класс мертвого потока больше не добраться , зачем (какой смысл) эту срань в памяти держать? Шта? Наводящие вопросы: - Кто должен освобождать эту память? ОС? RTL? Если ОС - как она узнает, как RTL выделяет память? Если RTL - как она узнает, что потока больше нет? - Как освобождатель узнает, что удалять память, выделенную потоком, должен (по плану) именно этот поток (т.е. поток не передавал эту память в другой поток)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 16:54 |
|
||
|
ну уловимые Memory Leaks
|
|||
|---|---|---|---|
|
#18+
GunSmoker, garbage collector ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 16:55 |
|
||
|
ну уловимые Memory Leaks
|
|||
|---|---|---|---|
|
#18+
TREY, наводящий вопрос №3: ты в Delphi пишешь или в .NET? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 16:56 |
|
||
|
ну уловимые Memory Leaks
|
|||
|---|---|---|---|
|
#18+
GunSmoker, конкретно как это реализовать мне не принципиально , можете посмотреть как это успешно работает в пхп например . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 16:58 |
|
||
|
ну уловимые Memory Leaks
|
|||
|---|---|---|---|
|
#18+
TREYGunSmoker, конкретно как это реализовать мне не принципиально , можете посмотреть как это успешно работает в пхп например .если бы это успешно работало, спецы по яве, например, были бы не нужны ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 17:02 |
|
||
|
ну уловимые Memory Leaks
|
|||
|---|---|---|---|
|
#18+
TREYkealon(Ruslan), внезапно .. мне казалось что память в потоках выделяется по принципу [каскадного ключа] , типа дропнул главный класс , все остальное похерилось , или уборщик мусора сам собрал . это же логично , если главного потока больше нет , в созданный класс мертвого потока больше не добраться , зачем (какой смысл) эту срань в памяти держать? "Зачем, смысл, стань"... Исправляй давай. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 17:06 |
|
||
|
ну уловимые Memory Leaks
|
|||
|---|---|---|---|
|
#18+
спасибо всем , еще прийду через пару дней ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 17:12 |
|
||
|
ну уловимые Memory Leaks
|
|||
|---|---|---|---|
|
#18+
TREYтакой вопрос .. если я убиваю/завершаю поток , чисто логически - разве все классы что были в нем созданы - не должны сами высвобождаться из памяти? Смотря как убиваешь и где они были созданы. Если созданы как внутренние переменные в Execute и ты прибиваешь поток по TerminateThread - не удалятся. Если созданы как поля класса потока и удаляются в деструкторе - то удалятся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2018, 10:56 |
|
||
|
|

start [/forum/topic.php?fid=58&startmsg=39655501&tid=2040749]: |
0ms |
get settings: |
6ms |
get forum list: |
15ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
208ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
2ms |
| others: | 213ms |
| total: | 512ms |

| 0 / 0 |
