View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001114 | SAS.Планета | Баг / Bug | public | 15-01-2012 18:42 | 10-10-2012 11:49 |
| Reporter | Tolik | Assigned To | zed | ||
| Priority | urgent | Severity | block | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | .Nightly | ||||
| Target Version | 120808 | Fixed in Version | 120808 | ||
| Summary | 0001114: BerkeleyDB: Unsupported tile record version! | ||||
| Description | Программа стала глючить всегда на одном и том же месте (на карте), если включен гибрид НЯК, на зуме 14. Поэтому есть подозрения на то, что sdb покорраптился (не приложен, т.к. размер 5 МБ). Файл elf тоже приложен. Кроме сабжевой ошибки, при закрытии также появляется memory leak. Версия 4781. Сбой произошёл без всякой видимой причины: лазил, лазил по карте и вдруг всё пропало. | ||||
| Tags | БД | ||||
| Attached Files | |||||
|
|
После удаления подозрительного файла sdb (слоя НЯК) стало ещё хуже: Error #-30973: DB_RUNRECOVERY: Fatal error, run database recovery. То есть покорраптился, видимо, sdb спутник Nokia Файл *.2.elf приложен. |
|
|
После удаления этого sdb Fatal error ушёл, но после изменения зума опять Unsupported tile record version! И уже, кажется, на любой карте. Это уже похоже на системную ошибку. Перезагрузка не помогает. Да, ещё list index out of bounds. |
|
|
Кстати насчёт утечки, прицеплюсь с вопросом. Коли уж я откопировался от TTileStorageBerkeleyDB - там в конструкторе создаётся приватная переменная класса FTileNotExistsTileInfo интерфейсного типа. Она сама должна умереть при смерти экземпляра класса, или её убить надо в деструкторе? Я ещё такие места видел в сасе, сам всегда убиваю, но мало ли вдруг она сама скончается... зы. Это с багой скорее всего не связано. ззы. Поделил бы rar-ом на 2 файла, да и делов, наверняка в этом деле файл БД нужнее elf-а. |
|
|
В моём случае сама БД не важна, можно просто стереть. Важно то, что (как мне кажется) что-то произошло, и программа стала портить сразу все открытые файлы БД. |
|
|
А кэш точно не от версии меньше 4759? Именно тогда я добавил новое поле и ввёл эту проверку, на номер версии (и там генерируется эксепшн Unsupported tile record version!). Подозрительные файлы sdb нужно просканировать утилиткой db_verify и если она найдёт ошибки запустить восстановление - db_recover Утечка памяти и list index out of bounds это сопутствующие потери из-за крэша, не обращайте внимание. >там в конструкторе создаётся приватная переменная класса FTileNotExistsTileInfo По-идее, любая интерфейсная переменная умирает автоматически при выходе из процедуры, если переменная локальная или при уничтожении класса, как в нашем случае. Присваивание значения nil вручную лишь перестраховка. Дебажная сборка следит за утечками памяти, так что если после нормального закрытия приложения никаких сообщений не выскакивает, то всё уничтожается нормально. |
|
|
>программа стала портить сразу все открытые файлы БД По-моему, это возможно только если программа упадёт, тогда она не успеет сохранить закэшированные в памяти данные в БД и при следующем запуске увидит, что файл испорчен. Но в этом случае должна сразу же появляться ошибка вроде Error #-30973: DB_RUNRECOVERY: Fatal error, run database recovery (т.е. сообщение от БД, а не сгенерированное в САС). |
|
|
>>там в конструкторе создаётся приватная переменная класса FTileNotExistsTileInfo > По-идее, любая интерфейсная переменная умирает автоматически при выходе из > процедуры, если переменная локальная или при уничтожении класса, как в нашем > случае. Присваивание значения nil вручную лишь перестраховка. Еще присваивание nil нужно что бы чуть более детерменированно освободить ресурсы. Иногда бывает нужно. Вообще обнуляется само, но если владеет какими-то ресурсами, то лучше убить руками. |
|
|
> А кэш точно не от версии меньше 4759? Точно, кэш новый. Тот кэш вообще не открывался в 4759 и был просто стёрт. > По-моему, это возможно только если программа упадёт Ну может и так. Если зависнет и будет убита. И что, каждый раз после этого придётся восстанавливать 2 десятка баз данных? Давайте разбираться по порядку. Лазию я значить по карте на недебажной версии, вдруг отрисовка останавливается, на экране остаётся какой-то кусок карты, который при изменении зума масштабируется, а вокруг остаётся белый фон. И повляется list index out of bound. Что точно значает это сообщение? Почему такое может произойти? Затем закрываю программу, запускаю дебажную - сразу появляется BerkeleyDB: Unsupported tile record version! Что это означает? Что БД уже испорчена, САС некорректно достаёт оттуда версию тайла? После этого перезапускаю ещё пару раз, стираю подозрительный sdb и т.п., в какой-то момент САС совсем зависает и его приходится мочить. После этого Fatal error, run database recovery. А это что означает? Что БД вообще уже не открывается? В конце концов перезагружаю комп, после этого работает всё плохо. Убираю вообще cache_db - всё ок (карты качаются в новую бд). Т.е. после этих телодвижений побито уже много файлов sdb. Какие именно - трудно сказать, т.к. при каждом попадании на такой файл всё виснет. Кстати, надо что-то с этим сделать: программа должна просто сказать, что файл такой-то не в порядке, и продолжать нормально работать (хотя бы с другими, неповреждёнными файлами). |
|
|
Странно, выходит, что всё началось именно с list index out of bound. Плохо, что теперь уже фиг знает где он появился и видимо он и стал причиной бага. И походу это не тот же самый list index out of bound что возникает _после_ AV в БД, что попал в лог. >Что БД уже испорчена, САС некорректно достаёт оттуда версию тайла? Нет, БД открылась нормально, но отдала какой-то мусор. >А это что означает? Что БД вообще уже не открывается? А вот теперь - да, сама БД уже повредилась. Да, надо прикручивать транзакции. Будем думать. |
|
|
Главное тут даже не найти первопричину бага, а сделать БД устойчивой к крэшам программы (чтобы файлы не портились). И программу сделать устойчивой к ошибкам в БД (чтоб с ума не сходила из-за них). |
|
|
>а сделать БД устойчивой к крэшам программы (чтобы файлы не портились). С точки зрения банальной логики помогут транзакции. Точнее даже коммит недокоммиченных и роллбэк недороллбэченных при старте файла БД. По крайней мере логока работы "взрослых" СУБД именно такая, они пытаются докатиться по максимуму, а потом откатывают всё что могут (при этом аналогично хотелось бы какой-нибудь "журнал" иметь с такими "записками" для юзера). |
|
|
В данном случае можно даже журнал не делать. Ну потеряется несколько свежескачанных тайлов - не беда. |
|
|
Попробовал 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 |
|
|
Кажется, для восстановления БД (http://pybsddb.sourceforge.net/utility/db_recover.html) надо обязательно создавать архив - снапшот БД и логи (http://pybsddb.sourceforge.net/ref/transapp/archival.html). Что в нашем случае теряет всякий смысл - проще делать периодически бэкап всего подряд. |
|
|
db_recover похоже работает, только если включены транзакции. В общем-то, включить их у меня получилось, но что-то они мне не очень нравятся. Во-первых создаётся штук 5 мелких файлов и один большой (10Мб) файл лога. Да, БД становится нечувствительна к крэшам приложения и стартует вроде как без проблем, по крайней мере, сколько я саса не убивал тремя кнопками он мне ни разу после перезапуска не пожаловался на кэш. Во-вторых, вот этот файл лога имеет свойство к размножению и если поставить закачку на ночь, то он забьёт весь винт... там, конечно, предусмотрены фишки по удалению ненужных логов (я включил одну, что удаляет их при перезапуске, можно и вручную периодически проводить чистку), но винт насиловать будет в 2 раза активнее - в эти логи сохраняются ВСЕ загружаемые тайлы что пишутся в БД. Ну и в-третьих, если удалить сам файл лога, то БД открыть уже не получается. Хоть db_verify ошибок в файлах sdb не находит, но открыть БД с поддержкой транзакций уже не выходит (просто взять и распаковать тайлы может и получится - не проверял). Да, нужен сюда эксперт по базам Беркли, а то как-то грустно становится... |
|
|
>файл лога имеет свойство к размножению Там по логике должен быть ограничен его размер администратором БД, иначе реально всё можно забить. Кроме того, какой смысл в увеличение лога, это ж не зеркалирование, оттуда должно пропадать уже закоммиченное в файл БД. Может какая-то проблема как раз в коммите, потому и лог растёт? |
|
|
И на другом компе возникли похожие проблемы. SASPlanet.Debug.win7.elf 2012-01-17_141819.png Что-то с базой случилось, какая-то Requested page not found, картинка замирает, программу приходится мочить. Нашёл плохой файл, стёр, всё нормально. db_verify.exe: Page 81: overflow page of invalid type 0 |
|
|
Сделал вот такой файл 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 :( |
|
|
Приаттачил exe с включёнными транзакциями. Воспринимает кэш от предыдущей версии (которая без транзакций). В кэше появится папка env - её не удаляем, иначе эта версия уже не сможет работать с кэшем (удаление папки env равносильно удалению кэша). Если сильных глюков не будет, то сделаю коммит в репо. |
|
|
Вроде нормально. Запустил скачивание области, убил процесс САС, проверил файлы - 1 из них попортился: db_verify: Page 4869: invalid next_pgno 4870 Запустил САС, закрыл, снова проверил - все файлы в порядке. А логи сколько места будут занимать? Удалил env, запустил САС - она виснет, другие карты тоже не показывает, закрываться не хочет. Надо подправить (если ещё не), сделать обработку ошибок БД. |
|
|
>А логи сколько места будут занимать? Один файл - 10Мб. При заполнении первого файла создаётся второй, а первый удаляется и т.д. >сделать обработку ошибок БД Единственное, что можно сделать - подавить вывод ошибок. |
|
|
Файл log.0000000001 создаётся сразу размером 10 МБ. Даже когда в БД всего несколько тайлов. Почему 10 МБ? Можно ли уменьшить? |
|
|
Насчёт ошибок - наоборот, не подавить, а сделать так, чтобы в случае ошибки программа сообщала, что БД такая-то испорчена, и продолжала нормально работать (если переключить на другую карту), а не вешалась. P.S. вообще-то в версии 4794 она уже не вешается. Удалил env, запустил САС. С теми тайлами, которые были в базе, ничего сделать не может: ни удалить, ни вывести на экран. Другие скачиваются. Надо вручную искать нерабочие sdb и стирать. Никаких ошибок не показывает. |
|
|
Если запустить db_recover -v -h путь_к_лог_файлу на нормальной БД, она говорит, что recovery complete, но БД портит. В САСе появляется fatal error - run recovery и она таки виснет. |
|
|
>Почему 10 МБ? Можно ли уменьшить? По дефолту столько. Уменьшить можно, но смысл, если он плодится только в путь? >Удалил env, запустил САС ... Надо вручную искать нерабочие sdb и стирать. C sdb всё нормально. Не надо удалять env - как его восстановить я без понятия (если это вообще возможно) и мне это очень не нравится. В sdb остаются ссылки на лог из env, а раз лог удалён, то ссылки недействительны и как-то их нужно из sdb удалять. Пока что тут тёмный лес. |
|
|
Смысл - у меня в старом кэше 130 папок (из них 120 ненужных, но кто ж их будет чистить :) Получится 1.3 ГБ мусора. Так что если это не повлияет на производительность или не знаю что, лучше размер уменьшить. Если env нет и не было, база же открывается нормально. М.б. можно удалить ссылки на лог из sdb и привести её обратно к такому до-envшному состоянию? Например, для восстановления БД в случае порчи лог-файла. |
|
|
>Получится 1.3 ГБ мусора. Так не мусор это, а информация о транзакциях. >М.б. можно удалить ссылки на лог из sdb и привести её обратно к такому до-envшному состоянию? Не факт. Нужно сильно рыть доки. Пока что решения не нашёл. |
|
|
>Файл log.0000000001 создаётся сразу размером 10 МБ. Даже когда в БД всего несколько тайлов. Почему 10 МБ? Потому что в целях увеличения производительности и надёжности существует общее правило - нужно избегать увеличения физического размера лога транзакций при записи в него и синхронного увеличения размеров данных на том же физическом носителе. Когда флешка с картой будет забита под завязку, резервирование этих 10 Мб (или сколько там будет) просто спасёт все данные. >>Получится 1.3 ГБ мусора. >Так не мусор это, а информация о транзакциях. А можно сделать один лог транзакций на все файлики в одном кэше? |
|
|
он и есть один - по одному на каждую карту |
|
|
Тогда откуда 1.3 ГБ мусора? А, понял, 130 папок - это 130 карт. Тогда получается, одни карты должны работать с логом, а другие карты - вообще read-only? |
|
|
и все уже сконвертированные базы надо в старой версии программы снова экспортировать назад в тайлы и снова сжимать в беркли уже новой версией?? Выяснил. Базы от старой версии подхватываются, лог создается. Но невозможно 2мя программами лезть в 1 папку с кэшами cache_db. кто первый успел тот и лезет. |
|
|
По этой проблеме открыт отдельный баг репорт 1125. Оба решены в версии 4860. |
| 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 | |
| 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 | |
| 15-01-2012 19:05 | Tolik | Note Edited: 0004979 | |
| 15-01-2012 19:05 | Tolik | Note Edited: 0004979 | |
| 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 | |
| 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 | |
| 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 | |
| 16-01-2012 17:14 | Tolik | Note Edited: 0005019 | |
| 16-01-2012 19:15 | Tolik | Note Edited: 0005019 | |
| 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 | |
| 17-01-2012 10:34 | Tolik | Note Edited: 0005063 | |
| 17-01-2012 11:06 | Tolik | Note Added: 0005065 | |
| 17-01-2012 11:17 | Tolik | Note Edited: 0005065 | |
| 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 | |
| 18-01-2012 04:26 | Tolik | Note Added: 0005076 | |
| 18-01-2012 04:32 | Tolik | Note Edited: 0005076 | |
| 18-01-2012 04:35 | Tolik | Note Edited: 0005076 | |
| 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 | |
| 19-01-2012 06:23 | DJ VK | Note Added: 0005106 | |
| 19-01-2012 07:38 | DJ VK | Note Edited: 0005106 | |
| 19-01-2012 07:39 | DJ VK | Note Edited: 0005106 | |
| 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 | => 41xxxx |
| 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 | 41xxxx => 120808 |
| 02-02-2012 10:32 | Tolik | Note Edited: 0005065 | |
| 10-10-2012 11:49 | Tolik | Status | resolved => closed |
| 08-08-2025 13:22 | zed | Category | Баг => Баг / Bug |