Recent changes to support-requests

FullDebugMode and LogErrorsToFile ignored

Andreas Wedel — Thu, 27 Dec 2018 16:36:08 -0000

Hello, I am trying to set {$define FullDebugMode} and {$define LogErrorsToFile} in the FastMM4Options.inc file, but after rebuilding the application these vars are not set.
I added some extra code in the application {$ifdef FullDebugMode}... and these lines
do not get compiled. When i change other vars in the inc-file they are loaded correctly.
In my opinion there is no other option set that .undef's the definition. I'm on this for hours and
don't know how to solve. I attched the inc.-file hoping you can help me or give me a clue.

Thank's a lot.

I'm using Delphi 2007, FastMM version 4.991 and the FastMM_FullDebugMode.dll is in the application directory.

FastMM LogAllocatedBlocksToFile in ShareMM

Ciuly — Fri, 05 Sep 2014 07:50:23 -0000

I have a bunch of EXEs dynamically loading another bunch of DLLs, most of them exposing COM objects.

Now I'm trying to debug one of these DLLs using one of the EXEs.

All projects are compiled with latest FastMM4 (4.991) with ShareMM and such, in fulldebugmode.

There is a routine that has some weird object creation/assign/destruction behavior so I was thinking to log those to catch the objects destroyed by it which were not created by it.

I use SetMMLogFileName('before') and LogAllocatedBlocksToFile(0, 0); to have a snapshot of whatever exists before the routine starts it's work.

Then do a PushALlocationGroup(1) and after the routine finishes, I do similar calls as above.

The problem is, nothing is logged. That kind of makes sense since the routine is executed in the DLL and the main MM is initialized by the EXE (already confirmed this in debugging).

So basically I need to make the log allocation blocks routines in FastMM share-aware. I looked over the code but I can't seem to figure out how to do that.

Anyone did this already or has some pointers to get me started?

Thanks.

Doesn't release medium blocks in FullDebugMode

Anonymous — Fri, 18 Jan 2013 08:50:36 -0000

The problem is reproduced with the following minimal example:

program test;

{$APPTYPE CONSOLE}

uses
fastmm4, sysutils;

var
p: array[1..10000] of Pointer;
i: Integer;
begin
for i := Low(p) to High(p) do
GetMem(p[i], i);
for i := Low(p) to High(p) do
FreeMem(p[i]);
end.

When compiled without FullDebugMode, the program releases OS memory after FreeMem loop (correct). It can be verified by setting breakpoint on "end." and checking memory consumption via e.g. ProcExp.
When compiled with FullDebugMode, the memory is not released. ProcExp shows that the program memory usage is >50Mb just prior to exiting.
Investigation shows that program has allocated a bunch of 1280K (medium) blocks.

Memory leak problem with fastMM

Anonymous — Wed, 18 Apr 2012 08:38:49 -0000

Hi,
We are using FastMM to detect memory leak.
In my project I am using runtime packages.
So I have checked Project-option-packages-use runtime Packages-checked
But I am not getting any leak report.
When I am uncheck that option it is reporting.
So what to do to detect memory leaks with Runtime packages option checked.

FastMM UsageTracker 64 bit support

M.Samadpour — Mon, 31 Oct 2011 02:20:43 -0000

FastMM Usage Tracker not function properly on 64bit mode.

Number of elements differs from declaration

Paul Voelker — Tue, 20 Sep 2011 19:29:29 -0000

When I compile FastMM into my project with the 'FullDebugMode' flag enabled, I get the error:

[DCC Error] FastMM4.pas(1396): E2072 Number of elements (8) differs from declaration (11)

If I compile without it, I don't get the error and can run my application. I am using the default FastMM4Options.inc file, except for turn the FullDebugMode flag on and off.

It looks like this issue was fixed a while back with issue ID: 3197933

So I am confused why I would be seeing this. I am new to FastMM, so it may be possible that I am just doing something completely wrong.

I am using C++Builder XE on a Windows 7 (64 bit).

Delphi 7 compiler error accessing IsMultiThread variable

Remy Lebeau — Mon, 14 Dec 2009 07:06:07 -0000

When FastMM4 is compiled into a package (in this case, Indy 10), installing that package produces a compiler error:

"need imported data reference...{$G}..to use IsMultiThread from FastMM4"

That error means, in short, that an imported variable is being accessed across package boundaries in code that does not allow such importing. In this case, it is the assembly code of FastGetMem(), FastFreeMem(), and FastReallocMem() that is causing the error. Variables in other packages can be imported in Pascal code, but not in assembly code. To work around the error, FastMM4 would have to access the IsMultiThread variable in a Pascal function that the assembly code calls when needed, or else the user has to compiler FastMM4 with the AssumeMultiThreaded option enabled instead.

FastMM with BDS 2007 R2

Anonymous — Thu, 09 Apr 2009 10:40:55 -0000

Hello,
I have BDS 2007 R2 and can't to start my application with FastMM. As defoul work it fine. But if I set {$define FullDebugMode} in .inc-file then goin exception on start. I'd tested it with 4.92, 4.84 and 4.72.

FastMM clash with mxOutlookBar's mxOutlookBarPro

Anonymous — Wed, 31 Dec 2008 01:52:49 -0000

Hi,
I'm a Chinese programmer,I find the FastMM clash with mxOutlookBar's mxOutlookBarPro

control,
The FastMM can induce the delphi wrong when the mxOutlookBarPro control release.
could you solve it? my fastMM version is v4.92.
CHB

DLL + String Failure?

MeW — Sun, 17 Feb 2008 22:43:48 -0000

I've got FastMM in an application and in a DLL. Whenever I've exchanged the string values through methods in the DLL, the libray cannot be unloaded without an excess violation. If I do the same without unloading the library it'll fail with a memory leak warning.

I was under the impression I could use the String type to exchange data between App and Dll. Perhaps someone could point me to my error, or report this as a bug?

Thanks in advance.

Btw. I've used the code below with Delphi6.