|
Notes |
|
|
(0011268)
|
|
zed
|
|
28-04-2013 16:33
|
|
Не поверите, но у меня всё работает. Опять.
Но у вас в sdb.log я вычитал вот такую ошибку:
>EBerkeleyDBExeption: Error #2: No such file or directory
что говорит о том, что SAS скорее всего не может получить доступ к какому-то файлу или каталогу.
Чтобы точнее определить, в чём загвоздка, удалите из папки env все файлы кроме лога (log.0000000001) и положите в него DB_CONFIG из аттача.
Затем запустите SAS, словите ошибку, закройте SAS и приложите сюда файл msg.log из папки cache_db\DG\.
Можете и сами посмотреть в тот лог и проверить, чтобы у SAS был доступ на запись во все папки и ко всем файлам, к которым происходит обращение в том логе. |
|
|
|
|
|
Сделал как написано. И кэш стал открываться. Файл msg.log не создан. При закрытии программы ошибка есть. Эльф прилагаю. |
|
|
|
(0011270)
|
|
zed
|
|
28-04-2013 16:57
|
|
>И кэш стал открываться.
О, значит была проблема с теми файликами что удалили. Попробуйте запустит не удаляя их, а только заменив DB_CONFIG (кэш возьмите из того архива, что приаттачили). Интересно, что напишет в лог.
>Файл msg.log не создан.
Точно в папке DG смотрели? Должен быть по-любому (с тем DB_CONFIG, что я приложил). Либо действительно чехарда с правами на запись.
>При закрытии программы ошибка есть. Эльф прилагаю.
В аттаче только утечка памяти, и то, кэш Беркли там не светится, так что течёт что-то другое. |
|
|
|
|
|
При замене только файла DB_CONFIG (я правильно понял, что файл без расширения надо удалить, а с расширением .txt туда положить?) тайлы открываться перестали, однако лог всё равно не создаётся. Я просмотрел все близлежащие папки. Зато в sdb.log появилась ещё одна запись. Какой-то папки или файла не может найти, но какой - непонятно. |
|
|
|
(0011272)
|
|
zed
|
|
28-04-2013 17:15
|
|
>а с расширением .txt
Не должно быть никакого расширения у этого файла. |
|
|
|
(0011273)
|
|
Papazol
|
28-04-2013 17:47
(edited on: 28-04-2013 17:53) |
|
Вот теперь что-то нарисовалось. Файл лога создался. Судя по нему, программа хотела открыть файл, созданный релизом из тайлового кэша, но которого по такому пути нет. Почему его нет - понятно, это при копировании создалась лишняя папка, из которой я всё перенёс в корень. Получается, что так делать нельзя. Но остальные подобные кэши почему не открываются? Они ведь никуда не копировались, а создавались из тайловых менеджером кэша.
|
|
|
|
(0011274)
|
|
zed
|
|
28-04-2013 18:30
|
|
Проблема в том, что в файле лога log.0000000001 остался абсолютный путь к кэшу. Когда-то давно, этот баг был пофикшен и теперь в файлах лога сохраняются только относительные пути. Вот вы видимо на этот баг и напоролись, используя релиз.
Для того, чтобы заработали те остальные кэши из релиза, нужно воспользоваться утилитой sdb_util и выполнить действие Reset LSN, с автоматическим удалением содержимого папки env. После этого, ночнушка подхватит кэш как положено. |
|
|
|
(0011275)
|
|
zed
|
28-04-2013 18:54
(edited on: 28-04-2013 18:57) |
|
И проблема даже не в самом файле лога, а в файле __db.005, в котором хранится кэш открытых страниц (mem pool) и в котором так же прописаны абсолютные пути к файлам БД (в релизе). Из-за этого и падает с ошибкой. Но ноги растут из того же бага, с абсолютными путями. Просто в файле лога эта ошибка не столь критична, как в файлах __db.xxx.
|
|
|
|
|
Проделал я сброс LSN со всеми "плохими" кэшами. Но это не помогло. Всё то же самое. Хотелось бы лог создать для них, посмотреть хоть, куда программа ломится.
Кроме того, я не могу упаковать обратно в БД тайловый кэш, который я из БД вытащил. Там-то не может быть никаких лишних путей.
Если произошла утечка памяти, компьютер следует перезагрузить, или не обязательно? |
|
|
|
(0011277)
|
|
zed
|
|
28-04-2013 19:06
|
|
>Проделал я сброс LSN со всеми "плохими" кэшами. Но это не помогло.
Т.е. папка env удалилась, вы запустили ночнушку и ничего?
>Хотелось бы лог создать для них, посмотреть хоть, куда программа ломится.
ПолОжите файлик DB_CONFIG - увидите.
>Кроме того, я не могу упаковать обратно в БД тайловый кэш, который я из БД вытащил.
Это уже что-то новенькое.
>Если произошла утечка памяти, компьютер следует перезагрузить
Нет. После закрытия САС вся память назад возвращается в систему автоматически. |
|
|
|
|
|
А папка env-то и не удалилась. Должна была автоматически? Теперь как с нею? |
|
|
|
(0011279)
|
|
zed
|
|
28-04-2013 19:14
|
|
>Теперь как с нею?
sdb_util - Config - Delete env folder on finish и повторить процедуру сброса LSN. |
|
|
|
|
Оказалось несколько иначе. На самом деле, папки env удалились, галка там стояла. Но при запуске программы эти папки создались заново.
Попробовал я заменить файл DB_CONFIG, чтоб лог создавался, но лог почему-то не создаётся. А в sdb.log всё та же проблема с несуществующей папкой/файлом. |
|
|
|
(0011282)
|
|
zed
|
|
28-04-2013 19:33
|
|
|
Выложите проблемную папку env. |
|
|
|
|
|
http://rghost.ru/45630211 |
|
|
|
(0011284)
|
|
zed
|
|
28-04-2013 19:43
|
|
Что-то тут не то. Вы точно не запускали релиз после того как сделали сброс LSN и удаление папки env?
Дело в том, что ночнушка сейчас по дефолту создаёт несколько большие буфера в env, т.е. к примеру файл __db.004 (буфер лога) должен весить 2Мб, а в вашем env размеры буферов такие, как в предыдущем релизе/старых ночнушках. |
|
|
|
|
В релизе нет дебажного exe-шника.
Думаю, надо взять тайм-аут до завтра, голова совсем уже не варит... |
|
|
|
|
|
Пока ничего не изменилось. Пробовал ночную 7254. |
|
|
|
(0011340)
|
|
zed
|
|
08-05-2013 07:12
|
|
>Пока ничего не изменилось
Так мы остановились на том, что у кэша Беркли, созданного при помощи старого релиза нужно удалить файлы __db.xxxx в папке env при помощи утилиты sdb_util, а затем запустить ночнушку, чтобы она создала эти файлики сама и чтобы они были бОльшего размера, чем сейчас, ввиду изменившихся дефолтных настроек. Причём нужно использовать не абы какую ночнушку, а именно последнюю. И что ещё важно - релизную версию на кэше Беркли уже запускать нельзя (никогда), иначе она опять нагадит в env.
А какой-либо доработке в самом САСе по этому поводу проводить не нужно. Описываемая вами ситуация - отголоски старого бага, который присутствует в старом релизе. Поэтому всё, что можно сделать, это вылечить старый кэш и юзать его уже только в новых версиях ночнушек. |
|
|
|
(0011349)
|
|
Papazol
|
08-05-2013 19:58
(edited on: 08-05-2013 20:00) |
|
Всё-таки что-то здесь не то... Сделал опять всё, как указано. Папка env удалилась. Запускаю программу, выбираю нужный кэш. Опять ошибка, и ничего не показывает. Папку env воссоздаёт. Но размеры файлов опять маленькие, как и раньше. Сама утилита sdb_util не изменилась? Правда, в последней ночнушке её нет.
Не знаю, напрямую это связано с моей проблемой или опосредованно, но я не могу конвертировать в Беркли тайловый кэш, который я ранее конвертировал из Беркли, но релизом. В тайловом-то кэше какие могут быть косяки, не позволяющие его упаковать? Он последней ночнушкой свободно открывается, как, впрочем, и предыдущими, это же обычный тайловый.
|
|
|
|
(0011350)
|
|
zed
|
|
08-05-2013 20:14
|
|
> Но размеры файлов опять маленькие, как и раньше.
Нонсенс. Файл DB_CONFIG появляется?
>Сама утилита sdb_util не изменилась?
Обновления утилиты регулярно публикуются в топике http://sasgis.org/forum/viewtopic.php?f=2&t=2024 |
|
|
|
|
Файл DB_CONFIG появляется:
set_flags DB_TXN_WRITE_NOSYNC on
set_lg_dir .
set_data_dir ..
set_cachesize 0 2097152 1
mutex_set_max 30000
set_lg_max 10485760
set_lg_bsize 2097152
log_set_config DB_LOG_AUTO_REMOVE on
Скачал последнюю версию sdb_util. Прогнал ею свой кэш. Всё опять то же самое. Поскольку в логе sdb есть упоминание отсутствия файла/папки, значит, ссылка на абсолютный путь не убрана. |
|
|
|
(0011355)
|
|
zed
|
|
09-05-2013 20:35
|
|
Для меня остаётся загадкой, почему при правильном DB_CONFIG создаются файлы неправильных размеров. Единственное предположение, так это то, что SAS создаёт конфиг, но по каким-то причинам не может его прочитать (хотя с чего бы вдруг?), игнорит и использует дефолтные настройки. Но даже в таком случае, должна начаться закачка карт прямо в папку env. Хотя, если вы говорите, что это старый DG, то там скорее всего включён режим "Только из кэша"?
Маловероятно, но может быть ещё проблема в русских символах в путях к кэшу, если они, конечно, есть, эти символы. Попробуйте расположить кэш по наиболее короткому пути с латинскими символами и без пробелов для надёжности. |
|
|
|
(0011356)
|
|
Papazol
|
09-05-2013 21:28
(edited on: 09-05-2013 21:30) |
|
Попробовал убрать кириллицу и пробелы, которые были. Как ни странно, это подействовало. Но только, как бы это сказать, наполовину. А именно, переименовав папку с тайловым кэшем, я тут же смог её упаковать в Беркли!
Проделав же с переименованным кэшем Беркли (другим, не этим!) процедуру сброса LSN, получил кэш без папки env, и она больше не создаётся. Соответственно, картинка не показывается, но и ошибки не возникает, по крайней мере, в части sdb, хотя утечка памяти всё равно есть. Пробовал утилитой восстановление, но никаких ошибок найдено не было.
Всё это означает, что зависимость работы от кириллицы/пробелов в названиях папок реально существует. Это не совсем хорошо. Более ранние версии к этому были лояльнее.
|
|
|
|
|
Ну всё, вроде бы эту тему можно считать закрытой.
Итак, кириллицу в названиях папок программа не приемлет напрочь. Либо это надо как-то решать, либо прямо заявить об этом, а лучше проверять и сообщать прямо в интерфейсе. Время, убитое на выявление ошибки, было слишком велико.
Все кэши, имевшие в названиях кириллицу, я переименовал, и они сразу заработали. И даже тот, у которого я удалял LSN, заработал тоже. Причём обнаружить в его названии наличие запрещённых символов оказалось непросто. Изначально он назывался "DG Рязань 2005_DB". Затем я дал ему имя "DG_Ryazan_2005_DB". Казалось бы, всё на латинице, ан нет, не работал. Обнаружено это было лишь по положению этой папки в окне Total Commander'а. Эта папка стояла не после ...Ryazan_2004..., а после всех ...Ryazan... |
|
|
|
(0011481)
|
|
zed
|
|
03-06-2013 08:23
|
|
|
Проблему с кириллицей решить можно. Если перекомпилировать либу и отключить у неё юникод (там от производителя предусмотрена директива), то всё чудесным образом начинает работать. Но мне это решение не очень нравится и нужно посмотреть, может удастся решить проблему и без перкомпиляции. |
|
|
|
|
>может удастся решить проблему и без перкомпиляции
У SQLite3 аналогичная проблема, лечится использованием AnsiToUtf8 (см. TSQLite3DbHandler.Open и сравни с OpenW). Может и тут также полечится? |
|
|
|
(0011487)
|
|
zed
|
|
03-06-2013 09:48
|
|
|
Тут тоже используется AnsiToUtf8 и сами БД нормально открываются, но где-то сбоит внутренний механизм в либе и когда она пытается достучаться до файлика DB_CONFIG выходит облом. Толи баг в либе, толи ещё хз что. |
|
|
|
(0011624)
|
|
zed
|
|
10-06-2013 17:31
|
|
Проверяйте. Сделал более-менее компромиссно: на русских путях будет работать, но изменить дефолтные настройки через DB_CONFIG не получится. Этот файл хоть и создаётся, но либа его игнорирует (вернее не может достучаться). Ну, т.е. будет всё тоже, что было и в релизе 121010.
НО консольные утилиты из комплекта sdb_util, на русских путях скорее всего правильно не заработают (так же не смогут прочитать DB_CONFIG, а для них это критично). Так что о восстановлении кэша по таким путям скорее всего придётся забыть. |
|
|
|
|
|
Уж лучше переименовать пути, но чтобы работало всё, что есть. Вот дать предупреждение о невалидных путях было бы полезно. |
|
|
|
(0011628)
|
|
zed
|
|
10-06-2013 18:09
|
|
|
Я могу только в лог записать сообщение, но наврят ли его кто будет читать. |
|
DB_CONFIG (664) 28-04-2013 16:34
msg.log (4,633) 28-04-2013 17:47