На главную... Продукты | Технологии | Классификаторы | Проекты | Скачать | Цены| Форум | Статьи | Обучение | Контакты

gisu64vcacces.dll access violation

Поиск  Пользователи  Правила  Войти
Форум » Настольные приложения » GIS ToolKit, GIS ToolKit Active, ГИС Конструктор для Windows
Страницы: Пред. 1 ... 5 6 7 8 9 След.
RSS
[ Закрыто ] gisu64vcacces.dll access violation, Application Verifier выдает access violation при загрузке gisu64vcacces.dll
 
Цитата
Елена Кузнецова написал:
Цитата
 Александр Волков  написал:
Можно ли устранить данную проблему во всех модулях?
Ваш вопрос передан специалисту на рассмотрение.

Спасибо!
Добрый день!
Не подскажете сколько еще времени займет рассмотрение данного вопроса?
 
Цитата
Александр Волков написал:
Не подскажете сколько еще времени займет рассмотрение данного вопроса?
Проблемой занимаемся, точные сроки решения пока назвать не можем.
 
Цитата
Елена Кузнецова написал:
Цитата
 Александр Волков  написал:
Не подскажете сколько еще времени займет рассмотрение данного вопроса?
Проблемой занимаемся, точные сроки решения пока назвать не можем.
Коллеги!
Очень интересует как продвигаются дела с моим насущным вопросом.
Обращаю внимание, что данную проблему не могут решить с 10 ноября 2017 года! Т.е. уже практически полгода!!!
В связи с этим, у меня очень большие проблемы с моим проджект менеджером.
Скажите, пожалуйста, что происходит и долго ли еще будут продолжаться мои мучения?!!!!
 
Цитата
Александр Волков написал:
Очень интересует как продвигаются дела с моим насущным вопросом.Обращаю внимание, что данную проблему не могут решить с 10 ноября 2017 года! Т.е. уже практически полгода!!!В связи с этим, у меня очень большие проблемы с моим проджект менеджером.Скажите, пожалуйста, что происходит и долго ли еще будут продолжаться мои мучения?!!!!
Решением проблем по Вашим разным вопросам мы действительно занимаемся уже полгода. Что касается последнего вопроса, то им мы занимаемся с 12.03.2018.  
Выяснение данного вопроса перешло в разряд исследований на предмет корректной совместной работы Embarcadero, Microsoft Application Verifier, Visual Studio 20** C++, в том числе в DEBUG сборках, которые требуют очень значительных временных затрат.
Изменено: Елена Кузнецова - 06.04.2018 09:14:01
 
Цитата
Елена Кузнецова написал:
Что касается последнего вопроса, то им мы занимаемся с 12.03.2018.  
Елена это очень странно, т.к. полгода назад я обратился к вам именно с этим вопросом, а сейчас вы пишите что занимаетесь им только с марта. Обратите внимание на название темы и на первые сообщения на первой странице.
Да изначально проблема вылезла только на одной dll, но это совершенно не означает что ее надо править только в одном месте, если она существует во всем продукте - это как то очень странно на мой взгляд превращать своих клиентов в тестеров.
 
Цитата
Александр Волков написал:
Елена это очень странно, т.к. полгода назад я обратился к вам именно с этим вопросом, а сейчас вы пишите что занимаетесь им только с марта. Обратите внимание на название темы и на первые сообщения на первой странице.Да изначально проблема вылезла только на одной dll, но это совершенно не означает что ее надо править только в одном месте, если она существует во всем продукте - это как то очень странно на мой взгляд превращать своих клиентов в тестеров.
Вы обращались к нам 10.11.2017 по поводу проблем с распределением памяти. На данный момент мы по Вашей просьбе от 12.03.2018 занимаемся исследованиями на предмет корректной совместной работы Embarcadero, Microsoft Application Verifier, Visual Studio 20** C++, в DEBUG сборках.  
 
Цитата
Елена Кузнецова написал:
Цитата
 Александр Волков  написал:
Елена это очень странно, т.к. полгода назад я обратился к вам именно с этим вопросом, а сейчас вы пишите что занимаетесь им только с марта. Обратите внимание на название темы и на первые сообщения на первой странице.Да изначально проблема вылезла только на одной dll, но это совершенно не означает что ее надо править только в одном месте, если она существует во всем продукте - это как то очень странно на мой взгляд превращать своих клиентов в тестеров.
Вы обращались к нам 10.11.2017 по поводу проблем с распределением памяти. На данный момент мы по Вашей просьбе от 12.03.2018 занимаемся исследованиями на предмет корректной совместной работы Embarcadero, Microsoft Application Verifier, Visual Studio 20** C++, в DEBUG сборках.  
Елена это не так.
Начнем с того, что проблему с памятью вы до сих пор не решили. Т.е. уже полгода она существует и ни как не решается. С горем пополам вы смогли победить эту проблему при загрузке библиотеки 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 сборку и получить все те же проблемы и попробовать их проанализировать (см приложенный скриншот)?!!! Качество вашей техподдержки мягко говоря обескураживает и заводит в ступор...
access_violation.png (161.89 КБ)
 
Здравствуйте!
Спасибо за ожидание и терпение.

Сборки DEBUG и RELEASE в данном случае не влияют на работу. Да, в DEBUG сборках не тот уровень оптимизации и много лишнего в выходном двоичном коде, но Application Verifier как ругался, так и будет ругаться.
В наших примерах присутствовала ошибка, связанная с некорректными параметрами для DEBUG сборки, что приводило к сбоям из-за различного выравнивания структур в памяти.
Эта ошибка была исправлена ранее, о чем Вам было сообщено.
И эта ошибка в примере не имеет отношения к корректности работы самих библиотек ГИС-ядра.

Ошибка, о которой шла речь в самом начале темы, была связана с использованием Вами режима Free в нестандартном варианте.
Исправленная библиотека была Вам предоставлена, поэтому вопрос с ней предлагаю считать закрытым.



Теперь о тех ситуациях, которые у Вас связаны с применением Application Verifier.

Как я уже писал Вам ранее, было бы чудом, если бы Application Verifier никак не среагировал бы на библиотеки не-Microsoft-овского формата, которые собраны со своим менеджером памяти.
Application Verifier, как и большинство прочих средств отслеживания утечек памяти, подменяет все вызовы выделения и освобождения памяти, старта и остановки потока, работы со стеком и пр. на свои. На что вряд ли рассчитан менеджер памяти Embarcadero, с которым собраны библиотеки ГИС-ядра.
Я привел Вам пример реакции  Application Verifier на совершенно пустую библиотеку Embarcadero, загружаемую в проект VC++.

Вы, кстати, правильно заметили, в предупреждениях Application Verifier не было сообщения про AV.

Как показали исследования данной проблемы, сообщения об Access Violation (то есть, о нарушении прав доступа к памяти) возникают при динамической загрузке в проект VC++ библиотек, использующих VCL (Visual Component Library).

Вот реакция Application Verifier на абсолютно пустую библиотеку, но с подключенной к ней VCL:



0xC0000005: Нарушение прав доступа при записи "0x0000000000002278" - это и есть AV.
Адрес памяти и то, считает ли Application Verifier возможным продолжить дальнейшую работу приложения, является вариативным.

Поэтому в отношении части библиотек ГИС-ядра Вы такого сообщения не наблюдаете (например, gisu64vcaccess.dll), так как они не используют VCL, а для остальных это сообщение присутствует.

Application Verifier, кстати, далеко не единственная программа проверки утечек памяти, которая критично относится к Borland/Embarcadero реализациям.
В некоторых средствах проверки даже были специальные настройки, чтобы лишний раз не ругаться на якобы утечки в Borland-овском (Embarcadero-вском) коде, так как они утечками по факту как правило не являются.
Пример: опция "Hide Borland leaks" в утилите EurekaLog.

В настоящее время мы не можем отказаться от использования Visual Component Library.

Поэтому, отвечая на Ваш вопрос:
Цитата
Александр Волков написал:
Дмитрий, а можно собрать ядро GisToolKit в Visual Studio? Или набор библиотеек gisu64vcvecex/gisu64vcacces используют что-то из платформы Embarcadero?

К сожалению, нельзя. Используется VCL.
Библиотеки, не использующие VCL могут быть пересобраны в Visual Studio, но это полумера и даже её реализация - это не быстрый вопрос.
В этом случае никаких визуальных средств не будет. Кроме того, возможно, придется отказаться еще от каких либо возможностей, реализованных на средствах Embarcsdero.

Я, кстати говоря, Вам задавал уже вопрос в этой связи.

Цитата
Денис Вицко написал:
Используете ли Вы визуальные диалоги из состава GTK? Если Вы укажете, какие задачи Вы хотите решить с помощью GTK, мы, возможно, посоветуем какое-то решение на базе альтернативных сборок ГИС-ядра.


Итак, какие же выводы из всего выше сказанного?

1.

Рекомендуется использовать статическую линковку библиотек ГИС-ядра вместо LoadLibrary.
Статические библиотеки (*.lib) для этого пока доступны тут. Впоследствии мы их добавим в инсталляцию.
При этом вызовы функций также следует реализовать без LoadLibrary/GetProcAdderess, так как если из библиотеки не будет ни одного статического вызова, оптимизатор VC++ просто исключит эту библиотеку из статической линковки.
В этом случае неродные для VC средства VCL будут единожды загружены в память, и область памяти, занятая ими не будет перераспределяться по законам менеджера памяти Embarcadero, как это происходит каждый раз при LoadLibrary.
Таким образом, приложение должно работать стабильнее, а Application Verifier, если его использовать, будет меньше ругаться и не должен реагировать на обращения к библиотеке как на AV.

2.
Использовать в полной мере Application Verifier для отладки, скорее всего, не получиться. Так как он продолжит ругаться на нестандартное для него поведение менеджера памяти Embarcadero. Кроме того, старт приложения "внутри" Application Verifier может привести к краху процесса, так как работа менеджера памяти Embarcadero, с которым собраны библиотеки, в этом случае непредсказуема.
 
Цитата
Денис Вицко написал:

1.
Рекомендуется использовать статическую линковку библиотек ГИС-ядра вместо LoadLibrary.
Статические библиотеки (*.lib) для этого пока  доступны тут . Впоследствии мы их добавим в инсталляцию.
При этом вызовы функций также следует реализовать без LoadLibrary/GetProcAdderess, так как если из библиотеки не будет ни одного статического вызова, оптимизатор VC++ просто исключит эту библиотеку из статической линковки.
В этом случае неродные для VC средства VCL будут единожды загружены в память, и область памяти, занятая ими не будет перераспределяться по законам менеджера памяти Embarcadero, как это происходит каждый раз при LoadLibrary.
Таким образом, приложение должно работать стабильнее, а Application Verifier, если его использовать, будет меньше ругаться и не должен реагировать на обращения к библиотеке как на AV.
Здравствуйте!

Не мог сразу ответить, был в командировке.

Коллеги! Может быть я сильно придирчив и у меня сильно завышенные требования, но я могу хотя бы раз получить нормальный цельнолитой архив с компонентами GTK (что является мировой практикой и хорошим тоном), а не собирать его по разным ссылкам и крупицам:

1) dll и хидеры лежат по одной ссылке
2) lib файлы по другой
3) lib файл для снятия лицензии и хидер к нему вы давали мне год назад


Можно ли при таком подходе рассчитывать на то, что все точно собрано одинаково, с одними флагами, хидеры соответствуют бинарям и все подходит к друг другу? У меня на этот счет возникают справедливые сомнения.

Я вас очень прошу собрать все на одной машине за один раз, собрать мне целый одинарный архив где есть все что нужно. Надеюсь на ваше понимание!


P.S. Люди уже давно для этих целей придумали сборочные серверы
Изменено: Александр Волков - 21.05.2018 11:25:18
 
Цитата
Александр Волков написал:
Не мог сразу ответить, был в командировке.Коллеги! Может быть я сильно придирчив и у меня сильно завышенные требования, но я могу хотя бы раз получить нормальный цельнолитой архив с компонентами GTK (что является мировой практикой и хорошим тоном), а не собирать его по разным ссылкам и крупицам:1) dll и хидеры лежат по одной ссылке2) lib файлы по другой3) lib файл для снятия лицензии и хидер к нему вы давали мне год назадМожно ли при таком подходе рассчитывать на то, что все точно собрано одинаково, с одними флагами, хидеры соответствуют бинарям и все подходит к друг другу? У меня на этот счет возникают справедливые сомнения.Я вас очень прошу собрать все на одной машине за один раз, собрать мне целый одинарный архив где есть все что нужно. Надеюсь на ваше понимание!
На нашем сайте обновлен архив с библиотеками GTK-12.
В архив gislib12x64vc.zip (Библиотеки для GIS ToolKit версия 12 для платформы "x64" (для Visual C++)) в папку
\gislib12x64vc\MS Visual Studio\ добавлены библиотеки (*.lib)
Страницы: Пред. 1 ... 5 6 7 8 9 След.
Читают тему (гостей: 1)



© КБ Панорама, 1991-2024

Регистрируясь или авторизуясь на форуме, Вы соглашаетесь с Политикой конфиденциальности