Patrick Speleman wrote:

> was writing outside of a memory block.

Having now seen this may be more about memory than the database, you
need to get the FastMM code built in, with the DLL, and turn on all the
memory checking tools. If you have a problem, it will show up where it
really is, not some time later when some random code happens to fall
over on it. In particular, set the allocation block padding to
something like 100 bytes, so really get off by one array use.

--

Matthew Jones

Matthew

>Having now seen this may be more about memory than the database, you
>need to get the FastMM code built in, with the DLL, and turn on all the
>memory checking tools. If you have a problem, it will show up where it
>really is, not some time later when some random code happens to fall
>over on it. In particular, set the allocation block padding to
>something like 100 bytes, so really get off by one array use.

Does that (or MadExcept or EurekaLog) work for C++?

Roy Lambert

Roy Lambert wrote:

> Does that (or MadExcept or EurekaLog) work for C++?

Hmm, missed that! (Am I supposed to read the whole post before
commenting? 8-)

However:

"(madExcept supports Delphi 4-7, Delphi 2005-XE6 (32bit and 64bit),
Borland C++ Builder 5-6 and Borland C++ Builder 2006-XE6 (32bit only
for now). Unfortunately MSVC++ or other C++ compilers are not supported
at this time.)"

A quick Google shows that FastMM is indeed compatible with XE5.
http://delphibistro.com/?p=186

Note the comment about not putting the DLL in the IDE directory!

--

Matthew Jones

Matthew

>Hmm, missed that! (Am I supposed to read the whole post before
>commenting? 8-)

I often fail at that as well

Roy

Thanks, I'll be trying FastMM shortly. I'll let you know how it goes.

Replacing the memory manager got me thinking, and I looked at the differences between our project file and a default file for a new project (the application is a crufty old thing with all sorts of weird quirks), and I noticed that it was statically linking the runtime library. After I enabled the "link with dynamic RTL" option and copied BORLNDMM.DLL from Rad Studio XE5 to the project directory, the errors in AQTime went away. As we're also statically linking packages I'm suspecting different versions of the RTL clashing internally.

Anyway, thanks for your help!