Memory Allocation

Polite Programmer

Sometimes, while allocating memory in my programs, I get NULL in responce to call of new operator. Sometimes, when I execute following pair of statements, I get Heap Error. TCHAR * szText = new TCHAR[iLen * 7] ; //... Some Code delete [] szText ; // Causes heap error Where and what I might be doing wrong?

Polite Programmer

More Object Oriented then C#

Cedric Moonen

What is the value of iLen ? And what is the code missing between these two lines. You don't provide any valuable information for us to help you...

Cédric Moonen Software developer
Charting control [Updated - v1.1]

Polite Programmer

You are right, not enough information: Value of iLen is > 0 < 200. Moreover, between the lines, we are just calling string manipulation functions like strlen, strcpy etc. But when the delete []szText is executed, heap corruption message follows....

Polite Programmer

More Object Oriented then C#

Lost User

Polite Programmer wrote:

I get NULL in responce to call of new operator.

Is this the problem? Also try to use Safe String APIs instead of strcpy etc

S o h a i l K a d i w a l a
To Err Is Human; to Debug, Divine

Cedric Moonen

Can you post the exact code ? We cannot help if you don't provide meaningfull informations.

Cédric Moonen Software developer
Charting control [Updated - v1.1]

Polite Programmer

Here is the full code, Comments starting with NOTE are the erroroneous... #include #include #include #include "resource.h" #include "convert.h" HWND hwndNextClipboardVierwer ; char * szInPageData ; HFONT hFont ; // Processes the conversion /* void ProcessConversion(HWND hDlg) { TCHAR * pInPageText = NULL ; TCHAR * pUnicodeText = NULL ; HWND hwndInPageText = GetDlgItem(hDlg, IDC_EDIT_INPAGE) ; HWND hwndUnicodeText = GetDlgItem(hDlg, IDC_EDIT_UNICODE) ; int iLen = GetWindowTextLength(hwndInPageText) ; if(iLen <=0) return ; pInPageText = new TCHAR[iLen + 1] ; GetWindowText(hwndInPageText, pInPageText, iLen) ; pUnicodeText = ConvertInPageToUncode(pInPageText, iLen) ; SetWindowText(hwndUnicodeText, pUnicodeText) ; if(pInPageText != NULL)delete []pInPageText ; if(pUnicodeText != NULL) delete []pUnicodeText ; } */ void DumpHex(TCHAR * szText, HWND hDlg) { int iLen = _tcsclen(szText) ; TCHAR szBuffer[10] ; /*NOTE: This call fails i.e. returns NULL (even iLen is > 0)*/ TCHAR * szHexDump = new TCHAR[iLen * 7] ; ZeroMemory(szHexDump, iLen * 7) ; for(int i = 0 ; i < iLen ; i++) { wsprintf(szBuffer, _T("0x%X, "), szText[i]) ; _tcscat(szHexDump, szBuffer) ; } SetDlgItemText(hDlg, IDC_EDIT_UNIHEX, szHexDump) ; /*NOTE: This Call generates Heap corruption message from CRT*/ delete [] szHexDump ; } BOOL CALLBACK DlgProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) { HANDLE hMemory = NULL; TCHAR * szUnicodeText = NULL ; char * lptstr = NULL ; int iLen = NULL ; switch(msg) { case WM_INITDIALOG: hwndNextClipboardVierwer = SetClipboardViewer(hWnd) ; hFont = CreateFont( 80, 80, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, _T("Pak Nastaleeq")) ; SendDlgItemMessage(hWnd, IDC_EDIT_UNICODE, WM_SETFONT, (WPARAM) hFont, TRUE) ; return FALSE ; // Handle the change of the clipboard. case WM_DRAWCLIPBOARD: if(OpenClipboard(hWnd)) { hMemory = GetClipboardData(CF_TEXT) ; lptstr = (char *) GlobalLock(hMemory) ; if(hMemory == NULL || lptstr == NULL) { CloseClipboard() ; return FALSE ; } iLen = strlen(lptstr) ; szInPageData = new char[iLen + 1] ; szUnicodeText = new TCHAR[(iLen / 2) + (iLen / 100) * 10] ; strcpy(szInPageData, lptstr) ; GlobalUnlock(hMemory) ; SendMessage(hwndNextClipboardVierwe

kakan

Polite Programmer wrote:

//... Some Code

Is it possible that "//... Some Code" writes more than iLen * 7 into szText? I.e. the terminating '\0' character? Or that "//... Some Code" causes a corrupted stack?

Alcohol. The cause of, and the solution to, all of life's problems - Homer Simpson

Polite Programmer

I'm sure it does'nt write past iLen * 7 but I'm not sure whether it can corrupt the stack. Please tell me how code can corrupt the stack? (Becuase I really dont know if the question seem stupid)

Polite Programmer

More Object Oriented then C#

kakan

Hello. IMO, The usual reason for stack corruption is this: foo { char text[5]; strcpy(text, "Hello"); } text is a stack variable of 5 chars, but the strcpy() copies 6 bytes to it. The last character written (the '\0' byte) will be written outside the boundry of text. ******** THIS IS A SIMPLIFIED EXPLANATION ******** The return address (to the function that called foo()) is also saved on the stack. When the function foo returns, the return address is picked up from the stack. But a part of the return address is now overwritten by the the '\0' byte, and is altered. So the program retuns to the wrong address, causing the program to go bananas. That's stack corruption. -- modified at 3:06 Wednesday 27th September, 2006 But you can get a lot of different fishy behaviour from stack corruption. It depends how the compiler uses the stack. It doesn't have to result in wrong return address, other things can happen, such as another stack variable suddenly changes its value, e.t.c.

Alcohol. The cause of, and the solution to, all of life's problems - Homer Simpson

David Crow

Polite Programmer wrote:

between the lines, we are just calling string manipulation functions like strlen, strcpy etc.

What if these are omitted? Does the problem still exist? If not, it could be that you are writing outside of the allocated memory.

"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15

"Judge not by the eye but by the heart." - Native American Proverb

David Crow

Polite Programmer wrote:

void DumpHex(TCHAR * szText, HWND hDlg) { int iLen = _tcsclen(szText) ; TCHAR szBuffer[10] ; /*NOTE: This call fails i.e. returns NULL (even iLen is > 0)*/ TCHAR * szHexDump = new TCHAR[iLen * 7] ; ZeroMemory(szHexDump, iLen * 7) ; for(int i = 0 ; i < iLen ; i++) { wsprintf(szBuffer, _T("0x%X, "), szText[i]) ; _tcscat(szHexDump, szBuffer) ; } /*NOTE: This Call generates Heap corruption message from CRT*/ delete [] szHexDump ; }

This is the code snippet that you need to focus on. What is the value of ilen? What does szBuffer look like each iteration of the loop? How are you verifying that szHexDump is big enough for iLen concatenations?

"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15

"Judge not by the eye but by the heart." - Native American Proverb

nutkase

I think you are mixing to many types of chars (i.e TCHARs, chars and LPSTRs). I think u have a confusion regarding there usage. First of all from ur code.... TCHAR *szUnicodeText = new TCHAR[(iLen / 2) + (iLen / 100) * 10] ; you give an impression that TCHAR == Unicode character???? this is a wrong assumption. The definition of TCHARs can be found in headers its something like #if defined _UNICODE #define TCHAR WCHAR #else #define TCHAR CHAR #enif so depending upon your build type (unicode or ansi) the type and hence the size of the TCHARs changes. I think you are trying to make some sort of clipbroard viewer to display the unicode and hex value of the data on the clipboard. try using this code instead in your DrawClipboard notification if(OpenClipboard()) { HANDLE hMemory = GetClipboardData(CF_TEXT) ; TCHAR *lptstr = (TCHAR*) GlobalLock(hMemory) ; if(hMemory == NULL || lptstr == NULL) { CloseClipboard() ; } int iLen = _tcslen(lptstr) ; TCHAR *szInPageData = new TCHAR[iLen + 1] ; _tcscpy(szInPageData, lptstr) ; USES_CONVERSION; LPWSTR szUnicodeText = T2W(szInPageData); GlobalUnlock(hMemory) ; ::SendMessage( hNextViewer, WM_DRAWCLIPBOARD, 0, 0 ) ; //ConvertInPageToUncode(szInPageData, iLen, szUnicodeText) ; DumpHex( W2T(szUnicodeText), GetSafeHwnd()) ; //SetDlgItemText(hWnd, IDC_EDIT_UNICODE, szUnicodeText) ; delete [] szInPageData ; } Trust me, nothing's impossible!