wenn p Null wird, darfst Du s nicht vergessen.
Das ist aber nur der Fehlerfall und erklärt jetzt nicht Euer herbes leak.
wenn p Null wird, darfst Du s nicht vergessen.
Das ist aber nur der Fehlerfall und erklärt jetzt nicht Euer herbes leak.
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;
}
Display More
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;
}
Display More
Bis jetzt immer noch kein Aufruf. Anscheinend wird die Funktion (zumindest im Core-VDR) nicht benutzt.
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 ;-).
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.
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...
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.
Ja der ist innerhalb von ein paar Minuten von 330 auf 370MB gewachsen.
Das ganze EPG glaube ich kaum. Das wäre deutlich mehr.
Da stehen auch Massenweise Strings drin wie 333333 oder auch Sachen die IBEV oder anderes Kryptisches.
Der Speicheranstieg ist bei Bedienung (OSD) viel höher als wenn der VDR so füt Aufnahmen läuft.
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.
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!
Da stehen auch Massenweise Strings drin wie 333333 oder auch Sachen die IBEV oder anderes Kryptisches.
Das hat so ein Dump an sich ;-).
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.
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.
Don’t have an account yet? Register yourself now and be a part of our community!