Absturz wegen cEvent::title == NULL - Warum???

kls · December 2, 2024 at 2:37 PM

Quote from shofmann

Ich habe exemplarisch mal ein wenig in Live herumgestöbert und frage mich, ob zum Beispiel hier:
...
… nicht auch noch ein LOCK_SCHEDULES_READ gebräucht würde.

Die Funktion bekommt ja 'schedules' übergeben, welches nur über einen Lock erhalten werden konnte.

Also nein.

Quote from shofmann

Heißt das, dass man keine Locks setzen muss, solange man den zugeordneten Pointer (Timers, Channels, Schedules, Recordings) im Code nicht benötigt?

So ist es.

Quote from shofmann

Welche indirekte Abhängigkeiten gibt es diesbezüglich? Wie etwa die folgenden:

Du musst nur die Listen locken, mit denen du arbeiten möchtest. Wenn du mit mehreren Listen gleichzeitig arbeiten möchtest, musst du sie alle locken, und zwar in genau der genannten Reihenfolge, da es sonst zu Verklemmungen kommen könnte, wenn mehrere Threads auf mehrere Listen warten, sie aber in unterschiedlicher Reihenfolge locken.

kls · December 2, 2024 at 2:41 PM

Quote from FireFly

Wie sieht es mit dem realloc() in den beiden cString::Append() in tools.c aus?

Da sehe ich keine Probleme, da in den Daten-Members von cTimer, cChannel, cEvent und cRecording kein cString vorkommt.

kls · December 2, 2024 at 2:48 PM

Quote from shofmann

Auch wenn die meisten davon vermutlich eher unkritisch sind, sollte man sie bei dieser Gelegenheit wohl besser doch auf potentielle Race conditions bzw. Use-after-free-Szenarien überprüfen.

Werde ich selber aus Zeitgründen nicht machen, bin aber natürlich für jeden Bug-Report dankbar.

MarkusE · December 2, 2024 at 2:51 PM

Ich denke, hier wäre zusätzliche Dokumentation hilfreich.

Ist generell ein lesender Zugriff auf ein cEvent nur dann erlaubt, wenn ein read lock auf schedules gehalten wird?

Oder: Darf ich auf bestimmte Methoden eines cEvent zugreifen, ohne einen read lock auf schedules? Z.B. auf EventID()?

Und brauche den read lock auf schedules nur beim Zugriff auf "kritische" Methoden, z.B. Title(), ShortText(), ...?

~ Markus

kls · December 2, 2024 at 2:56 PM

MarkusE Sobald ein Pointer auf ein Objekt in einer dieser Listen dereferenziert wird, muss ein entsprechender Lock bestehen.

Siehe auch tools.h:

Code

class cListBase {
...
  bool Lock(cStateKey &StateKey, bool Write = false, int TimeoutMs = 0) const;
       ///< Tries to get a lock on this list and returns true if successful.
       ///< By default a read lock is requested. Set Write to true to obtain
       ///< a write lock. If TimeoutMs is not zero, it waits for the given
       ///< number of milliseconds before giving up.
       ///< If you need to lock more than one list at the same time, make sure
       ///< you set TimeoutMs to a suitable value in all of the calls to
       ///< Lock(), and be prepared to handle situations where you do not get all
       ///< of the requested locks. In such cases you should release all the locks
       ///< you have obtained so far and try again. StateKey.TimedOut() tells you
       ///< whether the lock attempt failed due to a timeout or because the state
       ///< of the lock hasn't changed since the previous locking attempt.
       ///< To implicitly avoid deadlocks when locking more than one of the global
       ///< lists of VDR at the same time, make sure you always lock Timers, Channels,
       ///< Recordings and Schedules in this sequence.
       ///< You may keep pointers to objects in this list, even after releasing
       ///< the lock. However, you may only access such objects if you are
       ///< holding a proper lock again. If an object has been deleted from the list
       ///< while you did not hold a lock (for instance by an other thread), the
       ///< object will still be there, but no longer within this list (it is then
       ///< stored in the ListGarbageCollector). That way even if you access the object
       ///< after it has been deleted, you won't cause a segfault. You can call the
       ///< Contains() function to check whether an object you are holding a pointer
       ///< to is still in the list. Note that the garbage collector is purged when
       ///< the usual housekeeping is done.

Display More

kls · December 2, 2024 at 3:20 PM

Es gibt noch eine Stelle, an der ich mich nicht an meine eigene Vorgabe gehalten habe

Diff

--- skinlcars.c 2024/09/21 10:53:07     5.7
+++ skinlcars.c 2024/12/02 14:15:55
@@ -1259,6 +1259,7 @@
      int NumDevices = 0;
      int y = ys04;
      // Timers and recording devices:
+     LOCK_SCHEDULES_READ;
      while (1) {
            int NumTimers = 0;
            const cDevice *Device = NULL;

SHofmann · December 2, 2024 at 5:10 PM

Quote from kls

Sobald ein Pointer auf ein Objekt in einer dieser Listen dereferenziert wird, muss ein entsprechender Lock bestehen.

Danke dir. Ich hatte so eine Antwort erwartet bzw. befürchtet. Da wird wohl in machen Plugins noch einiges zu berichtigten sein…

kfb77 · December 2, 2024 at 6:05 PM

Quote from shofmann

Heißt das, dass man keine Locks setzen muss, solange man den zugeordneten Pointer (Timers, Channels, Schedules, Recordings) im Code nicht benötigt?

Quote from kls

So ist es.

und

Quote from kls

Sobald ein Pointer auf ein Objekt in einer dieser Listen dereferenziert wird, muss ein entsprechender Lock bestehen.

Ist für mich gerade irgendwie ein Wiederspruch.

Beispiel:

Code

bool cEpgHandlerMarkad::HandleEvent(cEvent *Event) {
... irgendwelcher Code
    if (Event->RunningStatus() <= 0) return false;

Brauche ich da einen LOCK_SCHEDULES_READ oder kann ich davon ausgehen, dass das Objekt für die Dauer des Aufrufes unverändert bleibt ?

Ich nutze ja nicht die Liste, sondern nur ein einzelnes Objekt davon.

kls · December 2, 2024 at 6:09 PM

Wenn du ein Objekt übergeben bekommst, ist dessen Liste gelockt.

kfb77 · December 2, 2024 at 6:12 PM

Das macht Sinn. Danke.

SHofmann · December 3, 2024 at 12:07 PM

Quote from kfb77

Ich nutze ja nicht die Liste, sondern nur ein einzelnes Objekt davon.

… das sich zwischen den Zeilen 1 und 3 ja inzwischen schon wieder geändert haben oder gar gelöscht worden sein könnte. Insofern wäre mir der Lock einsichtiger, aber irgendwie bin ich jetzt noch mehr verwirrt.

Für mich stellt sich die Situation bislang so dar: Wann auch immer man auf eine der Listen zugreift (sprich: einen der besagten Pointer benötigt) oder (später) eines seiner Objekte referenziert, braucht man Locks auf die ursprüngliche Liste sowie die Listen aller Objekte, die davon direkt oder indirekt verlinkt sind.

Liege ich jetzt damit richtig, oder ist das noch immer nicht die ganze Wahrheit?

kfb77 · December 3, 2024 at 12:11 PM

Quote from shofmann

… das sich zwischen den Zeilen 1 und 3 ja inzwischen schon wieder geändert haben oder gar gelöscht worden sein könnte.

Nein, kann es nicht, da:

Quote from kls

Wenn du ein Objekt übergeben bekommst, ist dessen Liste gelockt.

FireFly · December 3, 2024 at 12:28 PM

genauer gesagt: Wenn du ein Objekt vom VDR übergeben bekommst, ist dessen Liste gelockt.

Wenn man selbst z.B. einen Event aus Schedules ändern will muss man Schedules locken solange man mit dem Event (-Pointer) arbeitet.

kls · December 3, 2024 at 3:57 PM

Quote from FireFly

genauer gesagt: Wenn du ein Objekt vom VDR übergeben bekommst, ist dessen Liste gelockt.

Ja, so war das natürlich gemeint.

Absturz wegen cEvent::title == NULL - Warum???

Participate now!

Users Viewing This Thread