Hi everyone
I'm having a little trouble with an MFC application, SDI, pretty simple stuff. However, the running of the app is absolutely crippled by stack\heap overflows. They appeared one day - I have no idea what has caused them - but most strangely there seems to be no real pattern to when they occur in the program execution. It's usually upon closing a dialog box which is used to alter strings in a CTypedPtrArray. A breakpoint is triggered, but in all sorts of different places. This one was in wincore.cpp, line 1812. Like I said, I cannot find the exact action that causes this to occur - sometimes it happens, sometimes it doesn't.
Windows has triggered a breakpoint in Agistment Utility.exe. This may be due to a corruption of the heap, and indicates a bug in Agistment Utility.exe or any of the DLLs it has loaded. The output window may have more diagnostic information...
HEAP[Agistment Utility.exe]: HEAP: Free Heap block 15f05f8 modified at 15f0640 after it was freed
I also receive "Out of memory" messages on a fairly regular basis, sometimes upon opening a document and sometimes later in program execution. Upon closing this message box I get a stream of error beeps for a few seconds before VS breaks at the chkstk.asm file, line 99, and I receive this message:
Unhandled exception at 0x10201d57 (msvcr80d.dll) in Agistment Utility.exe: 0xC0000005: Access violation reading location 0x00030000.
Having only been programming for a few months, this is a bit beyond me - I can't pick up what the exception is in the assembly code, so any help with what could cause these errors would be much appreciated! Thanks in advance,
Simon Robb

Unexplained stack\heap overflow
Prof
Egad! How did I miss that !
Yoshifumi INOUE
I guess that you are overwriting memory boundaries on the heap. In other words: Your are allocating some memory chunks, but you write beyond the end of this storage and so the heap gets destroyed.
You can place some ASSERT(AfxCheckMemory()); in your code. This will fire an ASSERT as soon as a corruption can be detected. Maybe you can narrow yourself to the problem.
Ido Tandy
Yes the _tcscopy_s macro was definately the problem, when that was commented out it didn't crash.
Thanks for your help, both of you... sorry to say I took the easy way out - I ended up using the AllocSysString function to get a BSTR, which i passed instead of the LPWSTR. It works a charm now - I'm a very happy young programmer =P
yogaboy
TLevin10
Sebastian Dev
Thanks Martin, that helped in isolating the problem.
I've tracked it down to the _tcscpy_s macro - I'm working with a tree view control and have to give the TVINSERTSTRUCT a LPWSTR, so I use this macro to convert a CString into the LPWSTR like this:
TVINSERTSTRUCT tvInsert; tvInsert.item.mask = TVIF_TEXT; int sizeOfString = pDoc->m_paddockList.ElementAt(i)->m_paddockName.GetLength()+1; LPWSTR str1 = new WCHAR(sizeOfString); // this is the bad line! _tcscpy_s(str1, sizeOfString, pDoc->m_paddockList.ElementAt(i)- >m_paddockName); tvInsert.item.pszText = str1;...where m_paddockName is a CString.
If I'm using the macro incorrectly, can you please tell me how - otherwise, can somebody give me a different way to perform the conversion from CString to LPWSTR (this one seems pretty clunky anyway).
Thanks, Simon.
zhu.zheng
Shouldn't you also set the cchTextMax member
Plus, since you are using the generic text macros, instead of a LPWSTR you should use a LPTSTR.
What happens if you comment out the call to _tcscpy_s Ignoring, the garbage that gets inserted, does it still crash
Harreld Kuiper
The major problem is this:
LPWSTR str1 = new WCHAR(sizeOfString);This code just allocates 1 WCHAR and initialiszes it with sizeOfString.
On my system this fires a warning C4244!
The correct code would be.
LPWSTR str1 = new WCHAR[sizeOfString];But read Nishants notes well!