Valgrind schickt mir folgende Fehlermeldung:

> ==25573==
> ==25573== HEAP SUMMARY:
> ==25573== in use at exit: 8 bytes in 1 blocks
> ==25573== total heap usage: 99 allocs, 98 frees, 2,126 bytes
> allocated
> ==25573==
> ==25573== 8 bytes in 1 blocks are definitely lost in loss record 1 of > 1
> ==25573== at 0x402471C: operator new(unsigned int)
> (vg_replace_malloc.c:255)
> ==25573== by 0x8053B01:
> __gnu_cxx::new_allocator<int>::allocate(unsigned int, void const*)
> (new_allocator.h:89)
> ==25573== by 0x80539EF: std::_Vector_base<int, std::allocator<int> > >::_M_allocate(unsigned
> int) (stl_vector.h:140)
> ==25573== by 0x805362C: std::vector<int, std::allocator<int>
> >::_M_insert_aux(__gnu_cxx::__n
> ormal_iterator<int*, std::vector<int, std::allocator<int> > >, int
> const&) (vector.tcc:322)
> ==25573== by 0x8053448: std::vector<int, std::allocator<int>
> >::push_back(int const&)
> (stl_vector.h:741)
> ==25573== by 0x80526A1: Man::mayhit(int, int, int, int, char,
> char, Draughts&, char, int&)
> (Man.cpp:236)
> ==25573== by 0x8052B32: Man::maymove(int, int, Draughts&, int&)
> (Man.cpp:346)
> ==25573== by 0x8054770: Move::execute(Draughts&,
> std::vector<std::string,
> std::allocatorstd::string >&) (Move.cpp:109)
> ==25573== by 0x804DAF7: Draughts::run() (Draughts.cpp:226)
> ==25573== by 0x8049992: main (main.cpp:65)
> ==25573==

Der Teil des Codes, wo das Problem auftritt ist folgender:

if(count_hit == high_hit)
{
  max_startpositions.push_back(helper);
}

else if(count_hit > high_hit)
{
  high_hit = count_hit;
  for (counter = max_startpositions.size(); counter > 0; counter--)
  {
    max_startpositions.pop_back();
  }
  max_startpositions.push_back(helper);
}

Wir leeren also den Vektor, wenn ein Stein gefunden wurde der mehr gegnereische Steine schlagen kann. Danach fügen wir diesen hinzu
---> geht ohne Leaks!

Sollte sich jetzt ein Stein finden, welcher gleich oft schlagen kann, wird dieser dem Vektor hinzugefügt ---> geht korrekt und es gibt auch in weiterer Folge keine Probleme mit dem Programm, aber eben das Speicher-Leak.

Was ist der Grund? Bitte um Hilfe!

Liebe Grüße

wie ist der vector 'max_startpositions' bzw. die Variable 'helper' denn deklariert und wie werden diese erstellt (arbeitest du mit Zeigern)?

Interessant wäre auch, was "helper" genau ist. Mit einem kompilierfähigen Minimalbeispiel wirst du vermutlich schnell eine Lösung bekommen....

danke mal für die Hilfe! das mit dem clear ist natürlich viel sauberer löst aber leider das problem nicht.

helper ist ein Integer. dieser wird in einer Schleife hochgezählt und wenn das if erfüllt ist. wird eben eine der beiden aktionen ausgeführt.
es geht eben grundlegend darum herauszufinden an welcher position(helper) sich der Stein oder auch die Steine deshalb vector befinden welche am meisten figuren schlagen können.

max_startposition erstelle ich so:

std::vector <int> max_startpositions;

lg

Wild geraten: Benutzt du exit() in deinem Programm?

undmit erzeuge ich auch nix innerhalb des vektors.

EDIT: im späteren verlauf des Programmes mache ich dies kommt ja einem exit gleich oder? aber darf dies zu jenem problem führen?

for(counter = 0; counter < max_startpositions.size(); counter++)
      {

        if((return_value == HIT) && (max_startpositions[counter] == startposition))
        {
          old_endposition = endposition;
          if(global_hit > 1)
          {
            multiple_hits = true;
            global_hit--;
            return HIT_MORE;
          }
          multiple_hits = false;

          return HIT;
        }

naja ich habe jetzt max_startpositions.clear();

vor den returns eingefügt das problem ist noch immer da:/ obwohl jetzt ja eigentlich nix mehr im vektor stehen dürfte...

std::vector<int> bla = { 1, 2, 3 };

{
    std::vector<int> foo;
    std::swap(foo, bla);
}

Irgendwo hantierst Du mit new und delete und Dir geht Speicher flöten, guck da!

Oder vielleicht hast Du irgendwo einen Destruktor, der nicht virtuell ist, in einer Basisklasse...

Ein vector<int> wird kaum ein Speicherleck haben...

std::vector::clear gibt nicht zwingend den Speicher frei, bzw wird es bei den allermeisten Implementierungen nicht tun. Löschen kannst du ihn explizit so:

std::vector<int> bla = { 1, 2, 3 };

{
    std::vector<int> foo;
    std::swap(foo, bla);
}

genau das wars!

danke!!!

std::vector<int>().swap(bla);

Ethon schrieb:

std::vector::clear gibt nicht zwingend den Speicher frei, bzw wird es bei den allermeisten Implementierungen nicht tun. Löschen kannst du ihn explizit so:

std::vector<int> bla = { 1, 2, 3 };

{
    std::vector<int> foo;
    std::swap(foo, bla);
}

genau das wars!

danke!!!

Ich verstehe nicht, was das eine mit dem anderen zu tun hat.
Das vector allozierten Speicher nicht wieder freigibt: geschenkt. Denn spätestens bei Programmende wird er das tun, es sei denn, man schafft es irgendwie seinen D'tor zu überspringen, z.B. mit dem beschriebenen exit() .

Ich kann gerade keine Versuche mit valgrind und vector anstellen, aber ich behaupte, dass Clear-and-minimize/shrink_to_fit() die Symptome und nicht die Ursachen beseitigt.

Eingebungen, Erläuterungen, Erklärungen für mich?

Dein Programm ruft den D'tor von startpositions nicht auf, da liegt der Hund begraben.

Ist die Klasse Man vielleicht von irgendwas abgeleitet? startposition ist Member von Man , richtig?

Ich denke Du solltest dem noch auf den Grund gehen, wenn Du C++ lernst.

Hier mal ein Beispiel, was ich mir vorstellen könnte, was passiert. Es ist so geschrieben, dass der Trace Deinem sehr ähnlich ist.

Du kannst das Speicherleck beseitigen in dem Du eine der beiden markierten Zeilen A oder B hinzufügst.
Aber während B die Symptome kaschiert, beseitigt A den Fehler!

#include <vector>

struct Foo {
  virtual void clear_and_minimize() = 0;
  // virtual ~Foo() {}  // Zeile A
};

struct Bar : Foo{
  std::vector<int> v;
  Bar() { v.push_back(42); v.push_back(42); }
  void clear_and_minimize() { std::vector<int>().swap(v); }
};

int main(){
  Foo* f = new Bar;
  // f->clear_and_minimize(); // Zeile B
  delete f;
}

valgrind schrieb:

==3483== HEAP SUMMARY:
==3483== in use at exit: 8 bytes in 1 blocks
==3483== total heap usage: 3 allocs, 2 frees, 44 bytes allocated
==3483==
==3483== 8 bytes in 1 blocks are definitely lost in loss record 1 of 1
==3483== at 0x4C2A3D7: operator new(unsigned long) (vg_replace_malloc.c:287)
==3483== by 0x4015F3: __gnu_cxx::new_allocator<int>::allocate(unsigned long, void const*) (in /tmp/test)
==3483== by 0x401406: std::_Vector_base<int, std::allocator<int> >::_M_allocate(unsigned long) (in /tmp/test)
==3483== by 0x400F50: std::vector<int, std::allocator<int> >::_M_insert_aux(__gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > >, int const&) (in /tmp/test)
==3483== by 0x400CA1: std::vector<int, std::allocator<int> >::push_back(int const&) (in /tmp/test)
==3483== by 0x400B25: Bar::Bar() (in /tmp/test)
==3483== by 0x400A56: main (in /tmp/test)
==3483==
==3483== LEAK SUMMARY:
==3483== definitely lost: 8 bytes in 1 blocks

Ich hoffe Du schaust nochmal drauf.
Allein schon, weil Du wahrscheinlich überall im code unnötige aufrufe von swap() hast...

ich versuche gerade zu verstehen, was du meisnt... liege ich richtig, dass du die Vermutung hast, dass ich den destruktor vergessen habe?

okay die klasse also man ist abgleleitet... der destruktor wird erzeugt, aber ist im moment leer. gehe ich richtig in der Vermutung, dass du meisnt ich soll swap() im Destruktor aufrufen?

aber ganz klar ist mir die situation immer noch nicht in der regel wird doch ein vector automatisch freigegeben?

danke jedenfalls für die nette Unterstützung

std::vector::clear gibt nicht zwingend den Speicher frei, bzw wird es bei den allermeisten Implementierungen nicht tun.

Wenn es darum geht, den Speicher wieder frei zu geben, schlage ich vor, das mit Gültigkeitsbereichen zu regeln.

liege ich richtig, dass du die Vermutung hast, dass ich den destruktor vergessen habe?

Den Destruktor der Basisklasse, ja. Vergessen, oder nicht virtuell deklariert, siehe seldons Antwort.

nero08 schrieb:

gehe ich richtig in der Vermutung, dass du meisnt ich soll swap() im Destruktor aufrufen?

Nein. Die swaps schmeisst Du alle wieder raus. Es sei denn Dir geht der Speicher aus.

nero08 schrieb:

aber ganz klar ist mir die situation immer noch nicht in der regel wird doch ein vector automatisch freigegeben?

Das stimmt, deswegen ist der vector ja so bequem. Wenn das Objekt, dessen Member der vector ist zerstört wird, gibt der vector den allozierten Speicher frei und gut is'.
Wird allerdings wie im Beispiel der D'tor von - in diesem Fall - Bar nicht aufgerufen, weil ~Foo() nicht virtuell ist, wird auch der D'tor des vector nicht aufgerufen. Damit bleibt der Inhalt des vectors im Speicher erhalten und ist unerreichbar verloren.
Mit dem swap() sorgst Du nun dafür, dass der vector dessen D'tor nicht aufgerufen wird, 0 Bytes alloziert, d.h. valgrind bekommt davon nix mit.

Allerdings ist das Fehlen eines virtuellem D'tor in einem Fall wie oben zusätzlich noch UB (s. C++ 5.3.5), müsste also auf jeden Fall gefixt werden.

Und obacht: dass das der Fehler ist, ist reine Spekulation!
Aber swap() fixt keinen Fehler - siehe auch die Antwort von SeppJ.

Good Hunting!

ich hatte wirklich in meiner Basisklasse keinen destruktor

habe ihn jetzt hinzugefügt und die swaps gekickt - und keine leaks

allerding stellt sich mir hier ein kleines verständnisproblem vl. mag wer daraug eingehen

Also ich habe in meiner Unterklasse einen vector welcher alle gelöschten steine speichert. diesen brauche ich bei einem erneuten aufruf der klasse wieder für eine überprüfung also ob man einen zug machen darf.

wird nicht durch den aufruf des destruktors dieser vektor also auch der Inhalt gelöscht?

EDIT: den vektor muss ich schon noch passend entleeren, aber wenn ich mich noch an die vorherigen Beiträge erinnere muss ich dies mit swap mache oder reicht clear doch aus?
also im Prinzip wird dann mittel destruktor der vektor im unterschied zu zuvor wirklich auch gelöscht?