Ошибка доступа к памяти при использовании "delayed" в Delphi XE2 с FastMM4

Delphi , Файловая система , DLL и PlugIns

Вопрос, поднятый пользователем, связан с использованием менеджера памяти FastMM4 в среде разработки Delphi XE2 при создании динамически подключаемых библиотек (DLL). Проблема заключается в том, что при использовании ключевого слова "delayed" для функций в DLL возникает ошибка доступа к памяти при закрытии приложения. Если же использовать функции без "delayed", то приложение закрывается без возникновения ошибок.

Описание проблемы и контекст:

Пользователь столкнулся с проблемой, когда пытался создать DLL с использованием ключевого слова "delayed" в Delphi XE2 с FastMM4. Основной код программы и DLL представлены ниже:

type
    function Add(X, Y : Integer) : Integer; overload; stdcall external 'MaDll.dll' delayed;

implementation
{$R *.dfm}
procedure TForm3.Button1Click(Sender : TObject);
begin
   try
      ShowMessage(IntToStr(Add(10, 5)));
   except
      on E : Exception do
         ShowMessage(E.Message);
   end;
end;
end.

library MaDll;
uses
  FastMM4,
  System.SysUtils,
  System.Classes;
{$R *.res}
function Add(X, Y : Integer) : Integer; stdcall;
begin
   Result := X + Y;
end;
exports
   Add;
begin
end.

При закрытии программы возникает ошибка доступа к памяти (EAccessViolation) в модуле MaDll.dll.

Подтвержденный ответ:

При использовании опции {$define AttemptToUseSharedMM} в FastMM4 для активации общей памяти DLL, возникает ошибка доступа к памяти. Это связано с тем, как FastMM4 управляет памятью в контексте DLL.

Альтернативный ответ и комментарии:

В комментариях обсуждается, что ошибка может быть связана с использованием отладчика, и предлагается использовать более новую версию Delphi для тестирования. Также указывается, что при активации {$define NeverUninstall} ошибка исчезает, но появляется проблема утечки памяти.

Решение проблемы:

Для решения данной проблемы следует не использовать активацию общей памяти DLL с помощью {$define AttemptToUseSharedMM}. Если это необходимо, можно активировать опцию {$define NeverUninstall}, но это приведет к утечке памяти. Вместо этого рекомендуется пересмотреть логику работы с памятью и использование DLL, возможно, пересмотреть архитектуру приложения таким образом, чтобы избежать использования "delayed" для функций в DLL.

Пример изменения кода:

{$define NeverUninstall}  // Не рекомендуется для постоянного использования

Важно помнить, что использование {$define NeverUninstall} носит временный характер и не решает проблему полностью, а лишь маскирует её. Рекомендуется тщательно изучить документацию FastMM4 и Delphi XE2, а также провести дополнительное тестирование в более новых версиях среды разработки, чтобы избежать подобных проблем и улучшить качество и надежность программного обеспечения.

Заключение:

При работе с DLL и FastMM4 в Delphi XE2 важно внимательно относиться к настройкам менеджера памяти и его взаимодействию с динамически подключаемыми библиотеками. Неправильная настройка может привести к ошибкам доступа к памяти, которые необходимо решать на этапе разработки и тестирования.

Создано по материалам из источника по ссылке.

Проблема заключается в ошибке доступа к памяти при закрытии приложения, использующего Delphi XE2 и FastMM4 для создания DLL с использованием ключевого слова 'delayed' для функций.

Комментарии и вопросы

Получайте свежие новости и обновления по Object Pascal, Delphi и Lazarus прямо в свой смартфон. Подпишитесь на наш Telegram-канал delphi_kansoftware и будьте в курсе последних тенденций в разработке под Linux, Windows, Android и iOS

:: Главная :: DLL и PlugIns ::