Speicherverbrauch steigt mit der Zeit

wenn p Null wird, darfst Du s nicht vergessen.

Das ist aber nur der Fehlerfall und erklärt jetzt nicht Euer herbes leak.

Zitat von ReelChris

Das ist aber nur der Fehlerfall und erklärt jetzt nicht Euer herbes leak

Im Orignalcode von kls geht doch bei p!=s der Block, auf den p zeigt verloren und s zeigt ins Nirvana.

Oder täusche ich mich da?

ah, ich hab den Diff falsch verstanden: richtig, s wird freigegeben, p geht verloren der strcpy ist Quatsch weil von Realloc mit erledigt. Im Fehlerfall bleibt s erhalten aber hat eine unerwartete Größe.

SHF du hast da vollkommen Recht, diese Funtion ist fehlerhaft!

In erster Näherung sollte das wohl so aussehen:

cString &cString::Append(const char *String)
{
  int l1 = s ? strlen(s) : 0;
  int l2 = String ? strlen(String) : 0;
  char *p = (char *)realloc(s, l1 + l2 + 1);
  if (p) {
     s = p;
     strcpy(s + l1, String);
     }
  else
     ;//TODO error
  return *this;
}

Allerdings habe ich eine Ausgabe eingebaut um zu sehen, ob diese Funktion überhaupt jemals aufgerufen wird.

Bis jetzt kein Aufruf.

Hier die Funktion mit allen Checks:

cString &cString::Append(const char *String)
{
  if (String) {
     int l1 = s ? strlen(s) : 0;
     int l2 = strlen(String);
     if (char *p = (char *)realloc(s, l1 + l2 + 1)) {
        s = p;
        strcpy(s + l1, String);
        }
     else
        esyslog("ERROR: out of memory");
     }
  return *this;
}

Bis jetzt immer noch kein Aufruf. Anscheinend wird die Funktion (zumindest im Core-VDR) nicht benutzt.

Zitat von kls

Anscheinend wird die Funktion (zumindest im Core-VDR) nicht benutzt.

Hatte mich auch schon gewundert, warum der Fehler nicht auch anderweitig aufgefallen ist.

An einigen Stellen (zB. args.c und sicher noch anderen) ist die Funktion aber schon drin.

Das mit args benutze ich nicht, daher hier auch kein entsprechender Aufruf.

Nachdem ich den Fehler jetzt gesehen habe wundert es mich auch, dass da nicht schon was passiert ist...

Wobei: cArgs::arg ist eine cStringList und kein cString ;-).

Zitat von kls

Wobei: cArgs::arg ist eine cStringList und kein cString ;-).

Ups, das hatte mein "grep" dann fälschlicherweise mit erwischt. Mir war die Feinheit auf die Schnelle nicht aufgefallen .

"Append" kommt ja nicht so selten vor ;-).

Edit:

cString::Append wird wohl wirklich nicht benutzt. Ich hab die Funktion auskommentiert und es gibt keine Fehlermeldungen.

Zitat von MegaV0lt

Bei den Strings steht eine menge zeug drin. Einiges könnte vom skin sein...

Ich denke der Dump ist vom Block:5645341c6000-56454ac39000 rw-p 00000000 00:00 0 [heap]?

Der passt von der Grösse und es ist auch einzige, wo sich nennenswert was tut.

So wie ich das sehe ist da der komplette EPG drin.

Das Vorgehen hilft also auch nicht weiter.

Ich empfehle nochmal, die Plugins auf das nötigste zu reduzieren und zu schauen, ob es dann immer noch auftritt.

Den Skin-Plugin kann man jedenfalls ohne einschränkung Benutzbarkeit zum Test mal raus nehmen.

Und cArgs wird ja nur einmal bei Programmstart aufgerufen, das hätte man dann schon gemerkt...

Zitat von MegaV0lt

Ja der ist innerhalb von ein paar Minuten von 330 auf 370MB gewachsen.

Das ist nach den Start normal.

Scheint am EPG zu liegen.

Man muss eine Weile warten, bis sich das stabilisiert hat.

Zitat von MegaV0lt

Das ganze EPG glaube ich kaum. Das wäre deutlich mehr.

Ob es wirklich vollständig ist, hab ich natürlich nicht kontrolliert, aber geschätzt 20% von dem Dump sind EPG.

370MB kann man sich im Hexeditor nur Stichprobenhaft ansehen. Selbst durchblätter ist nicht in sinnvollem Zeitrahmen möglich!

Zitat von MegaV0lt

Da stehen auch Massenweise Strings drin wie 333333 oder auch Sachen die IBEV oder anderes Kryptisches.

Das hat so ein Dump an sich ;-).

Zitat von MegaV0lt

333333 ist z.b sehr oft vorhanden

Ist das normal? Oder schon ein Hinweis auf ein Leck?

Kann ich nicht beurteilen, "333333" sagt mir nichts.

Das kann default Wert in irgend einem Datenfeld sein oder sonstwas, was zufällig den String "333333" ergibt.

Zitat von MegaV0lt

Der Speicheranstieg ist bei Bedienung (OSD) viel höher als wenn der VDR so füt Aufnahmen läuft.

Dann versuch es doch bitte mal ohne Skin-Plugins.

Wenn dann der Speicheranstieg nicht mehr auftritt, weiss man, dass es an den Plugins liegt.

Dann kannst du auch die Dumps vergleichen und sehen, ob die "333333" noch so häufig sind.

Speicheranstieg ist bei Bedienung (Transponderwechsel) kann aber auch am EPG liegen. Das sollte sich aber nach einer Weile Zappen auf einem Niveau einpendeln.