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

gisu64vcacces.dll access violation снова

Поиск  Пользователи  Правила  Войти
Форум » Настольные приложения » GIS ToolKit, GIS ToolKit Active, ГИС Конструктор для Windows
Страницы: 1 2 След.
RSS
gisu64vcacces.dll access violation снова
 
#1
06.06.2018 13:03:09
Коллеги!


По мотивам закрытой темы http://www.gisweb.ru/forum/forum2/topic9163/messages/

Зря вы закрыли тему, т.к. проблема нестабильной работы с рандомными падениями так  и не была решена, к тому же, мы столкнулись с вновь открывшимися чудесами (о них позже), и более того: Ура!!! Мы научились железобетонно воспроизводить проблему и теперь можно наконец то отладиться и пофиксить багу.
Итак, если перед LoadLibrary gisu64vcacces.dll выделить жирный кусок памяти > 2 Гигабайт, начнутся чудеса (см приложенный load_library_crash_with_2Gb.png)

Следуя вашим рекомендациям из http://www.gisweb.ru/forum/forum2/topic9163/messages/?PAGEN_1=8 , решил слинковаться с GTK через *.lib файлы, но от этого не полегчало, чудес прибавилось.Если перед вызовом mapOpenMap выделить 2 гигабайта памяти получим access violation reading location c весьма странным callstack где то внутри shape.iml64 (см  приложенный lib_files_crash_with_2Gb.png)

Но самое интересное впереди. Если мы выделим 4 гигабайта, мы получим не reading, а тот самый writting location! И если мы нажмем кнопочку Continue в окошке студии, мы получим интересный message box от GTK - не могу найти shape.iml64 (см приложенный lib_files_crash_with_4Gb.png)

Что-то у вас с менеджером памяти, коллеги + еще возможно что-то в GTK перетирает еще и чужую память. Помните тут http://www.gisweb.ru/forum/forum2/topic9163/messages/ я вам писал, что при использовании GTK у нас были случаи, когда кто-то перетирал наши данные? У нас каким то чудным образом оказывались пустые std::string, которые заполнялись до загрузки GTK.
Прошу Вас скорейшим образом решить данную проблему. Пошел уже 8ой месяц как мы мучаемся с данной проблемой - постоянно придумываем костыли, чтобы ПО хоть как то работало, и у нас уже горят все сроки!
Тестовый проект можно скачать тут: https://cloud.mail.ru/public/4ZRD/NudxXffob
 
 
 
#2
07.06.2018 10:50:28
В ГИС-ядре (компилируется в Embarcadero) для выделения памяти используется только new и delete. По идее они работают с теми же системными функциями, что и в VS.
Первая ситуация говорит о том, что когда попросили 2 ГБ, то ntdll не смогла загрузить библиотеку. На практике сталкивались с ситуацией похожей, когда попытка запросить память больше
чем физически есть приводит к непредсказуемому поведению программы. При выделении памяти надо контролировать, что ее система выделила (проверять что вернула new).
 
 
 
#3
07.06.2018 13:31:38
Цитата
Andrey Gheleznyakov написал:
В ГИС-ядре (компилируется в Embarcadero) для выделения памяти используется только new и delete. По идее они работают с теми же системными функциями, что и в VS.
Первая ситуация говорит о том, что когда попросили 2 ГБ, то ntdll не смогла загрузить библиотеку. На практике сталкивались с ситуацией похожей, когда попытка запросить память больше
чем физически есть приводит к непредсказуемому поведению программы. При выделении памяти надо контролировать, что ее система выделила (проверять что вернула new).
Я извиняюсь, но вы что надо мной издеваетесь?!!! То что вы пишете не выдерживает ни какой критики! Я вам выслал пример, который можно собрать и запустить у себя, вы видимо этого даже не делали! Сколько уже можно морочить мне голову? Я уже устал читать тут отписки ваших сотрудников!!!! Видимо мне пора звонить в вашу компанию и просить разговор с вашим начальством!


1) new уже очень давно кидает исключение std::bad_alloc если у нее не получилось выделить память. Ознакомьтесь: http://en.cppreference.com/w/cpp/memory/new/bad_alloc
2) Проблема проявляется на разных машинах, с разной конфигурацией железа
3) На моей машине установлено 32 Гигабайта ОЗУ и при запуске тестов свободно 19 Гигабайт (см скриншоты ниже)

Давайте разбираться в проблеме и вникать в нее! С вашими библиотеками невозможно работать! Найдите и исправьте проблему, запустите мой тестовый пример наконец-то и все увидите своими глазами.
На последок, стану уже в 100500ый раз вашим тестером, посмотрите скриншоты ниже:
19gb_available2.png (157.06 КБ)
19gb_available.png (145.44 КБ)
 
 
 
#4
08.06.2018 13:52:26
Добрый день.
Хотелось бы получить обратную связь. Будет ли анализироваться данная проблема?
 
 
 
#5
13.06.2018 09:21:46
Цитата
Александр Волков написал:
Хотелось бы получить обратную связь. Будет ли анализироваться данная проблема?
Вопрос рассматривается, ответ будет дан немного позже.

Спасибо.
 
 
 
#6
27.06.2018 13:11:53
Цитата
Елена Кузнецова написал:
Цитата
 Александр Волков  написал:
Хотелось бы получить обратную связь. Будет ли анализироваться данная проблема?
Вопрос рассматривается, ответ будет дан немного позже.

Спасибо.
Добрый день!
Скажите, пожалуйста, сколько нам еще ждать? Прошло уже больше 2-х недель, но до сих пор нет ни какого решения. Нас крайне поджимают сроки, мы не можем столько ждать.
 
 
 
#7
27.06.2018 21:52:54
Тестирование библиотеки gisu64vcacces.dll пока не завершено.

Тестирование библиотеки gisu64vcacces.dll выполняется с применением:
-консольного приложения TestConsole_2008_2GB.exe (VC 2008) c выделением 2 ГБ памяти,
-консольного приложения TestConsole_2008_0GB.exe (VC 2008) без выделения памяти,
-MFC-приложения MapViewer.exe.

В ходе выполнения тестов в исходные тексты библиотеки gisu64vcacces.dll внесены следующие изменения:

1. Добавлен контроль выполнения метода GdiplusStartup при инициализации GDI+.
2. Выделение и освобождение памяти вынесено из библиотеки gisu64vcacces.dll и соответственно Embarcadero.
Собрана VC-библиотека gisu64vcmemory.dll для выделения и освобождение памяти.
Исходные тесты VC-библиотеку gisu64vcmemory.dll в папке \Source\ архива 06_27_Test.zip.
VC-библиотека gisu64vcmemory.dll содержит 2 функции:
Код
// Выделение/Освобождение памяти в библиотеках GisToll Kit
__declspec(dllexport) char * __stdcall AllocateVc(unsigned int size);
__declspec(dllexport) void __stdcall FreeVc(char * memory);

В библиотеку gisu64vcacces.dll добавлены функции:
Код
 // Функция загружает библиотеку gisu64vcmemory.dll
 // Запрашивает адреса функций AllocateVc, FreeVc
_MAPIMP int _MAPAPI mapInitAllocateVcManager();


 // Функция выгружает библиотеку gisu64vcmemory.dll
_MAPIMP int _MAPAPI mapCloseAllocateVcManager();

Промежуточные результаты тестов опубликованы в таблице \Таблица\Таблица.xlsx архива 06_27_Test.zip.
Содержимое архива 06_27_Test.zip:
\Data\           - тестовые данные,
\DLL_ТЕСТ\ - библиотеки и исполняемые модули,
\Source\       - исходные тексты тестовых модулей и библиотеки выделения/освобождения памяти,
\Таблица\    - таблица фиксации тестов.
 
 
 
#8
28.06.2018 08:58:30
Цитата
Dmitry_ написал:
Тестирование библиотеки gisu64vcacces.dll пока не завершено.
Скажите, пожалуйста, сколько еще потребуется времени для тестирования и окончательного релиза GTK?
 
 
 
#9
28.06.2018 09:42:04
Цитата
Александр Волков написал:
Цитата
 Dmitry_  написал:
Тестирование библиотеки gisu64vcacces.dll пока не завершено.
Скажите, пожалуйста, сколько еще потребуется времени для тестирования и окончательного релиза GTK?
Сроки окончания релиза GTK  сказать трудно, с вопросом разбираемся.
 
 
 
#10
28.06.2018 10:14:16
Рекомендую выделять не только 2 гигабайта при тестировании, но и больше. Когда я выделял 4 гигабайта - поведение программы менялось
 
 
 
Страницы: 1 2 След.
Читают тему (гостей: 1)



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

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