SASGIS - SAS.Планета |
View Issue Details |
|
ID | Project | Category | View Status | Date Submitted | Last Update |
0002735 | SAS.Планета | [All Projects] Баг | public | 29-05-2015 12:03 | 29-07-2015 13:32 |
|
Reporter | Fetser | |
Assigned To | vdemidov | |
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | not fixable | |
Platform | | OS | | OS Version | |
Product Version | .Nightly | |
Target Version | | Fixed in Version | | |
|
Summary | 0002735: "Out of memory" при экспорте меток в Debug версии |
Description | SAS.Planet.Nightly.150528.8771. При попытки экспорта большой базы sml (Например такой https://yadi.sk/d/qvC_xKUdgrcCT ) в kml или kmz программа закрывается с ошибкой.
Ошибка наблюдается только в дебажной версии, а релизная работает нормально. |
Steps To Reproduce | |
Additional Information | |
Tags | No tags attached. |
Relationships | related to | 0002745 | closed | vdemidov | Не работает экспорт меток в sml |
|
Attached Files | SASPlanet.Debug KML.elf (80,611) 29-05-2015 12:03 https://bugtracker.sasgis.org/file_download.php?file_id=1884&type=bug SASPlanet.Debug KMZ.elf (91,960) 29-05-2015 12:04 https://bugtracker.sasgis.org/file_download.php?file_id=1885&type=bug |
|
Issue History |
Date Modified | Username | Field | Change |
29-05-2015 12:03 | Fetser | New Issue | |
29-05-2015 12:03 | Fetser | File Added: SASPlanet.Debug KML.elf | |
29-05-2015 12:04 | Fetser | File Added: SASPlanet.Debug KMZ.elf | |
29-05-2015 12:30 | vdemidov | Note Added: 0015966 | |
29-05-2015 12:33 | Fetser | Note Added: 0015967 | |
29-05-2015 12:33 | zed | Note Added: 0015968 | |
29-05-2015 12:36 | vdemidov | Note Added: 0015969 | |
29-05-2015 12:40 | vdemidov | Note Added: 0015970 | |
29-05-2015 12:48 | zed | Note Added: 0015971 | |
29-05-2015 12:53 | Fetser | Note Added: 0015972 | |
29-05-2015 13:28 | vasketsov | Note Added: 0015973 | |
29-05-2015 13:30 | vasketsov | Note Edited: 0015973 | bug_revision_view_page.php?bugnote_id=15973#r6602 |
29-05-2015 14:26 | vasketsov | Note Added: 0015974 | |
29-05-2015 17:56 | zed | Note Added: 0015975 | |
29-05-2015 17:59 | zed | Note Edited: 0015975 | bug_revision_view_page.php?bugnote_id=15975#r6604 |
29-05-2015 18:08 | zed | Note Added: 0015976 | |
30-05-2015 09:50 | vasketsov | Note Added: 0015977 | |
30-05-2015 10:09 | zed | Note Added: 0015978 | |
31-05-2015 18:31 | zed | Note Added: 0015980 | |
31-05-2015 18:41 | zed | Summary | SAS.Planet.Nightly.150528.8771 ошибка при экспорте => "Out of memory" при экспорте меток в Debug версии |
31-05-2015 18:41 | zed | Description Updated | bug_revision_view_page.php?rev_id=6606#r6606 |
11-06-2015 12:55 | zed | Relationship added | related to 0002745 |
29-07-2015 13:32 | vdemidov | Note Added: 0016238 | |
29-07-2015 13:32 | vdemidov | Status | new => resolved |
29-07-2015 13:32 | vdemidov | Resolution | open => not fixable |
29-07-2015 13:32 | vdemidov | Assigned To | => vdemidov |
29-07-2015 13:32 | vdemidov | Status | resolved => closed |
Notes |
|
|
Ну что я могу сказать Out of memory оно и есть. До перехода на 64-битный компилятор (а это даже не планируется) вряд ли что-то изменится. Все данные программы должны влезать в 2 гигабайта. |
|
|
(0015967)
|
Fetser
|
29-05-2015 12:33
|
|
Categorymarks.sml + marks.sml = 140 Мб это уже так критично? |
|
|
(0015968)
|
zed
|
29-05-2015 12:33
|
|
Просто экспорт нужно делать по-умнее. Не строить дерево в памяти, а сделать итератор. |
|
|
|
Само дерево в памяти жрет совсем не много. Жрет и падает на создании XML при помощи парсера. |
|
|
|
> 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 гига памяти даже за вычетом уже использованного пространства. Лучше сразу использовать правильный целевой формат.
Но здесь проблема где-то рядом, около этого самого Упс.
|
|
|
|
>сделать итератор
Это конечно было бы совсем замечательно, если бы нашёлся доброволец, который бы сделал миграцию меток между двумя БД меток по типу менеджера кэша. |
|
|
(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. Релизная версия и дебажная версия без эврики работают нормально, а вот с эврикой идёт перерасход памяти. То ли там утечка, то ли это так много надо служебной информации для эврики, чтобы всё контролировать, но ноги растут оттуда. |
|
|
|
>виновата 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. |
|
|
|
Увы за диагностику в дебажной версии нужно платить. |
|