Warning: this topic talks about using shared memory manager only. If you do not share the memory manager between executable modules (the default case) - then you can use any memory manager(s) in any combinations without limitations. Obviously, all sharing options must be turned off.

General information

Therefore, if you're using a shared memory manager - then you must ensure that all executable modules are compatible with each other. You can do this by selecting (and following) one of the following scenarios:

In other words, you can't have shared memory manager and different settings for "Enable extended memory manager" option in different modules. Consider enabling the "Enable extended memory manager" option as "using another memory manager". Obviously, in order to use shared memory manager, you must use the same memory manager in all modules. That's why you can't have different settings for "Enable extended memory manager" option.

If you're not using shared memory manager - then "Enable extended memory manager" option can be set differently for each individual module. Also, "Share memory manager" and "Use existing shared memory manager" options should be unchecked.

Important Warning: using any memory leaks detection feature with any shared memory manager (no matter how it is implemented) is a very bad idea. Consider the following case:

1. Your EXE loads DLL;

2. DLL links into your EXE's memory manager;

3. DLL allocates memory (which is actually "your EXE allocates memory");

4. DLL unloads without deallocating the memory from step 3;

5. EXE shutdowns;

6. EXE's memory leaks detection will find a leak (allocated on step 3);

7. EXE will be unable to get a meaningful report, because the DLL that allocated the memory is already unloaded.

If you want to have a useful leaks detection - you will have to refactor your DLL API by removing dependence on a shared memory manager. Moral of the story: if you are using a shared memory manager - you should turn off memory leaks checks. However, you can use other debugging memory features.

Using EurekaLog and FastMM together

Since EurekaLog is compatible with FastMM - you can (for example):

and

The above would work:

To always use EurekaLog's memory manager:

or

or

Warning: in case you use both FastMM and EurekaLog in the same module:

and

or

Using EurekaLog and Delphi (2007+) together

Starting with Delphi 2007 - there are standard AttemptToUseSharedMemoryManager and ShareMemoryManager functions, which you can use for sharing memory manager. These functions are wrappers for FastMM's sharing functionality (which is a standard memory manager since Delphi 2006).

Thus, this case is the same as "Using EurekaLog and FastMM together", but instead of FastMM and setting the "ShareMM" option you can use the ShareMemoryManager function. All notes, warnings, gotchas from the "Using EurekaLog and FastMM together" case are also applied here.

Using EurekaLog and SimpleShareMem together

The SimpleShareMem unit is a wrapper for the AttemptToUseSharedMemoryManager and ShareMemoryManager functions (see above).

Thus, this case is the same as "Using EurekaLog and FastMM together", but instead of FastMM and setting the "ShareMM" option you can use the SimpleShareMem unit. All notes, warnings, gotchas from the "Using EurekaLog and FastMM together" case are also applied here.

Using EurekaLog and borlndmm.dll or ShareMem together

EurekaLog is not compatible with BorlandMM.dll and the ShareMem unit. It is recommended to use FastMM with the "ShareMM" option (or the ShareMemoryManager function, or the SimpleShareMem unit) instead - see above. If it is not possible - then you must disable "Enable extended memory manager" option for all your EurekaLog-enabled modules (see the "General information" section above). Using of EurekaLog's debugging capabilities will be not possible.

Note: other EurekaLog's features (not memory-related) still will be accessible.

Using EurekaLog and dynamic RTL in C++ Builder together

EurekaLog is not compatible with BorlandMM.dll and the dynamic RTL in C++ Builder. It's recommended to use statically-linked RTL instead. If this is not possible - then you must disable "Enable extended memory manager" option for all your EurekaLog-enabled modules. Using of EurekaLog's debugging capabilities will be not possible.

Note: other EurekaLog's features (not memory-related) still will be accessible.

Using EurekaLog and other 3rd party memory manager together

EurekaLog is not compatible with other shared memory managers. It is recommended to use FastMM with the "ShareMM" option (or the ShareMemoryManager function, or the SimpleShareMem unit) instead - see above. If this is not possible - then you must disable "Enable extended memory manager" option for all your EurekaLog-enabled modules. Using of EurekaLog's debugging capabilities will be not possible. You may only use capabilities of your shared memory manager, but not EurekaLog.

Note: other EurekaLog's features (not memory-related) still will be accessible.

What can go wrong

If you'll use wrong settings - you can get these issues:

Typical reasons for these issues include the following:

See also: