"CRT detected that the application wrote to memory after end of heap buffer"

std::wstring CLists::GetItemText(UINT Pos){
	int NameLenght = (int)::SendMessage(m_Handle, LB_GETTEXTLEN, Pos, NULL);
	TCHAR *Name = new TCHAR[NameLenght];
	SecureZeroMemory(Name, NameLenght);
	::SendMessage(m_Handle, LB_GETTEXT, Pos, (LPARAM)Name);
	std::wstring os(Name);
	delete [] Name;
	return os;
}

{VS 2005 Prof}

"::SendMessage(m_Handle, LB_GETTEXTLEN, Pos, NULL);" returniert 6 und der string ist "Second"

also anders formuliert (Pseudocode):

TCHAR *Name = new TCHAR[6];
SecureZeroMemory(Name, 6);
*Name = _T("Second")
std::wstring os(Name);
delete [] Name; // error

ich versteh das nicht wirklich

"CRT detected that the application wrote to memory after end of heap buffer" sagt das er mehr loeschen will als reserviert wurde

-----

#idee-bekommen-hab

kann es sein das das "delete []" n zeichen loeschen will bis ein \0 kommt und da es zu wenig war kommt keines ?

std::wstring CLists::GetItemText(UINT Pos){
    int NameLenght = ((int)::SendMessage(m_Handle, LB_GETTEXTLEN, Pos, NULL)+1);
    TCHAR *Name = new TCHAR[NameLenght];
    SecureZeroMemory(Name, NameLenght);
    ::SendMessage(m_Handle, LB_GETTEXT, Pos, (LPARAM)Name);
    std::wstring os(Name);
    delete []Name;
    return os;
}

dankeschoen {haette ja mal in den speicher schauen koennen #gg}

Babelfish sagt zu der Fehlermeldung:

Babelfish schrieb:

CRT ermittelte, daß die Anwendung zum Gedächtnis nach Ende des Haufenpuffers schrieb.

Es geht definitiv darum, dass du über die Grenzen des angeforderten Speichers schreibst. delete[] kümmert sich nicht um Nullbytes, die Anzahl der Elemente des Arrays werden irgendwo vor dem Anfang des Blocks gespeichert (und zwar unabhängig vom verwendeten Typ, dessen Arrays ja nicht nullterminiert sein müssen).

BTW:
Die Grenzüberschreitung hat undefiniertes Verhalten zur Folge. Das heisst nicht dass er zu genau dem Zeitpunkt abstürzen muss.

meine theorie ist das delete bis zum \0 loeschen will

Nein, delete ist es vollkommen egal, was im Speicher steht. Wohlgemerkt der Speicher der Nutzdaten. Also die Anzahl der Bytes, die new reservieren soll. Wie LordJaxom schon schrieb, wird der Fehler daher rühren, dass durch das Überschreiben von irgendwelchen Kontrolldaten ausserhalb der eigentlichen Nutzdaten der Speichermanager Amok läuft.

Liest Du was hier geschrieben wird?

konnte gestern nur ueberfliegen hatte kaum zeit - dank fuer die ausfuehrlichen erklaerungen {=