Title: Re: Invalid Address specified to RtlFreeHeap( 00870000, 008A1E90 ) on using FreeInternalIdList
**

 

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
Sent: Tuesday, July 18, 2006 7:45 AM
To: Angus Comber; [email protected]
Subject: RE: Invalid Address specified to RtlFreeHeap( 00870000, 008A1E90 ) on using FreeInternalIdList

 

 

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

__20060125_______________________This posting was submitted with HTML in it___

Reply via email to