FastMM crashes on 64 bits when debug info (MAP file) is present

Question

I am trying to compile an old program for 64 bits (Win7, Delphi XE7). However, I have a problem with FastMM. Instead of showing the leak report it crashes in FastMM_FullDebugMode64.dll

The error is:

---------------------------
Debugger Exception Notification
---------------------------
Project TestCompile.exe raised exception class $C0000005 with message 'c0000005 ACCESS_VIOLATION'.

This is the code necessary to reproduce the issue:

program TestCompile;
uses
  fastmm4,
  Vcl.Forms, Unit1 in 'Unit1.pas' {Form1}; {$R *.res}
begin
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.


UNIT Unit1;
...  
IMPLEMENTATION  

VAR TSL: TStringList;
procedure TForm1.Button1Click(Sender: TObject);
begin
 TSL:= TStringList.Create;  // we generate a leak here. fastmm should report this
end;

end.

As you can see there is no personal/3rd party code. All is done with Delphi code.
The DLL is the one provided with FastMM (4.992/2016) package.

It works on 32 bit. On 64 bits, it crashes the program if I run under IDe (debugger). I can only Reset the program (ctrl+f2). Outside the IDE the program just works (FastMM is configure not to show the log when running outside the IDE).

Update: This has something to do with the presence of debug info ('Map file' under 'Delphi compiler -> Linking').

I know you commented on this recently, but : http://stackoverflow.com/a/22685753/327083 — J..., Nov 15 '16 at 16:20
Can we presume, therefore, that the logging does not function correctly if you simply continue execution through this debugger exception? — J..., Nov 15 '16 at 16:21
Yes, I can continue the execution BUT my problem is different. In @IanGoldby's question, FastMM is not working in a specific case. In my case FastMM is not working AT ALL on a default/empty project. It is like FastMM was not designed to work on 64 bits (BUT I am not saying this!! Obviously it works on 64 bits - for others) — Gabriel, Nov 15 '16 at 16:24
To quote @davidheffernan - "Yes, it's quite frustrating until you realise that there's nothing wrong with your code!". I think there is something wrong with my setup! — Gabriel, Nov 15 '16 at 16:29
Yes, I could simply comment (compiler directive) fastmm when compiling for 64 bits. But it is so strange to see that FastMM is not working (in my case) AT ALL on 64 bits. Maybe there are some settings I need to change in FastMM? — Gabriel, Nov 15 '16 at 16:36
Yes, I understand - I just wanted to make sure that this was a real bug and not just a stray (normal) exception in FastMM that did not otherwise adversely affect its operation. — J..., Nov 15 '16 at 16:37
How can the latest stable version be from 2015 when he released 4.992 last month? (https://github.com/pleriche/FastMM4/releases) — Stefan Glienke, Nov 15 '16 at 16:45
Sorry, I just checked about 3 weeks about and the latest stable version was 4.991. I guess Pierre released an update the day I checked for updates :) :) I will download this new version. Anyway, the bug (?) I report doesn't seem to be present in the release log (as fixed). — Gabriel, Nov 15 '16 at 16:47
I cannot reproduce your issue. Created a new blank VCL application, button, TStringList.Create, added FULLDEBUGMODE to defines, added FastMM4 to the dpr uses, put the 64bit dll (from the precompiled folder of the FastMM repo) into the directory next to exe, debugged the application. Got the leak dialog and the text file with the call stack. — Stefan Glienke, Nov 15 '16 at 16:52
The code in the question is incomplete. I don't see the `Form1` variable declared anywhere.. — J..., Nov 15 '16 at 16:56
@J... - Sorry. Probably deleted by accident. But whatever Delphi creates for you as default VCL app, that is it. — Gabriel, Nov 15 '16 at 16:59
@BadPresident_Bad ...so, what's different with your `.inc` file? — J..., Nov 15 '16 at 17:00
UPDATE! I deleted the DPROJ file and let delphi rebuild it. It worked until I set the 'Map file' (under 'Delphi compiler -> Linking') to 'Detailed' - default was 'None'. Settings this option back to none, will not make FastMM work again. So, once broken the DPROJ file, remain broken. — Gabriel, Nov 15 '16 at 17:41
*potentially* means what it says. If you want us to look at an off-site file, put it in a location that doesn't warn that it's *potentially malicious*. Every malware site says *ignore the warnings - they're wrong*. Why should we trust some anonymous user on SO? — Ken White, Nov 15 '16 at 18:06
@KenWhite - Defining 'potentially' here is totally off-topic. please stay on-topic with some constructive comments/posts about current problem. — Gabriel, Nov 15 '16 at 18:11
Which you say after conveniently deleting your comment that defined *potentially*. And it is on-topic - you posted a link in a comment asking us to review your code, which you posted in a potentially malicious location. — Ken White, Nov 15 '16 at 18:12
I have the same trouble with 64 dll. It crashes when there is a map file, do you solve the problem? — Michael Gendelev, Oct 19 '17 at 17:31

Stefan Glienke · Accepted Answer · 2016-11-15T17:50:09.953

1

It looks like the precompiled 64bit DLL contained in the repository is outdated and does not reflect changes done in the past.

There was a potential crash when the executable does not contain debug information.

From FastMM_FullDebugMode.dpr

Version 1.61 (5 September 2010):
  - Recompiled using the latest JCL in order to fix a possible crash on shutdown
    when the executable contains no debug information. (Thanks to Hanspeter
    Widmer.)

Recompiled the DLL using a rather recent JCL and it does not crash anymore.

Also reported this: https://github.com/pleriche/FastMM4/issues/27

edited Nov 15 '16 at 17:50

answered Nov 15 '16 at 17:44

Stefan Glienke

20,860
2
48
102

I also managed to narrow down the problem to 'debug info (please see my last comment). However, my conclusion is that it crashes when the debug info is present. You say the opposite. – Gabriel Nov 15 '16 at 17:45
1. You make a reference to an old DLL (2015). This means this bug is a regression? 2. There is a place from where I can download the DLL (I don't have Jedi)? 3. I can't believe I am that only one that has this bug in millions of Delphi 64 bit users :) or.... is the community smaller and smaller. – Gabriel Nov 15 '16 at 17:49
1. I used the DLL that comes with the repository to reproduce this. 2. Recompile it yourself. JCL is open source. 3. Probably nobody did disable debug info in a debug build and use the precompiled DLL ;) – Stefan Glienke Nov 15 '16 at 17:51
maybe you should also put the link to this stackoverflow discussion? Pierre might find additional info here. – Gabriel Nov 15 '16 at 17:53
1

3. You don't understand! In my case the 'debug info' is enabled. The crash appears only when I enable it !!!!! The crash does not appears for a default project (where the debug info is disabled BY DEFAULT) :) Weird, right? – Gabriel Nov 15 '16 at 17:55
3. Additional info: it crashes it the TestCompile.map (7MB) file is present, and it works (I see the leak report) when I delete the file. But anyway, it is indeed related to the debug info. – Gabriel Nov 15 '16 at 18:00
1

I'm one of the early adopters of 64 bit Delphi. I never use the 64 bit debugger. Because it is too flaky. – David Heffernan Nov 15 '16 at 19:39
1

"Because it is too flaky" - (as a rule of thumb) we should use technologies Embarcadero releases (64bit, fmx, vcl styles etc) at 3-5 versions (years) after they have been released. They are way to unstable in the first years. Let's hope this will change with Delphi Berlin (where they seems to have repaired list quite long of bugs) – Beno Nov 21 '16 at 14:24

FastMM crashes on 64 bits when debug info (MAP file) is present

1 Answers1