0

I've recently joined a new company with a suite of legacy apps written in C++ Builder 6 and am investigating some memory issues. To do this I'm using the latest Fast MM from GitHub and got it working ok with a simple BCB project.

In the actual projects, Fast MM says it can't start because 'Another third party memory manager has been installed'. After investigating this, it seems to be because of Teechart V7, which is used extensively in the projects.

If I add a Teechart control to my simple app I get the above message. We have the Teechart source code but I can't find anything in it that looks like a custom memory manager and am wondering if I can recompile it to use Fast MM. But, being a C++ Builder dev with very humble Delphi skills, I'm unsure if this is the right approach or why TeeChart causes Fast MM to think another memory manager is operating...

Any hints would be appreciated...

Andy

Ken White
  • 123,280
  • 14
  • 225
  • 444
AndyB
  • 162
  • 8
  • "*We have the Teechart source code but I can't find anything in it that looks like a custom memory manager*" - then chances are that your use of FastMM is simply installing/initializing it too late at runtime, after the standard memory manager has already been used. – Remy Lebeau Jan 15 '22 at 07:06
  • USEOBJ("FastMM4BCB.cpp"); is the second line in the project.cpp file - right after the #include. If I don't have a teechart object in the app's only form, them FastMM manager initialises and detects leaks. If I add a teechart to the main form then FastMM reports it can't initialise. I don't know how I can add FastMM earlier to my project... – AndyB Jan 16 '22 at 09:13
  • `USEOBJ()` doesn't actually do anything, it is an empty macro. In any case, have you followed [these instructions](https://stackoverflow.com/a/18961232/65863)? You might try disabling FastMM and then use [`GetMemoryManager()`](https://docwiki.embarcadero.com/Libraries/en/System.GetMemoryManager) at runtime to see if different MemoryManagers are actually being used when Teechart is used vs when it is not used. – Remy Lebeau Jan 16 '22 at 09:58
  • Thanks Remy. Yes, I've followed those instructions. So, I guess I can delete the USEOBJ() line, as it does nothing... I will try the GetMemoryManager() function. – AndyB Jan 16 '22 at 20:18
  • GetMemoryManager() showed that TeeChart was using a different memory manager and the debug module view showed the Borland memory manager was being used. There are direct calls in the teechart code to the memory manager's functions. As the legacy app is building with runtime packages (probably due to its size and linker issues) the teechart.bpl had a dependancy on the borland mm. I can fix this either by adding fastmm to teechart and rebuilding it or switching to ulink and building without runtime packages. – AndyB Jan 17 '22 at 08:16

1 Answers1

0

Teechart Pro V7 makes direct calls to the memory manager and building our app with runtime packages meant that TeeChart.bpl's dependency on the the Borland memory manager caused the problem. The simplest fix is to not include any Teechart package in the build with runtime packages list (assuming the linker can cope with the increased .EXE size) and/or use the third party ULink linker (ftp://ftp.styx.cabel.net/pub/UniLink/) which seems to cope with any size of deliverable.

Another option is to add FastMM to Teechart's projects (assuming you have the sources) and rebuild...

AndyB
  • 162
  • 8