SASGIS - SAS.Планета
View Issue Details
0001341SAS.Планета[All Projects] Багpublic19-06-2012 05:3710-10-2012 11:42
Tolik 
zed 
highcrashalways
closedfixed 
Windows7Ultimate
.Nightly 
120808120808 
0001341: Невозможно восстановить испорченный кэш Беркли
После зависания программы во время скачки нескольких зумов её пришлось убивать, кэш Беркли, естественно, попортился.
Его не удаётся восстановить известными мне способами, а именно:
verify.bat не находит битых файлов, load.bat работает, но это не помогает.
При запуске программы и переходе на область с плохой БД всё виснет.

Цель этого запроса - создать инструмент, который чинит или хотя бы отбраковывает плохие файлы БД.
1. Скачать http://narod.ru/disk/53365782001.a96e8e6c8d87711a994c5f73fff7af36/map.bad.zip.html
2. Распаковать куда-нибудь
3. Запустить verify.bat - ничего не найдёт.
4. Запустить load.bat - отработает успешно (запускать надо, т.к. логов в зипе нет).
5. Открыть карту гугла, найти Палермо (на z12), указать путь к плохому кэшу.
6. Составить карту заполнения на зуме 17 или 18.
7. Всё пропало.
БД
zip env.zip (4,515,627) 19-06-2012 05:44
http://www.sasgis.org/mantis/file_download.php?file_id=849&type=bug
zip verify.load.zip (580,533) 18-07-2012 09:31
http://www.sasgis.org/mantis/file_download.php?file_id=873&type=bug
Issue History
19-06-2012 05:37TolikNew Issue
19-06-2012 05:43zedNote Added: 0007483
19-06-2012 05:44zedSummaryНевозможно восстановить покоррапченный кэш Беркли => Невозможно восстановить испорченный кэш Беркли
19-06-2012 05:44TolikFile Added: env.zip
19-06-2012 05:45TolikNote Added: 0007484
19-06-2012 05:46zedNote Added: 0007485
19-06-2012 05:48TolikNote Added: 0007486
19-06-2012 05:49TolikNote Added: 0007487
19-06-2012 06:01vdemidovNote Added: 0007492
19-06-2012 06:02zedNote Added: 0007493
19-06-2012 06:02TolikNote Added: 0007494
19-06-2012 06:02TolikNote Added: 0007495
19-06-2012 06:33zedNote Added: 0007500
19-06-2012 06:37TolikNote Added: 0007501
19-06-2012 06:37TolikAssigned To => zed
19-06-2012 06:37TolikStatusnew => acknowledged
19-06-2012 06:37zedNote Added: 0007503
19-06-2012 06:38zedNote Added: 0007504
19-06-2012 06:40vdemidovNote Added: 0007505
19-06-2012 06:41vdemidovNote Added: 0007506
19-06-2012 06:44zedNote Added: 0007507
19-06-2012 06:46TolikNote Added: 0007508
20-06-2012 04:19TolikNote Added: 0007536
20-06-2012 07:44zedNote Added: 0007542
20-06-2012 07:45TolikNote Added: 0007543
20-06-2012 07:53zedNote Added: 0007544
20-06-2012 08:06zedNote Edited: 0007544bug_revision_view_page.php?bugnote_id=7544#r3691
20-06-2012 08:52TolikNote Added: 0007551
20-06-2012 08:57TolikNote Added: 0007552
20-06-2012 08:57TolikNote Edited: 0007552bug_revision_view_page.php?bugnote_id=7552#r3693
20-06-2012 13:04zedNote Added: 0007556
21-06-2012 07:39TolikNote Added: 0007575
21-06-2012 07:40TolikNote Edited: 0007575bug_revision_view_page.php?bugnote_id=7575#r3707
26-06-2012 18:24zedNote Added: 0007696
07-07-2012 13:24gpsMaxTag Attached: БД
08-07-2012 19:05zedAssigned Tozed =>
08-07-2012 19:05zedStatusacknowledged => feedback
08-07-2012 19:10zedNote Added: 0007782
18-07-2012 09:16TolikNote Added: 0007821
18-07-2012 09:16TolikStatusfeedback => new
18-07-2012 09:16TolikFile Added: verify.load.zip
18-07-2012 09:23TolikStatusnew => resolved
18-07-2012 09:23TolikFixed in Version => 120808
18-07-2012 09:23TolikResolutionopen => fixed
18-07-2012 09:23TolikAssigned To => zed
18-07-2012 09:31TolikFile Deleted: verify.load.zip
18-07-2012 09:31TolikFile Added: verify.load.zip
18-07-2012 09:31TolikNote Edited: 0007821bug_revision_view_page.php?bugnote_id=7821#r3789
18-07-2012 09:33TolikNote Added: 0007822
18-07-2012 09:34TolikStatusresolved => assigned
18-07-2012 09:38TolikNote Edited: 0007822bug_revision_view_page.php?bugnote_id=7822#r3791
18-07-2012 19:52zedNote Added: 0007828
18-07-2012 20:05zedNote Added: 0007829
19-07-2012 05:16TolikNote Added: 0007830
19-07-2012 05:20TolikNote Edited: 0007830bug_revision_view_page.php?bugnote_id=7830#r3795
24-07-2012 20:28vdemidovTarget Version => 120808
25-07-2012 05:45vdemidovResolutionfixed => reopened
02-08-2012 19:34zedNote Added: 0008052
03-08-2012 18:52zedStatusassigned => resolved
03-08-2012 18:52zedResolutionreopened => fixed
10-10-2012 11:42TolikStatusresolved => closed

Notes
(0007483)
zed   
19-06-2012 05:43   
>т.к. логов в зипе нет
Ммм, без логов восстановить сложно. Можно их тоже приложить для комплекта?
(0007484)
Tolik   
19-06-2012 05:45   
Ну приложил, только это уже наверняка не те логи.
(0007485)
zed   
19-06-2012 05:46   
А, и кэш я так понимаю, уже тоже после обработки батниками?
(0007486)
Tolik   
19-06-2012 05:48   
Кэш после load.bat, запуска sas (который сгенерил новый env), зависания её.

Должен же быть способ проверить целостность каждого отдельного файла?
(0007487)
Tolik   
19-06-2012 05:49   
Есть ещё кэш Both, у которого на z18 та же проблема.
(0007492)
vdemidov   
19-06-2012 06:01   
>Цель этого запроса - создать инструмент, который чинит или хотя бы отбраковывает плохие файлы БД.
>При запуске программы и переходе на область с плохой БД всё виснет.
Если все так плохо, то нужно не только инструмент сделать, но и тайлохранилище от зависаний лечить.
(0007493)
zed   
19-06-2012 06:02   
Какая версия ночнушки использовалась?
(0007494)
Tolik   
19-06-2012 06:02   
В принципе, для этого и существует лог. Только вот что-то не помог.
(0007495)
Tolik   
19-06-2012 06:02   
120613,5625
(0007500)
zed   
19-06-2012 06:33   
Карта заполнения начала строиться, и даже успело найти что-то на z18, а потом словил вот такое сообщение: "First chance exception at $7C812AFB. Exception class EBerkeleyDBExeption with message 'BerkeleyDB: Lock table is out of available object entries'. Process SASPlanet.exe (3528)" и кэш перестал работать.
После перезапуска попробовал отцентрировать карту на z18 в том месте, где карта заполнения успела показать, что тайлы есть и получил вот такое сообщение: "Exception class EImagingError with message 'Memory 0852A520 (13292 Bytes) does not contain valid image in "Joint Photographic Experts Group Image" format.'." Т.е. там какой-то мусор оказался...
(0007501)
Tolik   
19-06-2012 06:37   
А конвертер из Беркли в кэш SAS ещё не готов? Интересно бы сконвертировать и посмотреть, что в тех тайлах (если их вообще можно оттуда вытащить).
Кстати, это был бы способ лечения - спасти что-нибудь, а мусор стереть.
(0007503)
zed   
19-06-2012 06:37   
Хотя странно, там же ж CRC32 всюду считается.
(0007504)
zed   
19-06-2012 06:38   
>А конвертер из Беркли в кэш SAS ещё не готов?
Ещё нет.
(0007505)
vdemidov   
19-06-2012 06:40   
>Хотя странно, там же ж CRC32 всюду считается.
Вот я и говорю, что сначала нужно разбираться с багами тайлохранилища, а уже потом тулзу для лечения кэша городить.
(0007506)
vdemidov   
19-06-2012 06:41   
>>А конвертер из Беркли в кэш SAS ещё не готов?
> Ещё нет.
А учитывая, что он будет скорее всего на базе того же кода что и тайлохранилище, то он будет так же зависать на битых базах :)
(0007507)
zed   
19-06-2012 06:44   
Зависает оно на карте заполнения из-за большого количества запросов (это возможно отдельный косяк с недавним прикручиванием ручных транзакций), а потайлово отдаёт нормально. Так что, распаковать вполне себе возможно. Теоретически.
(0007508)
Tolik   
19-06-2012 06:46   
Не, у меня зависало и без карты заполнения, просто при переходе на плохой зум.

А насчёт багов - конечно, я надеюсь, что в процессе исследования они и выплывут.
(0007536)
Tolik   
20-06-2012 04:19   
Кстати, с той версией libdb51.dll, что в ночной сборке, db_verify.exe вообще не работает. Работает с той, что в репозитории (zedxxx-berkeleydb-1d625d3b3e37.zip).
Надо поменять dll в ночнушке.
(0007542)
zed   
20-06-2012 07:44   
В ночнушке более свежая версия dll.
(0007543)
Tolik   
20-06-2012 07:45   
тогда надо где-то откопать более свежие exe
(0007544)
zed   
20-06-2012 07:53   
(edited on: 20-06-2012 08:06)
Berkeley DB 11 gR2 (11.2.5.1.29): http://www.oracle.com/technetwork/products/berkeleydb/downloads/index-082944.html

Только и эти exe с той dll могут не заработать, т.к. dll я сам компилировал из исходников, а про exe как-то и не подумал.

(0007551)
Tolik   
20-06-2012 08:52   
Блин, удалил подозрительные зумы руками, да видать не все. Теперь при экспорте зависает! :(
(0007552)
Tolik   
20-06-2012 08:57   
Скачал эту версию, мне она бесполезна, т.к. одни исходники.
Может, новый verify отловит битые файлы, если его скомпилировать?

(0007556)
zed   
20-06-2012 13:04   
>т.к. одни исходники.
Есть там и бинарники: Berkeley DB 5.1.29.msi Windows installer http://download.oracle.com/berkeley-db/db-5.1.29.msi

>Может, новый verify отловит битые файлы,
Сомневаюсь, там же только баг-фиксы. Вот тут чейнджлог: http://download.oracle.com/otndocs/products/berkeleydb/html/changelog_5_1.html
(0007575)
Tolik   
21-06-2012 07:39   
(edited on: 21-06-2012 07:40)
Так, стёр полностью весь кэш Беркли (sat, map, both), выкачал Палермо в кэш САС, сконвертировал в МЯК, задачу выполнил, вернёмся к нашим баранам.

Сконверировал весь скачанный кэш САС в Беркли. Всё вроде хорошо, всё показывает.
Смотрю карту заполнения. На Both z18 - всё зависает.

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

Ночнушка сегодняшняя, dll оотуда.

(0007696)
zed   
26-06-2012 18:24   
Всё-таки тут была проблема не в битом кэше, а в эксепшене 'BerkeleyDB: Lock table is out of available object entries', который стал вылазить после того, как я попытался в Беркли пускать несколько тайлов под одной транзакцией. Как только я это отключил, кэш спокойно распаковался на винт.

А то, что у меня там был эксепшен 'Memory 0852A520 (13292 Bytes) does not contain valid image...' так это из-за того, что в кэше лежат *.png файлы и это не Google Sat (куда я подключал кэш) а Google Map.

Так что, если db_verify показывает, что кэш порядке, то ему можно верить на 100% и искать баги в другом месте.
(0007782)
zed   
08-07-2012 19:10   
Нужен подопытный убитый кэш Беркли, чтобы выработать методы борьбы. Приаттаченный кэш был (и есть) валидный в полном смысле слова, а проблемы были в коде САС (которые я пофиксил в баге 0001350).
(0007821)
Tolik   
18-07-2012 09:16   
(edited on: 18-07-2012 09:31)
Проверил свой битый кэш на 120718.06066 (не тот, что в аттаче).

При попадании на плохой файл всё виснет.
Скачал Berkeley DB 5.1.29.msi Windows installer http://download.oracle.com/berkeley-db/db-5.1.29.msi
Вытащил оттуда db_load и db_verify и libdb51.dll !! (приаттачил сюда).
verify ничего не нашел.
Стёр директорию env, запустил load, запустил SAS - всё открывается, не виснет, карта заполнения строится.

(0007822)
Tolik   
18-07-2012 09:33   
(edited on: 18-07-2012 09:38)
Опять-таки, с той dll, что в ночнушке, verify не работает, когда попадает на битый файл. Версии совпадают. Надо поменять в ночнушке (?)

А битого кэша пока больше нет, можно считать проблему решённой.

(0007828)
zed   
18-07-2012 19:52   
В релизе САСа присутствую библиотеки msvcp71.dll и msvcr71.dll. Это ран-тайм библиотеки визуал студии 2003 и нужны они для ECW библиотек и от них никуда не деться.

Далее, я добавил в САС библиотеку, для работы с jpeg - jpeg62.dll и эта библиотека была скомпилирована (мной) в визуал студии 2008 и стала зависима от ран-тайм библиотек msvcp90.dll и msvcr90.dll. Скомпилировать jpeg62.dll в 2003-й студии (и сделать её зависимой от msvcp71.dll и msvcr71.dll) нельзя, т.к. там ограничение, на минимальную версию для компиляции - 2005.
 
Далее, я решил добавить в САС Беркли, но оказалось, что официальная dll и утилиты скомпилированы в 2005-ой студии - это минимальная поддерживаемая версия студии. Выходило, что появлялась ещё зависимость и от msvcp80.dll и msvcr80.dll. Поэтому, чтобы немного уменьшить зоопарк с зависимостью от msvcr, я пересобрал libdb51.dll в 2008-ой студии. Возможно, не самое правильное решение, и нужно было лучше пересобрать jpeg62.dll в 2005-ой студии, но вот так я решил.

Все остальные, добавляемые мной библиотеки (libpng15, zlib1, proj480, FreeImage), я стараюсь компилировать в 2003-й студии, хотя, в идеале, лучше бы перейти на 2010-ю студию и компилировать всё в ней (за исключением ECW - он то и тормозит прогресс) и, соответственно, положить msvcp100.dll и msvcr100.dll в релиз САСа. Но это +1Мб к релизу.
(0007829)
zed   
18-07-2012 20:05   
Вот, собственно, после этого бага: 0001139 я и решил компилировать Беркли в 2008-й студии, поскольку на то, что не загружается jpeg никто не жаловался (т.е. у большинства пользователей библиотеки msvcp90.dll и msvcr90.dll стоят в системе).
(0007830)
Tolik   
19-07-2012 05:16   
(edited on: 19-07-2012 05:20)
Это какой-то вынос мозга. Надо держать на компе 3-4 версии Студии, компилировать каждую библиотеку в своей версии, а версию выбирать методом проб и ошибок???

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

И не стоит уже считать эти мегабайты к релизу. Модемы на 1200 бод (и даже на 56к) давно вымерли как динозавры.

(0008052)
zed   
02-08-2012 19:34   
http://sasgis.org/forum/viewtopic.php?f=2&t=2024#p29268

В ближайшее время пересоберу все библиотеки (+ утилиты для восстановление кэша Беркли) в десятой студии и добавлю их вместе с ран-таймами в ночнушку.