Цитата | ||
---|---|---|
Елена Кузнецова написал:
Спасибо! |
Не подскажете сколько еще времени займет рассмотрение данного вопроса?
12.03.2018 10:22:57
Не подскажете сколько еще времени займет рассмотрение данного вопроса? |
|||||
|
|
12.03.2018 14:05:49
|
|||
|
|
05.04.2018 18:00:17
Очень интересует как продвигаются дела с моим насущным вопросом. Обращаю внимание, что данную проблему не могут решить с 10 ноября 2017 года! Т.е. уже практически полгода!!! В связи с этим, у меня очень большие проблемы с моим проджект менеджером. Скажите, пожалуйста, что происходит и долго ли еще будут продолжаться мои мучения?!!!! |
|||||
|
|
06.04.2018 09:13:34
Выяснение данного вопроса перешло в разряд исследований на предмет корректной совместной работы Embarcadero, Microsoft Application Verifier, Visual Studio 20** C++, в том числе в DEBUG сборках, которые требуют очень значительных временных затрат.
Изменено: |
|||
|
|
06.04.2018 10:49:41
Да изначально проблема вылезла только на одной dll, но это совершенно не означает что ее надо править только в одном месте, если она существует во всем продукте - это как то очень странно на мой взгляд превращать своих клиентов в тестеров. |
|||
|
|
06.04.2018 14:16:47
|
|||
|
|
10.04.2018 11:23:00
Начнем с того, что проблему с памятью вы до сих пор не решили. Т.е. уже полгода она существует и ни как не решается. С горем пополам вы смогли победить эту проблему при загрузке библиотеки gisu64vcacces.dll, но при этом при попытке загрузить другие библиотеки проблема снова всплывает. Это не означает что она решена, она есть и не решена и очень нам мешает. В приложении происходят падения, которые чудным образом лечатся если загрузку вашей библиотеки перенести по коду немного в другое место - это ненормально, и то что Application Verifier ругается на access violation writting location дает мне полное право утверждать, что с вашим модулем не все в порядке. Мы уже полгода мучаемся с этой проблемой попутно разрешив еще целую кучу проблем в ваших модулях. У нас уже скоро релиз, а мы все танцуем с бубном и перекидываем загрузку вашей библиотеки с одного места в другое, чтобы хоть как то работать!!! Это просто возмутительно! 01.03.2018 18:03:11 - я вам написал что при загрузке других модулей ваших библиотек проблема с access violation writting location повторяется, приложил вам скриншоты с вашего же тестового примера. Да на нем DEBUG режим. Не поленюсь снова на 5 минут стать вашим тестером!!!!! и соберу пример в Release режиме и получу опять же тот самый access violation writting location!!!! Скажите, пожалуйста, причем тут DEBUG сборка про которую вы говорите?!!! Почему вы сами не можете собрать Release сборку и получить все те же проблемы и попробовать их проанализировать (см приложенный скриншот)?!!! Качество вашей техподдержки мягко говоря обескураживает и заводит в ступор... |
|||||
|
|
14.04.2018 15:53:40
Здравствуйте!
Спасибо за ожидание и терпение. Сборки DEBUG и RELEASE в данном случае не влияют на работу. Да, в DEBUG сборках не тот уровень оптимизации и много лишнего в выходном двоичном коде, но Application Verifier как ругался, так и будет ругаться. В наших примерах присутствовала ошибка, связанная с некорректными параметрами для DEBUG сборки, что приводило к сбоям из-за различного выравнивания структур в памяти. Эта ошибка была исправлена ранее, о чем Вам было сообщено. И эта ошибка в примере не имеет отношения к корректности работы самих библиотек ГИС-ядра. Ошибка, о которой шла речь в самом начале темы, была связана с использованием Вами режима Free в нестандартном варианте. Исправленная библиотека была Вам предоставлена, поэтому вопрос с ней предлагаю считать закрытым. Теперь о тех ситуациях, которые у Вас связаны с применением Application Verifier. Как Application Verifier, как и большинство прочих средств отслеживания утечек памяти, подменяет все вызовы выделения и освобождения памяти, старта и остановки потока, работы со стеком и пр. на свои. На что вряд ли рассчитан менеджер памяти Embarcadero, с которым собраны библиотеки ГИС-ядра. Я привел Вам Вы, кстати, правильно заметили, в предупреждениях Application Verifier не было сообщения про AV. Как показали исследования данной проблемы, сообщения об Access Violation (то есть, о нарушении прав доступа к памяти) возникают при динамической загрузке в проект VC++ библиотек, использующих VCL ( Вот реакция Application Verifier на абсолютно пустую библиотеку, но с подключенной к ней VCL: 0xC0000005: Нарушение прав доступа при записи "0x0000000000002278" - это и есть AV. Адрес памяти и то, считает ли Application Verifier возможным продолжить дальнейшую работу приложения, является вариативным. Поэтому в отношении части библиотек ГИС-ядра Вы такого сообщения не наблюдаете (например, gisu64vcaccess.dll), так как они не используют VCL, а для остальных это сообщение присутствует. Application Verifier, кстати, далеко не единственная программа проверки утечек памяти, которая критично относится к Borland/Embarcadero реализациям. В некоторых средствах проверки даже были специальные настройки, чтобы лишний раз не ругаться на якобы утечки в Borland-овском (Embarcadero-вском) коде, так как они утечками по факту как правило не являются. Пример: опция "Hide Borland leaks" в утилите EurekaLog. В настоящее время мы не можем отказаться от использования Visual Component Library. Поэтому, отвечая на Ваш вопрос:
К сожалению, нельзя. Используется VCL. Библиотеки, не использующие VCL могут быть пересобраны в Visual Studio, но это полумера и даже её реализация - это не быстрый вопрос. В этом случае никаких визуальных средств не будет. Кроме того, возможно, придется отказаться еще от каких либо возможностей, реализованных на средствах Embarcsdero. Я, кстати говоря, Вам задавал уже вопрос в этой связи.
Итак, какие же выводы из всего выше сказанного? 1. Рекомендуется использовать статическую линковку библиотек ГИС-ядра вместо LoadLibrary. Статические библиотеки (*.lib) для этого пока При этом вызовы функций также следует реализовать без LoadLibrary/GetProcAdderess, так как если из библиотеки не будет ни одного статического вызова, оптимизатор VC++ просто исключит эту библиотеку из статической линковки. В этом случае неродные для VC средства VCL будут единожды загружены в память, и область памяти, занятая ими не будет перераспределяться по законам менеджера памяти Embarcadero, как это происходит каждый раз при LoadLibrary. Таким образом, приложение должно работать стабильнее, а Application Verifier, если его использовать, будет меньше ругаться и не должен реагировать на обращения к библиотеке как на AV. 2. Использовать в полной мере Application Verifier для отладки, скорее всего, не получиться. Так как он продолжит ругаться на нестандартное для него поведение менеджера памяти Embarcadero. Кроме того, старт приложения "внутри" Application Verifier может привести к краху процесса, так как работа менеджера памяти Embarcadero, с которым собраны библиотеки, в этом случае непредсказуема. |
|||||
|
|
21.05.2018 11:22:50
Не мог сразу ответить, был в командировке. Коллеги! Может быть я сильно придирчив и у меня сильно завышенные требования, но я могу хотя бы раз получить нормальный цельнолитой архив с компонентами GTK (что является мировой практикой и хорошим тоном), а не собирать его по разным ссылкам и крупицам: 1) dll и хидеры лежат по одной ссылке 2) lib файлы по другой 3) lib файл для снятия лицензии и хидер к нему вы давали мне год назад Можно ли при таком подходе рассчитывать на то, что все точно собрано одинаково, с одними флагами, хидеры соответствуют бинарям и все подходит к друг другу? У меня на этот счет возникают справедливые сомнения. Я вас очень прошу собрать все на одной машине за один раз, собрать мне целый одинарный архив где есть все что нужно. Надеюсь на ваше понимание! P.S. Люди уже давно для этих целей придумали сборочные серверы
Изменено: |
|||
|
|
22.05.2018 10:56:07
В архив gislib12x64vc.zip (Библиотеки для GIS ToolKit версия 12 для платформы "x64" (для Visual C++)) в папку \gislib12x64vc\MS Visual Studio\ добавлены библиотеки (*.lib) |
||||
|
|
|||
© КБ Панорама, 1991-2024 Регистрируясь или авторизуясь на форуме, Вы соглашаетесь с Политикой конфиденциальности |