I'm hunting some memoryleaks and I use FastMM in FullDebugMode to get event logs. This works pretty fine, but the stacktrace is...not very nice at all.
A short example:
This block was allocated by thread 0x25F8, and the stack trace (return addresses) at the time was:
4081E8 [FastMM4.pas][FastMM4][_ZN7Fastmm411DebugGetMemEx][8737]
4086A5 [FastMM4.pas][FastMM4][_ZN7Fastmm413DebugAllocMemEx][9019]
F0D820 [_ZN6System8AllocMemEx]
F18A0D [_ZN6System8TMonitor6CreateEv]
F18EEB [_ZN6System8TMonitor10GetMonitorEPNS_7TObjectE]
10AE265 [_ZN6System7Classes16CheckSynchronizeEi]
54CAC7 [Vcl.Forms.pas][Vcl.Forms][_ZN3Vcl5Forms12TApplication4IdleERK6tagMSG][11044]
54B598 [Vcl.Forms.pas][Vcl.Forms][_ZN3Vcl5Forms12TApplication13HandleMessageEv][10473]
54BA24 [Vcl.Forms.pas][Vcl.Forms][_ZN3Vcl5Forms12TApplication3RunEv][10611]
566719 [ServerRunner.pas][ServerRunner][_ZN12Serverrunner9RunServerEv][113]
This is not easy readable for me. I like that unit name is in square backets, but what did happen to methods names? I understand there is fully qualified name of the method with it's arguments types. But what is the mess (like _ZN3, 5, 12, 3, Ev) injected into it?
_ZN3, 5, 12, 3, Ev
This is called name mangling.
Because it is possible to overload 2 functions with the same name (if using different parameters) the compiler needs some way to tell them apart.
The way this is done is by encoding the parameters in a vendor specific way and adding these codes to the method name.
See this question on SO: Delphi - unmangle names in BPL's
Delphi comes with a utility called tdump.exe and tdump64.exe that can decode the mangled names for you.
Someone even wrote a ruby gem for it.
tdump -e <name_of_exe>
Will do the trick and display all unmangled names.
Here's some more reading: http://www.int0x80.gr/papers/name_mangling.pdf
If you're willing to invest then MadExcept unmangles the names for you.