SASGIS - SAS.Планета
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001114SAS.Планета[All Projects] Багpublic15-01-2012 18:4210-10-2012 11:49
ReporterTolik 
Assigned Tozed 
PriorityurgentSeverityblockReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version.Nightly 
Target Version120808Fixed in Version120808 
Summary0001114: BerkeleyDB: Unsupported tile record version!
DescriptionПрограмма стала глючить всегда на одном и том же месте (на карте), если включен гибрид НЯК, на зуме 14. Поэтому есть подозрения на то, что sdb покорраптился (не приложен, т.к. размер 5 МБ).
Файл elf тоже приложен. Кроме сабжевой ошибки, при закрытии также появляется memory leak.

Версия 4781.
Сбой произошёл без всякой видимой причины: лазил, лазил по карте и вдруг всё пропало.
Steps To Reproduce
Additional Information
TagsБД
Relationships
Attached Files? SASPlanet.Debug.elf (145,074) 15-01-2012 18:42
https://bugtracker.sasgis.org/file_download.php?file_id=592&type=bug
? SASPlanet.Debug.2.elf (96,104) 15-01-2012 18:51
https://bugtracker.sasgis.org/file_download.php?file_id=593&type=bug
? SASPlanet.Debug.win7.elf (232,701) 17-01-2012 10:23
https://bugtracker.sasgis.org/file_download.php?file_id=598&type=bug
png 2012-01-17_141819.png (32,579) 17-01-2012 10:25
https://bugtracker.sasgis.org/file_download.php?file_id=599&type=bug
png

7z SASPlanet.7z (1,840,688) 17-01-2012 13:05
https://bugtracker.sasgis.org/file_download.php?file_id=601&type=bug
Issue History
Date ModifiedUsernameFieldChange
15-01-2012 18:42TolikNew Issue
15-01-2012 18:42TolikFile Added: SASPlanet.Debug.elf
15-01-2012 18:46TolikStatusnew => acknowledged
15-01-2012 18:46TolikDescription Updatedbug_revision_view_page.php?rev_id=2477#r2477
15-01-2012 18:50TolikNote Added: 0004978
15-01-2012 18:51TolikFile Added: SASPlanet.Debug.2.elf
15-01-2012 18:55TolikNote Added: 0004979
15-01-2012 18:58TolikNote Edited: 0004979bug_revision_view_page.php?bugnote_id=4979#r2479
15-01-2012 19:05TolikNote Edited: 0004979bug_revision_view_page.php?bugnote_id=4979#r2480
15-01-2012 19:05TolikNote Edited: 0004979bug_revision_view_page.php?bugnote_id=4979#r2481
15-01-2012 19:06gpsMaxTag Attached: БД
15-01-2012 19:42vasketsovNote Added: 0004982
15-01-2012 19:43vasketsovNote Edited: 0004982bug_revision_view_page.php?bugnote_id=4982#r2483
15-01-2012 20:00TolikNote Added: 0004983
15-01-2012 20:05zedNote Added: 0004984
15-01-2012 20:08zedNote Added: 0004985
15-01-2012 20:15vdemidovNote Added: 0004987
16-01-2012 04:23TolikNote Added: 0004994
16-01-2012 05:06TolikNote Edited: 0004994bug_revision_view_page.php?bugnote_id=4994#r2490
16-01-2012 07:35zedNote Added: 0005006
16-01-2012 09:14TolikNote Added: 0005007
16-01-2012 10:46vasketsovNote Added: 0005009
16-01-2012 11:15TolikNote Added: 0005010
16-01-2012 17:02TolikNote Added: 0005019
16-01-2012 17:10TolikNote Edited: 0005019bug_revision_view_page.php?bugnote_id=5019#r2504
16-01-2012 17:14TolikNote Edited: 0005019bug_revision_view_page.php?bugnote_id=5019#r2505
16-01-2012 19:15TolikNote Edited: 0005019bug_revision_view_page.php?bugnote_id=5019#r2506
16-01-2012 19:23TolikNote Added: 0005022
16-01-2012 19:41zedNote Added: 0005023
16-01-2012 21:01vasketsovNote Added: 0005024
17-01-2012 10:23TolikFile Added: SASPlanet.Debug.win7.elf
17-01-2012 10:24TolikNote Added: 0005063
17-01-2012 10:25TolikFile Added: 2012-01-17_141819.png
17-01-2012 10:27TolikNote Edited: 0005063bug_revision_view_page.php?bugnote_id=5063#r2526
17-01-2012 10:34TolikNote Edited: 0005063bug_revision_view_page.php?bugnote_id=5063#r2527
17-01-2012 11:06TolikNote Added: 0005065
17-01-2012 11:17TolikNote Edited: 0005065bug_revision_view_page.php?bugnote_id=5065#r2529
17-01-2012 11:18TolikSeveritycrash => block
17-01-2012 13:05zedFile Added: SASPlanet.7z
17-01-2012 13:09zedNote Added: 0005067
17-01-2012 17:34TolikNote Added: 0005068
18-01-2012 04:22zedNote Added: 0005074
18-01-2012 04:23TolikNote Added: 0005075
18-01-2012 04:24TolikNote Edited: 0005075bug_revision_view_page.php?bugnote_id=5075#r2533
18-01-2012 04:26TolikNote Added: 0005076
18-01-2012 04:32TolikNote Edited: 0005076bug_revision_view_page.php?bugnote_id=5076#r2535
18-01-2012 04:35TolikNote Edited: 0005076bug_revision_view_page.php?bugnote_id=5076#r2536
18-01-2012 04:53TolikNote Added: 0005078
18-01-2012 05:07zedNote Added: 0005079
18-01-2012 05:17TolikNote Added: 0005081
18-01-2012 05:24zedNote Added: 0005083
18-01-2012 07:26vasketsovNote Added: 0005086
18-01-2012 07:27TolikNote Added: 0005087
18-01-2012 07:30vasketsovNote Added: 0005088
18-01-2012 07:31vasketsovNote Edited: 0005088bug_revision_view_page.php?bugnote_id=5088#r2544
19-01-2012 06:23DJ VKNote Added: 0005106
19-01-2012 07:38DJ VKNote Edited: 0005106bug_revision_view_page.php?bugnote_id=5106#r2556
19-01-2012 07:39DJ VKNote Edited: 0005106bug_revision_view_page.php?bugnote_id=5106#r2557
21-01-2012 07:47TolikNote Added: 0005147
21-01-2012 07:48TolikStatusacknowledged => resolved
21-01-2012 07:48TolikFixed in Version => 24xxxx
21-01-2012 07:48TolikResolutionopen => fixed
21-01-2012 07:48TolikAssigned To => zed
23-01-2012 08:34vdemidovTarget Version => 120808
23-01-2012 08:49vdemidovFixed in Version24xxxx => 120808
02-02-2012 10:32TolikNote Edited: 0005065bug_revision_view_page.php?bugnote_id=5065#r2678
10-10-2012 11:49TolikStatusresolved => closed

Notes
(0004978)
Tolik   
15-01-2012 18:50   
После удаления подозрительного файла sdb (слоя НЯК) стало ещё хуже:
Error #-30973: DB_RUNRECOVERY: Fatal error, run database recovery.
То есть покорраптился, видимо, sdb спутник Nokia
Файл *.2.elf приложен.
(0004979)
Tolik   
15-01-2012 18:55   
(edited on: 15-01-2012 19:05)
После удаления этого sdb Fatal error ушёл, но после изменения зума опять Unsupported tile record version! И уже, кажется, на любой карте.
Это уже похоже на системную ошибку. Перезагрузка не помогает.

Да, ещё list index out of bounds.
(0004982)
vasketsov   
15-01-2012 19:42   
(edited on: 15-01-2012 19:43)
Кстати насчёт утечки, прицеплюсь с вопросом. Коли уж я откопировался от TTileStorageBerkeleyDB - там в конструкторе создаётся приватная переменная класса FTileNotExistsTileInfo интерфейсного типа. Она сама должна умереть при смерти экземпляра класса, или её убить надо в деструкторе? Я ещё такие места видел в сасе, сам всегда убиваю, но мало ли вдруг она сама скончается...
зы. Это с багой скорее всего не связано.
ззы. Поделил бы rar-ом на 2 файла, да и делов, наверняка в этом деле файл БД нужнее elf-а.
(0004983)
Tolik   
15-01-2012 20:00   
В моём случае сама БД не важна, можно просто стереть.
Важно то, что (как мне кажется) что-то произошло, и программа стала портить сразу все открытые файлы БД.
(0004984)
zed   
15-01-2012 20:05   
А кэш точно не от версии меньше 4759? Именно тогда я добавил новое поле и ввёл эту проверку, на номер версии (и там генерируется эксепшн Unsupported tile record version!). Подозрительные файлы sdb нужно просканировать утилиткой db_verify и если она найдёт ошибки запустить восстановление - db_recover

Утечка памяти и list index out of bounds это сопутствующие потери из-за крэша, не обращайте внимание.

>там в конструкторе создаётся приватная переменная класса FTileNotExistsTileInfo
По-идее, любая интерфейсная переменная умирает автоматически при выходе из процедуры, если переменная локальная или при уничтожении класса, как в нашем случае. Присваивание значения nil вручную лишь перестраховка.

Дебажная сборка следит за утечками памяти, так что если после нормального закрытия приложения никаких сообщений не выскакивает, то всё уничтожается нормально.
(0004985)
zed   
15-01-2012 20:08   
>программа стала портить сразу все открытые файлы БД
По-моему, это возможно только если программа упадёт, тогда она не успеет сохранить закэшированные в памяти данные в БД и при следующем запуске увидит, что файл испорчен. Но в этом случае должна сразу же появляться ошибка вроде Error #-30973: DB_RUNRECOVERY: Fatal error, run database recovery (т.е. сообщение от БД, а не сгенерированное в САС).
(0004987)
vdemidov   
15-01-2012 20:15   
>>там в конструкторе создаётся приватная переменная класса FTileNotExistsTileInfo
> По-идее, любая интерфейсная переменная умирает автоматически при выходе из
> процедуры, если переменная локальная или при уничтожении класса, как в нашем
> случае. Присваивание значения nil вручную лишь перестраховка.
Еще присваивание nil нужно что бы чуть более детерменированно освободить ресурсы. Иногда бывает нужно. Вообще обнуляется само, но если владеет какими-то ресурсами, то лучше убить руками.
(0004994)
Tolik   
16-01-2012 04:23   
(edited on: 16-01-2012 05:06)
> А кэш точно не от версии меньше 4759?
Точно, кэш новый. Тот кэш вообще не открывался в 4759 и был просто стёрт.

> По-моему, это возможно только если программа упадёт
Ну может и так. Если зависнет и будет убита. И что, каждый раз после этого придётся восстанавливать 2 десятка баз данных?

Давайте разбираться по порядку.

Лазию я значить по карте на недебажной версии, вдруг отрисовка останавливается, на экране остаётся какой-то кусок карты, который при изменении зума масштабируется, а вокруг остаётся белый фон. И повляется list index out of bound.
Что точно значает это сообщение? Почему такое может произойти?

Затем закрываю программу, запускаю дебажную - сразу появляется BerkeleyDB: Unsupported tile record version!
Что это означает? Что БД уже испорчена, САС некорректно достаёт оттуда версию тайла?

После этого перезапускаю ещё пару раз, стираю подозрительный sdb и т.п., в какой-то момент САС совсем зависает и его приходится мочить. После этого Fatal error, run database recovery.
А это что означает? Что БД вообще уже не открывается?

В конце концов перезагружаю комп, после этого работает всё плохо. Убираю вообще cache_db - всё ок (карты качаются в новую бд). Т.е. после этих телодвижений побито уже много файлов sdb. Какие именно - трудно сказать, т.к. при каждом попадании на такой файл всё виснет.
Кстати, надо что-то с этим сделать: программа должна просто сказать, что файл такой-то не в порядке, и продолжать нормально работать (хотя бы с другими, неповреждёнными файлами).
(0005006)
zed   
16-01-2012 07:35   
Странно, выходит, что всё началось именно с list index out of bound. Плохо, что теперь уже фиг знает где он появился и видимо он и стал причиной бага. И походу это не тот же самый list index out of bound что возникает _после_ AV в БД, что попал в лог.

>Что БД уже испорчена, САС некорректно достаёт оттуда версию тайла?
Нет, БД открылась нормально, но отдала какой-то мусор.
 
>А это что означает? Что БД вообще уже не открывается?
А вот теперь - да, сама БД уже повредилась.

Да, надо прикручивать транзакции. Будем думать.
(0005007)
Tolik   
16-01-2012 09:14   
Главное тут даже не найти первопричину бага, а сделать БД устойчивой к крэшам программы (чтобы файлы не портились).
И программу сделать устойчивой к ошибкам в БД (чтоб с ума не сходила из-за них).
(0005009)
vasketsov   
16-01-2012 10:46   
>а сделать БД устойчивой к крэшам программы (чтобы файлы не портились).
С точки зрения банальной логики помогут транзакции. Точнее даже коммит недокоммиченных и роллбэк недороллбэченных при старте файла БД. По крайней мере логока работы "взрослых" СУБД именно такая, они пытаются докатиться по максимуму, а потом откатывают всё что могут (при этом аналогично хотелось бы какой-нибудь "журнал" иметь с такими "записками" для юзера).
(0005010)
Tolik   
16-01-2012 11:15   
В данном случае можно даже журнал не делать. Ну потеряется несколько свежескачанных тайлов - не беда.
(0005019)
Tolik   
16-01-2012 17:02   
(edited on: 16-01-2012 19:15)
Попробовал db_verify и db_recover.
C первым всё ясно, выдаёт кучу ошибок. Нашёл ок. 10 битых файлов на разных зумах, надоело. Надо написать скрипт, чтобы пройти по всем директориям и поудалять все плохие.

А со вторым не разобрался (хотя man и почитал). В параметрах имя файла не указать, без него вроде ничего не делает (только пытается читать лог).

Загрузил для примера пару битых файлов, попробуйте восстановить:
http://narod.yandex.ru/disk/37887098001/nokia.z15.9.5.38.20.zip
http://narod.yandex.ru/disk/37887125001/yanarodmap.z14.4.2.19.10.zip
(0005022)
Tolik   
16-01-2012 19:23   
Кажется, для восстановления БД (http://pybsddb.sourceforge.net/utility/db_recover.html) надо обязательно создавать архив - снапшот БД и логи (http://pybsddb.sourceforge.net/ref/transapp/archival.html).
Что в нашем случае теряет всякий смысл - проще делать периодически бэкап всего подряд.
(0005023)
zed   
16-01-2012 19:41   
db_recover похоже работает, только если включены транзакции.

В общем-то, включить их у меня получилось, но что-то они мне не очень нравятся.
Во-первых создаётся штук 5 мелких файлов и один большой (10Мб) файл лога. Да, БД становится нечувствительна к крэшам приложения и стартует вроде как без проблем, по крайней мере, сколько я саса не убивал тремя кнопками он мне ни разу после перезапуска не пожаловался на кэш.
Во-вторых, вот этот файл лога имеет свойство к размножению и если поставить закачку на ночь, то он забьёт весь винт... там, конечно, предусмотрены фишки по удалению ненужных логов (я включил одну, что удаляет их при перезапуске, можно и вручную периодически проводить чистку), но винт насиловать будет в 2 раза активнее - в эти логи сохраняются ВСЕ загружаемые тайлы что пишутся в БД.
Ну и в-третьих, если удалить сам файл лога, то БД открыть уже не получается. Хоть db_verify ошибок в файлах sdb не находит, но открыть БД с поддержкой транзакций уже не выходит (просто взять и распаковать тайлы может и получится - не проверял).

Да, нужен сюда эксперт по базам Беркли, а то как-то грустно становится...
(0005024)
vasketsov   
16-01-2012 21:01   
>файл лога имеет свойство к размножению
Там по логике должен быть ограничен его размер администратором БД, иначе реально всё можно забить. Кроме того, какой смысл в увеличение лога, это ж не зеркалирование, оттуда должно пропадать уже закоммиченное в файл БД. Может какая-то проблема как раз в коммите, потому и лог растёт?
(0005063)
Tolik   
17-01-2012 10:24   
(edited on: 17-01-2012 10:34)
И на другом компе возникли похожие проблемы.
SASPlanet.Debug.win7.elf
2012-01-17_141819.png

Что-то с базой случилось, какая-то Requested page not found, картинка замирает, программу приходится мочить.

Нашёл плохой файл, стёр, всё нормально.
db_verify.exe: Page 81: overflow page of invalid type 0
(0005065)
Tolik   
17-01-2012 11:06   
(edited on: 02-02-2012 10:32)
Сделал вот такой файл verify.bat:

@echo off
for /r %%i in (*.sdb) do (
c:\ut\SASPlanet.Nightly\db_verify "%%i"
if errorlevel 1 move "%%i" "%%i.BAD"
)

Нашёл 9 битых файлов на компе, на котором я проблем не замечал!
Короче, blocking issue :(
(0005067)
zed   
17-01-2012 13:09   
Приаттачил exe с включёнными транзакциями. Воспринимает кэш от предыдущей версии (которая без транзакций). В кэше появится папка env - её не удаляем, иначе эта версия уже не сможет работать с кэшем (удаление папки env равносильно удалению кэша).

Если сильных глюков не будет, то сделаю коммит в репо.
(0005068)
Tolik   
17-01-2012 17:34   
Вроде нормально.
Запустил скачивание области, убил процесс САС, проверил файлы - 1 из них попортился: db_verify: Page 4869: invalid next_pgno 4870
Запустил САС, закрыл, снова проверил - все файлы в порядке.

А логи сколько места будут занимать?

Удалил env, запустил САС - она виснет, другие карты тоже не показывает, закрываться не хочет. Надо подправить (если ещё не), сделать обработку ошибок БД.
(0005074)
zed   
18-01-2012 04:22   
>А логи сколько места будут занимать?
Один файл - 10Мб. При заполнении первого файла создаётся второй, а первый удаляется и т.д.

>сделать обработку ошибок БД
Единственное, что можно сделать - подавить вывод ошибок.
(0005075)
Tolik   
18-01-2012 04:23   
(edited on: 18-01-2012 04:24)
Файл log.0000000001 создаётся сразу размером 10 МБ. Даже когда в БД всего несколько тайлов. Почему 10 МБ? Можно ли уменьшить?
(0005076)
Tolik   
18-01-2012 04:26   
(edited on: 18-01-2012 04:35)
Насчёт ошибок - наоборот, не подавить, а сделать так, чтобы в случае ошибки программа сообщала, что БД такая-то испорчена, и продолжала нормально работать (если переключить на другую карту), а не вешалась.

P.S. вообще-то в версии 4794 она уже не вешается.

Удалил env, запустил САС. С теми тайлами, которые были в базе, ничего сделать не может: ни удалить, ни вывести на экран. Другие скачиваются. Надо вручную искать нерабочие sdb и стирать. Никаких ошибок не показывает.
(0005078)
Tolik   
18-01-2012 04:53   
Если запустить db_recover -v -h путь_к_лог_файлу на нормальной БД, она говорит, что recovery complete, но БД портит. В САСе появляется fatal error - run recovery и она таки виснет.
(0005079)
zed   
18-01-2012 05:07   
>Почему 10 МБ? Можно ли уменьшить?
По дефолту столько. Уменьшить можно, но смысл, если он плодится только в путь?

>Удалил env, запустил САС ... Надо вручную искать нерабочие sdb и стирать.
C sdb всё нормально. Не надо удалять env - как его восстановить я без понятия (если это вообще возможно) и мне это очень не нравится. В sdb остаются ссылки на лог из env, а раз лог удалён, то ссылки недействительны и как-то их нужно из sdb удалять. Пока что тут тёмный лес.
(0005081)
Tolik   
18-01-2012 05:17   
Смысл - у меня в старом кэше 130 папок (из них 120 ненужных, но кто ж их будет чистить :) Получится 1.3 ГБ мусора. Так что если это не повлияет на производительность или не знаю что, лучше размер уменьшить.


Если env нет и не было, база же открывается нормально. М.б. можно удалить ссылки на лог из sdb и привести её обратно к такому до-envшному состоянию?
Например, для восстановления БД в случае порчи лог-файла.
(0005083)
zed   
18-01-2012 05:24   
>Получится 1.3 ГБ мусора.
Так не мусор это, а информация о транзакциях.

>М.б. можно удалить ссылки на лог из sdb и привести её обратно к такому до-envшному состоянию?
Не факт. Нужно сильно рыть доки. Пока что решения не нашёл.
(0005086)
vasketsov   
18-01-2012 07:26   
>Файл log.0000000001 создаётся сразу размером 10 МБ. Даже когда в БД всего несколько тайлов. Почему 10 МБ?
Потому что в целях увеличения производительности и надёжности существует общее правило - нужно избегать увеличения физического размера лога транзакций при записи в него и синхронного увеличения размеров данных на том же физическом носителе. Когда флешка с картой будет забита под завязку, резервирование этих 10 Мб (или сколько там будет) просто спасёт все данные.

>>Получится 1.3 ГБ мусора.
>Так не мусор это, а информация о транзакциях.
А можно сделать один лог транзакций на все файлики в одном кэше?
(0005087)
Tolik   
18-01-2012 07:27   
он и есть один - по одному на каждую карту
(0005088)
vasketsov   
18-01-2012 07:30   
(edited on: 18-01-2012 07:31)
Тогда откуда 1.3 ГБ мусора?
А, понял, 130 папок - это 130 карт.
Тогда получается, одни карты должны работать с логом, а другие карты - вообще read-only?
(0005106)
DJ VK   
19-01-2012 06:23   
(edited on: 19-01-2012 07:39)
и все уже сконвертированные базы надо в старой версии программы снова экспортировать назад в тайлы и снова сжимать в беркли уже новой версией??

Выяснил. Базы от старой версии подхватываются, лог создается. Но невозможно 2мя программами лезть в 1 папку с кэшами cache_db. кто первый успел тот и лезет.
(0005147)
Tolik   
21-01-2012 07:47   
По этой проблеме открыт отдельный баг репорт 1125.
Оба решены в версии 4860.