gisu64vcacces.dll access violation

Пользователь

Сообщений: 3267 Регистрация: 26.12.2008

14.11.2017 22:28:38

Цитата
Oleg Belenkov написал: Проблема с загрузкой библиотеки может быть, если в папке с приложением не хватает системных библиотек.

Можете прокомментировать, почему приложение собранное в GTK12 под х64
на чистом ПК просит сначала библиотеку gisu64grd.dll а только после неё gisu64acces.dll?
Причём прошу обратить внимание, если gisu64grd.dll не найдена, а gisu64acces.dll присутствует,
то даже при наличии ключа выдаётся странное сообщение:

Впрочем лучше один раз увидеть, чем прочитать "портянку" текста

Не тот глуп кто не знает, а тот, кто не знает где искать.

Andrey Gheleznyakov

Администратор

Сообщений: 2796 Регистрация: 09.06.2008

#12

15.11.2017 08:41:11

Во первых перепутаны причина и следствие. Хорошо видео было. Вызывается функция mapOpen... из gisu64acces, которая в свою очередь вызывает библиотеку gisu64grd.dll, а поскольку ее нет то ряд функций не отрабатывает и выдается предупреждение.

Александр Волков

Пользователь

Сообщений: 108 Регистрация: 25.06.2012

#13

15.11.2017 12:42:47

Цитата
Денис Вицко написал: имеем такие же ругательства со стороны Microsoft Application Verifier:

Ну ругательства не совсем такие же, нет ни одного упоминания про Access violation writing location, и как я понял все ошибки валятся при попытке выгрузить пустую библиотеку. При загрузке вроде как нет сообщений.
Это очень настораживает.

Изменено: Александр Волков - 15.11.2017 12:57:45

Александр Волков

Пользователь

Сообщений: 108 Регистрация: 25.06.2012

#14

15.11.2017 13:08:23

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

Проблема возникает после загрузки библиотеки.

Т.к. у нас Free версия, то нам приходится линковаться с libgislink12x64vc.lib, которая тянет за собой зависимости из gisu64vcacces.dll, следовательно нам нужно слинковаться еще с gisu64vcacces.lib. Т.е. наша итоговая библиотека (она называется libstgismap.dll), использующая gis tool kit, явно зависит от gisu64vcacces.dll. Внутри libstgismap.dll так же производится загрузка gisu64vcvecex.dll, через LoadLibrary, т.к. lib файла от gisu64vcvecex.dll у нас нет.

При загрузке libstgismap.dll в главное приложение кем-то была перетерта память на куче. Проблема возникает еще до вызова каких либо функций из API GisToolKit, единственное что успели вызвать - это gisLink(). Если в коде изменить место загрузки библиотеки проблема может либо пропасть, либо выскочить в другом месте.

Изменено: Александр Волков - 15.11.2017 13:10:04

KFF

Пользователь

Сообщений: 3267 Регистрация: 26.12.2008

#15

15.11.2017 14:58:07

Цитата
Andrey Gheleznyakov написал: Вызывается функция mapOpen... из gisu64acces, которая в свою очередь вызывает библиотеку gisu64grd.dll, а поскольку ее нет то ряд функций не отрабатывает и выдается предупреждение.

ОК. Уточняющий вопрос.
Весь набор библиотек x64 копируется в системную папку в том числе gisu64grd.dll и gisu64acces.dll
С папки в которой размещён ЕХЕ файл удаляются обе билиотеки. Загрузка gisu64acces.dll командой LoadLibrary выполняется нормально

Вопрос: почему при запуске приложения наблюдается та же картина что и на ролике?
Получается, в компонентах ГТК12 библиотека gisu64acces.dll держится постоянно загруженной,
а gisu64grd.dll компоненты не могут найти даже по пути загруженной gsu64acces.dll ???

Не тот глуп кто не знает, а тот, кто не знает где искать.

Andrey Gheleznyakov

Администратор

Сообщений: 2796 Регистрация: 09.06.2008

#16

15.11.2017 15:19:05

1. Все gisu64 библиотеки находятся в System. ОС - Windows 7. Запускаю 64х приложение, сделанное на ГТК12. Отрываю карту. Все нормально.
2. Удаляем gisu64grd.dll из System. Запускаю 64х приложение. Ругается на отсутствие gisu64grd.dll.

Кто что не находит - не понимаю. А gsu64acces.dll в приложении на ГТК12 грузится всегда, так как к проекту подключена статически (данная библиотека нужна всегда).

Цитата
KFF написал: а gisu64grd.dll компоненты не могут найти даже по пути загруженной gsu64acces.dll ???

О.Б.: Получается, что не могут. Библиотека должна быть либо вместе с приложением в одной папке, либо в папке, зарегистрированной в реестре, как папка некоторого приложения,
либо как системная папка (но не одна из папок в системной папке Windows).

Oleg Belenkov

Администратор

Сообщений: 4114 Регистрация: 05.06.2008

#17

15.11.2017 16:11:30

Цитата
Александр Волков написал: Проблема возникает после загрузки библиотеки.

Прошу написать нам на почту panorama@gisinfo.ru
Мы вышлем новую версию lib, которая не будет зависеть от способа загрузки библиотек. Это должно устранить данную проблему. Спасибо за сообщение!

Александр Волков

Пользователь

Сообщений: 108 Регистрация: 25.06.2012

#18

17.11.2017 18:18:02

Цитата

Oleg Belenkov написал:

Цитата
Александр Волков написал: Проблема возникает после загрузки библиотеки.

Проблему это не полечило.

Александр Волков

Пользователь

Сообщений: 108 Регистрация: 25.06.2012

#19

17.11.2017 18:21:45

Цитата

Денис Вицко написал:

Я сделал абсолютно пустую библиотеку OMF (не содержащую ни одного вызова, ни одной переменной, - ничего).
При LoadLibrary этой библиотеки в тестовый проект на VC++:

Код

 int main()
{
   //HMODULE hm = ::LoadLibraryW(L"gisu64vcacces.dll");
   HMODULE hm = ::LoadLibraryW(L"testdll.dll");
   if (!hm)
      std::cerr << "LoadLibrary error!" << std::endl;
   else
      std::cout << "LoadLibrary - OK!" << std::endl;

   std::cout << "Press Enter..." << std::endl;
   std::cin.get();

   if (hm)
      FreeLibrary(hm);
    return 0;
}

имеем такие же ругательства со стороны Microsoft Application Verifier:

Скрытый текст

Цитата

=======================================
VERIFIER STOP 0000000000000201: pid 0x289C: Unloading DLL containing an active critical section.

0000000005F91C88 : Critical section address. Run !cs -s <address> to get more information.
00000000001A8DA0 : Critical section initialization stack trace. Run dps <address> to dump the stack trace.
000000000582BFE4 : DLL name address.
0000000005F80000 : DLL base address.

=======================================
This verifier stop is continuable.
After debugging it use `go' to continue.

=======================================

ConsoleApplication1.exe вызвал срабатывание точки останова.

=======================================
VERIFIER STOP 0000000000000201: pid 0x289C: Unloading DLL containing an active critical section.

0000000005F91FC0 : Critical section address. Run !cs -s <address> to get more information.
000000000019F120 : Critical section initialization stack trace. Run dps <address> to dump the stack trace.
000000000582BFE4 : DLL name address.
0000000005F80000 : DLL base address.

=======================================
This verifier stop is continuable.
After debugging it use `go' to continue.

=======================================

ConsoleApplication1.exe вызвал срабатывание точки останова.

=======================================
VERIFIER STOP 0000000000000201: pid 0x289C: Unloading DLL containing an active critical section.

0000000005F91FE8 : Critical section address. Run !cs -s <address> to get more information.
00000000001A8AE0 : Critical section initialization stack trace. Run dps <address> to dump the stack trace.
000000000582BFE4 : DLL name address.
0000000005F80000 : DLL base address.

=======================================
This verifier stop is continuable.
After debugging it use `go' to continue.

=======================================

ConsoleApplication1.exe вызвал срабатывание точки останова.

=======================================
VERIFIER STOP 0000000000000201: pid 0x289C: Unloading DLL containing an active critical section.

0000000005F92010 : Critical section address. Run !cs -s <address> to get more information.
00000000001A9090 : Critical section initialization stack trace. Run dps <address> to dump the stack trace.
000000000582BFE4 : DLL name address.
0000000005F80000 : DLL base address.

=======================================
This verifier stop is continuable.
After debugging it use `go' to continue.

=======================================

ConsoleApplication1.exe вызвал срабатывание точки останова.

=======================================
VERIFIER STOP 0000000000000350: pid 0x289C: Unloading DLL that allocated TLS index that was not freed.

000000000009ABBA : TLS index
0000000005F8E80E : Address of the code that allocated this TLS index.
000000000582BFE4 : DLL name address. Use du to dump it.
0000000005F80000 : DLL base address.

=======================================
This verifier stop is continuable.
After debugging it use `go' to continue.

=======================================

ConsoleApplication1.exe вызвал срабатывание точки останова.

=======================================
VERIFIER STOP 0000000000000900: pid 0x289C: A heap allocation was leaked.

00000000058EAFC0 : Address of the leaked allocation. Run !heap -p -a <address> to get additional information about the allocation.
0000000000196DE0 : Address to the allocation stack trace. Run dps <address> to view the allocation stack.
000000000582BFE4 : Address of the owner dll name. Run du <address> to read the dll name.
0000000005F80000 : Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.

=======================================
This verifier stop is continuable.
After debugging it use `go' to continue.

=======================================

ConsoleApplication1.exe вызвал срабатывание точки останова.

=======================================
VERIFIER STOP 0000000000000903: pid 0x289C: A virtual reservation was leaked.

000007FFFFFA0000 : Leaked reservation address.
00000000001A8EB0 : Address to the allocation stack trace. Run dps <address> to view the allocation stack.
000000000582BFE4 : Address of the owner dll name. Run du <address> to read the dll name.
0000000005F80000 : Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.

=======================================
This verifier stop is continuable.
After debugging it use `go' to continue.

=======================================

ConsoleApplication1.exe вызвал срабатывание точки останова.

"ConsoleApplication1.exe" (Win32). Выгружено "C:\GISDLL\testdll.dll"
Программа "[10396] ConsoleApplication1.exe" завершилась с кодом 0 (0x0).

Поэтому проблема, якобы обнаруженная Microsoft Application Verifier, не является проблемой.
И, к сожалению, Microsoft Application Verifier использовать для проверки не получится.

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

Пока грешить на утечки внутри gisu64vcacces.dll считаю преждевременным.

Если внимательно посмотреть приложенный лог, то в нем нет ни одного упоминания о access violation writing location, да и судя по всему все ошибки, которые выдал Application Verifier - это ошибки, возникшие при выгрузке библиотеки. Если вы сделаете LoadLibrary на gisu64access.dll, вы получите access violation writing location на загрузке, на пустой библиотеке этого сообщения нет.
Как вы можете объяснить этот факт? Все указывает на то, что внутри gisu64vcacces.dll существует какая то проблема.

Oleg Belenkov Администратор Сообщений: 4114 Регистрация: 05.06.2008	#20 18.11.2017 10:48:43 Пересобрали библиотеки в более новой версии Embarcadero C++ (v. 7). http://public.gisinfo.ru/panorama/gislib12x64vc.zip В системной папке (папке приложения после его инсталляции) должны быть системные библиотеки - borlndmm.dll (от 30.08.2014) и cc64160mt.dll Может это исправит диагностический протокол.