Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17


problem with AtlWinModuleTerm and free() called in pWinModule->m_rgWindowClassAtoms.RemoveAll();

Posted on 2006-07-18
Medium Priority
Last Modified: 2008-02-20

Ok.  Something I changed in my code recently is giving me a heap error when my ATL module tries to terminate.

ATL::AtlWinModuleTerm calls pWinModule->m_rgWindowClassAtoms.RemoveAll();

m_rgWindowClassAtoms is a CSimpleArray and remove all looks like this:

      void RemoveAll()
            if(m_aT != NULL)
                  for(int i = 0; i < m_nSize; i++)
                  free(m_aT);   // The Offending "free"
                  m_aT = NULL;
            m_nSize = 0;
            m_nAllocSize = 0;

Unfortunately, when it tries to free(m_aT), it asserts.  The assert is from the following code:

         * If this ASSERT fails, a bad pointer has been passed in. It may be
         * totally bogus, or it may have been allocated from another heap.
         * The pointer MUST come from the 'local' heap.

However, the offending window class (I've narrowed down the possibilities so I know exactly which class is causing the problem) is defined with CWindowImpl and uses the DECLARE_WND_CLASS macro.  



In short, I'm not managing rgWindowClassAtoms, ATL should be.  

If I comment out the "free(m_aT)", the code works just fine.  But I'm sure that's a memory leak for the rest of the CSimpleArrays out there. (Not sure if it matters for the Term(), but it probably does).

I'm using ATL 7.0 and the only clear insight I've found so far online is a write up that suggests both the underlying problem and a work-around.

However, I /am/ statically linking to ATL as near as I can tell, so I should already have the workaround in place.

I'm really not sure what to do. For the moment I'm planning on re-writing the ATL files to avoid the bug, and accept the memory leak until I can figure out a way around this problem.

Anyone have a solution that isn't a memory leak?

Question by:jandrieu
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 7
  • 4
LVL 15

Expert Comment

ID: 17130964
Check to see if your code is calling Init/Term methods.

In ATL 7.0.,Init and Term methods have moved into the constructors and destructors for the module classes; there is no longer a need to call Init and Term.


Author Comment

ID: 17132014
Good idea.  No luck.  

The only hits for a search on Term( and Init( are in the ATL files plus a CComObject I initialize in a customized IConnectionPointImplMT<T, piid, CDV>::EnumConnections.
LVL 15

Expert Comment

ID: 17132765
I am not sure if
is causing you the problem.

You can use the DECLARE_WND_CLASS_EX macro to provide your own styles and background color.

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.


Author Comment

ID: 17132991
That didn't seem to help either.

I tried:

Which compiled & ran, but still left the heap bug.


Which game a parameter error (as expected, actually).

And then I commented out the line entirely.

That didn't work either.
LVL 15

Expert Comment

ID: 17133222

Btw what changes you made? Was it all working fine without your changes?

Author Comment

ID: 17134482
Unfortunately, it's not clear what changes made the difference or when.  I had the program working fine before I started implementing Drag & Drop into/from my own MSHTML CAxWindow, adding several new COM classes and figuring out how to get that to work.  That was causing a lot of crashes on its own, so I didn't pay attention at first when the app started crashing at shutdown.

Once I got the drag & drop working, I started paying attention to the heap bug.  In doing so, I isolated out what I had added bit by bit. I now have the heap problem, but NONE of my new classes are being used.  I don't even include their .h files.  I had thought it might be something with my IDataObject implementation, misusing STGMEDIUM, but it happens without doing ANY drag & drop. I don't even register the drag & drop at this point.

One set of changes was moving from hand-written registry functions to the ATL macros.  I've been working with a variety of sources for sample code and my earliest code handled DllRegisterServer manually.  Now I use the ATL DllRegisterServer().

I look into that and see if I can change anything.


Author Comment

ID: 17134621

So I went back to my old RegisterServer functions and even excised my new classes out of the IDL and the VS project.

No luck.
LVL 15

Accepted Solution

lakshman_ce earned 1000 total points
ID: 17138148
I would suggest you to take the base code that you had initially and see if heap problem exists in that code.
If it exists you can check this link to see if you are missing anything.

LVL 49

Expert Comment

ID: 17142317
I'm pretty sure that the main reason to get that assert is that the item being freed has already been freed.

I'd breakpoint the code in CSimpleArray to see if something else has already deleted it.

I'm sorry if this offends you but there is also another possibility:  
You may be thinking the wrong line is causing the problem.  Whenever I write a for... loop, I use curly braces and one happy side effect is that it is always very clear which line is being executed when single-stepping:

               for(int i = 0; i < m_nSize; i++) {       // added
                }                                                  // added
               free(m_aT);   // The Offending "free"

Note too, that you are using m_nSize to determine how many items to free.  I'd recommend using the GetSize() member function.

-- Dan

Author Comment

ID: 17142539
As far as I can tell, the array is valid.  (I've gone back in history with SourceSafe so I can't test that directly anymore.)  However, the m_AT[i].~T(); always worked fine, which means that m_aT must be valid.

I did, when I was debugging it before, walk through and document all the pointers that were freed with this particular function.  None of the pointer values were repeated.  My guess is that m_aT is on a different heap.

As for the braces.  I agree. This, however, is code straight from the ATL library.  I'll avoid updating it if possible.


Author Comment

ID: 17143986
Here's the latest, in case anyone is still following this thread:

Apparently, I'm thrashing the heap somewhere. That's my best guess for the assert.
I also know that the OnFinalMessage for CMyWindow is getting called, but the destructor is not.

I had return in time to a place where I wasn't causing problems, then slowly went forward, adding code. Only to find that when the bug resurfaced, the latest changes were apparently not the cause.  Grrr. I've turned off pre-compiled headers in case there was something with that. Suffice to say I'm back in the midst of the heap bug.


Author Comment

ID: 17223066
Ultimately, I rebuilt the underlying codebase from the ground up (for this component). That cleaned up some potential issues, but I still have no idea what was causing the crash.

I've awarded points to the best advice, but since it wasn't a specific answer to the problem but rather a general strategy for working around the problem, I gave a grade of C.

But, at the end of the day, it was still the right answer. Chasing after phantom bugs sucks.  At least now the codebase is a little cleaner and hopefully a bit more stable.


Featured Post

On Demand Webinar: Networking for the Cloud Era

Ready to improve network connectivity? Watch this webinar to learn how SD-WANs and a one-click instant connect tool can boost provisions, deployment, and management of your cloud connection.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

The following diagram presents a diamond class hierarchy: As depicted, diamond inheritance denotes when two classes (e.g., CDerived1 and CDerived2), separately extending a common base class (e.g., CBase), are sub classed simultaneously by a fourt…
In Easy String Encryption Using CryptoAPI in C++ ( I described how to encrypt text and recommended that the encrypted text be stored as a series of hexadecimal digits -- because cyphertext may…
Video by: ITPro.TV
In this episode Don builds upon the troubleshooting techniques by demonstrating how to properly monitor a vSphere deployment to detect problems before they occur. He begins the show using tools found within the vSphere suite as ends the show demonst…
In this video, Percona Solution Engineer Rick Golba discuss how (and why) you implement high availability in a database environment. To discuss how Percona Consulting can help with your design and architecture needs for your database and infrastr…
Suggested Courses

704 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question