Цитата |
---|
Александр Волков написал: Хорошо, жду ваших тестов. Но у нас явные признаки того, что кто-то ездит по памяти, может быть gisu64vcacces.dll не причем, но все же хотелось бы удостовериться. |
Применять Microsoft Application Verifier для проверки утечек в приложении, использующем библиотеки GTK, скорее всего не получиться.
Проблема в том, что Microsoft Application Verifier, судя по всему, не умеет работать с библиотеками стандарта OMF и ожидает логику работы по стандарту COFF.
Библиотеки ядра GIS ToolKit являются библиотеками стандарта OMF.
VS работает со своим стандартом от Micrsoft - COFF.
Отличие как раз в работе с памятью (в частности - адресация параметров функций, и главное - варианты освобождения стека).
Однако, при динамической загрузке (через LoadLibrary) проблемы отличия стандартов решает сама операционная система. То есть, если в проект на VS подключать DLL не родного для него стандарта OMF, то при подключении через LoadLibrary никаких проблем с памятью быть не может.
Чтобы использовать статическую линковку OMF библиотек в проекты VS необходимы определенные "танцы с бубном" для получения *.LIB для линковки.
Если все правильно сделано, то и в этом случае утечек памяти тоже не будет.
Теперь к вопросу по использованию Microsoft Application Verifier.
Возможно, у него есть какие-то дополнительные параметры, позволяющие учесть ситуацию с библиотеками OMF, но мы об этом не знаем.
По факту Microsoft Application Verifier рассматривает подключение библиотеки не COFF стандарта и ее выгрузку уже как ошибку.
Я сделал абсолютно пустую библиотеку 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 считаю преждевременным.
PS
Используете ли Вы визуальные диалоги из состава GTK?
Если Вы укажете, какие задачи Вы хотите решить с помощью GTK, мы, возможно, посоветуем какое-то решение на базе альтернативных сборок ГИС-ядра.