void* operator new(size_t Size)
{
	void* p = malloc(Size);
	std::cerr << "new      " << p << std::endl;
	return p;
}

void* operator new[](size_t Size)
{
	void* p = malloc(Size);
	std::cerr << "new[]    " << p << std::endl;
	return p;
}

void operator delete(void* p)
{
	std::cerr << "delete   " << p << std::endl;
	free(p);
}

void operator delete[](void* p)
{
	std::cerr << "delete[] " << p << std::endl;
	free(p);
}

Ich möchte bei mir Fehler abfangen, die auf die Verwechslung von delete und delete[] im Programm zurückzuführen sind. Dazu würde ich die Adressen bei der Allokation speichern und zusätzlich merken, ob die []-Version von new angewandt wurde. So weit, so gut - bei skalaren Typen und PODs funktioniert das Ganze gut, ich kann Fehler durch Verwendung der falschen delete -Version erkennen.

Bei Klassentypen jedoch gibt es ein Problem: Je nachdem, welche Version von delete aufgerufen wird, handelt es sich um eine andere Adresse. In den Funktionen mit der Array-Version beinhaltet der Zeiger eine Adresse vier Byte vor dem Zeiger der Nicht-Array-Version. Das führt unweigerlich zu Heap Corruptions.

Hat jemand einen Lösungsansatz? Da sich die Zeiger bei skalaren Typen "normal" verhalten, kann ich nicht jedes Mal 4 Byte subtrahieren/addieren. Hier dürfte nicht mal Boost ( is_pod ) helfen, da ja die Typinformation durch void* verloren geht...

Grüße,
Michael

PS: Hast Du evtl. probiert etwas mit new alloziertes mit delete[] wieder freizugeben? Das würde ja genau dazu führen, dass der compiler dann 4 Bytes von der Addresse des Zeigers, der aus new (ohne []) stammt "abzieht".

new[] bekommt immer [...] und delete[] bekommt ebenselben pointer wieder.

Eben, das Problem taucht ja auf, wenn ich entweder new[] und delete oder new und delete[] auf den gleichen Zeiger ausführe. Diesen Fehlerfall will ich ja abfangen.

Da ich mir alle Adressen von allokiertem Speicherbereich in Containern merke, habe ich mir auch überlegt, jeweils zu schauen, ob ein Eintrag mit 4 Bytes zuvor/danach vorhanden ist. Jedoch ist das nicht ganz sicher, da es ja sein könnte, dass an dieser Position ein anderer Speicherblock stehen würde...

const int noarray = 5;
const int isarray = 11;

void* operator new(size_t Size)
{
    int* p = (int*)malloc(Size+sizeof(int));
	p[0] = noarray;

	std::cerr << "new      " << p << "  size: " << Size << std::endl;
    return reinterpret_cast<void*>(p+1);
}

void* operator new[](size_t Size)
{
    int* p = (int*)malloc(Size+sizeof(int));
	p[0] = isarray;

	std::cerr << "new[]    " << p_ << "  size: " << Size << std::endl;
    return reinterpret_cast<void*>(p+1);
}

void operator delete(void* p)
{
    int* p_ = reinterpret_cast<int*>(p);
	p_-=1;
	if( *p_ != noarray ) {
		std::cerr << "ERRROORRRR!!!" << std::endl;
	}

	std::cerr << "delete   " << p_ << std::endl;
    free(reinterpret_cast<void*>(p_));
}

void operator delete[](void* p)
{   
	int* p_ = reinterpret_cast<int*>(p);
	p_-=1;
	if( *p_ != isarray ) {
		std::cerr << "ERRROORRRR!!!" << std::endl;
	}

	std::cerr << "delete[] " << p << std::endl;
    free(reinterpret_cast<void*>(p_));
}

Ich hab das jetzt nicht total durchdacht, aber grundsätzlich würde ich sagen, stellt das doch kein problem dar.

Das Problem ist aber eben, dass ich nicht PODs und Klassentypen unterscheiden kann (zumindest wüsste ich nicht wie). Bei PODs ist die Adresse für einzelne und zusammenhängende Speicherblöcke die gleiche.

Dein Code kann so auch nicht funktionieren, da delete immer zuerst den Destruktor des Objekts aufruft und erst anschliessend operator delete . Wenn der Zeiger nicht direkt auf das Objekt zeigt, kommt es zu einer Zugriffsverletzung.

Warum auch nicht?

Nexus schrieb:

Dein Code kann so auch nicht funktionieren, da delete immer zuerst den Destruktor des Objekts aufruft und erst anschliessend operator delete . Wenn der Zeiger nicht direkt auf das Objekt zeigt, kommt es zu einer Zugriffsverletzung.

Also von Nachricht zu Nachricht willst du was anderes. In der ersten Nachricht wunderst du dich, warum die Zeiger unterschiedlich sind. In der 2. Message klingt es so, als hättest du es in der 1. schon gewusst, warum.

Nicht wirklich. In der ersten stellte ich fest, dass die Adressen bei delete und delete[] bei Klassentypen unterschiedlich seien, und fragte nach einem Lösungsansatz. Im zweiten Post wollte ich dich auf die Verwendung von verschiedenen Speicheroperatoren (z.B. new und delete[] ) aufmerksam machen, da du anscheinend meine Frage falsch verstanden hattest.

Decimad schrieb:

In der dritten willst du auf einmal etwas verhindern, was mit operator delete nicht verhindern kannst (selbst wenn du wüsstest ob array POD oder nicht), weil es schon geschehen ist?

Hm, jetzt weiss ich nicht mehr, was du genau damit meinst. Der Fehler in deinem Code besteht darin, dass das Argument des delete -Operators (also ptr in der unten stehenden Codezeile) ein Zeiger auf ein Objekt sein muss, dessen Destruktor dann aufgerufen wird. Bei dir ist das nicht der Fall, weil zuerst noch vier Byte int kommen. Dann wird der Destruktor natürlich nicht richtig bzw. gar nicht aufgerufen und bei dem Versuch entsteht eine Zugriffsverletzung.

delete ptr;

Verstehst du mein Problem? Es gibt keinen trivialen Ansatz, der sowohl für PODs und Klassentypen funktioniert, da diese unterschiedlich gehandhabt werden.

Grüße,
Michael

const int noarray = 5;
const int isarray = 11;

void* operator new(size_t Size)
{
    unsigned int* p = (unsigned int*)malloc(Size+12);
    p[0] = noarray;
    p[1] = noarray | 0xF00;
    p[2] = 1;

    std::cerr << "new      " << p << "  size: " << Size << "  returned: " << p+3 << std::endl;
    return reinterpret_cast<void*>(p+3);
}

void* operator new[](size_t Size)
{
    unsigned int* p = (unsigned int*)malloc(Size+12);
    p[0] = isarray;
    p[1] = isarray | 0xF00;
    p[2] = 1;

    std::cerr << "new[]    " << p << "  size: " << Size << "  returned: " << p+3 << std::endl;
    return reinterpret_cast<void*>(p+3);
}

void operator delete(void* p)
{
    unsigned int* p_ = reinterpret_cast<unsigned int*>(p);
    p_-=3;
    if( (*p_&0xFF) == isarray ) {		
        std::cerr << "ERRROORRRR!!!" << std::endl;
    }
    if( *p_&0xF00 ) p_-=1;

    std::cerr << "delete called with   " << p << "  freeing: " << p_ << std::endl;
    free(reinterpret_cast<void*>(p_));
}

void operator delete[](void* p)
{   
    unsigned int* p_ = reinterpret_cast<unsigned int*>(p);
    p_-=2;
    if( (*p_&0xFF) == noarray ) {
        std::cerr << "ERRROORRRR!!!" << std::endl;

    }
    if( *p_ & 0xF00 ) p_ -= 1;

    std::cerr << "delete[] called with " << p << "  freeing: " << p_ <<  std::endl;
    free(reinterpret_cast<void*>(p_));
}

Ich hätte aber noch einige Fragen zu deinem Code: Was machst du genau mit der binären Logik ( operator& und operator| )? Und die 5 und 11 sind einfach willkürliche Zahlen? Und was ist mit den Hexadezimalwerten? Auch sonst versteh ich noch nicht ganz alles, ich versuchs mal zu interpretieren.

Allerdings scheint mir das sehr viel Aufwand... Ist das reinterpret_cast en hier eigentlich überall einem definierten Verhalten? Man müsste einfach statt 4 sizeof(int) einsetzen, dann sollte es auch portabel sein... Oder man machts gleich mit char .

Die binäre Logik dient nur dazu, dass ich mir sparen konnte noch zusätzlich zwei konstanten zu definieren. Sie dient hier dazu, zu unterscheiden, ob man beim ersten oder zweiten Typfeld ist.

Ich hab mir eben auch überlegt, das mit 3 char s zu machen - der Wertebereich würde ja längstens reichen. Aber wieso unterteilst du die einzelnen int s noch, wenn du sowieso drei belegst?

Decimad schrieb:

Aber er funktioniert natürlich nur unter der Annahme, das der Compiler seine Verwaltung von dynamischen Feldern eines nicht-POD's so handhabt, wie du es beobachtet hast.

Hm, ein guter Einwand. Weiss diesbezüglich jemand mehr?

Schlussendlich scheint es mir ein bisschen viel Aufwand zu sein (wovon Teile möglicherweise gar nicht immer definiertes Verhalten sind) - ansonsten lass ich das einfach meine andere Abfrage erledigen (ob der Zeiger, der freigegeben wurde, gültig ist). Dann erhält man zwar eine weniger spezifische Fehlermeldung, aber da die Verwechslung von delete und delete[] wohl nicht sehr häufig vorkommt...

Naja, vorläufig werde ich es trotzdem mit deinem Ansatz versuchen und schauen, ob er sich bewährt. Vielen Dank nochmals.

Wie meinst du das mit dem Unterteilen?

Ich verstehe deinen Ansatz grundsätzlich nicht ganz.

Wenn Speicher allokiert wird, forderst du doch zusätzlich noch Speicher für 3 int s vor dem "normalen" Speicherbereich an. Dann überprüfst du beim Freigeben, ob an den Stellen der vorher allokierten int -Speicherbereiche das Richtige steht (5 bei new , 11 bei new[] ).

Jetzt sagst du, du brauchst die binäre Logik, um herauszufinden, in welchem Typfeld du bist. Das verstehe ich nicht ganz...

Decimad schrieb:

Bezüglich des gewählten Typs. Die 1 muss meiner Meinung nach sowieso in einem int stehen (halt weil delete[] darauf baut), drum machts doch nur mehr Aufwand, den Rest dann noch in char's zu packen.

Sorry, welche Funktion hat die 1 in der dritten 4-Byte-Speicherzelle? Einfach als Puffer, da delete[] bei Klassentypen beginnt, vor dem tatsächlichen Speicherbereich zu löschen?

Ich allokiere jetzt nur zwei int -Felder vor dem eigentlichen Speicherbereich, auf die ich in den Freigabefunktionen mit ptr[-2] und ptr[-1] bei den Freigabefunktionen zugreife. Da immer zuerst auf ptr[-1] geprüft wird (und dieser Speicherbereich in jedem Falle reserviert wurde), sollte der Zugriff auf Speicher, der einem nicht gehört, vermieden werden.

const int NoArray = 42;
const int IsArray = 13;
const int Buffer = 1;

void* operator new(size_t Size)
{	
	int* ptr = reinterpret_cast<int*>(malloc(Size + 2*sizeof(int)));

	ptr[0] = NoArray;
	ptr[1] = Buffer;

	return reinterpret_cast<void*>(ptr + 2);
}

void* operator new[](size_t Size)
{
	int* ptr = reinterpret_cast<int*>(malloc(Size + 2*sizeof(int)));

	ptr[0] = IsArray;
	ptr[1] = Buffer;

	return reinterpret_cast<void*>(ptr + 2);
}

void operator delete(void* Pointer)
{
	int* ptr = reinterpret_cast<int*>(Pointer);

	if (ptr[-1] != Buffer || ptr[-2] != NoArray)
		std::cerr << "/!\\ Fehler!" << std::endl;
}

void operator delete[](void* Pointer)
{
	int* ptr = reinterpret_cast<int*>(Pointer);

	if (ptr[-1] != Buffer || ptr[-2] != IsArray)
		std::cerr << "/!\\ Fehler!" << std::endl;
}

Einige Dinge verstehe ich trotzdem noch nicht:

• Wieso muss Buffer genau 1 sein, damit es zu keiner Zugriffsverletzung kommt? Du hast ja auch gesagt, dass dort sowieso eine 1 stehen muss, weil sie für delete[] benötigt wird...
• Warum funktioniert das nur mit int (bei char oder short gibt es Zugriffsverletzungen)? Ist das so, weil bei mir int gleich gross wie ein Zeiger ist? Müsste man demnach auch das allgemein halten, wenn man Portabilität gewährleisten will?
• Gibt es noch sonstige Stellen, die gefährlich sein könnten (undefiniertes Verhalten etc.)?

Aber das könnte wahrscheinlich auch von Compiler zu Compiler variieren... Hm, ich glaube, dafür gibts wohl keine wirklich standardkonforme Lösung.
Und es wird doch einfach sizeof(void*) zurückgegangen, und nicht sizeof(int) , oder? Dass das oft das Gleiche ist, ist ja eher Zufall...

Ansonsten, ist mein Code ungefähr brauchbar? Oder wieso ist deiner um einiges komplizierter?

Dein Code ist hauptsächlich deshalb schöner, weil du meinen genommen hast und ihn schöner gemacht hast

Sollte kein Vorwurf sein, nur dank dir hab ich diesen Code ja so hingekriegt.

Nur die Geschichten mit der binären Logik und dem dritten Feld haben mich von Anfang an verwirrt, deshalb habe ich jetzt versucht, ohne sie auszukommen.

Decimad schrieb:

Woher weißt du, das der Compiler um sizeof(void*) vorspringt und nicht um sizeof(int)? Ich dachte mir halt, da steht also eine Zahl vor, die 4 byte groß ist, also ist es ein int Alles Annahmen...

Nun ja, ich habe mir vorgestellt, dass er halt gerade eine Zelle im Arbeitsspeicher zurückgeht, und eine Adresse benötigt halt sizeof(void*) Bytes (Grösse eines Zeigers). Aber meistens sollte das sowieso gleich der Grösse von int sein... Aber ja, ist halt auch so eine Annahme. So wirklich portabel bringt man das sowieso kaum hin...

Vielen Dank für deine Hilfe, du hast mich echt weitergebracht!