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

Strange stacktrace when detecting memory leak on x64 compiled application #56

Open
UKobsa opened this issue Jul 25, 2018 · 1 comment
Open

Comments

@UKobsa
Copy link

UKobsa commented Jul 25, 2018

Hi,

I created a small Delphi XE10.2 application explicitly using FastMM4 and memory leak detection on debug mode. It creates a simple memory leak.
When compiling for Win32, the memory log looks fine:

A memory block has been leaked. The size is: 36

This block was allocated by thread 0x1398, and the stack trace (return addresses) at the time was:
419C66 [FastMM4][DebugAllocMem$qqri]
4070B2 [System.pas][System][AllocMem$qqri][4701]
642E75 [Unit1.pas][Unit1][TForm1.Button1Click][30]
591EE9 [Vcl.Controls.pas][Vcl.Controls][Controls.TControl.Click][7454]
5A9847 [Vcl.StdCtrls.pas][Vcl.StdCtrls][Stdctrls.TCustomButton.Click][5449]
5AA355 [Vcl.StdCtrls.pas][Vcl.StdCtrls][Stdctrls.TCustomButton.CNCommand][5910]
591979 [Vcl.Controls.pas][Vcl.Controls][Controls.TControl.WndProc][7338]
7750702C [GetWindowLongW]
77507038 [GetWindowLongW]
77512420 [NotifyWinEvent]
75028D07 [Unknown function at DPA_Merge]

But when compiling for Win64, the same result looks really strange:

A memory block has been leaked. The size is: 40

This block was allocated by thread 0xB44, and the stack trace (return addresses) at the time was:
426EE9 [FastMM4][_ZN7Fastmm411DebugGetMemEx]
427405 [FastMM4][_ZN7Fastmm413DebugAllocMemEx]
409380 [System.pas][System][_ZN6System8AllocMemEx][4672]
7546A4 [Unit1.pas][Unit1][_ZN5Unit16TForm112Button1ClickEPN6System7TObjectE][30]
64C9B3 [Vcl.Controls.pas][Vcl.Controls][_ZN3Vcl8Controls8TControl5ClickEv][7454]
67001B [Vcl.StdCtrls.pas][Vcl.StdCtrls][_ZN3Vcl8Stdctrls13TCustomButton5ClickEv][5449]
670F44 [Vcl.StdCtrls.pas][Vcl.StdCtrls][_ZN3Vcl8Stdctrls13TCustomButton9CNCommandERN6Winapi8Messages10TWMCommandE][5910]
40DA85 [System.pas][System][_ZN6System7TObject8DispatchEPv][17790]
64C2A0 [Vcl.Controls.pas][Vcl.Controls][_ZN3Vcl8Controls8TControl7WndProcERN6Winapi8Messages8TMessageE][7338]
6530B0 [Vcl.Controls.pas][Vcl.Controls][_ZN3Vcl8Controls11TWinControl7WndProcERN6Winapi8Messages8TMessageE][10209]
66FA65 [Vcl.StdCtrls.pas][Vcl.StdCtrls][_ZN3Vcl8Stdctrls14TButtonControl7WndProcERN6Winapi8Messages8TMessageE][5286]

Where do that strange characters come from? Is this a known problem? And howto fix it (or where to look for it)?

kind regards,
Ulrich

@GunSmoker
Copy link

Those are mangled names. Mangling includes function's prototype info in text name (e.g. arguments, types, etc.). AFAIK, FastMM does not have any code which can unmangle names. Basically, it reads what is written in .map file. If you recompile FastMM with 3rd party support (e.g. EurekaLog, madExcept, JCL) - then 3rd party code MAY unmangle names for you (depending on how you compile your project). You can also disable mangling in linker options for your project.

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

2 participants