| **
Angus, FWIW, I thought better of this. While
using the release-mode C run-time may fix your problem, it’s a bad idea
to rely on that fix. Doing so relies on an assumption that
FreeARxyz uses the free() function, and will correctly free memory you allocate
with malloc(), as long as you match version of the C run-time. This is an
implementation detail of the API. You should *never* call the FreeARxyz functions unless the entire
structure you are passing was allocated by the API itself. The Remedy API provides deallocators, but
not allocators; so there is no way to guarantee that you are allocating your
own memory using an allocator compatible with Remedy’s deallocators,
unless the Remedy API allocated the memory itself. (FWIW, I can’t think
of any other libraries that provides deallocators without allocators, or vice
versa – it’s a bit odd). RTL uses this approach – it never
calls the FreeARxyz functions except on memory allocated directly from an API
call. It then uses new and delete internally for all of its own allocation. Yet
another benefit of using it… Dan From: Dan Hardy I've seen problems in the past like this if you are
malloc'ing memory with the debug version of the function, and freeing it with
the release mode version. This is what is happening if you are using the
debug multi-threaded DLL in your compiler options for your own code. The
Remedy API was compiled using the release-mode multi-threaded DLL (msvcrt.dll
vs msvcrtd.dll with VS 6.0), and the FreeARxxx functions are calling their
code; therefore you have a debug malloc and a release free. That's very
likely your cause. You can still compile your project in debug mode to
debug, but switch the release mode C runtime (which you don't need to debug
anyway). Besides that issues, I see two immediate issues in the below
code: 1. The memory leak in the for loop. You need to free
the ARInternalIdList each time - it's leaking it for every entry that matches
except the last one. 2. This code will crash if there are no matching
entries. In that case, it will call FreeARInternalIdList on an
uninitialized structure, which will cause a memory exception (a free of a bogus
address). You should almost always initialize your structures, e.g.
ARInternalIdList idList = {0, NULL}. All three of these are several of the many reasons to move
to a later technology, whether it's C++, COM, Java, or .NET. I know you're not interested in getting into VS .NET.
Even with VS 6.0, you could use the RTL package to simplify the use of the
library with proper objects. IMHO, "C" code like that below is
too verbose, error prone, and difficult to maintain to be a productive
development environment. (But really, I don't mean to start a religious
discussion...my "proof" of this is the code comparison at http://rtl.sourceforge.net/doc).
If I get the time, I'll "translate" the below code for you to show
that it is probably 80% smaller and simpler. Dan |
Title: Re: Invalid Address specified to RtlFreeHeap( 00870000, 008A1E90 ) on
using FreeInternalIdList
- Re: Invalid Address specified to RtlFreeHeap( 00870000, 008A1E90... Dan Hardy
- Re: Invalid Address specified to RtlFreeHeap( 00870000, 008... Dan Hardy

