|
Notes |
|
|
|
|
Давай подробности. У меня не воспроизводится. |
|
|
|
(0006084)
|
|
Garl
|
|
14-03-2012 09:25
|
|
в карте на котороый вываливается стоит UseDwn=0
в остальном вроде всё стандартно |
|
|
|
|
|
Увы, тикет пока ни о чем. Ни версия не указана, ни какого типа тайлы, да вообще ничего. Прикрепленный elf файл вообще об утечке памяти, а не авешке. |
|
|
|
(0006088)
|
|
Garl
|
|
14-03-2012 09:31
|
|
на отдельно взятой копии с другим кэшем вылета нет.
debug версия не вылетает.
тайлы jpg нарезаные Global mapper'ом
вылетает только процесс генерации. с картинкой без каких либо пояснений. |
|
|
|
|
> на отдельно взятой копии с другим кэшем вылета нет.
Ну тогда дебаггер в руки и вперед.
И еще убедись, что вылетает билд именно моей ветки, а не собранный vasketsov-ым. |
|
|
|
(0006091)
|
|
Garl
|
14-03-2012 09:36
(edited on: 14-03-2012 09:37) |
|
вылетает сегодняшняя ночнушка
120308 всё ок
|
|
|
|
|
|
Найди хотя бы место, где вылетает. |
|
|
|
|
Ну чего, ждать этот инцидент, или потихоньку можно заливаться?
Вроде все "поверхностные" баги уже должны были отловиться... |
|
|
|
(0006113)
|
|
Garl
|
|
15-03-2012 02:58
|
|
заливаться.
поймаю - профиксим. |
|
|
|
(0006201)
|
|
Garl
|
|
19-03-2012 09:29
|
|
так же вылетает второй поток генерации вышележащих тайлов.
раньше можно было делать и 3 и 4 потока и всё работало на ура. |
|
|
|
|
Валится в файле ImagingJpeg тут:
procedure TermSource(cinfo: j_decompress_ptr);
var
Src: PSourceMgr;
begin
Src := PSourceMgr(cinfo.src);
// Move stream position back just after EOI marker so that more that one
// JPEG images can be loaded from one stream
JIO.Seek(Src.Input, -Src.Pub.bytes_in_buffer, smFromCurrent);
end;
(по крайней мере остановка тут) |
|
|
|
|
|
Похоже на то, что вылезла та же нетредсейфовость, что и при чтении. |
|
|
|
|
>вылезла та же нетредсейфовость
Если это про то, чего я тебя спрашивал - то этот кусок зовётся изнутри BeginWrite .. EndWrite.
Возможно что-то другое. |
|
|
|
|
|
Проблема в том, что в отличие от ридеров, которые создаются по 1 на каждый формат, врайтеров для каждого формата может быть несколько с разными настройками. И даже если каждый завернут в свою синхронизацию, в итоге будет авешка. |
|
|
|
|
>врайтеров для каждого формата может быть несколько с разными настройками
Ситуация простая и воспроизводимая 100%.
Беру гугл.
1. Выделяю область на 14-м уме и качаю (галку "закрыть окно" отключаю). Может и без этого шага можно.
2. Для неё же переключаюсь.на генерацию и генерю вышележащие зумы 12-7.
3. Нажимаю на запуск генерации 3-4 раза - на самом деле сколько успею, валится быстро и уверенно.
Разве тут несколько разных классов райтеров будет? |
|
|
|
|
|
Вроде бы не должно. Хорошая была гипотеза. |
|
|
|
|
может несколько экземпляров одного класса уже будут валить?
ведь то что я спрашивал - это синхронизация внутри одного "вампира", а другой там вроде как бы и нету. |
|
|
|
(0006213)
|
|
zed
|
|
20-03-2012 09:00
|
|
|
Приаттачил exe, который юзает libjpeg для чтения/записи жпегов. Проверьте на нём. По-идее, так же должна увеличиться и скорость сжатия тайлов, жаль нет счётчиков для TileSave. |
|
|
|
(0006214)
|
|
vasketsov
|
20-03-2012 09:39
(edited on: 20-03-2012 09:42) |
|
На приаттаченном ошибка не вылезла.
Но лишних 700 килобайт несколько напрягло.
>должна увеличиться и скорость сжатия тайлов
Визуально скорость генерации вышележащих стала выше, но как известно, один раз не пи#$%ас. Счётчики конечно нужны. И для tilestorage тоже.
|
|
|
|
(0006215)
|
|
Garl
|
|
20-03-2012 09:44
|
|
>который юзает libjpeg
вылетов не наблюдается :) ура |
|
|
|
(0006216)
|
|
zed
|
|
20-03-2012 09:58
|
|
>Но лишних 700 килобайт несколько напрягло.
Это дебажная версия :) Если полностью перейти на libjpeg, то размер exe наоборот должен килов на 100 уменьшиться. Этот imaging ведь тоже завязан на эту либу, только они взяли да переписали сишный код на паскаль, причём сделано это было довольно давно (лет с 10 назад) и соответственно, либа там очень старая.
>вылетов не наблюдается :) ура
Это на картах с jpeg тайлами, а на png/gif всё осталось как и прежде (а прежде оно там вылетало кстати?). |
|
|
|
(0006217)
|
|
zed
|
20-03-2012 10:09
(edited on: 20-03-2012 10:17) |
|
Может вкорячить туда же libpng и libgif, да выкинуть imaging со всеми потрохами? Но тогда нужно будет все эти либы слинковать статически.
Весь Imaging, вкомпиленный в exe, занимает ~900k. В итоге, либы будут занимать меньший размер (тем более, что они и так и так юзаются для склейки, т.е. в релизе они будут присутствовать по любому).
|
|
|
|
(0006218)
|
|
Garl
|
|
20-03-2012 10:10
|
|
тикет был открыт при падении на JPG.
до остальных форматов руки не доходили. |
|
|
|
|
>тогда нужно будет все эти либы слинковать статически
почему? |
|
|
|
(0006220)
|
|
zed
|
|
20-03-2012 10:21
|
|
Не, ну можно конечно, оставить как сейчас, но логичнее их жёстко привязать к сасу, потому как без них, сас вообще работать не будет (не сможет отображать тайлы в гуе). Сейчас, без libjpeg не работает только одна отдельно-взятая функция склейки в JPEG.
|
|
|
|
|
>без них, сас вообще работать не будет
Ну так это можно же сделать и без статической линковки либы. |
|
|
|
(0006222)
|
|
zed
|
|
20-03-2012 10:33
|
|
|
Можно, но вопрос - зачем? Чем плоха статика? |
|
|
|
|
Ну например либа заменится на новую версию.
Или переход там обязательно связан с изменением API? |
|
|
|
(0006224)
|
|
zed
|
|
20-03-2012 11:35
|
|
|
Я наверное неправильно выразился, имелся в виду способ вызова dll-ки без использования GetProcAdress, т.е. статическая загрузка dll. |
|
|
|
|
>статическая загрузка dll
Ну вот и представь себе вместо libjpeg61.dll потребуется подсунуть libjpeg8.dll без пересборки (ну или наоборот откатиться). Статическая линковка dll ведь подразумевает необходимость захардкодить её имя.
Я потому и спрашиваю про (не)изменность api этих dll (может то, о чём я волнуюсь, вообще не имеет смысла, и это совсем разные dll). |
|
|
|
(0006226)
|
|
zed
|
|
20-03-2012 12:05
|
|
>Ну вот и представь себе вместо libjpeg61.dll потребуется подсунуть libjpeg8.dll без пересборки
Нет, так нельзя, там разные структуры в интерфейсе. |
|
|
|
|
|
ну коли смена dll только через пересборку - тогда не вижу принципиальных минусов. разве что вдруг все сервисы резко откажутся от jpeg-ов и оно станет просто ненужным. |
|
|
|
(0006228)
|
|
zed
|
20-03-2012 12:25
(edited on: 20-03-2012 12:26) |
|
Без пересборки можно менять либы, у которых не изменяется "ведущая" версия (которая, как правило, выносится в имя dll):
jpeg8.dll можно заменять на любую 8-ю версию, так же, как можно обновить и jpeg62.dll (сейчас там turbo-1.1.1, а уже доступна turbo-1.2.0)
libpng15.dll можно менять на любую 1.5.xxx (в сасе сейчас лежит 1.5.7, но уже вышла 1.5.9)
zlib1.dll - лежит 1.2.5, но можно обновлять до 1.2.6
и т.д.
|
|
|
|
(0006231)
|
|
Garl
|
|
21-03-2012 07:29
|
|
в ночнушке 120321 уже libjpeg юзается?
есть траблы:
текущий зум 13, выделяем больше 1 тайла и генерим из 14 до 1 (учитывая вышележащие, может и не надо)
некоторые тайлы становятся размером 0 байт.
и соответственно не отображаются. |
|
|
|
(0006232)
|
|
zed
|
|
21-03-2012 10:09
|
|
>уже libjpeg юзается?
нет |
|
|
|
|
|
Часто AV даже просто при одной генерации вышележащих вылазит. Именно там где описано в сообщении 6202. |
|
|
|
|
|
А как сейчас с этим багом? Продолжает вылетать, и если да, то на каких форматах? |
|
|
|
(0007442)
|
|
Garl
|
|
18-06-2012 04:51
|
|
|
вроде вылета нету, но тайлы периодически не генерятся |
|
|
|
|
|
В смысле теряются? Просто не сохраняется, или поврежденное сохраняется, или процесс прекращается? На каких форматах наблюдается? |
|
|
|
(0007446)
|
|
Garl
|
|
18-06-2012 07:04
|
|
|
я первый день после больничного. как разгребусь погоняю получше с нормальным баг репортом ) ибо всё на чём вылетало находится на работе. |
|
|
|
|
|
|
|
(0007451)
|
|
Garl
|
|
18-06-2012 08:15
|
|
|
получается что программа пытается прочитать файл, который ещё дописывается :) |
|
|
|
|
|
Тоесть реально тайл сохранился, а при чтении программа получила ошибку? |
|
|
|
(0007453)
|
|
Garl
|
18-06-2012 08:26
(edited on: 18-06-2012 08:29) |
|
ага, но всёравно временами получаем тайлы = 0
|
|
|
|
|
|
Поймай в дебагере ошибку, что на err2.jpg и кинь сюда стек |
|
|
|
|
|
Просто то что видно на err.jpg это все правильно. Это ошибка чтения jpg. Все честно. Оно попыталось прочитать нулевой файл и получило ексепшен. А вот AV с err2.jpg уже странно. Как и при каких обстоятельствах она появляется? |
|
|
|
(0007456)
|
|
Garl
|
|
18-06-2012 08:42
|
|
она попала на скриншот случайно, еле поймал,
при передвижении карты - тайл отрисовался и ошибки не стало |
|
|
|
|
У меня ошибка возникала при генерации вышележащих (зум 16 из 18) если одновременно выполнены два условия:
а) текущий зум 16;
б) выбрано более одного тайла на 16 зуме.
Если текущий зум не 16 либо выбран ровно один тайл на 16-м зуме для (пере)генерации - ошибки нет.
Описанное поведение - 100% воспроизводится. |
|
|
|
(0007637)
|
|
DJ VK
|
|
25-06-2012 09:41
|
|
наблюдал это при скачке сразу двух типов тайлов PNG+JPG с сохранением в PNG.
так что дело не в JPG. |
|
|
|
(0007638)
|
|
DJ VK
|
25-06-2012 09:43
(edited on: 25-06-2012 09:45) |
|
бага появилась где-то после 5045 и намного раньше 5297 (так и не исправлена)
кому надо - берите 5045 (могу прислать), стабильная версия.
|
|
|
|
|
|
Сделал. Для всех операций через Vampyre Imaging Library глобальный лок. Тестируйте завтра и обязательно отпишитесь у кого воспроизводилась эта ошибка. |
|
|
|
(0007645)
|
|
Garl
|
|
25-06-2012 13:33
|
|
|
полёт нормальный! прям не нарадуюсь! |
|
|
|
(0007646)
|
|
zed
|
|
25-06-2012 13:39
|
|
|
Это лишь подтверждает, что проблема в библиотеке. Но с глобальным локом мы превратили работу с тайлами из многопоточной в однопоточную. |
|
|
|
|
Ну не совсем. Операции чтения с диска и перепроецирования все равно идут в других потоках независимо. Но согласен от Vampyre Imaging Library нужно отказываться.
Я попробовал чуток ее причесать для тредсейфовости и не выдержал. Слишком много там глобальных переменных. |
|
gen_prev_err.png (4,892) 14-03-2012 06:21
SASPlanet.Debug.elf (5,210) 14-03-2012 09:23
err2.jpg (72,680) 18-06-2012 08:14