Memory Leaks on VirtualAlloc with BTMemoryModule

[brian]

Hello, XE6/latest madExpect, I'm using the option to report Memory Leaks on shutdown:

I am using BTMemoryModule to load a DLL from memory/resource, which triggers madExpect reporting memory leaks at the end, are these real?

link to BTMemoryModule: http://pastebin.com/2d9gTbiC

memleak report:

type: VirtualAlloc
address: $71d1000
size: 177664
access rights: ./.

main thread ($1134):
671cd432 madExcept32.dll madExceptDbg 2511 VirtualAllocCallback
006a8694 NDSTokyoTrim.exe BTMemoryModule 196 CopySections
006a8cee NDSTokyoTrim.exe BTMemoryModule 418 BTMemoryLoadLibary

type: VirtualAlloc
address: $71d0000
size: 262144
access rights: ./.

main thread ($1134):
671cd432 madExcept32.dll madExceptDbg 2511 VirtualAllocCallback
006a8ca4 NDSTokyoTrim.exe BTMemoryModule 409 BTMemoryLoadLibary

type: VirtualAlloc
address: $71d0000
size: 262144
access rights: ./.

main thread ($1134):
671cd432 madExcept32.dll madExceptDbg 2511 VirtualAllocCallback
006a8c3f NDSTokyoTrim.exe BTMemoryModule 396 BTMemoryLoadLibary

[madshi]

Why would they not be real? Usually when madExcept reports a leak, it's real. There may be bugs in madExcept, of course, but your first assumption should be that what madExcept reports is real - unless there are indications that suggest otherwise.

[brian]

These are a few of the reported leaks:

Code: Select all

  l_old_header: TImageNtHeaders;
  l_code, l_headers: Pointer;
    // reserve memory for image of library
    l_code := VirtualAlloc(Pointer(l_old_header.OptionalHeader.ImageBase), l_old_header.OptionalHeader.SizeOfImage, MEM_RESERVE, PAGE_READWRITE);
    VirtualAlloc(l_code, l_old_header.OptionalHeader.SizeOfImage, MEM_COMMIT, PAGE_READWRITE);
    CopySections(f_data, l_old_header, l_result);

they should be freed here on BTMemoryFreeLibrary

Code: Select all

f_module: PBTMemoryModule
  l_module: PBTMemoryModule;

      FreeMemory(l_module.modules);
        VirtualFree(l_module.codeBase, 0, MEM_RELEASE);
      HeapFree(GetProcessHeap(), 0, f_module);

[madshi]

Hmmmm... You're right, this is really a bug in madExcept. I'll fix it for the next release. Thanks for letting me know!

[chuchiring]

Hmmmm... You're right, this is really a bug in madExcept. I'll fix it for the next release. Thanks for letting me know!

how to get your fix before the next release? current I still have problem with FastMM & madExcept

[madshi]

http://madshi.net/madCollectionBeta.exe (installer 2.7.9.9)

[brian]

Hmmmm... You're right, this is really a bug in madExcept. I'll fix it for the next release. Thanks for letting me know!

One more with VirtualAlloc: http://blog.synopse.info/post/2010/03/1 ... ersion-1.1

Code: Select all

function JpegDecode(Buffer: pointer; BufferLen: cardinal;
  var pImg: PJpegDecode): TJpegDecodeError; stdcall;
asm     pop ebp  // delphi created a push ebp
        sub     eax, eax
        pushad
        mov     eax, dword ptr [esp + 2CH] // pImg
        mov     dword ptr [eax], 0
        mov     eax,TBLOffset+TBLSize+TBL64Size
        call    AllocMem // SSE2 ops expect 16 bytes aligned data -> no GetMem() <---------------------------


function AllocMem(Size: integer): pointer;
asm // use Windows heap for memory allocation (16 bytes align + set to zero)
        push        PAGE_READWRITE
        push        MEM_COMMIT
        push        eax
        push        0
        call        VirtualAlloc <---------------------------
end;

allocation number: 1084570
program up time: 9.23 s
type: VirtualAlloc
address: $116a0000
size: 10264
access rights: read/write

main thread ($1378):
671cd7c8 madExcept32.dll madExceptDbg 2544 VirtualAllocCallback
007851aa MalUpdater3.exe jpegdec 197 AllocMem
007889da MalUpdater3.exe jpegdec 3605 JpegDecode

[madshi]

@brian, are you sure this is a bug in madExcept? Is "VirtualFree" called for this allocated memory? If so, can you create a little demo project for me which reproduces this problem?

FWIW, the leak report seems to indicate that the allocated memory area is still readable, which suggests that it was *not* freed. This suggests that it's a real leak and not a bug in madExcept.

[brian]

Actually nevermind this one, the issue seems more complex and I'm not sure what's going on and whether it's maybe the jpeg decoder at fault: with the option to report leaks I get an exception the 1st time I call JpegDecode, "EInvalidOp/Invalid floating point operation.", but then.. if I call JpegDecode again, the 2nd time it works, and from then on.. it doesn't raise an exception again unless I restart the exe (and it never fails if I disable the resource leak setting)

[madshi]

Hmmmm... If you want me to look into that, I'd need to know which exact Delphi version you're using, and I'd need a small demo project to reproduce the issue on my development PC.

[brian]

Using XE7, but I recall the same happening in XE6 as well.

https://mega.co.nz/#!L1gHFCTK!6mRvWPmUx ... 4AbxYVs0A4

Thank you.

[madshi]

Ok, it seems that the madExcept32.dll (used for leak checking) somehow changes the FPU exception mask in such a way that floating point errors result in an exception. Funny enough, if I compile that DLL with Delphi 7, the problem does not occur. If I compile that DLL with Delphi XE2, the problem occurs. What is more: The madExcept32.dll in its initialization already calls the RTL to force floating point exceptions to be turned off - but this doesn't seem to work for XE2! Looks like a bug in Delphi.

Anyway, I've more or less worked around the issue now. At least your test project shouldn't crash, anymore, with the next madExcept version. I still need to find a clean proper fix for this, though...

[brian]

That indicates there is actually an issue in the ASM code though? (as there is a FP error if I understood correctly)

[madshi]

You mean the JpecDecode ASM code? I'm not totally sure about that. The crash occurred when the madExcept32.dll's leak checking called the RTL function "Move". That function internally uses the FPU to move memory around. For reason "Move" resulted in an FPU exception being raised. I've now fixed this problem just for "Move", and that made the JpecDecode problem go away. I'm not sure if anyone is really at fault here. For all I know, maybe the FPU exceptions were intentionally activated by JpecDecode and then me calling "Move" behind JpecDecode's back produced the problem. Or maybe it's really a bug inside of JpecDecode or inside of Move, or something. In any case, the problem appears to be fixed now in the new 4.0.11 madExcept release.

http://madshi.net/madCollection.exe (madExcept 4.0.11, installer 2.7.10.0)