CString is garbage when called from outside dll 1

[titanandrews]

Hi All,
I have a function in a dll which returns a const CString. When called from within the dll, it works fine. But, when I call this function from outside the dll, the function returns garbage. And when the dtor is automatically called (when the CString goes out of scope) I get an assertion failed from MFC. The assert fails on _ASSERTE(_CrtIsValidHeapPointer(pUserData)); The comment for this statement says,
/*
* 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.
*/

Has anyone seen this before and knows what I need to do to correct the problem?

many thanks,

Barry

 

[xwb]

Instead of returning the const CString, pass in a CString reference that is filled in by the routine. It may not be the best solution but it works.

 

[titanandrews]

Unfortunately, this also does not work. I get a crash in NTDLL as soon as I assign a value to the CString reference passed in to the function. Again, the function works from within the dll, but does not when called from outside. Somewhere I have an incompatibility. I just cannot figure out where.
Do you or anyone else have any more ideas? I don't get the same error as before. Now it's even more cryptic as I cannot go into NTDLL for debug info. My function looks similar to this:

void MyApp::GetInfo(CString& strInfo)
{
   CString strTmp = GetSomeOtherInfo();
   strInfo = strTmp; //This is where I crash.
}

thanks,

Barry

 

[xwb]

Looks like there is heap corruption somewhere else. Try adding this. It may help you find whether your heap was corrupted before you started or as a result of GetSomeOtherInfo.

#include <malloc.h>

static void HeapCheck (LPCTSTR strTitle)
{
#ifdef _DEBUG
   /* Check heap status */
   switch( _heapchk () )
   {
   case _HEAPOK:
      break;
   case _HEAPEMPTY:
      break;
   case _HEAPBADBEGIN:
      MessageBox (0, strTitle, _T(&quot;Bad Start of Heap&quot;), MB_OK);
      break;
   case _HEAPBADNODE:
      MessageBox (0, strTitle, _T(&quot;Bad node in Heap&quot;), MB_OK);
      break;
   default:
      MessageBox (0, strTitle, _T(&quot;Unknown heap status&quot;), MB_OK);
      break;
   }
#endif
}


void MyApp::GetInfo(CString& strInfo)
{
   HeapCheck (&quot;Before GetSomeOtherInfo&quot;);
   CString strTmp = GetSomeOtherInfo();
   HeapCheck (&quot;After GetSomeOtherInfo&quot;);
   strInfo = strTmp; //This is where I crash.
}

 

[titanandrews]

Thanks for the info xwb! I found the problem, but I am still a bit confused as to why. When I switch to release build, everything works fine. I found some threads in other newsgroups (If you just search Google groups for this "_ASSERTE(_CrtIsValidHeapPointer(pUserData));&quot you will get a ton of hits.) that talk about not being able to free memory that was allocated from another exe. So in my case, I had a CString in a function in an exe which I passed to a function in a dll which would fill it. After the assignment occurs, CString::FreeData() is automatically called and that's where I have trouble. The exe was a release build, but the dll was a debug build. I wonder if that is the problem. I suppose I could try building the exe in debug mode and see.

Please keep the thread going if anyone has anything useful to add.


thanks,

Barry

 

[xwb]

I'll look through my compiler/linker switches because we're passing CStrings to and fro from one DLL to another (this is a MFC + SDK + C# application). It works fine in both debug and release mode.

Are you linked to the MFC DLL or statically linked? My apps are normally linked to the DLL.

 

[titanandrews]

But are all dlls built in either release or debug? If I build one in release and one in debug, that's when I have a problem. Sorry, not sure what you mean by this, "Are you linked to the MFC DLL or statically linked?"


Barry

 

[xwb]

Under Settings/General/Microsoft Foundation Classes. Do you have "Use MFC in a static library" or "Use MFC in a shared DLL". I have never tried it as a static library.

Another possibility is to make sure all the memory allocation is only done in one module.