🚀 go-pugleaf

Ian Boyd wrote:

> FastMM is nice, and i like the extra validation it has in
> FullDebugMode. But the dependency on an external dll is a pain,
> bother and a danger.
> 
> Two applications have gone live with FullDebugMode defined. In one
> case an automated agent failed for two months before anyone noticed;
> costing the customer a good amount of money.

Ouch!
 
> Some of you i'm sure would respond, "Well it's your own fault for
> being careless. It's not FastMM's fault."  

Yup :)

> True enough.

OK, that's settled ;-)
 
> I want my application to run slower, be 100kB larger, and crash 
> randomly when problems are detected. Is there any way to do this?

In case you haven't, try VB ;-)


> But the solution i would like is to shoot myself in my own foot - and
> i'm looking for the gun.  I want to have the option of compiling the
> FullDebugMode.dll code into my application - so there isn't a
> dependancy on an external dll.

> We're using FastMM to replace MemCheck, which was a simple memory
> leak checker that compiled fully into the executable.

Option uno:
Not what you're looking for but it will prevent you're app from
crashing unnoticed is using the LoadDebugDLLDynamically define.

Another option would be, when not using the "sharedmem" option, to
include the code from the FastMM_FullDebugMode.dpr file, by using
another {$ifdef} in your own copy of the FastMM4.pas file.

-- 
Pieter

Hi Ian,

 > i want to have the option of compiling the
> FullDebugMode.dll code into my application - so there isn't a dependancy on 
> an external dll.

FastMM doesn't support this.  By being in a DLL the full debug code has 
its own copy of the memory manager that isn't affected by whatever 
caused the fault to trigger in the first place.  Older versions did have 
the debug code compiled in, and the debug code's allocations would hit 
the same error that triggered it in the first place, causing an endless 
loop and eventual stack overflow.

Craig

> Not what you're looking for but it will prevent you're app from
> crashing unnoticed is using the LoadDebugDLLDynamically define.

i found that define. But someone took the time to include a warning about 
using that option:

    " Note that this may cause problems due to a changed DLL unload
    order when sharing the memory manager. Use with care."

So i didn't want to blindly turn it on when it can somehow cause unspecified 
problems.

> FastMM doesn't support this.  By being in a DLL the full debug code has 
> its own copy of the memory manager that isn't affected by whatever caused 
> the fault to trigger in the first place.  Older versions did have the 
> debug code compiled in, and the debug code's allocations would hit the 
> same error that triggered it in the first place, causing an endless loop 
> and eventual stack overflow.

This wasn't all the time, right? Only special circumstances would mean that
allocations would fail?

My trying to double free a pointer, and FastMM catching it, wouldn't make
FastMM fail on everthing after that, right?

Ian Boyd wrote:

> > Not what you're looking for but it will prevent you're app from
> > crashing unnoticed is using the LoadDebugDLLDynamically define.
> 
> i found that define. But someone took the time to include a warning
> about using that option:
> 
>    " Note that this may cause problems due to a changed DLL unload
>    order when sharing the memory manager. Use with care."
> 
> So i didn't want to blindly turn it on when it can somehow cause
> unspecified problems.

Are you sharing the memory manager? That means you're already using
external DLLs and/or packages? If so, then what is the problem adding
one more file to your installation?

-- 
Pieter

> This wasn't all the time, right? Only special circumstances would mean that
> allocations would fail?

The bug that made Pierre move the code into a DLL was rare, but it was 
triggered by the contents of the stack, so you could hit it even if your 
code was perfect.

> My trying to double free a pointer, and FastMM catching it, wouldn't make
> FastMM fail on everthing after that, right?

FastMM will(should) just fail that one allocation and continue working.

Craig Peterson wrote:
>> This wasn't all the time, right? Only special circumstances would mean 
>> that
>> allocations would fail?
> 
> The bug that made Pierre move the code into a DLL was rare, but it was 
> triggered by the contents of the stack, so you could hit it even if your 
> code was perfect.

I bet that was fun to track down. <eg>

DD