[gelöst] Segmentation fault bei Aufruf von vdr --help mit installierten Plugin tvscraper

FireFly Sollte auch kein Problem sein, denn

cEpgHandler::~cEpgHandler() 
{ 
 EpgHandlers.Del(this, false); 
}

kls: das "false" in EpgHandlers.Del(this, false); bedeutet ja, dass DeleteObj == false ist in cListBase::Del(cListObject *Object, bool DeleteObject), also das Objekt nur aus der Liste entfernt wird aber nicht mit delete gelöscht wird.
Gelöscht wird es erst beim Aufräumen im Destruktur von cListBase, der seine Clear()-Methode aufruft wie kfb77 oben schrieb.
Aber wenn es nicht mehr in der Liste ist kann der Destruktur es auch nicht mehr löschen oder bin ich komplett auf dem Holzweg?? Ich bitte um Aufklärung ....

Quote from FireFly

ich kann nur sagen, dass ich ohne zusätzliche Doku in meinem EPG-Plugin das EPGHandler-Objekt in Initialize() erzeuge und in Stop() lösche und keine Probleme habe.

Normalerweise funktioniert das ja auch, Klaus hat das sauber programmiert: Du kannst das Objekt löschen, aber wenn Du es nicht tust, löscht VDR das Objekt.

Das Problem ist dass VDR eine globale Liste mit diesen Objekten hat.

• VDR selbst greift auf diese globale Liste zu, z.B. beim EPG Scan und beim Aufräumen der Liste.
• Plugins greifen in einem anderen Thread auf die gleiche globale Liste zu, z.B. bei new cMyEpgHandler();, und auch wenn das Plugin den so erzeugten EPG Handler mit delete löscht.

Wir brächten also eine Dokumentation der Zeitpunkte, zu denen die Plugins EPG Handler erzeugen und löschen dürfen: Weil zu diesen Zeitpunkten sichergestellt ist, dass VDR selbst nicht auf diese Liste zugreift. Hoffen wir mal, dass nicht 2 verschiedene Plugins gleichzeitig auf diese Liste zugreifen .

Oder brauchen wir doch ein Locking für diese Liste?

~ Markus

Quote from FireFly

das "false" in EpgHandlers.Del(this, false); bedeutet ja, dass DeleteObj == false ist in cListBase::Del(cListObject *Object, bool DeleteObject), also das Objekt nur aus der Liste entfernt wird aber nicht mit delete gelöscht wird.

Klar, wir befinden uns ja hier im Destruktor eines cEpgHandler. D.h. der cEpgHandler meldet sich als "letzte Amtshandlung" von der Liste ab, die Liste darf aber nicht nochmal den Destruktor aufrufen.

Quote from FireFly

Gelöscht wird es erst beim Aufräumen im Destruktur von cListBase,

Nein, gelöscht wird es beim Verlassen des Destruktors von cEpgHandler (der ja gezielt mit delete aufgerufen wurde).

Quote from MarkusE

Oder brauchen wir doch ein Locking für diese Liste?

Wenn man es so macht, wie gedacht (also nur erzeugen, aber nicht explizit löschen) sollte es keine Probleme geben und kein Locking erforderlich sein. Wenn man es explizit löschen möchte, wäre ein LOCK_SCHEDULES_WRITE angebracht.

Ok, Danke Euch beiden für die Erklärung!

Ist eigentlich sichergestellt, dass alle cPlugin::Initialize() Aufrufe der Plugins hintereinander ausgeführt werden?

Oder kann es sein, dass cPlugin::Initialize() für 2 verschiedene Plugins gleichzeitig läuft, weil sie in 2 verschiedenen Threads laufen?

Ja:

bool cPluginManager::InitializePlugins(void) 
{ 
 for (cDll *dll = dlls.First(); dll; dll = dlls.Next(dll)) { 
     cPlugin *p = dll->Plugin(); 
     if (p) { 
        isyslog("initializing plugin: %s (%s): %s", p->Name(), p->Version(), p->Description()); 
        if (!p->Initialize()) 
           return false; 
        } 
     } 
 return true; 
}

btw: Macht das mit dem Initialize überhaupt einen Unterschied?

Zu dem Zeitpunkt sollte doch noch nicht erwartet werden, dass irgendein Plugin seine Funktion/Job ausführt. Oder versteh ich das falsch?

Quote from wirbel

btw: Macht das mit dem Initialize überhaupt einen Unterschied?

Zu dem Zeitpunkt sollte doch noch nicht erwartet werden, dass irgendein Plugin seine Funktion/Job ausführt. Oder versteh ich das falsch?

Doch, es macht einen Unterschied:

Wenn zwei Plugins in Initialize eine Instanz ihrer Klasse des epghandlers gleichzeitig erzeugen, wird gleichzeitig auf eine globale Tabelle (Liste der epghandler) zugegriffen.

Aber Klaus hat ja bestätigt, dass das nicht passieren kann, weil Initialize seriell aufgerufen wird.