<![CDATA[Speicherleck? Oder falsches Kopieren?]]>Mein Programm endet mit der Meldung "terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc"

Ich versuche hier nicht allzuviel Code zu posten, aber genug um das Problem hoffentlich erkennen zu können.

Es gibt im Grunde genommen nur 2 relevante Klassen.
Atome und Moleküle, wobei Moleküle fast nichts anderes als ein Vector von Atomen sind.

class Atom
{
protected:
    Eigen::Vector3d position;
    std::list<Atom* > neighbours;

public:
	Atom();
	Atom(const Atom& other);
	Atom& operator=(const Atom& other);
	virtual ~Atom();

	virtual void setPosition3d(double, double, double);
	virtual Eigen::Vector3d getPosition3d() const;

	virtual void connect(Atom& atom);
	virtual void disconnect(Atom& atom);
	virtual bool isConnected(const Atom& atom) const;
	virtual double distance(const Atom& atom) const;
	virtual void move(double x, double y, double z);
};

Atom::Atom(const Atom& other)
{
    this->position = other.position;

    for (std::list<Atom*>::const_iterator iter = other.neighbours.begin();
            iter != other.neighbours.end(); iter++)
    {
        connect(**iter);
    }
}

Atom& Atom::operator=(const Atom& other)
{
    if (this != &other)
    {
        this->position = other.position;

        for (std::list<Atom*>::const_iterator iter = other.neighbours.begin();
                iter != other.neighbours.end(); iter++)
        {
            connect(**iter);
        }
    }
    return *this;
}

Atom::~Atom()
{
    for (std::list<Atom*>::iterator iter = neighbours.begin();
            iter != neighbours.end(); iter++)
    {
        (*iter)->neighbours.remove(this);
    }
}

class Molecule
{
friend class FileReader;

protected:
	std::vector<Atom> atoms;

public:
	Molecule();
	virtual ~Molecule();

	void addAtom(const Atom&);

	const std::vector<Atom>& getAtoms() const ;
	std::vector<Atom>& getAtoms();
};

void Molecule::addAtom(const Atom& atom)
{
    atoms.push_back(atom);
}

Das wären die hoffentlich relevanten Teile bisher. Nun möchte ich ein Molekül anlegen. Das soll später aus einer Datei heraus geschehen. Im Moment habe ich aber 10 Atome per Hand eingegeben:

Molecule FileReader::readFile(std::string path)
{
	Molecule m;
	if (path == "")
	{
		Atom a[10];

		a[0].setPosition3d(26.091, 52.849, 39.889);
		a[1].setPosition3d(27.437, 49.969, 37.786);
		a[2].setPosition3d(24.961, 47.988, 35.671);
		a[3].setPosition3d(25.194, 44.925, 33.360);
		a[4].setPosition3d(22.428, 44.503, 30.712);
		a[5].setPosition3d(21.933, 40.811, 29.752);
		a[6].setPosition3d(19.604, 39.512, 26.973);
		a[7].setPosition3d(19.324, 37.742, 23.567);
		a[8].setPosition3d(20.108, 39.651, 20.294);
		a[9].setPosition3d(17.487, 42.426, 19.756);

		for (int i = 0; i < 9; i++)
		{
			a[i].connect(a[i + 1]);
		}

		for (int i = 0; i < 10; i++)
		{
			m.addAtom(a[i]);
		}
	}

	else
	{... Andere Daten}

	return m;
}

Das Problem schein bei Molecule.addAtom() aufzutreten. Ich verstehe die Debugger -Ausgaben leider nicht vollständig. Allerdings zeigt er mir Teile aus STL_VECTOR mit der Methode
_M_allocate(size_t __n)
{ return __n != 0 ? _M_impl.allocate(__n) : 0; }
an.

Zugriffe auf
atoms[i größer 0]
schlagen auch fehl. Es scheinen keine Daten angelegt zu sein.

Würde mich freuen, wenn mir jemand sagen kann, woran ich im Moment scheitere.

]]>https://www.c-plusplus.net/forum/topic/306186/speicherleck-oder-falsches-kopierenRSS for NodeSat, 08 Aug 2026 08:59:39 GMTFri, 20 Jul 2012 11:43:41 GMT60<![CDATA[Reply to Speicherleck? Oder falsches Kopieren? on Fri, 20 Jul 2012 11:43:41 GMT]]>Mein Programm endet mit der Meldung "terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc"

Ich versuche hier nicht allzuviel Code zu posten, aber genug um das Problem hoffentlich erkennen zu können.

Es gibt im Grunde genommen nur 2 relevante Klassen.
Atome und Moleküle, wobei Moleküle fast nichts anderes als ein Vector von Atomen sind.

class Atom
{
protected:
    Eigen::Vector3d position;
    std::list<Atom* > neighbours;

public:
	Atom();
	Atom(const Atom& other);
	Atom& operator=(const Atom& other);
	virtual ~Atom();

	virtual void setPosition3d(double, double, double);
	virtual Eigen::Vector3d getPosition3d() const;

	virtual void connect(Atom& atom);
	virtual void disconnect(Atom& atom);
	virtual bool isConnected(const Atom& atom) const;
	virtual double distance(const Atom& atom) const;
	virtual void move(double x, double y, double z);
};

Atom::Atom(const Atom& other)
{
    this->position = other.position;

    for (std::list<Atom*>::const_iterator iter = other.neighbours.begin();
            iter != other.neighbours.end(); iter++)
    {
        connect(**iter);
    }
}

Atom& Atom::operator=(const Atom& other)
{
    if (this != &other)
    {
        this->position = other.position;

        for (std::list<Atom*>::const_iterator iter = other.neighbours.begin();
                iter != other.neighbours.end(); iter++)
        {
            connect(**iter);
        }
    }
    return *this;
}

Atom::~Atom()
{
    for (std::list<Atom*>::iterator iter = neighbours.begin();
            iter != neighbours.end(); iter++)
    {
        (*iter)->neighbours.remove(this);
    }
}

class Molecule
{
friend class FileReader;

protected:
	std::vector<Atom> atoms;

public:
	Molecule();
	virtual ~Molecule();

	void addAtom(const Atom&);

	const std::vector<Atom>& getAtoms() const ;
	std::vector<Atom>& getAtoms();
};

void Molecule::addAtom(const Atom& atom)
{
    atoms.push_back(atom);
}

Das wären die hoffentlich relevanten Teile bisher. Nun möchte ich ein Molekül anlegen. Das soll später aus einer Datei heraus geschehen. Im Moment habe ich aber 10 Atome per Hand eingegeben:

Molecule FileReader::readFile(std::string path)
{
	Molecule m;
	if (path == "")
	{
		Atom a[10];

		a[0].setPosition3d(26.091, 52.849, 39.889);
		a[1].setPosition3d(27.437, 49.969, 37.786);
		a[2].setPosition3d(24.961, 47.988, 35.671);
		a[3].setPosition3d(25.194, 44.925, 33.360);
		a[4].setPosition3d(22.428, 44.503, 30.712);
		a[5].setPosition3d(21.933, 40.811, 29.752);
		a[6].setPosition3d(19.604, 39.512, 26.973);
		a[7].setPosition3d(19.324, 37.742, 23.567);
		a[8].setPosition3d(20.108, 39.651, 20.294);
		a[9].setPosition3d(17.487, 42.426, 19.756);

		for (int i = 0; i < 9; i++)
		{
			a[i].connect(a[i + 1]);
		}

		for (int i = 0; i < 10; i++)
		{
			m.addAtom(a[i]);
		}
	}

	else
	{... Andere Daten}

	return m;
}

Das Problem schein bei Molecule.addAtom() aufzutreten. Ich verstehe die Debugger -Ausgaben leider nicht vollständig. Allerdings zeigt er mir Teile aus STL_VECTOR mit der Methode
_M_allocate(size_t __n)
{ return __n != 0 ? _M_impl.allocate(__n) : 0; }
an.

Zugriffe auf
atoms[i größer 0]
schlagen auch fehl. Es scheinen keine Daten angelegt zu sein.

Würde mich freuen, wenn mir jemand sagen kann, woran ich im Moment scheitere.

]]>https://www.c-plusplus.net/forum/post/2234346https://www.c-plusplus.net/forum/post/2234346Fri, 20 Jul 2012 11:43:41 GMT<![CDATA[Reply to Speicherleck? Oder falsches Kopieren? on Fri, 20 Jul 2012 12:08:51 GMT]]>Das wird wohl nicht funktionieren:

Molecule FileReader::readFile(std::string path)
{
    Molecule m;
    if (path == "")
    {
        Atom a[10];

        a[0].setPosition3d(26.091, 52.849, 39.889);
        a[1].setPosition3d(27.437, 49.969, 37.786);
        a[2].setPosition3d(24.961, 47.988, 35.671);
        a[3].setPosition3d(25.194, 44.925, 33.360);
        a[4].setPosition3d(22.428, 44.503, 30.712);
        a[5].setPosition3d(21.933, 40.811, 29.752);
        a[6].setPosition3d(19.604, 39.512, 26.973);
        a[7].setPosition3d(19.324, 37.742, 23.567);
        a[8].setPosition3d(20.108, 39.651, 20.294);
        a[9].setPosition3d(17.487, 42.426, 19.756);

        for (int i = 0; i < 9; i++)
        {
            a[i].connect(a[i + 1]);
        }

Deine verbundenen Atome sind nämlich ein paar Zeilen später nicht mehr vorhanden, da du sie auf dem Stack angelegt hast.

Ob das jetzt zu deinem Fehler führt kann ich nicht sagen, der besagt jedenfalls, dass dir der Speicher ausgegangen ist. Wie viele Atome legst du denn an?

]]>https://www.c-plusplus.net/forum/post/2234354https://www.c-plusplus.net/forum/post/2234354Fri, 20 Jul 2012 12:08:51 GMT<![CDATA[Reply to Speicherleck? Oder falsches Kopieren? on Fri, 20 Jul 2012 12:13:30 GMT]]>Und warum sind die Methoden alle virtual? oO

]]>https://www.c-plusplus.net/forum/post/2234357https://www.c-plusplus.net/forum/post/2234357Fri, 20 Jul 2012 12:13:30 GMT<![CDATA[Reply to Speicherleck? Oder falsches Kopieren? on Fri, 20 Jul 2012 12:21:45 GMT]]>Wenn du Problem mit Laufzeitfehlern hast, dann gib uns bitte auch lauffähigen Code. Siehe dritter Link in meiner Signatur.

Ich halte dein Design für äußerst ungünstig. Du hast ja anscheinend mehrere gleichberechtigte Kopien der Atome (warum eigentlich?), die dann aber alle verbunden sind. Das heißt, wenn Atom a und Atom b benachbart sind und du eine Kopie von a machst, dann ist b bei deinem Code auf einmal ein Nachbar sowohl von a als auch von der Kopie. Das ist bestimmt nicht gewollt!
Weiterhin haben verkettete Listen nichts in performancekritischem Code verloren, wenn es in diesem Code nicht um die Stärken der Listen geht. Letzteres wird hier sicherlich der Fall sein.
Es ist vermutlich auch sehr ungünstig, dass du Pointer auf Objekte in Containern hast, die eventuell Umallokieren. Dein Array ist zwar statisch, aber die Molekülklasse hat ja anscheinend einen vector und wie schon erwähnt, werden die Atomkopien im Molekül auch Nachbarn der anderen Atome. Der Vector wird beim Vergrößern aber irgendwann einmal umallokieren und die Pointer werden alle ungültig.
Noch etwas: Es ist bei dir derzeit möglich, ein Atom in einem ungültigen Zustand zu erzeugen, da du ohne Not einen Defaultkonstruktor angelegt hat, der ein unvollständiges Atom erzeugt. Vermutlich weil du sonst das Array nicht hättest benutzen können. Benutze konsequent C++-Sprachmittel, dann brauchst du solche Hacks auch nicht. Jedenfalls sollte ein Konstruktor immer ein gültiges Objekt erzeugen, keine leere Hülle.
Funktionen mit Namen wie "distance" kingen nicht nach typischen Memberfunktionen. Die Distanz zweier Objekte ist doch keine Eigenschaft eines dieser Objekte. Das klingt eher nach einem Fall für freie Funktionen.

Du siehst, es gibt neben dem schon genannten Fehler noch jede Menge technischer und designerischer Verbesserungmöglichkeiten, viele davon sogar dringend. Ich bin jetzt noch nicht einmal in die Tiefe des Codes eingedrungen, sondern berichte nur von meinem ersten Eindruck.

]]>https://www.c-plusplus.net/forum/post/2234361https://www.c-plusplus.net/forum/post/2234361Fri, 20 Jul 2012 12:21:45 GMT<![CDATA[Reply to Speicherleck? Oder falsches Kopieren? on Fri, 20 Jul 2012 12:46:04 GMT]]>Danke für die Antworten erstmal.

Ich weiß, dass das Programm einige Design-Schwächen aufweist. Meine Erfahrung in C++ ist auch nicht allzu berauschend.

cooky451 schrieb:

Und warum sind die Methoden alle virtual? oO

Ursprünglich war es geplant, dass verschiedene Dateiformate unterstützt werden, deren Atome neben den minimal erforderlichen Daten noch einige Extras speichern können.

Du hast ja anscheinend mehrere gleichberechtigte Kopien der Atome (warum eigentlich?), die dann aber alle verbunden sind. Das heißt, wenn Atom a und Atom b benachbart sind und du eine Kopie von a machst, dann ist b bei deinem Code auf einmal ein Nachbar sowohl von a als auch von der Kopie. Das ist bestimmt nicht gewollt!

Es ist gewollt. Mir ist leider nichts besseres eingefallen, wie ich sonst Moleküle kopieren könnte. Wenn ich A-B kopiere, wollte ich sichergehen, dass A' - B' auch verbunden sind.

Es ist vlt zu sagen, dass während des Programmes nur 3 Moleküle mit sagen wir 100-10000 Atomen benötigt werden.

Es ist bei dir derzeit möglich, ein Atom in einem ungültigen Zustand zu erzeugen, da du ohne Not einen Defaultkonstruktor angelegt hat, der ein unvollständiges Atom erzeugt. Vermutlich weil du sonst das Array nicht hättest benutzen können.

Dem habe ich bisher keine gr0ße Beachtung geschenkt.

Was mich jedoch am meisten interessiert ist, warum das Programm nun so abnormal terminiert. Heute morgen lief es noch und eigenltich habe ich nichts am Einlesen der Daten verändert.

Wenn du Problem mit Laufzeitfehlern hast, dann gib uns bitte auch lauffähigen Code. Siehe dritter Link in meiner Signatur.

Ich werde versuchen, etwas zu extrahieren. Könnte allerdings ein wenig Zeit beanspruchen.

Zunächst einmal vielen Dank für die Tipps bisher, auch wenn ich mich gleich im Voraus dafür entschuldige, dass ich sie nicht alle sofort beherzigen kann.
Das hat nichts mit Uneinsichtigkeit zu tun, nur drängt die Zeit und ein schlecht funktionierendes Programm hilft mir erstmal mehr als ein nicht funktionierendes Programm.

Ich mach mich mal daran, ein lauffähiges Beispiel zusammenzustellen.

]]>https://www.c-plusplus.net/forum/post/2234374https://www.c-plusplus.net/forum/post/2234374Fri, 20 Jul 2012 12:46:04 GMT<![CDATA[Reply to Speicherleck? Oder falsches Kopieren? on Fri, 20 Jul 2012 13:04:36 GMT]]>Ravenheart_unreg schrieb:

Du hast ja anscheinend mehrere gleichberechtigte Kopien der Atome (warum eigentlich?), die dann aber alle verbunden sind. Das heißt, wenn Atom a und Atom b benachbart sind und du eine Kopie von a machst, dann ist b bei deinem Code auf einmal ein Nachbar sowohl von a als auch von der Kopie. Das ist bestimmt nicht gewollt!

Es ist gewollt. Mir ist leider nichts besseres eingefallen, wie ich sonst Moleküle kopieren könnte. Wenn ich A-B kopiere, wollte ich sichergehen, dass A' - B' auch verbunden sind.

Ich glaube du verstehst den Fehler gar nicht! In dem Beispiel ist nicht nur A-B verbunden und A'-B', sondern auch A-A', A-B', A'-B und B-B'. Ich kann mir einfach nicht vorstellen, dass dies wirklich gewollt ist.

Was mich jedoch am meisten interessiert ist, warum das Programm nun so abnormal terminiert. Heute morgen lief es noch und eigenltich habe ich nichts am Einlesen der Daten verändert.

Ich denke, manni66 war da schon auf einer heißen Spur. Ansonsten Debugger anwerfen. Unter Linux auch mal valgrind mit allen Tests drauf loslassen. Von dem zu urteilen, was ich bisher sehe, sind da bestimmt viele Fehler drin.

]]>https://www.c-plusplus.net/forum/post/2234379https://www.c-plusplus.net/forum/post/2234379Fri, 20 Jul 2012 13:04:36 GMT<![CDATA[Reply to Speicherleck? Oder falsches Kopieren? on Fri, 20 Jul 2012 13:30:36 GMT]]>

Ich glaube du verstehst den Fehler gar nicht! In dem Beispiel ist nicht nur A-B verbunden und A'-B', sondern auch A-A', A-B', A'-B und B-B'. Ich kann mir einfach nicht vorstellen, dass dies wirklich gewollt ist.

Ich weiß dass das sehr unschön ist und ich mir definitiv etwas schöneres überlegen sollte.
Im Moment sollte es jedoch so sein, dass Atome, welche kopiert werden, stets temporär sind und ohnehin verfallen. Wie in diesem Beispiel A-B' .
Zwar haben A' und B' noch die Adressen von A und B gespeichert, jedoch verlasse ich mich darauf, (allein das ist ja schon ein Merkmal für schlechtes Design) dass das nie eine Rolle spielen wird.

bool Atom::isConnected(const Atom& atom) const
{
    for (std::list<Atom*>::const_iterator iter = neighbours.begin();
            iter != neighbours.end(); iter++)
    {
        if (*iter == &atom)
            return true;
    }
    return false;
}

Solange ein Atom keine Adresse bekommt, die vorher schon ein anderes, nicht mehr existentes Atom hatte, sollte das imo funktionieren.

Aber ich stimme voll und ganz mit dir überein, dass das nicht optimal gelöst und sehr fehleranfällig obendrein.

Das Problem ist in nur in der Methode:
m.addAtom(atom[i])

Valgrind gibt so etwas aus:
==5025== Warning: silly arg (-16) to __builtin_new()

Im Debugger finde ich auch Hinweise auf ein ungültiges new in Vector:
__gnu_cxx::new_allocator<Atom>::allocate() at new_allocator.h:94 0x40f479

Leider weiß ich dennoch nicht, wie ich diese Information auswerten kann.

Falls jemanden noch etwas Offensichtliches auffalen sollte, dann kann eres bitte posten.
Ansonsten mache ich mich mal daran, das ganze so weit wie möglich zu verbessern.
Ein etwas besseres Design hilf mir hoffentlich die meisten Fehlerquellen auszuschließen.

]]>https://www.c-plusplus.net/forum/post/2234389https://www.c-plusplus.net/forum/post/2234389Fri, 20 Jul 2012 13:30:36 GMT<![CDATA[Reply to Speicherleck? Oder falsches Kopieren? on Fri, 20 Jul 2012 14:01:58 GMT]]>Ravenheart_unreg schrieb:

Aber ich stimme voll und ganz mit dir überein, dass das nicht optimal gelöst und sehr fehleranfällig obendrein.

Ravenheart_unreg schrieb:

Solange ein Atom keine Adresse bekommt, die vorher schon ein anderes, nicht mehr existentes Atom hatte, sollte das imo funktionieren.

Fällt dir nichts auf? Du hast Fehler.

Das Problem ist in nur in der Methode:
m.addAtom(atom[i])

Valgrind gibt so etwas aus:
==5025== Warning: silly arg (-16) to __builtin_new()

Da ist höchstwahrscheinlich schon lange vorher was falsch. Vermutlich existiert das vector-Objekt gar nicht mehr. Compilier mal mit Debugsymbolen (beim GCC mit -g) und starte valgrind mit (fast) allen Tests. Ich mache meistens:

valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --track-fds=yes ./executable
]]>https://www.c-plusplus.net/forum/post/2234398https://www.c-plusplus.net/forum/post/2234398Fri, 20 Jul 2012 14:01:58 GMT<![CDATA[Reply to Speicherleck? Oder falsches Kopieren? on Fri, 20 Jul 2012 14:13:24 GMT]]>

Fällt dir nichts auf? Du hast Fehler.

Mir fällt leider nichts auf 😞

Da ist höchstwahrscheinlich schon lange vorher was falsch. Vermutlich existiert das vector-Objekt gar nicht mehr. Compilier mal mit Debugsymbolen (beim GCC mit -g) und starte valgrind mit (fast) allen Tests.

Ich kompiliere standardmäßig mit -g3

Ausgabe von valgrind mit den von dir gegebenen Argumenten:

valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --track-fds=yes ./iENM
==6301== Memcheck, a memory error detector
==6301== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==6301== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==6301== Command: ./iENM
==6301== 
Erhalte Atom: 26.091
52.849
39.889
KOPIERKTR
Erhalte Atom: 27.437
49.969
37.786
==6301== Warning: silly arg (-16) to __builtin_new()
**6301** new/new[] failed and should throw an exception, but Valgrind
**6301**    cannot throw exceptions and so is aborting instead.  Sorry.
==6301==    at 0x4C26D0C: ??? (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6301==    by 0x4C28766: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6301==    by 0x40F588: __gnu_cxx::new_allocator<Atom>::allocate(unsigned long, void const*) (new_allocator.h:94)
==6301==    by 0x40F0D8: std::_Vector_base<Atom, std::allocator<Atom> >::_M_allocate(unsigned long) (in /home/anubis/Coding/workspace eclipse c++/iENM/Debug/iENM)
==6301==    by 0x43BE3B: void std::vector<Atom, std::allocator<Atom> >::_M_emplace_back_aux<Atom const&>(Atom const&&&) (vector.tcc:402)
==6301==    by 0x43BAD2: std::vector<Atom, std::allocator<Atom> >::push_back(Atom const&) (stl_vector.h:891)
==6301==    by 0x43B635: Molecule::addAtom(Atom const&) (Molecule.cpp:28)
==6301==    by 0x410778: FileReader::readFile(std::string) (FileReader.cpp:45)
==6301==    by 0x43DDD8: main (main.cpp:25)
==6301== 
==6301== FILE DESCRIPTORS: 3 open at exit.
==6301== Open file descriptor 2: /dev/pts/1
==6301==    <inherited from parent>
==6301== 
==6301== Open file descriptor 1: /dev/pts/1
==6301==    <inherited from parent>
==6301== 
==6301== Open file descriptor 0: /dev/pts/1
==6301==    <inherited from parent>
==6301== 
==6301== 
==6301== HEAP SUMMARY:
==6301==     in use at exit: 4,397 bytes in 18 blocks
==6301==   total heap usage: 26 allocs, 8 frees, 12,641 bytes allocated
==6301== 
==6301== 5 bytes in 1 blocks are still reachable in loss record 1 of 18
==6301==    at 0x4C28BED: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6301==    by 0x7434918: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74F56F2: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74320F7: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x400DF7F: call_init (dl-init.c:85)
==6301==    by 0x400E076: _dl_init (dl-init.c:134)
==6301==    by 0x4000B29: ??? (in /lib/x86_64-linux-gnu/ld-2.13.so)
==6301== 
==6301== 6 bytes in 1 blocks are still reachable in loss record 2 of 18
==6301==    at 0x4C28BED: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6301==    by 0x7434918: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74F57CA: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74320F7: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x400DF7F: call_init (dl-init.c:85)
==6301==    by 0x400E076: _dl_init (dl-init.c:134)
==6301==    by 0x4000B29: ??? (in /lib/x86_64-linux-gnu/ld-2.13.so)
==6301== 
==6301== 6 bytes in 1 blocks are still reachable in loss record 3 of 18
==6301==    at 0x4C28BED: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6301==    by 0x7434918: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74F58A2: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74320F7: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x400DF7F: call_init (dl-init.c:85)
==6301==    by 0x400E076: _dl_init (dl-init.c:134)
==6301==    by 0x4000B29: ??? (in /lib/x86_64-linux-gnu/ld-2.13.so)
==6301== 
==6301== 24 bytes in 1 blocks are still reachable in loss record 4 of 18
==6301==    at 0x4C28BED: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6301==    by 0x7434918: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74FC468: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74F5719: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74320F7: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x400DF7F: call_init (dl-init.c:85)
==6301==    by 0x400E076: _dl_init (dl-init.c:134)
==6301==    by 0x4000B29: ??? (in /lib/x86_64-linux-gnu/ld-2.13.so)
==6301== 
==6301== 24 bytes in 1 blocks are still reachable in loss record 5 of 18
==6301==    at 0x4C28BED: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6301==    by 0x7434918: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74FC468: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74F57F1: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74320F7: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x400DF7F: call_init (dl-init.c:85)
==6301==    by 0x400E076: _dl_init (dl-init.c:134)
==6301==    by 0x4000B29: ??? (in /lib/x86_64-linux-gnu/ld-2.13.so)
==6301== 
==6301== 24 bytes in 1 blocks are still reachable in loss record 6 of 18
==6301==    at 0x4C28BED: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6301==    by 0x7434918: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74FC468: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74F58CC: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74320F7: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x400DF7F: call_init (dl-init.c:85)
==6301==    by 0x400E076: _dl_init (dl-init.c:134)
==6301==    by 0x4000B29: ??? (in /lib/x86_64-linux-gnu/ld-2.13.so)
==6301== 
==6301== 56 bytes in 1 blocks are still reachable in loss record 7 of 18
==6301==    at 0x4C286E7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6301==    by 0x40F588: __gnu_cxx::new_allocator<Atom>::allocate(unsigned long, void const*) (new_allocator.h:94)
==6301==    by 0x40F0D8: std::_Vector_base<Atom, std::allocator<Atom> >::_M_allocate(unsigned long) (in /home/anubis/Coding/workspace eclipse c++/iENM/Debug/iENM)
==6301==    by 0x43BE3B: void std::vector<Atom, std::allocator<Atom> >::_M_emplace_back_aux<Atom const&>(Atom const&&&) (vector.tcc:402)
==6301==    by 0x43BAD2: std::vector<Atom, std::allocator<Atom> >::push_back(Atom const&) (stl_vector.h:891)
==6301==    by 0x43B635: Molecule::addAtom(Atom const&) (Molecule.cpp:28)
==6301==    by 0x41075E: FileReader::readFile(std::string) (FileReader.cpp:44)
==6301==    by 0x43DDD8: main (main.cpp:25)
==6301== 
==6301== 60 bytes in 1 blocks are possibly lost in loss record 8 of 18
==6301==    at 0x4C286E7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6301==    by 0x6710AB8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17)
==6301==    by 0x67124A4: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17)
==6301==    by 0x6712582: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17)
==6301==    by 0x43DDC1: main (main.cpp:25)
==6301== 
==6301== 136 bytes in 1 blocks are still reachable in loss record 9 of 18
==6301==    at 0x4C28BED: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6301==    by 0x7434918: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74F5E64: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74F566B: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74320F7: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x400DF7F: call_init (dl-init.c:85)
==6301==    by 0x400E076: _dl_init (dl-init.c:134)
==6301==    by 0x4000B29: ??? (in /lib/x86_64-linux-gnu/ld-2.13.so)
==6301== 
==6301== 136 bytes in 1 blocks are still reachable in loss record 10 of 18
==6301==    at 0x4C28BED: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6301==    by 0x7434918: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74F5E64: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74F574A: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74320F7: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x400DF7F: call_init (dl-init.c:85)
==6301==    by 0x400E076: _dl_init (dl-init.c:134)
==6301==    by 0x4000B29: ??? (in /lib/x86_64-linux-gnu/ld-2.13.so)
==6301== 
==6301== 136 bytes in 1 blocks are still reachable in loss record 11 of 18
==6301==    at 0x4C28BED: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6301==    by 0x7434918: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74F5E64: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74F5822: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74320F7: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x400DF7F: call_init (dl-init.c:85)
==6301==    by 0x400E076: _dl_init (dl-init.c:134)
==6301==    by 0x4000B29: ??? (in /lib/x86_64-linux-gnu/ld-2.13.so)
==6301== 
==6301== 256 bytes in 1 blocks are still reachable in loss record 12 of 18
==6301==    at 0x4C28BED: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6301==    by 0x7434918: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74FC47A: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74F58CC: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74320F7: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x400DF7F: call_init (dl-init.c:85)
==6301==    by 0x400E076: _dl_init (dl-init.c:134)
==6301==    by 0x4000B29: ??? (in /lib/x86_64-linux-gnu/ld-2.13.so)
==6301== 
==6301== 488 bytes in 1 blocks are still reachable in loss record 13 of 18
==6301==    at 0x4C28147: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6301==    by 0x4102EB: FileReader::readFile(std::string) (FileReader.cpp:16)
==6301==    by 0x43DDD8: main (main.cpp:25)
==6301== 
==6301== 512 bytes in 1 blocks are still reachable in loss record 14 of 18
==6301==    at 0x4C28BED: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6301==    by 0x7434918: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74FC47A: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74F5719: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74320F7: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x400DF7F: call_init (dl-init.c:85)
==6301==    by 0x400E076: _dl_init (dl-init.c:134)
==6301==    by 0x4000B29: ??? (in /lib/x86_64-linux-gnu/ld-2.13.so)
==6301== 
==6301== 512 bytes in 1 blocks are still reachable in loss record 15 of 18
==6301==    at 0x4C28BED: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6301==    by 0x7434918: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74FC47A: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74F57F1: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74320F7: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x400DF7F: call_init (dl-init.c:85)
==6301==    by 0x400E076: _dl_init (dl-init.c:134)
==6301==    by 0x4000B29: ??? (in /lib/x86_64-linux-gnu/ld-2.13.so)
==6301== 
==6301== 672 bytes in 1 blocks are still reachable in loss record 16 of 18
==6301==    at 0x4C28BED: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6301==    by 0x7434918: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74F4F81: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74F5663: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74320F7: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x400DF7F: call_init (dl-init.c:85)
==6301==    by 0x400E076: _dl_init (dl-init.c:134)
==6301==    by 0x4000B29: ??? (in /lib/x86_64-linux-gnu/ld-2.13.so)
==6301== 
==6301== 672 bytes in 1 blocks are still reachable in loss record 17 of 18
==6301==    at 0x4C28BED: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6301==    by 0x7434918: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74F4F81: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74F5742: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74320F7: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x400DF7F: call_init (dl-init.c:85)
==6301==    by 0x400E076: _dl_init (dl-init.c:134)
==6301==    by 0x4000B29: ??? (in /lib/x86_64-linux-gnu/ld-2.13.so)
==6301== 
==6301== 672 bytes in 1 blocks are still reachable in loss record 18 of 18
==6301==    at 0x4C28BED: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6301==    by 0x7434918: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74F4F81: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74F581A: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x74320F7: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0)
==6301==    by 0x400DF7F: call_init (dl-init.c:85)
==6301==    by 0x400E076: _dl_init (dl-init.c:134)
==6301==    by 0x4000B29: ??? (in /lib/x86_64-linux-gnu/ld-2.13.so)
==6301== 
==6301== LEAK SUMMARY:
==6301==    definitely lost: 0 bytes in 0 blocks
==6301==    indirectly lost: 0 bytes in 0 blocks
==6301==      possibly lost: 60 bytes in 1 blocks
==6301==    still reachable: 4,337 bytes in 17 blocks
==6301==         suppressed: 0 bytes in 0 blocks
==6301== 
==6301== For counts of detected and suppressed errors, rerun with: -v
==6301== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)

Als Laie kann ich nur herauslesen, dass eine Speicherallokation für einen Alllokator fehlschlägt.

Ich könnte um den Abbruch von valgrnd zu verhindern, eventuell die Tipps von
http://stackoverflow.com/questions/365458/how-can-i-detect-if-a-program-is-running-from-within-valgrind befolgen

]]>https://www.c-plusplus.net/forum/post/2234402https://www.c-plusplus.net/forum/post/2234402Fri, 20 Jul 2012 14:13:24 GMT<![CDATA[Reply to Speicherleck? Oder falsches Kopieren? on Fri, 20 Jul 2012 14:20:59 GMT]]>Da bleibt mir nur der Ruf nach einem lauffähigem Beispiel, welches den Fehler zeigt, damit man sich das mal selber angucken kann.

]]>https://www.c-plusplus.net/forum/post/2234403https://www.c-plusplus.net/forum/post/2234403Fri, 20 Jul 2012 14:20:59 GMT