Help, missing something here!

Let's say I have a .DLL with a function like this:

Code:

---

// function declaration
CString GetStringValue(const CString &fieldname);

// function definition
CString GetStringValue(const CString &fieldname)
{
  CString str;
  (some stuff to read a field value from a database)
  str = db.getvalue(blah blah blah)
  return(str);
}

---

and the function is used by the calling program like this:

Code:

---

CString str;
str = GetStringValue("State");

....

---

no problem, until 'str' goes out of scope in the calling program, then the runtime library crashes with a heap error when it runs the destructor ~CString().

Why is this?

it's caused by an improper way of linking into the DLL.

If the DLL has been compiled with a built-in CRT (or MFC), then it's the task of THAT CRT-code to dispose of the string.

In this case, your app has it's own heapmanager in it's own bit of CRT library.

A string gets allocated from the DLL (with the DLL's heapmanager), and you're attempting to delete it with another heapmanager (the one from the app). This causes the crash...

----
Solutions

1) If you are creating a DLL it's best to use the MFC and the CRT as .dll's as well.
A program using that dll should also dynamically link to MFC/CRT as well.
In this case only one heapmanager is active in the entire process (the one in MSVCRT.DLL or MSVCRT71.DLL)

2) If the DLL _MUST_ be compiled with CRT linked in, then you must also provide explicit functions to dispose of objects allocated from the DLL. In this case it's best not to return types like CString that are hard if not impossible to explicitely delete with the right heapmanager.

My link settings for both the .DLL and the calling program are set to "Use MFC in a Shared DLL" (using VC 6.0).

Is this what you were referring to? Any other thoughts?

Well...the problem is rather depending on the CRT library as mentioned by OReubens. You need to check that you are using the same CRT linking option...

and it's the same, all using MFC in a shared .DLL.

Any other items I can check? Or other linker settings?

How about threading model? Are both projects multi-threaded / single-threaded?

created using Appwizard. Nothing special, I haven't made any changes.

Is/are there any compiler and/or linker settings that are messing me up? Both projects are optimized for speed.

BTW here is the exact message I get in VC's status pane:

HEAP[Report Creator.exe]: Invalid Address specified to RtlValidateHeap( 340000, dc43e4 )

Call Stack:

NTDLL! 77f97704()
NTDLL! 77fb6688()
NTDLL! 77f935f9()
KERNEL32! 77e9f540()
MSVCRTD! 102142c0()
MSVCRTD! 10213611()
MSVCRTD! 10213541()
operator delete(void * 0x00dc4404) line 351 + 12 bytes
CString::FreeData() line 146 + 15 bytes
CString::~CString() line 213
CMainFrame::OnCreate(tagCREATESTRUCTA * 0x0012fb80) line 151 + 34 bytes
CWnd::OnWndMsg(unsigned int 1, unsigned int 0, long 1244032, long * 0x0012fa08) line 1811 + 13 bytes
CWnd::WindowProc(unsigned int 1, unsigned int 0, long 1244032) line 1585 + 30 bytes
AfxCallWndProc(CWnd * 0x00345040 {CMainFrame hWnd=0x045306e0}, HWND__ * 0x045306e0, unsigned int 1, unsigned int 0, long 1244032) line 215 + 26 bytes
AfxWndProc(HWND__ * 0x045306e0, unsigned int 1, unsigned int 0, long 1244032) line 368
AfxWndProcBase(HWND__ * 0x045306e0, unsigned int 1, unsigned int 0, long 1244032) line 220 + 21 bytes
USER32! 77e3a244()
USER32! 77e14730()
USER32! 77e1cf17()
NTDLL! 77fa02ff()
USER32! 77e1cf5a()
CWnd::CreateEx(unsigned long 0, const char * 0x001340b8, const char * 0x003453cc, unsigned long 13598720, int -2147483648, int -2147483648, int -2147483648, int -2147483648, HWND__ * 0x00000000, HMENU__ * 0x0e0c0bd5, void * 0x00000000) line 694 + 54 bytes
CFrameWnd::Create(const char * 0x001340b8, const char * 0x003453cc, unsigned long 13598720, const tagRECT & {top=-2147483648 bottom=0 left=-2147483648 right=0}, CWnd * 0x00000000 {CWnd hWnd=???}, const char * 0x00000080, unsigned long 0, CCreateContext * 0x00000000) line 564 + 79 bytes
CFrameWnd::LoadFrame(unsigned int 128, unsigned long 13598720, CWnd * 0x00000000 {CWnd hWnd=???}, CCreateContext * 0x00000000) line 695 + 45 bytes
CMDIFrameWnd::LoadFrame(unsigned int 128, unsigned long 13598720, CWnd * 0x00000000 {CWnd hWnd=???}, CCreateContext * 0x00000000) line 286 + 24 bytes
CReportCreatorApp::InitInstance() line 96 + 30 bytes
AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x001333ad, int 1) line 39 + 11 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x001333ad, int 1) line 30
WinMainCRTStartup() line 330 + 54 bytes
KERNEL32! 77ea847c()

Quote:

---

Originally posted by zombie69
and it's the same, all using MFC in a shared .DLL.

---

No...I am not talking about the MFC dll here...I am talking about the run-time library instead...you can check the setting under the 'C/C++' within the project settings...

The problem is rather, that your application and your dll are using different memory managers...

they're both the same. (Debug multithreaded DLL).

I really need to find the source of this problem. I'm getting close to deployment.

Appreciate any other items I should check and/or fix.

Make sure you have compiled both projects as debug or both as release. In debug builds extra memory is allocated around any memory you allocate so special functions can check if they have been overwritten (ie the expected eyecatchers are still there)

what do
db.getvalue() return.

you may have to do an allocSysstring() there somewhere.

Ok I see the problem.

you are decaring CString str; inside your dll and passing it back to the caller. This may not be valid address for the caller because str is local to the dll method.

what you need to do is a supply a CString &str by the caller and in the dll you fill that with the value.

void GetStringValue(const CString FileName, CString &str)
{
str = db.getvalue(blah blah blah)
}

Quote:

---

you are decaring CString str; inside your dll and passing it back to the caller. This may not be valid address for the caller because str is local to the dll method.

what you need to do is a supply a CString &str by the caller and in the dll you fill that with the value.

void GetStringValue(const CString FileName, CString &str)
{
str = db.getvalue(blah blah blah)
}

---

While this remark may be true for some classes, it is a bogus solution in this case. Whether the CString is returned, or CString is passed as a pointer/reference, in both cases the DLL will cause (re)allocation, and the destruction will be done in the App.

The way the problem is described, and the stack trace are pretty much a sure indication that my initial assertion is indeed what's causing this. That is... assuming the address is at all valid of course, if the address got overwritten then anything is possible.

There is a probably heapmanager embedded in the DLL, and there's another one in the application code. Memory allocated from the DLL's heapmanager is attempted to be deleted from the application's heapmanager.

[Merged threads]

There are two things you can try:
(1) Pass a Ctring& into the DLL instead of returning a CString.
The problem will NOT disappear, but debugging is easier!
(2) Instead of returning a CString, return a BSTR which can be created easily from CString inside your DLL:
BSTR dll_bstr = str.AllocSysString();
Convert the BSTR back into a CString in your exe (e.g. use _bstr_t)
and the BSTR must of course be deleted in your exe! But this is done by "standard" API functions and does not depend on Compiler settings:
::SysFreeString(exe_bstr);