Anonymous | Login | Signup for a new account | 21-11-24 13:08 UTC |
All Projects | SAS.Планета | Домен, сайт, форум, багтрекер | Доработка карты (ZMP) | Переводы и локализации | Прочее |
My View | View Issues | Change Log | Roadmap | Search |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0001114 | SAS.Планета | [All Projects] Баг | 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 | ||||||
Platform | OS | OS Version | |||||||
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 | SASPlanet.Debug.elf [^] (145,074 bytes) 15-01-2012 18:42 SASPlanet.Debug.2.elf [^] (96,104 bytes) 15-01-2012 18:51 SASPlanet.Debug.win7.elf [^] (232,701 bytes) 17-01-2012 10:23 2012-01-17_141819.png [^] (32,579 bytes) 17-01-2012 10:25 SASPlanet.7z [^] (1,840,688 bytes) 17-01-2012 13:05 | ||||||||
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. |
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 |
My View | View Issues | Change Log | Roadmap | Search |
Copyright © 2007 - 2024 SAS.Planet Team |