Notes |
|
|
Ночная сборка спотыкается всегда при экспорте "обработано 5900" см. вложение
Релиз 121010 экспортирует без ошибок. Но в релизе 121010 JNX на выходе получается пожатый с потерей качества. |
|
|
|
На последней ночной сборке (130621) подтвердить не удается.
most41rus, проверьте, пожалуйста, проявляется ли ошибка на любой выбранной области, или только на какой-то конкретной. |
|
|
|
AlexWhiter, на последней ночной, та же ошибка с той же областью см скриншот.
Потом взял другую область с того же района, она чуть больше первой, тоже ошибка (скриншот А). Загрузил область меньше, в другом районе карты, экспорт прошёл без ошибок(скришот В). Выделил в ошибочной области меньший кусок, экспорт без ошибок (скриншот С). Может размеры области и количество сохраняемых файлов как то влияют? |
|
|
|
На прямоугольной области тоже проявляется?
Какой минимальный размер области (в тайлах), при которой экспорт начинает падать?
100000 скаченных тайлов у меня нет под рукой.
Попробую загрузить, сколько смогу. Но надо знать, на каком количестве тайлов можно уже и остановиться. |
|
|
(0011737)
|
most41rus
|
21-06-2013 05:21
(edited on: 21-06-2013 05:41) |
|
Вот сейчас поставил прямоугольник 76.635 , экспорт упал. На 70.310 экспортирует.
У меня получается в таких пределах.
Upd. Сейчас упал прямоугольник на 69 000 и 62 000, что то не понятное происходит. Вот только что на 50 000 выдал ошибку.
|
|
|
|
Понятно.
Только что проверял на области с 71000 тайлами. Ошибка не вылетела.
Скачаю порядка 100000 тайлов, может быть, начнет воспроизводиться. |
|
|
|
ЕМНИП я снимками закидывал когда, там и 120 тыщ было, так что проблема может быть нев количестве тайлов как таковом |
|
|
|
Воспроизвести так и удалось. |
|
|
|
Я так понимаю, эта ошибка связана с отсутствием доступа (ERROR_NOACCESS). |
|
|
(0011764)
|
AlexWhiter
|
24-06-2013 04:02
(edited on: 24-06-2013 04:03) |
|
Не совсем так.
Если бы отсутствовал доступ, была бы ошибка 5, ERROR_ACCESS_DENIED (и именно она вылазит, если попробовать сохранить файл в каталог, для которого нет прав на запись).
А ERROR_NOACCESS - это обращение по ошибочному адресу памяти ("Invalid access to memory location").
Учитывая то, что ошибка в разных случаях происходит на различном этапе, а иногда вообще не проявляется, рискну предположить, что происходит либо что-то вроде buffer overrun'а, либо двойное разрушение какого-то объекта.
|
|
|
|
Проблема с доступом к FFile?
Вот темка есть, может поможет:
http://www.sql.ru/forum/735297/blockread-i-o-998-error |
|
|
(0011766)
|
AlexWhiter
|
24-06-2013 04:53
(edited on: 24-06-2013 04:54) |
|
most41rus, сделайте, пожалуйста, следующее: повторите возникновение ошибки, при этом не закрывайте сообщение об "I/O Error" - пусть повисит.
Откройте Task Manager, в списке процессов ткните правой кнопкой мышки по процессу SasPlanet и выберите в менюшке пункт "Создать дамп памяти" (не уверен, что в русской версии Win7 он называется именно так, но смысл должен быть схожий).
Task Manager сделает дамп памяти во временном каталоге.
Пришлите архив с этим дампом мне на электронку a.whiter@yandex.ru с указанием того, какой билд программы используется.
|
|
|
|
|
|
|
Я бы посоветовал использовать TFileStream, там на порядок более вменяемые эксепшены вылазят. |
|
|
|
vdemidov, описанная на sql.ru ситуация - результат некорректного использования blockread. blockread/blockwrite предполагают нетипизированные файлы, при открытии которых устанавливается размер блока вторым параметром reset/rewrite, который и не был указан в том случае.
С возникшей у most41rus ситуацией всё веселее - по какой-то причине в кэше оказались JPEGовые тайлы нулевой длины.
JNXLib полагается на то, что на вход поступают корректные потоки JPG, от которых перед записью откусываются первые два байта.
В случае же пустого потока получалось, что вызывается blockwrite с некорректным адресом сохраняемого буфера и отрицательной длиной, это и вызывало ошибку 998.
Для устранения я добавил в JNXLib проверку длины подсовываемого JPEGа.
most41rus уже проверил, ошибка больше не проявляется. |
|