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 та же проблема. |
|
|
|
>Цель этого запроса - создать инструмент, который чинит или хотя бы отбраковывает плохие файлы БД.
>При запуске программы и переходе на область с плохой БД всё виснет.
Если все так плохо, то нужно не только инструмент сделать, но и тайлохранилище от зависаний лечить. |
|
|
(0007493)
|
zed
|
19-06-2012 06:02
|
|
Какая версия ночнушки использовалась? |
|
|
(0007494)
|
Tolik
|
19-06-2012 06:02
|
|
В принципе, для этого и существует лог. Только вот что-то не помог. |
|
|
(0007495)
|
Tolik
|
19-06-2012 06:02
|
|
|
|
(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 ещё не готов?
Ещё нет. |
|
|
|
>Хотя странно, там же ж CRC32 всюду считается.
Вот я и говорю, что сначала нужно разбираться с багами тайлохранилища, а уже потом тулзу для лечения кэша городить. |
|
|
|
>>А конвертер из Беркли в кэш 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
В ближайшее время пересоберу все библиотеки (+ утилиты для восстановление кэша Беркли) в десятой студии и добавлю их вместе с ран-таймами в ночнушку. |
|