ich habe folgende valgrind ausgabe:

==15746== 62 bytes in 2 blocks are definitely lost in loss record 286 of 775
==15746==    at 0x4A085C7: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==15746==    by 0x3780C9B860: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib64/libstdc++.so.6.0.8)
==15746==    by 0x3780C9C364: ??? (in /usr/lib64/libstdc++.so.6.0.8)
==15746==    by 0x3780C9C511: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib64/libstdc++.so.6.0.8)
==15746==    by 0x4659CA: TestApplication::handleEvent(AEvent*) (TestApplication.cc:1280)
==15746==    by 0x4D2319: EventGroup<AEvent>::sendTo(SubscriberSet, std::string) (AEvent.h:34)
==15746==    by 0x42A887: Dispatcher::process() (Dispatcher.cc:791)

an der entsprechenden stelle in der TestApplication wird folgendes gemacht:

dis->signal( new BEvent("message"));  //TestApplication.cc:1280

Und BEvent ist verkürzt:

class BEvent : public BEventGroup<BEvent> {
        public:

            BEvent(const std::string & s)
            : measurement(s) {
            }

        private:
            std::string measurement;
        };

Kann mir jemand erklären, woher der Fehler kommt und wie ich ihn wegbekomme? Valgrind habe ich mit valgrind -v --leak-check=yes aufgerufen.

Schon mal dank!

in der angegebenen zeile. laut log wird es auch verarbeitet vom eventhandler und der löscht am ende alle events.

in der angegebenen zeile. laut log wird es auch verarbeitet vom eventhandler und der löscht am ende alle events.

Entweder stimmt diese Aussage nicht und der eventhandler kümmert sich nicht um die Freigabe, obwohl er die Verantwortung für die Ressource hat. Oder der eventhandler ist fehlerhaft programmiert, zum Beispiel könnte er ein Ressourcenhandler sein, der die Regel der großen Drei verletzt.

Ich tippe mal auf letzteres.

die regel der großen drei????

der eventhandler ist im dispatcher beheimatet und sieht im process schritt wie folgt aus:

void
        Dispatcher::process() {

            if (pendingObjects.size() > 0) {

                DEBUG("process - Processing " << pendingObjects.size() << " pending objects: " << pendingObjects);
                DeliverableObject * object;
                for (auto o = pendingObjects.begin(); o != pendingObjects.end();) {
                    object = *o;

                    if (object != NULL) {
                        DEBUG("process - Processing " << object << ", groups: " << object->getGroups());

                        GroupList groups = object->getGroups();
                        for (auto g = groups.begin(); g != groups.end(); g++) {
                            SubscriberSet subscribers = subscriptions[*g];
                            DEBUG("process - Type " << *g << " has " << subscribers.size() << " subscribers");

                            if (subscribers.size() > 0) {
                                object->sendTo(subscribers, *g);
                            }
                        }
                    }
                    else {
                        DEBUG("process - Error: Object is NULL! Delivery aborted.");
                    }

                    // The iterator <o> used here has to be reinitialized after each
                    // erase operation to ensure its sanity.
                    o = pendingObjects.erase(o);

                    DEBUG("process - Finished " << object);
                    DEBUG("process - " << pendingObjects.size() << " objects left.")
                    delete object; //<<--- lösche event ?!
                }
                DEBUG("process - Finished processing pending objects.");
            }
        }

Das ganze haben wir selbst geschrieben und basiert auf dem Curiously recurring template pattern.
http://en.wikipedia.org/wiki/Curiously_recurring_template_pattern

wir nutzen da die type_info einer klasse um sich für einen event zu registrieren. tut eigentlich ganz gut, bis auf das valgrind gemaule.

Der output sagt:

DIS@192.168.0.1:100 process - Processing BEvent [Measurement: REJOIN], groups: [EventE, PN6BEventE, PN618BEventE]
DIS@192.168.0.1:100 process - Type EventE has 1 subscribers
DIS@192.168.0.1:100 process - Type PN6BEventE has 1 subscribers
DIS@192.168.0.1:100 process - Finished BEvent [Measurement: REJOIN]
DIS@192.168.0.1:100 process - 0 objects left.

Daher nehm ich an, dass es auch gelöscht wird bei delete im obigen code. oder irre ich hier?

Hat DeliverableObject einen virtuellen Destruktor?

DeliverableObject koennte auch ein BEvent-Zeiger als Member haben, ohne virtuellen Destruktor.

Hat DeliverableObject einen virtuellen Destruktor?

DeliverableObject koennte auch ein BEvent-Zeiger als Member haben, ohne virtuellen Destruktor.

Dann ist das gezeigte delete nicht das, welches das Event löscht.

knivil schrieb:

Hat DeliverableObject einen virtuellen Destruktor?

DeliverableObject koennte auch ein BEvent-Zeiger als Member haben, ohne virtuellen Destruktor.

Dann ist das gezeigte delete nicht das, welches das Event löscht.

Whatever, der Destruktor kann aber das Event loeschen und dann waere gezeigtes delete dafuer verantwortlich. Es bringt jetzt nichts alle Moeglichkeiten durchzuraten. Es koennte auch ganz anders sein.

sorry, gestern abend war ich unterwegs und hab nicht mehr reingeschaut. freut mich, dass die frage soviel interesse weckt!

es scheint in der tat der fehlende virtuelle konstruktor gewesen zu sein. diesen hinzugefügt und valgrind ist glücklich. heißt das, wenn delete aufgerufen wurde, dass da nur das deliverableObject gelöscht wurde, und die darauf aufbauenden events blieben übrig?

was sind nochmal die großen drei?

ich danke euch vielmals.

da nur das deliverableObject gelöscht wurde, und die darauf aufbauenden events blieben übrig

Das kommt drauf an, wie die Klassen zueinander in Beziehung stehen. Ansosnte: Ja, wenn BEventGroup<BEvent> von DeliverableObject erbt.

Ansosnten: CRTP nutzen aber Grundlagen nicht verstehen. Irgendwas laeuft falsch.

crtp haben wir ja nicht genommen weil es so fancy ist, sondern weil es der einzige weg war, den wir gefunden hatten um das abonnieren von eventgruppen zu ermöglichen. lieber wäre es mir ohne gewesen.

das man copy constructor, zuweisungs operator und destructor immer angeben soll weiß ich. mir war es bloß nicht unter dem begriff der großen drei geläufig und da der hinweis bezüglich des eventhandlers gemacht wurde auch gerade nicht klar.

das man copy constructor, zuweisungs operator und destructor immer angeben soll weiß ich.

Das ist aber falsch. Die Regel der Grossen Drei besagt nur, dass wenn du einen der drei implementierst, du dann meistens auch die anderen zwei brauchst. In C++11 ist es mit Move-Konstruktor und Move-Zuweisungsoperator die Regel der Grossen Fünf.

Ich würde sogar behaupten, im Allgemeinen ist es gut, wenn man diese Memberfunktionen dem Compiler überlassen kann. Es zeigt nämlich, dass man gut von Low-Level-Operationen wie Speicherverwaltung, Kopieren, etc. abstrahiert hat und sich Objekte selbst kopieren/verschieben können. Gibt natürlich Fälle, wo eine Implementierung trotzdem nötig ist, meist wegen Exceptionsicherheit.

Interessanter Artikel: Rule Of Zero