View Issue Details

IDProjectCategoryView StatusLast Update
0001908SAS.ПланетаБаг / Bugpublic15-06-2013 16:00
ReporterPapazol Assigned Tozed  
PrioritynormalSeverityminorReproducibilityhave not tried
Status resolvedResolutionfixed 
PlatformWindowsOSXPOS VersionProfessional SP3
Product Version.Nightly 
Target Version131111Fixed in Version131111 
Summary0001908: Ошибка при открытии кэша Беркли
DescriptionЕсть ряд снимков DG, скачанных давно и упакованных в базу данных Беркли. Ночная сборка 7253 не открывает ни один из этих снимков и даёт ошибку. Другие кэши работают нормально.
Steps To Reproduce1. С помощью релиза 20121010 копирую один из снимков в другой кэш типа SASPlanet (т. е. тайловый).
2. Делаю zmp для работы с этим кэшем.
3. Проверяю его работоспособность на релизе.
4. Выделяю один тайл на z15 и копирую z15-z17 в новое место с изменением типа кэша на Беркли.
5. Делаю zmp для работы уже с этим кэшем.
6. Проверяю его работоспособность на релизе.
4. Делаю полигон, чтобы можно было найти нужное место. Экспортирую его в kmz.
5. Создаю новую папку, в которую распаковываю содержимое архива с ночной сборкой 7253.
6. Кидаю созданный тестовый кэш в папку \SASPlanet\cache_db\DG.
7. Кидаю zmp для соответствующего кэша в папку \SASPlanet\Maps\sas.maps.
8. Открываю программу 7253 (Debug). Никакие настройки не изменяю. По умолчанию устанавливается Гугль. Отменяю режим "Интернет и кэш".
9. Импортирую kmz с границами снимка. Вывожу его на экран.
10. Открываю карту, соответствующую тестовому кэшу.
11. Возникает ошибка.
12. Закрываю программу.
13. Упаковываю кэш, zmp и kmz в архив и кладу его на файлообменник.
Ссылка: http://rghost.ru/45624129
TagsNo tags attached.
Attached Files
DB_CONFIG (664 bytes)   
set_flags DB_TXN_WRITE_NOSYNC on
set_lg_dir .
set_data_dir ..
set_cachesize 0 2097152 1
mutex_set_max 30000
set_lg_max 10485760
set_lg_bsize 2097152
log_set_config DB_LOG_AUTO_REMOVE on

set_verbose DB_VERB_DEADLOCK
set_verbose DB_VERB_FILEOPS
set_verbose DB_VERB_FILEOPS_ALL
set_verbose DB_VERB_RECOVERY
set_verbose DB_VERB_REGISTER
set_verbose DB_VERB_REPLICATION
set_verbose DB_VERB_REP_ELECT
set_verbose DB_VERB_REP_LEASE
set_verbose DB_VERB_REP_MISC
set_verbose DB_VERB_REP_MSGS
set_verbose DB_VERB_REP_SYNC
set_verbose DB_VERB_REP_SYSTEM
set_verbose DB_VERB_REPMGR_CONNFAIL
set_verbose DB_VERB_REPMGR_MISC
set_verbose DB_VERB_WAITSFOR 
DB_CONFIG (664 bytes)   
SASPlanet.Debug.elf (63,654 bytes)
msg.log (4,633 bytes)
stat_m.txt (2,696 bytes)   
264KB	Total cache size
1	Number of caches
1	Maximum number of caches
264KB	Pool individual cache size
0	Maximum memory-mapped file size
0	Maximum open file descriptors
0	Maximum sequential buffer writes
0	Sleep after writing maximum sequential buffers
0	Requested pages mapped into the process' address space
308	Requested pages found in the cache (98%)
6	Requested pages not found in the cache
252	Pages created in the cache
6	Pages read into the cache
264	Pages written from the cache to the backing file
4	Clean pages forced from the cache
15	Dirty pages forced from the cache
0	Dirty pages written by trickle-sync thread
239	Current total page count
239	Current clean page count
0	Current dirty page count
37	Number of hash buckets used for page location
37	Number of mutexes for the hash buckets
4096	Assumed page size used
1926	Total number of times hash chains searched for a page
8	The longest hash chain searched for a page
0	Total number of hash chain entries checked for page
0	The number of hash bucket locks that required waiting (0%)
0	The maximum number of times any hash bucket lock was waited for (0%)
0	The number of region locks that required waiting (0%)
0	The number of buffers frozen
0	The number of buffers thawed
0	The number of frozen buffers freed
273	The number of page allocations
38	The number of hash buckets examined during allocations
2	The maximum number of hash buckets examined for an allocation
19	The number of pages examined during allocations
1	The max number of pages examined for an allocation
0	Threads waited on page I/O
0	The number of times a sync is interrupted
Pool File: I:\SASPlanet\cache\DG\DG Рязань 2002\z16\19\10\78.40.sdb
1024	Page size
0	Requested pages mapped into the process' address space
64	Requested pages found in the cache (96%)
2	Requested pages not found in the cache
51	Pages created in the cache
2	Pages read into the cache
55	Pages written from the cache to the backing file
Pool File: I:\SASPlanet\cache\DG\DG Рязань 2002\z15\9\5\39.20.sdb
1024	Page size
0	Requested pages mapped into the process' address space
20	Requested pages found in the cache (90%)
2	Requested pages not found in the cache
14	Pages created in the cache
2	Pages read into the cache
18	Pages written from the cache to the backing file
Pool File: I:\SASPlanet\cache\DG\DG Рязань 2002\z17\39\20\156.81.sdb
1024	Page size
0	Requested pages mapped into the process' address space
224	Requested pages found in the cache (99%)
2	Requested pages not found in the cache
187	Pages created in the cache
2	Pages read into the cache
191	Pages written from the cache to the backing file
stat_m.txt (2,696 bytes)   

Activities

zed

28-04-2013 16:33

manager   ~0011268

Не поверите, но у меня всё работает. Опять.

Но у вас в sdb.log я вычитал вот такую ошибку:
>EBerkeleyDBExeption: Error #2: No such file or directory
что говорит о том, что SAS скорее всего не может получить доступ к какому-то файлу или каталогу.

Чтобы точнее определить, в чём загвоздка, удалите из папки env все файлы кроме лога (log.0000000001) и положите в него DB_CONFIG из аттача.
Затем запустите SAS, словите ошибку, закройте SAS и приложите сюда файл msg.log из папки cache_db\DG\.

Можете и сами посмотреть в тот лог и проверить, чтобы у SAS был доступ на запись во все папки и ко всем файлам, к которым происходит обращение в том логе.

Papazol

28-04-2013 16:51

reporter   ~0011269

Сделал как написано. И кэш стал открываться. Файл msg.log не создан. При закрытии программы ошибка есть. Эльф прилагаю.

zed

28-04-2013 16:57

manager   ~0011270

>И кэш стал открываться.
О, значит была проблема с теми файликами что удалили. Попробуйте запустит не удаляя их, а только заменив DB_CONFIG (кэш возьмите из того архива, что приаттачили). Интересно, что напишет в лог.

>Файл msg.log не создан.
Точно в папке DG смотрели? Должен быть по-любому (с тем DB_CONFIG, что я приложил). Либо действительно чехарда с правами на запись.

>При закрытии программы ошибка есть. Эльф прилагаю.
В аттаче только утечка памяти, и то, кэш Беркли там не светится, так что течёт что-то другое.

Papazol

28-04-2013 17:12

reporter   ~0011271

При замене только файла DB_CONFIG (я правильно понял, что файл без расширения надо удалить, а с расширением .txt туда положить?) тайлы открываться перестали, однако лог всё равно не создаётся. Я просмотрел все близлежащие папки. Зато в sdb.log появилась ещё одна запись. Какой-то папки или файла не может найти, но какой - непонятно.

zed

28-04-2013 17:15

manager   ~0011272

>а с расширением .txt
Не должно быть никакого расширения у этого файла.

Papazol

28-04-2013 17:47

reporter   ~0011273

Last edited: 28-04-2013 17:53

Вот теперь что-то нарисовалось. Файл лога создался. Судя по нему, программа хотела открыть файл, созданный релизом из тайлового кэша, но которого по такому пути нет. Почему его нет - понятно, это при копировании создалась лишняя папка, из которой я всё перенёс в корень. Получается, что так делать нельзя. Но остальные подобные кэши почему не открываются? Они ведь никуда не копировались, а создавались из тайловых менеджером кэша.

zed

28-04-2013 18:30

manager   ~0011274

Проблема в том, что в файле лога log.0000000001 остался абсолютный путь к кэшу. Когда-то давно, этот баг был пофикшен и теперь в файлах лога сохраняются только относительные пути. Вот вы видимо на этот баг и напоролись, используя релиз.

Для того, чтобы заработали те остальные кэши из релиза, нужно воспользоваться утилитой sdb_util и выполнить действие Reset LSN, с автоматическим удалением содержимого папки env. После этого, ночнушка подхватит кэш как положено.

zed

28-04-2013 18:54

manager   ~0011275

Last edited: 28-04-2013 18:57

И проблема даже не в самом файле лога, а в файле __db.005, в котором хранится кэш открытых страниц (mem pool) и в котором так же прописаны абсолютные пути к файлам БД (в релизе). Из-за этого и падает с ошибкой. Но ноги растут из того же бага, с абсолютными путями. Просто в файле лога эта ошибка не столь критична, как в файлах __db.xxx.

Papazol

28-04-2013 18:59

reporter   ~0011276

Проделал я сброс LSN со всеми "плохими" кэшами. Но это не помогло. Всё то же самое. Хотелось бы лог создать для них, посмотреть хоть, куда программа ломится.

Кроме того, я не могу упаковать обратно в БД тайловый кэш, который я из БД вытащил. Там-то не может быть никаких лишних путей.

Если произошла утечка памяти, компьютер следует перезагрузить, или не обязательно?

zed

28-04-2013 19:06

manager   ~0011277

>Проделал я сброс LSN со всеми "плохими" кэшами. Но это не помогло.
Т.е. папка env удалилась, вы запустили ночнушку и ничего?

>Хотелось бы лог создать для них, посмотреть хоть, куда программа ломится.
ПолОжите файлик DB_CONFIG - увидите.

>Кроме того, я не могу упаковать обратно в БД тайловый кэш, который я из БД вытащил.
Это уже что-то новенькое.

>Если произошла утечка памяти, компьютер следует перезагрузить
Нет. После закрытия САС вся память назад возвращается в систему автоматически.

Papazol

28-04-2013 19:10

reporter   ~0011278

А папка env-то и не удалилась. Должна была автоматически? Теперь как с нею?

zed

28-04-2013 19:14

manager   ~0011279

>Теперь как с нею?
sdb_util - Config - Delete env folder on finish и повторить процедуру сброса LSN.

Papazol

28-04-2013 19:28

reporter   ~0011281

Оказалось несколько иначе. На самом деле, папки env удалились, галка там стояла. Но при запуске программы эти папки создались заново.

Попробовал я заменить файл DB_CONFIG, чтоб лог создавался, но лог почему-то не создаётся. А в sdb.log всё та же проблема с несуществующей папкой/файлом.

zed

28-04-2013 19:33

manager   ~0011282

Выложите проблемную папку env.

Papazol

28-04-2013 19:35

reporter   ~0011283

http://rghost.ru/45630211

zed

28-04-2013 19:43

manager   ~0011284

Что-то тут не то. Вы точно не запускали релиз после того как сделали сброс LSN и удаление папки env?

Дело в том, что ночнушка сейчас по дефолту создаёт несколько большие буфера в env, т.е. к примеру файл __db.004 (буфер лога) должен весить 2Мб, а в вашем env размеры буферов такие, как в предыдущем релизе/старых ночнушках.

Papazol

28-04-2013 19:51

reporter   ~0011285

В релизе нет дебажного exe-шника.
Думаю, надо взять тайм-аут до завтра, голова совсем уже не варит...

Papazol

08-05-2013 06:52

reporter   ~0011339

Пока ничего не изменилось. Пробовал ночную 7254.

zed

08-05-2013 07:12

manager   ~0011340

>Пока ничего не изменилось
Так мы остановились на том, что у кэша Беркли, созданного при помощи старого релиза нужно удалить файлы __db.xxxx в папке env при помощи утилиты sdb_util, а затем запустить ночнушку, чтобы она создала эти файлики сама и чтобы они были бОльшего размера, чем сейчас, ввиду изменившихся дефолтных настроек. Причём нужно использовать не абы какую ночнушку, а именно последнюю. И что ещё важно - релизную версию на кэше Беркли уже запускать нельзя (никогда), иначе она опять нагадит в env.

А какой-либо доработке в самом САСе по этому поводу проводить не нужно. Описываемая вами ситуация - отголоски старого бага, который присутствует в старом релизе. Поэтому всё, что можно сделать, это вылечить старый кэш и юзать его уже только в новых версиях ночнушек.

Papazol

08-05-2013 19:58

reporter   ~0011349

Last edited: 08-05-2013 20:00

Всё-таки что-то здесь не то... Сделал опять всё, как указано. Папка env удалилась. Запускаю программу, выбираю нужный кэш. Опять ошибка, и ничего не показывает. Папку env воссоздаёт. Но размеры файлов опять маленькие, как и раньше. Сама утилита sdb_util не изменилась? Правда, в последней ночнушке её нет.

Не знаю, напрямую это связано с моей проблемой или опосредованно, но я не могу конвертировать в Беркли тайловый кэш, который я ранее конвертировал из Беркли, но релизом. В тайловом-то кэше какие могут быть косяки, не позволяющие его упаковать? Он последней ночнушкой свободно открывается, как, впрочем, и предыдущими, это же обычный тайловый.

zed

08-05-2013 20:14

manager   ~0011350

> Но размеры файлов опять маленькие, как и раньше.
Нонсенс. Файл DB_CONFIG появляется?

>Сама утилита sdb_util не изменилась?
Обновления утилиты регулярно публикуются в топике http://sasgis.org/forum/viewtopic.php?f=2&t=2024

Papazol

09-05-2013 17:11

reporter   ~0011354

Файл DB_CONFIG появляется:
set_flags DB_TXN_WRITE_NOSYNC on
set_lg_dir .
set_data_dir ..
set_cachesize 0 2097152 1
mutex_set_max 30000
set_lg_max 10485760
set_lg_bsize 2097152
log_set_config DB_LOG_AUTO_REMOVE on

Скачал последнюю версию sdb_util. Прогнал ею свой кэш. Всё опять то же самое. Поскольку в логе sdb есть упоминание отсутствия файла/папки, значит, ссылка на абсолютный путь не убрана.

zed

09-05-2013 20:35

manager   ~0011355

Для меня остаётся загадкой, почему при правильном DB_CONFIG создаются файлы неправильных размеров. Единственное предположение, так это то, что SAS создаёт конфиг, но по каким-то причинам не может его прочитать (хотя с чего бы вдруг?), игнорит и использует дефолтные настройки. Но даже в таком случае, должна начаться закачка карт прямо в папку env. Хотя, если вы говорите, что это старый DG, то там скорее всего включён режим "Только из кэша"?

Маловероятно, но может быть ещё проблема в русских символах в путях к кэшу, если они, конечно, есть, эти символы. Попробуйте расположить кэш по наиболее короткому пути с латинскими символами и без пробелов для надёжности.

Papazol

09-05-2013 21:28

reporter   ~0011356

Last edited: 09-05-2013 21:30

Попробовал убрать кириллицу и пробелы, которые были. Как ни странно, это подействовало. Но только, как бы это сказать, наполовину. А именно, переименовав папку с тайловым кэшем, я тут же смог её упаковать в Беркли!

Проделав же с переименованным кэшем Беркли (другим, не этим!) процедуру сброса LSN, получил кэш без папки env, и она больше не создаётся. Соответственно, картинка не показывается, но и ошибки не возникает, по крайней мере, в части sdb, хотя утечка памяти всё равно есть. Пробовал утилитой восстановление, но никаких ошибок найдено не было.

Всё это означает, что зависимость работы от кириллицы/пробелов в названиях папок реально существует. Это не совсем хорошо. Более ранние версии к этому были лояльнее.

Papazol

10-05-2013 07:15

reporter   ~0011357

Ну всё, вроде бы эту тему можно считать закрытой.
Итак, кириллицу в названиях папок программа не приемлет напрочь. Либо это надо как-то решать, либо прямо заявить об этом, а лучше проверять и сообщать прямо в интерфейсе. Время, убитое на выявление ошибки, было слишком велико.
Все кэши, имевшие в названиях кириллицу, я переименовал, и они сразу заработали. И даже тот, у которого я удалял LSN, заработал тоже. Причём обнаружить в его названии наличие запрещённых символов оказалось непросто. Изначально он назывался "DG Рязань 2005_DB". Затем я дал ему имя "DG_Ryazan_2005_DB". Казалось бы, всё на латинице, ан нет, не работал. Обнаружено это было лишь по положению этой папки в окне Total Commander'а. Эта папка стояла не после ...Ryazan_2004..., а после всех ...Ryazan...

zed

03-06-2013 08:23

manager   ~0011481

Проблему с кириллицей решить можно. Если перекомпилировать либу и отключить у неё юникод (там от производителя предусмотрена директива), то всё чудесным образом начинает работать. Но мне это решение не очень нравится и нужно посмотреть, может удастся решить проблему и без перкомпиляции.

vasketsov

03-06-2013 09:41

manager   ~0011485

>может удастся решить проблему и без перкомпиляции
У SQLite3 аналогичная проблема, лечится использованием AnsiToUtf8 (см. TSQLite3DbHandler.Open и сравни с OpenW). Может и тут также полечится?

zed

03-06-2013 09:48

manager   ~0011487

Тут тоже используется AnsiToUtf8 и сами БД нормально открываются, но где-то сбоит внутренний механизм в либе и когда она пытается достучаться до файлика DB_CONFIG выходит облом. Толи баг в либе, толи ещё хз что.

zed

10-06-2013 17:31

manager   ~0011624

Проверяйте. Сделал более-менее компромиссно: на русских путях будет работать, но изменить дефолтные настройки через DB_CONFIG не получится. Этот файл хоть и создаётся, но либа его игнорирует (вернее не может достучаться). Ну, т.е. будет всё тоже, что было и в релизе 121010.

НО консольные утилиты из комплекта sdb_util, на русских путях скорее всего правильно не заработают (так же не смогут прочитать DB_CONFIG, а для них это критично). Так что о восстановлении кэша по таким путям скорее всего придётся забыть.

Papazol

10-06-2013 18:02

reporter   ~0011627

Уж лучше переименовать пути, но чтобы работало всё, что есть. Вот дать предупреждение о невалидных путях было бы полезно.

zed

10-06-2013 18:09

manager   ~0011628

Я могу только в лог записать сообщение, но наврят ли его кто будет читать.

Issue History

Date Modified Username Field Change
28-04-2013 16:07 Papazol New Issue
28-04-2013 16:33 zed Note Added: 0011268
28-04-2013 16:34 zed File Added: DB_CONFIG
28-04-2013 16:50 Papazol File Added: SASPlanet.Debug.elf
28-04-2013 16:51 Papazol Note Added: 0011269
28-04-2013 16:57 zed Note Added: 0011270
28-04-2013 17:12 Papazol Note Added: 0011271
28-04-2013 17:15 zed Note Added: 0011272
28-04-2013 17:47 Papazol Note Added: 0011273
28-04-2013 17:47 Papazol File Added: msg.log
28-04-2013 17:53 Papazol Note Edited: 0011273
28-04-2013 18:30 zed Note Added: 0011274
28-04-2013 18:54 zed Note Added: 0011275
28-04-2013 18:54 zed File Added: stat_m.txt
28-04-2013 18:57 zed Note Edited: 0011275
28-04-2013 18:59 Papazol Note Added: 0011276
28-04-2013 19:06 zed Note Added: 0011277
28-04-2013 19:10 Papazol Note Added: 0011278
28-04-2013 19:14 zed Note Added: 0011279
28-04-2013 19:28 Papazol Note Added: 0011281
28-04-2013 19:33 zed Note Added: 0011282
28-04-2013 19:35 Papazol Note Added: 0011283
28-04-2013 19:43 zed Note Added: 0011284
28-04-2013 19:51 Papazol Note Added: 0011285
07-05-2013 07:21 vdemidov Assigned To => zed
07-05-2013 07:21 vdemidov Status new => assigned
07-05-2013 17:01 zed Status assigned => feedback
08-05-2013 06:52 Papazol Note Added: 0011339
08-05-2013 06:52 Papazol Status feedback => assigned
08-05-2013 07:12 zed Note Added: 0011340
08-05-2013 09:33 vdemidov Status assigned => feedback
08-05-2013 19:58 Papazol Note Added: 0011349
08-05-2013 19:58 Papazol Status feedback => assigned
08-05-2013 20:00 Papazol Note Edited: 0011349
08-05-2013 20:14 zed Note Added: 0011350
09-05-2013 06:30 zed Status assigned => feedback
09-05-2013 17:11 Papazol Note Added: 0011354
09-05-2013 17:11 Papazol Status feedback => assigned
09-05-2013 20:35 zed Note Added: 0011355
09-05-2013 21:28 Papazol Note Added: 0011356
09-05-2013 21:30 Papazol Note Edited: 0011356
10-05-2013 07:15 Papazol Note Added: 0011357
03-06-2013 07:47 vdemidov Target Version => 131111
03-06-2013 08:23 zed Note Added: 0011481
03-06-2013 09:41 vasketsov Note Added: 0011485
03-06-2013 09:48 zed Note Added: 0011487
10-06-2013 17:31 zed Note Added: 0011624
10-06-2013 17:31 zed Status assigned => feedback
10-06-2013 18:02 Papazol Note Added: 0011627
10-06-2013 18:02 Papazol Status feedback => assigned
10-06-2013 18:09 zed Note Added: 0011628
15-06-2013 16:00 zed Status assigned => resolved
15-06-2013 16:00 zed Fixed in Version => 131111
15-06-2013 16:00 zed Resolution open => fixed
08-08-2025 13:22 zed Category Баг => Баг / Bug