Überprüfen ob delete seine Arbeit gemacht hat[Dedupe]

[Bebu]

Hallo, ich habe mal wieder ein kleines Problem, für das ich noch keine rechte Lösung weiß.
Ich schreibe gerade an der Testklasse für den SqliteWrapper weiter. Wer sich das ansehen will, es liegt im Branch Dataholding. Ich will dabei testen, ob der dynamisch angeforderte Speicher für das Sql Result wieder freigegeben wird. Hier erst einmal die zu testende Funktion:

Code: Alles auswählen

void Dedupe::Dataholding::SqliteWrapper::FreeResult()
{
  Dedupe::Dataholding::SqliteWrapper::Row row;
  Dedupe::Dataholding::SqliteWrapper::Value value;

  for( Dedupe::Dataholding::SqliteWrapper::Result::const_iterator
        iter = ReturningTable.begin(); iter != ReturningTable.end(); iter++ )
  {
    row = *iter;
    for( Dedupe::Dataholding::SqliteWrapper::Row::const_iterator
         RowIter = row.begin(); RowIter != row.end(); RowIter++ )
    {
      value = RowIter->second;

      delete( value );
      value = NULL;
    }
  }
  ReturningTable.clear();
}

Hier noch die verwendeten Datentypen:

Code: Alles auswählen

typedef Dedupe::Dataholding::Variant::Data * Value;
typedef std::map<std::string,Value> Row;
typedef std::vector<Row> Result;

Variant::Data ist eine Basisklasse, die jeden Datentyp halten kann. Das ganze wird als Tabelle abgebildet, d.h. Ein Row enthält den Spaltennamen und den Basisklassenpointer auf den zugehörigen Wert. Diese Row wird dann in einen Vector vom Typ Result gepusht. Die obige Funktion durchläuft jetzt diesen Vector und jedes Row und löscht über den Basisklassenpointer die Daten, auf die Value zeigt. Ich will jetzt überprüfen, ob alles, worauf ein Value zeigt auch gelöscht wurde, und nicht irgendwo ein Wert übersehen wird. Ich dachte an eine Liste, mit allen Valueadressen. Nach dem Aufruf der Löschfunktion müsste ich dann nur überprüfen, ob an den Adressen auch nichts mehr steht. Nur ein Zugriff auf einen tatsächlich gelöschten Bereich, ergibt ein Segmentation fault. Kann man so eine Art Testzugriff machen, damit der Fehler nicht auftritt und ich trotzdem weiß, ob alles weg ist? Meine Versuche mit Operatorenüberladung waren nicht zufriedenstellend und für automatische Tests auch eher unpraktisch. Man kann zwar per Valgrind testen, daher weiß ich auch, das die Funktion fehlerfrei arbeitet, aber ich will das ganze gerne im Unittest haben.

[Xin]

Meine Versuche mit Operatorenüberladung waren nicht zufriedenstellend und für automatische Tests auch eher unpraktisch. Man kann zwar per Valgrind testen, daher weiß ich auch, das die Funktion fehlerfrei arbeitet, aber ich will das ganze gerne im Unittest haben.

Welche Operatoren hast Du überladen?

Mir fällt auch nur ein, dass man im Testprogramm die Operatoren new und delete (bzw. new [] und delete [] für Arrays) überlädt und alloziierten Speicherbereiche z.B. in einer Liste hält und die freigegebenen aus dieser Liste streicht.
Das kann wohl ein kleines Framework namens DUMA übernehmen, was ich aber noch nicht getestet habe.

[Bebu]

Welche Operatoren hast Du überladen?

Ich habe mich an new und delete versucht. Für new war es nicht so schwer, man kann sich ohne Probleme eine eigene Variante schreiben, der man zusätzliche Argumente mitgeben kann. Auf diese Weise kann man mit der Hilfe von Macros das überladene new aufrufen, das seinerseits mit dem globalen arbeitet. Leider ist es mit delete nicht so einfach, das lässt sich nicht auf diese Weise überladen, weil hier nur ein Übergabeargument erlaubt ist. Man muss also den Umweg über eine Funktion nehmen und per Makro alle delete stellen durch den Funktionsaufruf ersetzen. Das wird aber problematisch, sobald man z.B. die STL verwendet. Also muss man per Preprozessorschalter alles ausschließen, was man nicht ersetzt haben will. Das ist zu aufwendig, weil es in jeder Codedatei stehen muss, obwohl es nur zum Debuggen und Testen gebraucht wird.

Mir fällt auch nur ein, dass man im Testprogramm die Operatoren new und delete (bzw. new [] und delete [] für Arrays) überlädt und alloziierten Speicherbereiche z.B. in einer Liste hält und die freigegebenen aus dieser Liste streicht.

Siehe oben

Das kann wohl ein kleines Framework namens DUMA übernehmen, was ich aber noch nicht getestet habe.

Das sieht allerdings sehr interessant aus, muss ich mir mal genauer ansehen.

[Xin]

http://proggen.org/doku.php?id=cpp:operator:memory ?

[Bebu]

Ich habe jetzt mal nach DUMA gesucht, aber die Bibliothek scheint seit 2009 nicht mehr weiterentwickelt worden zu sein und ich habe auch keine wirklichen Anleitungen, oder Erklärungen dazu gefunden. Hast du da zufällig was rumliegen?

[Xin]

Ich habe jetzt mal nach DUMA gesucht, aber die Bibliothek scheint seit 2009 nicht mehr weiterentwickelt worden zu sein und ich habe auch keine wirklichen Anleitungen, oder Erklärungen dazu gefunden. Hast du da zufällig was rumliegen?

Ich nicht, aber das Netz hat was ausgespuckt, was ich mir hier dazu mal ausgedruckt habe, weil ich es eigentlich selbst testen wollte.

http://duma.sourceforge.net/74_75_76_77 ... ing_DE.pdf

Ich brauche eine Alternative zu Valgrind auf Windows. Solange Du unter Linux bist, solltest Du Dir Valgrind ansehen.

[Bebu]

Ja, diese Anleitung habe ich auch gefunden, ich kämpfe aber trotzdem damit. Wenn ich die Dumapp.h einbinde, bekomme ich einen undefined referenze fehler für die überladenen Versionen von new und delete, obwohl ich duma mit zum Programm linke. Wenn ich es nur dazu linke, und keine Header einbinde, dann meldet sich Duma zwar auf der Konsole, schreibt aber auch immer NO_LEAKDETECTION. Ich habe mir Duma einfach aus den Ubuntuquellen installiert, aber ich komme noch nicht so ganz klar.

[MoonGuy]

Bin mir nicht sicher, ob das geht, aber kann man einen Testzugriff nicht über try-catch Exceptions erschummeln? Also ein Versuch wäre es wert!

[Bebu]

Bin mir nicht sicher, ob das geht, aber kann man einen Testzugriff nicht über try-catch Exceptions erschummeln? Also ein Versuch wäre es wert!

Das wird wohl eher nicht klappen. Ein Zugriff auf einen falschen Speicherbereich wirft keine Exception. Das wird direkt vom Betriebssystemkernel überwacht. Stellt der so einen Zugriff fest, dann wirft der Kernel eine Ausnahme und schießt das Verursachende Programm wegen eines Segmantion fault ab, das heißt sofortiges Programmende.

[Xin]

Ich will dabei testen, ob der dynamisch angeforderte Speicher für das Sql Result wieder freigegeben wird.

...

Bin mir nicht sicher, ob das geht, aber kann man einen Testzugriff nicht über try-catch Exceptions erschummeln? Also ein Versuch wäre es wert!

Das Nichtfreigeben von Speicher führt nicht zu Segmentation-Faults.