Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Access Violation using MemoryModule for large application built with runtime packages #9

Open
ccy opened this issue Jul 4, 2020 · 0 comments

Comments

@ccy
Copy link

ccy commented Jul 4, 2020

using MemoryModule will cause access violation for large application built with runtime packages.

This happen to FixPtr function in ExecuteTLS.

This is due to the code was allocated via VirtualAlloc to allocate memory at arbitrary position:

    // reserve memory for image of library
    // XXX: is it correct to commit the complete memory region at once?
    //      calling DllEntry raises an exception if we don't...
    code := VirtualAlloc(Pointer(old_header.OptionalHeader.ImageBase),
                         old_header.OptionalHeader.SizeOfImage,
                         MEM_RESERVE or MEM_COMMIT,
                         PAGE_READWRITE);
    if code = nil then
    begin
      // try to allocate memory at arbitrary position
      code := VirtualAlloc(nil,
                           old_header.OptionalHeader.SizeOfImage,
                           MEM_RESERVE or MEM_COMMIT,
                           PAGE_READWRITE);
      if code = nil then
      begin
        SetLastError(ERROR_OUTOFMEMORY);
        Exit;
      end;
    end;

And it further affect in ExecuteTLS:

callback := FixPtr(callback);

I refer to c version of MemoryModule: https://github.com/fancycode/MemoryModule/blob/master/MemoryModule.c

It seems calling FixPtr isn't require.

ccy added a commit to eStreamSoftware/Delphi_MemoryModule that referenced this issue Jul 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant