View Issue Details

IDProjectCategoryView StatusLast Update
0001721SAS.ПланетаБаг / Bugpublic05-12-2012 13:01
ReporterPapazol Assigned Tozed  
PrioritynormalSeveritycrashReproducibilityhave not tried
Status resolvedResolutionfixed 
PlatformWindowsOSXPOS VersionProfessional SP3
Product Version.Nightly 
Target Version131111Fixed in Version131111 
Summary0001721: Крушение при конвертации кэша в БД
DescriptionСразу после нажатия "Начать" возникает Access violation.
TagsNo tags attached.
Attached Files
SASPlanet.Debug.elf (38,153 bytes)
sasmem.jpg (237,679 bytes)   
sasmem.jpg (237,679 bytes)   

Activities

vdemidov

30-11-2012 20:17

manager   ~0010094

Last edited: 30-11-2012 20:17

Судя по всему вы не выбрали тип файлов в исходном хранилище, точнее неправильно введено расширение.

Papazol

01-12-2012 08:00

reporter   ~0010099

Last edited: 01-12-2012 08:14

Ну вроде как правильно выбрал расширение.
Однако решил проверить, что у меня в кэше. И оказалось, что в папках с z9 по z14 имеются файлы *.png. Откуда они взялись - вопрос не суть, но. Получается, что если в кэш затесался хотя бы один "не такой" файл, процесс может прерваться на самом интересном месте? Хорошо, у меня сразу попался *.png, ничего не успело начаться даже. И где искать этот "не такой"?
Нельзя просто игнорировать файлы с несовпадающим расширением?

Добавлено
Удалил указанные папки с мусором. Так всё равно то же самое происходит. Указал вообще одну маленькую папку, там точно только *.jpg, не работает.

vdemidov

01-12-2012 08:12

manager   ~0010100

Нет. Оно свалилось еще до начала любых операций после того как не нашло такого зарегистрированного в программе расширения. А файлы с другим расширением оно просто не заметило бы. Все вопросы по этому конвертеру к Zed.

Papazol

01-12-2012 08:17

reporter   ~0010101

Last edited: 01-12-2012 09:38

Да, вопросы к zed. Надо, понимаешь, срочно конвертнуть, а тут вон чаго.
Самое интересное - релиз от 10 октября работает нормально с тем же кэшем.

vasketsov

01-12-2012 11:06

manager   ~0010102

Дружище, это сработала проверка на _входе_ в файловое хранилище что не определился первичный тип файла (contenttype).
Ни до какого конкретного тайла (файла), ни тем более до его чтения, ни уж тем более до СУБД дело даже не дошло.
Так что вполне очевидно, что чистка "мусора" ничего не дала.

Попробуй jpeg указать а не jpg.

Papazol

01-12-2012 11:34

reporter   ~0010103

Last edited: 01-12-2012 11:37

Во-первых, jpeg - это неправильно, если речь о расширении файлов, а поле названо именно так. И если действительно нужно там писАть jpeg, то это ваще круто! Во-вторых, я уже сконвертировал этот кэш с помощью релиза, всё прошло OK. Все параметры, устанавливаемые в окошке, абсолютно такие же, в том числе и jpg.
Вообще-то надо бы подробно описать весь процесс, а то я, например, конвертировал всего два раза, и в обоих случаях были какие-то проблемы.

Кстати, jpeg не помогает, и даже png, не имеющий разночтений, всё равно не конвертируется.
Да, а что, разве у всех остальных в последней ночнушке это нормально работает?

vdemidov

01-12-2012 11:49

manager   ~0010104

>Да, а что, разве у всех остальных в последней ночнушке это нормально работает?
Не знаю. Просто, вероятно, им никто больше не пользуется. Я этого окошка даже не видел ни разу в живую. Только разок в дизайнере открывал.

Fetser

01-12-2012 12:27

reporter   ~0010106

>Просто, вероятно, им никто больше не пользуется.
Пользуюсь регулярно, но конечно не каждый день. Последний раз конвертил 13 ноября и тогда всё сработало без вопросов. Точно какая версия программы была трудно проверить но обычно стоит ночнушка, ну максимум двух дневной давности. Сейчас проверил релиз работает, ночнушка за 19 ноября уже не работает как и все последующие. Более ранних версий увы не сохранилось.

zed

01-12-2012 13:45

manager   ~0010107

vdemidov
>Все вопросы по этому конвертеру к Zed
Вот только не нужно переводить стрелки. Да, этот конвертер делал я, но затем, ты провёл там типа рефакторинг и сломал его. Причём, очевидно, что после рефакторинга ты даже и не пробовал запускать этот конвертер, потому что валится он стабильно и БД тут совершенно ни при чём.

Баг исправил, но ночнушку придётся долго ждать, у меня пока что сильно ограничен доступ к интернету.

P.S. А раширение можно указывать в различных вариантах: "*.jpg" или ".jpg" или просто "jpg"

vdemidov

01-12-2012 14:03

manager   ~0010108

>Причём, очевидно, что после рефакторинга ты даже и не пробовал запускать этот конвертер
Конечно не пробовал. Точно так же я не проверяю еще сотню других разных функций. Я уже писал, что я вообще ни разу не запускал ибо он мне не нужен. С моей точки зрения не самый необходимый функционал. А проверяю я самый базовый. Я бы на твоем месте вообще задал расширение не полем ввода, а комбобоксом, все равно оно непредусмотренные расширения не воспримет. А еще я бы сделал выбор исходного и результирующего хранилищ двумя вариантами, или из списка zmp и тогда дополнительно ничего больше выбирать не нужно, или постороннее хранилище и тогда нужно задавать кучу параметров. Но еще раз повторяю, что мне этот функционал не нужен и переделывать я его не собираюсь.

vasketsov

01-12-2012 14:42

manager   ~0010109

>у всех остальных в последней ночнушке это нормально работает?
Я в БД копировал кэш не через конвертер, а через "операции-скопировать", с указанием версии. После реализации копирования в БД оно работает. EXE-ха есть в доработке про СУБД.

>я бы сделал выбор исходного и результирующего хранилищ двумя вариантами
Вообще говоря да. И "операции-скопировать" в принципе тоже. Вводить руками то что уже и так есть в zmp - потенциально багоопасно.

Papazol

01-12-2012 15:05

reporter   ~0010110

Есть ли вообще смысл иметь данную процедуру в двух местах одновременно? Может, оставить одно что-то, скорей всего в копировании как в более общем варианте?

vasketsov

01-12-2012 19:01

manager   ~0010112

>смысл иметь данную процедуру в двух местах одновременно?
Это разные процедуры.
См. 5 параграф описания хотелки 1709.

Papazol

02-12-2012 08:40

reporter   ~0010115

Хотелка 1709 чуть о другом, причём так сходу понять, о чём именно, весьма трудно. В отношении данного вопроса я понял, что различия упомянутых процедур в том, что одна из них обрабатывает весь кэш, а другая - только выделенную область. Выделенной областью может быть в том числе и весь кэш, поэтому процедура копирования может полностью охватить все случаи. Это может быть неудобно из-за необходимости выделять "весь мир", но работать-то это будет. Можно даже внести в интерфейс опцию "Выделить всё", и тогда вообще без проблем.
Так понял я, а как на самом деле?

Fetser

02-12-2012 10:36

reporter   ~0010116

Я так понимаю, что разница в том что изначально пытается программа конвертить. В случае копирования программа ищет все файлы в области и если их нет то тратит время на проверку и поиск тайлов которых нет в кэше. А менеджере кэша она не проверяет отсутствующие тайлы, а конвертит те что есть в кэше, без проверки отсутствующих.

vasketsov

02-12-2012 17:39

manager   ~0010117

>но работать-то это будет
Как быстрее скопировать папку z18, в проводнике руками, или выделив весь сир и копируя выделенную область? Понятно почему?
Так вот менеджер кэша по идее копирует как проводник СОДЕРЖИМОЕ, а не перечисляя все тайлы.

Papazol

02-12-2012 19:59

reporter   ~0010118

Ладно, согласен оставить оба варианта:)
Но проверять работоспособность придётся у обоих. Кстати, подумалось: а есть смысл конвертировать выделенную область в БД? Как применять это?
Это оффтоп, пока новую ночнушку ждём.

Dima2000

02-12-2012 20:30

developer   ~0010119

>а есть смысл конвертировать выделенную область в БД? Как применять это?
Смысл есть, например перенести на другую машину не весь многогигабайтный кэш, а лишь нужную область.

>Как быстрее скопировать папку z18, в проводнике руками, или выделив весь сир и копируя выделенную область? Понятно почему?
Кстати, если сделать новый итератор для задач перебора лишь существующих тайлов (что применимо к экспорту, копированию, удалению, даже построению карты заполнения), то можно приблизить скорость перебора к скорости менеджера кэша. Итератор при этом должен идти по папкам кэша в ограничивающем прямоугольнике и проверять найденные файлы на попадание в полигон и лишь тогда выдавать их на выход. Для оптимизации можно для каждого Х (и каждого Y/1024) сначала построить внутри список существующих файлов, проверить его на попадание в полигон, и потом выдать в сортированном по Y виде. Тогда вообще "выхлоп" будет аналогичен существующему итератору, только во много раз быстрее. Во всяком случае для дефолтного файлового кэша. Для БД не уверен.

DJ VK

03-12-2012 16:22

manager   ~0010124

Last edited: 03-12-2012 19:38

>>Сейчас проверил релиз работает, ночнушка за 19 ноября уже не работает как и все последующие.
Релиз и последующие ночнушки (недели 2 давности может) у меня работают нормально. но системный кэш растет и через некоторое время съедает всю(!) свободную озу. Она не съедается вся, но конкретно занята и все тормозит. Но это не винда глючит, а планета какими-то скрытыми механизмами винду притормаживает. По закрытию планеты ОЗУ вновь восстанавливается, приходится скачав несколько полигонов :-((( перезапускать программу. Работает после этого шустро. Скачивается сразу в Беркли, думаю дело в этом... Может только xp64 такая глючная?

vdemidov

03-12-2012 19:48

manager   ~0010126

А в чем вопрос то? Растет системный кэш так как идет работа с кучей файлов. А в случае берклидб это далеко немелкие файлы.

Issue History

Date Modified Username Field Change
30-11-2012 20:05 Papazol New Issue
30-11-2012 20:05 Papazol File Added: SASPlanet.Debug.elf
30-11-2012 20:17 vdemidov Note Added: 0010094
30-11-2012 20:17 vdemidov Note Edited: 0010094
01-12-2012 08:00 Papazol Note Added: 0010099
01-12-2012 08:01 Papazol Note Edited: 0010099
01-12-2012 08:12 vdemidov Note Added: 0010100
01-12-2012 08:14 Papazol Note Edited: 0010099
01-12-2012 08:17 Papazol Note Added: 0010101
01-12-2012 09:38 Papazol Note Edited: 0010101
01-12-2012 11:06 vasketsov Note Added: 0010102
01-12-2012 11:34 Papazol Note Added: 0010103
01-12-2012 11:36 Papazol Note Edited: 0010103
01-12-2012 11:37 Papazol Note Edited: 0010103
01-12-2012 11:49 vdemidov Note Added: 0010104
01-12-2012 12:27 Fetser Note Added: 0010106
01-12-2012 13:45 zed Note Added: 0010107
01-12-2012 14:03 vdemidov Note Added: 0010108
01-12-2012 14:42 vasketsov Note Added: 0010109
01-12-2012 15:05 Papazol Note Added: 0010110
01-12-2012 19:01 vasketsov Note Added: 0010112
02-12-2012 08:40 Papazol Note Added: 0010115
02-12-2012 10:36 Fetser Note Added: 0010116
02-12-2012 17:39 vasketsov Note Added: 0010117
02-12-2012 19:59 Papazol Note Added: 0010118
02-12-2012 20:30 Dima2000 Note Added: 0010119
03-12-2012 16:22 DJ VK Note Added: 0010124
03-12-2012 16:27 DJ VK Sticky Issue No => Yes
03-12-2012 16:27 DJ VK File Added: sasmem.jpg
03-12-2012 19:38 DJ VK Note Edited: 0010124
03-12-2012 19:48 vdemidov Note Added: 0010126
04-12-2012 06:39 vdemidov Sticky Issue Yes => No
05-12-2012 13:01 vdemidov Status new => resolved
05-12-2012 13:01 vdemidov Fixed in Version => 131111
05-12-2012 13:01 vdemidov Resolution open => fixed
05-12-2012 13:01 vdemidov Assigned To => zed
05-12-2012 13:01 vdemidov Target Version => 131111
08-08-2025 13:22 zed Category Баг => Баг / Bug