Форум SAS.Планета

Во первых спасибо все кто занимается проектом!

И вот возник вопрос, делаю собственную сборку, все ок было. Но при тесте на больших файлах для импорта, прога висит.

Процесс выглядит так.
1. Чистые SML файлы
2. Делаю импорт KML файлов (около 30мб) - импорт ОК, пару секунд
3. Делаю рестарт...и она просто висит... ни разу не дождался окончания.

На маленьких файлах все ок.(ну просто наверно быстрее грузятся)

Собираю на Delphi XE2 + компоненты из архива REQ. Делал полностью чистую сборку из ваших архивов, без моих изменений.
Вин 7 и 8 х64

Еще разница в размере фала между оригинальным и моим почти 3мб

Что может быть??

добавлю что повисает после вызова

Код: Выделить всё

  VMarkDb :=
    TMarkDbSml.Create(
      FDbId,
      VState,
      IncludeTrailingPathDelimiter(ABasePath) + 'marks.sml',
      AVectorItemSubsetBuilderFactory,
      FFactoryDbInternal,
      ALoadDbCounter,
      ASaveDbCounter
    );

Процедура LoadMarksFromFile

FCdsMarks.XMLData := XML; вот в этом месте зависает

eseses писал(а):Что может быть??

Если ночнушка грузит нормально, то скорее всего проблемы с юникодом.

да точно проблема с юникодом...но как решить не пойму

и кстати кто под какой IDE собирал нормально? у меня XE2 update 4

Вести с полей.

Вообщем так и не нашел я проблем именно с юникодом.

Очень странно.

Решил кинуть на главную форму компонент clientdataset и загрузить в него SML - в дизайн тайм все ок

решил проверить в рантайм

закометил все в LoadMarksFromFile

добавил

Код: Выделить всё

                  frm_main.frmMain.CD.FileName:='c:\marks.sml';
               frm_main.frmMain.CD.Active:=true;


Итог точно такой же висит...
при этом этот же в чистом приложении этот же файл и той же ИДЕ грузится за пару секунд

eseses писал(а):
и кстати кто под какой IDE собирал нормально? у меня XE2 update 4

Delphi 2007 же!

Оказывается, это баг в либе MidasLib который наблюдается только при статической линковке с MidasLib.dcu (и это наш случай). Если же в проекте закомментировать подключаемый юнит MidasLib и привязаться тем самым к внешней dll, то всё работает как часы.

Глубокое погружение в отладку показало, что баг живёт в парсере xml, а конкретно в конверторе string -> float. Под отладчиком можно увидеть, что код "висит" в функции atof в которую, по всей видимости, неправильно передаётся параметр (указатель на сишную строку), в результате чего, функция очень долго ищет символ конца строки, выходя за диапазон памяти где физически лежит xml и останавливается только за её пределами, напоровшись на случайный ноль. И так при парсинге каждого значения с плавающей точкой (а у нас их 4 на каждую метку), так что можно себе представить, какой там творится ад, при попытке распарсить даже небольшой файл меток.

Вбив в гугл "delphi midaslib bug" (хорошо, когда знаешь что искать ) довольно быстро можно найти тикет: [Regression in XE2] With MidasLib unit static linking, TClientDataSet loading XML large file takes long time откуда узнаём, что баг появился в XE2, а пофикшен только в XE6 (и то, слава богу - тикет был открыт аж в 2012 году!).