SASGIS - SAS.Планета
View Issue Details
0002735SAS.Планета[All Projects] Багpublic29-05-2015 12:0329-07-2015 13:32
Fetser 
vdemidov 
normalminoralways
closednot fixable 
.Nightly 
 
0002735: "Out of memory" при экспорте меток в Debug версии
SAS.Planet.Nightly.150528.8771. При попытки экспорта большой базы sml (Например такой https://yadi.sk/d/qvC_xKUdgrcCT ) в kml или kmz программа закрывается с ошибкой.

Ошибка наблюдается только в дебажной версии, а релизная работает нормально.
No tags attached.
related to 0002745closed vdemidov Не работает экспорт меток в sml 
? SASPlanet.Debug KML.elf (80,611) 29-05-2015 12:03
http://www.sasgis.org/mantis/file_download.php?file_id=1884&type=bug
? SASPlanet.Debug KMZ.elf (91,960) 29-05-2015 12:04
http://www.sasgis.org/mantis/file_download.php?file_id=1885&type=bug
Issue History
29-05-2015 12:03FetserNew Issue
29-05-2015 12:03FetserFile Added: SASPlanet.Debug KML.elf
29-05-2015 12:04FetserFile Added: SASPlanet.Debug KMZ.elf
29-05-2015 12:30vdemidovNote Added: 0015966
29-05-2015 12:33FetserNote Added: 0015967
29-05-2015 12:33zedNote Added: 0015968
29-05-2015 12:36vdemidovNote Added: 0015969
29-05-2015 12:40vdemidovNote Added: 0015970
29-05-2015 12:48zedNote Added: 0015971
29-05-2015 12:53FetserNote Added: 0015972
29-05-2015 13:28vasketsovNote Added: 0015973
29-05-2015 13:30vasketsovNote Edited: 0015973bug_revision_view_page.php?bugnote_id=15973#r6602
29-05-2015 14:26vasketsovNote Added: 0015974
29-05-2015 17:56zedNote Added: 0015975
29-05-2015 17:59zedNote Edited: 0015975bug_revision_view_page.php?bugnote_id=15975#r6604
29-05-2015 18:08zedNote Added: 0015976
30-05-2015 09:50vasketsovNote Added: 0015977
30-05-2015 10:09zedNote Added: 0015978
31-05-2015 18:31zedNote Added: 0015980
31-05-2015 18:41zedSummarySAS.Planet.Nightly.150528.8771 ошибка при экспорте => "Out of memory" при экспорте меток в Debug версии
31-05-2015 18:41zedDescription Updatedbug_revision_view_page.php?rev_id=6606#r6606
11-06-2015 12:55zedRelationship addedrelated to 0002745
29-07-2015 13:32vdemidovNote Added: 0016238
29-07-2015 13:32vdemidovStatusnew => resolved
29-07-2015 13:32vdemidovResolutionopen => not fixable
29-07-2015 13:32vdemidovAssigned To => vdemidov
29-07-2015 13:32vdemidovStatusresolved => closed

Notes
(0015966)
vdemidov   
29-05-2015 12:30   
Ну что я могу сказать Out of memory оно и есть. До перехода на 64-битный компилятор (а это даже не планируется) вряд ли что-то изменится. Все данные программы должны влезать в 2 гигабайта.
(0015967)
Fetser   
29-05-2015 12:33   
Categorymarks.sml + marks.sml = 140 Мб это уже так критично?
(0015968)
zed   
29-05-2015 12:33   
Просто экспорт нужно делать по-умнее. Не строить дерево в памяти, а сделать итератор.
(0015969)
vdemidov   
29-05-2015 12:36   
Само дерево в памяти жрет совсем не много. Жрет и падает на создании XML при помощи парсера.
(0015970)
vdemidov   
29-05-2015 12:40   
> Categorymarks.sml + marks.sml = 140 Мб это уже так критично?
Возможно. Грубо 140 * 2 = 280 Мб так как хранится в двух экземплярах в памяти - в виде датасета и объектов. Еще 140 Мб а то и больше на результат текста kml. И думаю где-то 140 * 2 Мб на представление xml дерева в виде парсера. Итого 700 Мб. Заметная часть от 2-х Гб.

Плюс советую проверить настройки кэша в памяти для тайлов. Он тоже может съедать дофига памяти.
(0015971)
zed   
29-05-2015 12:48   
А, в этом дело. Ну, может тогда переделать запись в kml без всяких там XMLDocument? Получится, конечно, не очень красиво, зато не будет отжирать память.
(0015972)
Fetser   
29-05-2015 12:53   
Немного цифр
версия SAСSPlanet 141221 при открытии этой базы заняла оперативки 224 Мб при экспорте в KMZ оперативки слопала 600 Мб с работой справилась
версия SASPlanet 150528 при открытии 365 Мб оперативки при экспорте потребление возросло до 1600 Мб после этого упала
(0015973)
vasketsov   
29-05-2015 13:28   
(edited on: 29-05-2015 13:30)
>До перехода на 64-битный компилятор (а это даже не планируется)
Если это та же самая база, на которой игрался я, а скорее всего так оно и есть, то в kml там всё залетает отлично, после того как я сегодня подчистил ссылку на MemStream для корректной смерти IBinaryData - и в kmz нормально экспортируется. EXE-ха x32 даже при сборке на Win 8.1 x64 XE2.
Экспорт в kml/kmz у нас идентичный (через Al).

>Итого 700 Мб
>оперативки слопала 600 Мб с работой справилась
Оценки вполне соответствуют друг другу, плюс-минус пол-лаптя.

>при экспорте потребление возросло до 1600 Мб
Упс.

>Не строить дерево в памяти, а сделать итератор
Есть подозрение, что в принципе не надо пытаться класть в kml то, что не влазит в 2 гига памяти даже за вычетом уже использованного пространства. Лучше сразу использовать правильный целевой формат.
Но здесь проблема где-то рядом, около этого самого Упс.

(0015974)
vasketsov   
29-05-2015 14:26   
>сделать итератор
Это конечно было бы совсем замечательно, если бы нашёлся доброволец, который бы сделал миграцию меток между двумя БД меток по типу менеджера кэша.
(0015975)
zed   
29-05-2015 17:56   
(edited on: 29-05-2015 17:59)
>после того как я сегодня подчистил ссылку на MemStream
Ну, в SAS оно там давно подчищалось.

>даже при сборке на Win 8.1 x64 XE2
Имею мнение, что важна только версия компилятора, но никак ни ОС, на которой происходит сборка.

>при экспорте потребление возросло до 1600 Мб после этого упала
А вот у меня такого не наблюдается. Экспортирует нормально, пиковое использование памяти ~ 750Мб. В простое около 300 Мб. При экспорте в kml, в пике было ~ 650Мб.

(0015976)
zed   
29-05-2015 18:08   
А, понял в чём причина. Во всём виновата Eurekalog. Релизная версия и дебажная версия без эврики работают нормально, а вот с эврикой идёт перерасход памяти. То ли там утечка, то ли это так много надо служебной информации для эврики, чтобы всё контролировать, но ноги растут оттуда.
(0015977)
vasketsov   
30-05-2015 09:50   
>виновата Eurekalog
Пришло время 7.2.3 Ent?
(0015978)
zed   
30-05-2015 10:09   
Если SACS не падает с той же эврикой, то надо разобраться. Не факт, что переход на новую версию тут поможет.
(0015980)
zed   
31-05-2015 18:31   
Да нет, и SACS ведёт себя аналогично - дебажной версии не хватает памяти, релизная работает нормально.

И самое интересное, что апгрейд эврики до версии 7.2.3 так же не помогает. Всё падает с Out of memory.

Если у эврики отключить слежение за утечками памяти, то всё это безобразие прекращается.

Вот что пишут в доках (для 7.x):

This technique generating the following limitations:

1. Enabling memory leak detection has little performance penalty (no more than about 5% for memory operations), because EurekaLog needs to build call stack for each memory allocation;

2. Enabling memory leak detection has little memory usage penalty (about 200 bytes for each memory allocation on x86-32 and about 400 bytes on x86-64);

3. Memory leak report automatically hides Assembler and CPU sections;

4. EurekaLog will not execute standard events during processing memory leak reports (this is because required resources was freed);

5. Call stack for memory leak is limited to 35 entries;

6. Memory leaks detection works only for standard Delphi's heap / memory manager (i.e. GetMem/FreeMem/ReallocMem); it can not find leaks with other memory managers (like HeapAlloc/HeapFree or VirtualAlloc/VirtualFree). Use resource leaks ability for that.

7. EurekaLog is unable to show human-readable call stack if DLL which created leak has been unloaded (this limitation is applicable only for applications with installed shared memory manager).

8. If you use shared memory manager - you must compile all modules with same memory manager settings. If you don't use shared memory manager - there is no additional limitations.

9. (C++ Builder only) "Dynamic RTL" is not supported in C++ Builder. If you enable "Dynamic RTL" option - EurekaLog's memory features will be disabled.
(0016238)
vdemidov   
29-07-2015 13:32   
Увы за диагностику в дебажной версии нужно платить.