0001114: BerkeleyDB: Unsupported tile record version!

Notes
(0004978) Tolik (manager) 15-01-2012 18:50	После удаления подозрительного файла sdb (слоя НЯК) стало ещё хуже: Error #-30973: DB_RUNRECOVERY: Fatal error, run database recovery. То есть покорраптился, видимо, sdb спутник Nokia Файл *.2.elf приложен.

(0004979) Tolik (manager) 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 (manager) 15-01-2012 19:42 edited on: 15-01-2012 19:43	Кстати насчёт утечки, прицеплюсь с вопросом. Коли уж я откопировался от TTileStorageBerkeleyDB - там в конструкторе создаётся приватная переменная класса FTileNotExistsTileInfo интерфейсного типа. Она сама должна умереть при смерти экземпляра класса, или её убить надо в деструкторе? Я ещё такие места видел в сасе, сам всегда убиваю, но мало ли вдруг она сама скончается... зы. Это с багой скорее всего не связано. ззы. Поделил бы rar-ом на 2 файла, да и делов, наверняка в этом деле файл БД нужнее elf-а.

(0004983) Tolik (manager) 15-01-2012 20:00	В моём случае сама БД не важна, можно просто стереть. Важно то, что (как мне кажется) что-то произошло, и программа стала портить сразу все открытые файлы БД.

(0004984) zed (manager) 15-01-2012 20:05	А кэш точно не от версии меньше 4759? Именно тогда я добавил новое поле и ввёл эту проверку, на номер версии (и там генерируется эксепшн Unsupported tile record version!). Подозрительные файлы sdb нужно просканировать утилиткой db_verify и если она найдёт ошибки запустить восстановление - db_recover Утечка памяти и list index out of bounds это сопутствующие потери из-за крэша, не обращайте внимание. >там в конструкторе создаётся приватная переменная класса FTileNotExistsTileInfo По-идее, любая интерфейсная переменная умирает автоматически при выходе из процедуры, если переменная локальная или при уничтожении класса, как в нашем случае. Присваивание значения nil вручную лишь перестраховка. Дебажная сборка следит за утечками памяти, так что если после нормального закрытия приложения никаких сообщений не выскакивает, то всё уничтожается нормально.

(0004985) zed (manager) 15-01-2012 20:08	>программа стала портить сразу все открытые файлы БД По-моему, это возможно только если программа упадёт, тогда она не успеет сохранить закэшированные в памяти данные в БД и при следующем запуске увидит, что файл испорчен. Но в этом случае должна сразу же появляться ошибка вроде Error #-30973: DB_RUNRECOVERY: Fatal error, run database recovery (т.е. сообщение от БД, а не сгенерированное в САС).

(0004987) vdemidov (manager) 15-01-2012 20:15	>>там в конструкторе создаётся приватная переменная класса FTileNotExistsTileInfo > По-идее, любая интерфейсная переменная умирает автоматически при выходе из > процедуры, если переменная локальная или при уничтожении класса, как в нашем > случае. Присваивание значения nil вручную лишь перестраховка. Еще присваивание nil нужно что бы чуть более детерменированно освободить ресурсы. Иногда бывает нужно. Вообще обнуляется само, но если владеет какими-то ресурсами, то лучше убить руками.

(0004994) Tolik (manager) 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 (manager) 16-01-2012 07:35	Странно, выходит, что всё началось именно с list index out of bound. Плохо, что теперь уже фиг знает где он появился и видимо он и стал причиной бага. И походу это не тот же самый list index out of bound что возникает _после_ AV в БД, что попал в лог. >Что БД уже испорчена, САС некорректно достаёт оттуда версию тайла? Нет, БД открылась нормально, но отдала какой-то мусор. >А это что означает? Что БД вообще уже не открывается? А вот теперь - да, сама БД уже повредилась. Да, надо прикручивать транзакции. Будем думать.

(0005007) Tolik (manager) 16-01-2012 09:14	Главное тут даже не найти первопричину бага, а сделать БД устойчивой к крэшам программы (чтобы файлы не портились). И программу сделать устойчивой к ошибкам в БД (чтоб с ума не сходила из-за них).

(0005009) vasketsov (manager) 16-01-2012 10:46	>а сделать БД устойчивой к крэшам программы (чтобы файлы не портились). С точки зрения банальной логики помогут транзакции. Точнее даже коммит недокоммиченных и роллбэк недороллбэченных при старте файла БД. По крайней мере логока работы "взрослых" СУБД именно такая, они пытаются докатиться по максимуму, а потом откатывают всё что могут (при этом аналогично хотелось бы какой-нибудь "журнал" иметь с такими "записками" для юзера).

(0005010) Tolik (manager) 16-01-2012 11:15	В данном случае можно даже журнал не делать. Ну потеряется несколько свежескачанных тайлов - не беда.

(0005019) Tolik (manager) 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 (manager) 16-01-2012 19:23	Кажется, для восстановления БД (http://pybsddb.sourceforge.net/utility/db_recover.html) надо обязательно создавать архив - снапшот БД и логи (http://pybsddb.sourceforge.net/ref/transapp/archival.html). Что в нашем случае теряет всякий смысл - проще делать периодически бэкап всего подряд.

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

(0005024) vasketsov (manager) 16-01-2012 21:01	>файл лога имеет свойство к размножению Там по логике должен быть ограничен его размер администратором БД, иначе реально всё можно забить. Кроме того, какой смысл в увеличение лога, это ж не зеркалирование, оттуда должно пропадать уже закоммиченное в файл БД. Может какая-то проблема как раз в коммите, потому и лог растёт?

(0005063) Tolik (manager) 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 (manager) 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 (manager) 17-01-2012 13:09	Приаттачил exe с включёнными транзакциями. Воспринимает кэш от предыдущей версии (которая без транзакций). В кэше появится папка env - её не удаляем, иначе эта версия уже не сможет работать с кэшем (удаление папки env равносильно удалению кэша). Если сильных глюков не будет, то сделаю коммит в репо.

(0005068) Tolik (manager) 17-01-2012 17:34	Вроде нормально. Запустил скачивание области, убил процесс САС, проверил файлы - 1 из них попортился: db_verify: Page 4869: invalid next_pgno 4870 Запустил САС, закрыл, снова проверил - все файлы в порядке. А логи сколько места будут занимать? Удалил env, запустил САС - она виснет, другие карты тоже не показывает, закрываться не хочет. Надо подправить (если ещё не), сделать обработку ошибок БД.

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

(0005075) Tolik (manager) 18-01-2012 04:23 edited on: 18-01-2012 04:24	Файл log.0000000001 создаётся сразу размером 10 МБ. Даже когда в БД всего несколько тайлов. Почему 10 МБ? Можно ли уменьшить?

(0005076) Tolik (manager) 18-01-2012 04:26 edited on: 18-01-2012 04:35	Насчёт ошибок - наоборот, не подавить, а сделать так, чтобы в случае ошибки программа сообщала, что БД такая-то испорчена, и продолжала нормально работать (если переключить на другую карту), а не вешалась. P.S. вообще-то в версии 4794 она уже не вешается. Удалил env, запустил САС. С теми тайлами, которые были в базе, ничего сделать не может: ни удалить, ни вывести на экран. Другие скачиваются. Надо вручную искать нерабочие sdb и стирать. Никаких ошибок не показывает.

(0005078) Tolik (manager) 18-01-2012 04:53	Если запустить db_recover -v -h путь_к_лог_файлу на нормальной БД, она говорит, что recovery complete, но БД портит. В САСе появляется fatal error - run recovery и она таки виснет.

(0005079) zed (manager) 18-01-2012 05:07	>Почему 10 МБ? Можно ли уменьшить? По дефолту столько. Уменьшить можно, но смысл, если он плодится только в путь? >Удалил env, запустил САС ... Надо вручную искать нерабочие sdb и стирать. C sdb всё нормально. Не надо удалять env - как его восстановить я без понятия (если это вообще возможно) и мне это очень не нравится. В sdb остаются ссылки на лог из env, а раз лог удалён, то ссылки недействительны и как-то их нужно из sdb удалять. Пока что тут тёмный лес.

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

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

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

(0005087) Tolik (manager) 18-01-2012 07:27	он и есть один - по одному на каждую карту

(0005088) vasketsov (manager) 18-01-2012 07:30 edited on: 18-01-2012 07:31	Тогда откуда 1.3 ГБ мусора? А, понял, 130 папок - это 130 карт. Тогда получается, одни карты должны работать с логом, а другие карты - вообще read-only?

(0005106) DJ VK (manager) 19-01-2012 06:23 edited on: 19-01-2012 07:39	и все уже сконвертированные базы надо в старой версии программы снова экспортировать назад в тайлы и снова сжимать в беркли уже новой версией?? Выяснил. Базы от старой версии подхватываются, лог создается. Но невозможно 2мя программами лезть в 1 папку с кэшами cache_db. кто первый успел тот и лезет.

(0005147) Tolik (manager) 21-01-2012 07:47	По этой проблеме открыт отдельный баг репорт 1125. Оба решены в версии 4860.

Users who viewed this issue
User List	Anonymous (3521x)
Total Views	3521
Last View	23-11-2024 09:30

Issue History
Date Modified	Username	Field	Change
15-01-2012 18:42	Tolik	New Issue
15-01-2012 18:42	Tolik	File Added: SASPlanet.Debug.elf
15-01-2012 18:46	Tolik	Status	new => acknowledged
15-01-2012 18:46	Tolik	Description Updated	View Revisions
15-01-2012 18:50	Tolik	Note Added: 0004978
15-01-2012 18:51	Tolik	File Added: SASPlanet.Debug.2.elf
15-01-2012 18:55	Tolik	Note Added: 0004979
15-01-2012 18:58	Tolik	Note Edited: 0004979	View Revisions
15-01-2012 19:05	Tolik	Note Edited: 0004979	View Revisions
15-01-2012 19:05	Tolik	Note Edited: 0004979	View Revisions
15-01-2012 19:06	gpsMax	Tag Attached: БД
15-01-2012 19:42	vasketsov	Note Added: 0004982
15-01-2012 19:43	vasketsov	Note Edited: 0004982	View Revisions
15-01-2012 20:00	Tolik	Note Added: 0004983
15-01-2012 20:05	zed	Note Added: 0004984
15-01-2012 20:08	zed	Note Added: 0004985
15-01-2012 20:15	vdemidov	Note Added: 0004987
16-01-2012 04:23	Tolik	Note Added: 0004994
16-01-2012 05:06	Tolik	Note Edited: 0004994	View Revisions
16-01-2012 07:35	zed	Note Added: 0005006
16-01-2012 09:14	Tolik	Note Added: 0005007
16-01-2012 10:46	vasketsov	Note Added: 0005009
16-01-2012 11:15	Tolik	Note Added: 0005010
16-01-2012 17:02	Tolik	Note Added: 0005019
16-01-2012 17:10	Tolik	Note Edited: 0005019	View Revisions
16-01-2012 17:14	Tolik	Note Edited: 0005019	View Revisions
16-01-2012 19:15	Tolik	Note Edited: 0005019	View Revisions
16-01-2012 19:23	Tolik	Note Added: 0005022
16-01-2012 19:41	zed	Note Added: 0005023
16-01-2012 21:01	vasketsov	Note Added: 0005024
17-01-2012 10:23	Tolik	File Added: SASPlanet.Debug.win7.elf
17-01-2012 10:24	Tolik	Note Added: 0005063
17-01-2012 10:25	Tolik	File Added: 2012-01-17_141819.png
17-01-2012 10:27	Tolik	Note Edited: 0005063	View Revisions
17-01-2012 10:34	Tolik	Note Edited: 0005063	View Revisions
17-01-2012 11:06	Tolik	Note Added: 0005065
17-01-2012 11:17	Tolik	Note Edited: 0005065	View Revisions
17-01-2012 11:18	Tolik	Severity	crash => block
17-01-2012 13:05	zed	File Added: SASPlanet.7z
17-01-2012 13:09	zed	Note Added: 0005067
17-01-2012 17:34	Tolik	Note Added: 0005068
18-01-2012 04:22	zed	Note Added: 0005074
18-01-2012 04:23	Tolik	Note Added: 0005075
18-01-2012 04:24	Tolik	Note Edited: 0005075	View Revisions
18-01-2012 04:26	Tolik	Note Added: 0005076
18-01-2012 04:32	Tolik	Note Edited: 0005076	View Revisions
18-01-2012 04:35	Tolik	Note Edited: 0005076	View Revisions
18-01-2012 04:53	Tolik	Note Added: 0005078
18-01-2012 05:07	zed	Note Added: 0005079
18-01-2012 05:17	Tolik	Note Added: 0005081
18-01-2012 05:24	zed	Note Added: 0005083
18-01-2012 07:26	vasketsov	Note Added: 0005086
18-01-2012 07:27	Tolik	Note Added: 0005087
18-01-2012 07:30	vasketsov	Note Added: 0005088
18-01-2012 07:31	vasketsov	Note Edited: 0005088	View Revisions
19-01-2012 06:23	DJ VK	Note Added: 0005106
19-01-2012 07:38	DJ VK	Note Edited: 0005106	View Revisions
19-01-2012 07:39	DJ VK	Note Edited: 0005106	View Revisions
21-01-2012 07:47	Tolik	Note Added: 0005147
21-01-2012 07:48	Tolik	Status	acknowledged => resolved
21-01-2012 07:48	Tolik	Fixed in Version	=> 24xxxx
21-01-2012 07:48	Tolik	Resolution	open => fixed
21-01-2012 07:48	Tolik	Assigned To	=> zed
23-01-2012 08:34	vdemidov	Target Version	=> 120808
23-01-2012 08:49	vdemidov	Fixed in Version	24xxxx => 120808
02-02-2012 10:32	Tolik	Note Edited: 0005065	View Revisions
10-10-2012 11:49	Tolik	Status	resolved => closed

Relationships

SASGIS