Das EPG des aktuellen Senders wird aber weiter erfasst und man sieht dadurch einen Speicheranstieg.
Das ist klar. Da findet ja auch kein "Scan" statt. Der "EPG-Scan" bedeutet, daß er aktiv durch die einzelnen Transponder schaltet.
Klaus
Das EPG des aktuellen Senders wird aber weiter erfasst und man sieht dadurch einen Speicheranstieg.
Das ist klar. Da findet ja auch kein "Scan" statt. Der "EPG-Scan" bedeutet, daß er aktiv durch die einzelnen Transponder schaltet.
Klaus
Hallo Leute,
ich habe es auf meinem VDR-Server auch mal getestet ... Interessanterweise scheint es bei mir damit zusammenzuhängen, ob bei softhddevice das VAAPI-Frontend attached ist oder nicht.
Der RSS steigt permament an, bis ich um 9:32 das VAAPI-Frontend detached habe:
220 playstation SVDRP VideoDiskRecorder 2.2.0; Mon Mar 16 09:31:56 2015; UTF-8
900 SoftHdDevice is detached
221 playstation closing connection
RSS-Speicher Auslastung:
So 15. Mär 14:34:05 CET 2015 : SIZE RSS CMD
So 15. Mär 14:34:05 CET 2015 : 1738992 107080 /usr/bin/vdr
So 15. Mär 14:44:05 CET 2015 : 1738992 123568 /usr/bin/vdr
So 15. Mär 14:54:05 CET 2015 : 1738992 123856 /usr/bin/vdr
So 15. Mär 15:04:05 CET 2015 : 1951192 178688 /usr/bin/vdr
So 15. Mär 15:14:05 CET 2015 : 1967720 213656 /usr/bin/vdr
So 15. Mär 15:24:05 CET 2015 : 1967720 223232 /usr/bin/vdr
So 15. Mär 15:34:05 CET 2015 : 1967720 230708 /usr/bin/vdr
So 15. Mär 15:44:05 CET 2015 : 1967720 239368 /usr/bin/vdr
So 15. Mär 15:54:05 CET 2015 : 1967720 246900 /usr/bin/vdr
So 15. Mär 16:04:05 CET 2015 : 1967720 255060 /usr/bin/vdr
So 15. Mär 16:14:05 CET 2015 : 1967720 263000 /usr/bin/vdr
So 15. Mär 16:24:05 CET 2015 : 1967720 270312 /usr/bin/vdr
So 15. Mär 16:34:05 CET 2015 : 2033256 278016 /usr/bin/vdr
So 15. Mär 16:44:05 CET 2015 : 2033256 285996 /usr/bin/vdr
So 15. Mär 16:54:05 CET 2015 : 2033256 293480 /usr/bin/vdr
So 15. Mär 17:04:05 CET 2015 : 2033256 300980 /usr/bin/vdr
So 15. Mär 17:14:05 CET 2015 : 2033256 308844 /usr/bin/vdr
So 15. Mär 17:24:05 CET 2015 : 2033256 316400 /usr/bin/vdr
So 15. Mär 17:34:05 CET 2015 : 2033256 323736 /usr/bin/vdr
So 15. Mär 17:44:05 CET 2015 : 2033256 331432 /usr/bin/vdr
So 15. Mär 17:54:05 CET 2015 : 2098792 338908 /usr/bin/vdr
So 15. Mär 18:04:05 CET 2015 : 2098792 346432 /usr/bin/vdr
So 15. Mär 18:14:05 CET 2015 : 2098792 354264 /usr/bin/vdr
So 15. Mär 18:24:05 CET 2015 : 2098792 361900 /usr/bin/vdr
So 15. Mär 18:34:05 CET 2015 : 2098792 369704 /usr/bin/vdr
So 15. Mär 18:44:05 CET 2015 : 2098792 377036 /usr/bin/vdr
So 15. Mär 18:54:05 CET 2015 : 2098792 384664 /usr/bin/vdr
So 15. Mär 19:04:05 CET 2015 : 2098792 392592 /usr/bin/vdr
So 15. Mär 19:14:05 CET 2015 : 2098792 399380 /usr/bin/vdr
So 15. Mär 19:24:05 CET 2015 : 2164328 406116 /usr/bin/vdr
So 15. Mär 19:34:05 CET 2015 : 2164328 413548 /usr/bin/vdr
So 15. Mär 19:44:06 CET 2015 : 2164328 420832 /usr/bin/vdr
So 15. Mär 19:54:06 CET 2015 : 2164328 428524 /usr/bin/vdr
So 15. Mär 20:04:06 CET 2015 : 2164328 434912 /usr/bin/vdr
So 15. Mär 20:14:06 CET 2015 : 2164328 442604 /usr/bin/vdr
So 15. Mär 20:24:06 CET 2015 : 2164328 450244 /usr/bin/vdr
So 15. Mär 20:34:06 CET 2015 : 2164328 458560 /usr/bin/vdr
So 15. Mär 20:44:06 CET 2015 : 2164328 466012 /usr/bin/vdr
So 15. Mär 20:54:06 CET 2015 : 2229864 472800 /usr/bin/vdr
So 15. Mär 21:04:06 CET 2015 : 2229864 480276 /usr/bin/vdr
So 15. Mär 21:14:06 CET 2015 : 2229864 487980 /usr/bin/vdr
So 15. Mär 21:24:06 CET 2015 : 2229864 495756 /usr/bin/vdr
So 15. Mär 21:34:06 CET 2015 : 2229864 503064 /usr/bin/vdr
So 15. Mär 21:44:06 CET 2015 : 2229864 510916 /usr/bin/vdr
So 15. Mär 21:54:06 CET 2015 : 2229864 518344 /usr/bin/vdr
So 15. Mär 22:04:06 CET 2015 : 2229864 525616 /usr/bin/vdr
So 15. Mär 22:14:06 CET 2015 : 2295400 533628 /usr/bin/vdr
So 15. Mär 22:24:06 CET 2015 : 2295400 540888 /usr/bin/vdr
So 15. Mär 22:34:06 CET 2015 : 2295400 548908 /usr/bin/vdr
So 15. Mär 22:44:06 CET 2015 : 2295400 556396 /usr/bin/vdr
So 15. Mär 22:54:06 CET 2015 : 2705008 616612 /usr/bin/vdr
So 15. Mär 23:04:06 CET 2015 : 2705008 633332 /usr/bin/vdr
So 15. Mär 23:14:06 CET 2015 : 2705008 642976 /usr/bin/vdr
So 15. Mär 23:24:06 CET 2015 : 2705008 651940 /usr/bin/vdr
So 15. Mär 23:34:06 CET 2015 : 2705008 659996 /usr/bin/vdr
So 15. Mär 23:44:06 CET 2015 : 2770544 667860 /usr/bin/vdr
So 15. Mär 23:54:06 CET 2015 : 2770544 675292 /usr/bin/vdr
Mo 16. Mär 00:04:06 CET 2015 : 2946684 708836 /usr/bin/vdr
Mo 16. Mär 00:14:06 CET 2015 : 2946684 716428 /usr/bin/vdr
Mo 16. Mär 00:24:06 CET 2015 : 2946684 724036 /usr/bin/vdr
Mo 16. Mär 00:34:06 CET 2015 : 2946684 731784 /usr/bin/vdr
Mo 16. Mär 00:44:06 CET 2015 : 2946684 739640 /usr/bin/vdr
Mo 16. Mär 00:54:06 CET 2015 : 2946684 746932 /usr/bin/vdr
Mo 16. Mär 01:04:06 CET 2015 : 2946684 754528 /usr/bin/vdr
Mo 16. Mär 01:14:06 CET 2015 : 3012220 762120 /usr/bin/vdr
Mo 16. Mär 01:24:06 CET 2015 : 3012220 769876 /usr/bin/vdr
Mo 16. Mär 01:34:06 CET 2015 : 3012220 777824 /usr/bin/vdr
Mo 16. Mär 01:44:06 CET 2015 : 3012220 785096 /usr/bin/vdr
Mo 16. Mär 01:54:06 CET 2015 : 3012220 792636 /usr/bin/vdr
Mo 16. Mär 02:04:06 CET 2015 : 2991740 776160 /usr/bin/vdr
Mo 16. Mär 02:14:06 CET 2015 : 2991740 783396 /usr/bin/vdr
Mo 16. Mär 02:24:06 CET 2015 : 2991740 791264 /usr/bin/vdr
Mo 16. Mär 02:34:06 CET 2015 : 3057276 798764 /usr/bin/vdr
Mo 16. Mär 02:44:06 CET 2015 : 3057276 806324 /usr/bin/vdr
Mo 16. Mär 02:54:06 CET 2015 : 3057276 814032 /usr/bin/vdr
Mo 16. Mär 03:04:06 CET 2015 : 3057276 821544 /usr/bin/vdr
Mo 16. Mär 03:14:06 CET 2015 : 3057276 829416 /usr/bin/vdr
Mo 16. Mär 03:24:06 CET 2015 : 3057276 836684 /usr/bin/vdr
Mo 16. Mär 03:34:06 CET 2015 : 3057276 844324 /usr/bin/vdr
Mo 16. Mär 03:44:06 CET 2015 : 3057276 851908 /usr/bin/vdr
Mo 16. Mär 03:54:06 CET 2015 : 3057276 859360 /usr/bin/vdr
Mo 16. Mär 04:04:06 CET 2015 : 3122812 867156 /usr/bin/vdr
Mo 16. Mär 04:14:06 CET 2015 : 3122812 874596 /usr/bin/vdr
Mo 16. Mär 04:24:06 CET 2015 : 3122812 882132 /usr/bin/vdr
Mo 16. Mär 04:34:06 CET 2015 : 3122812 889752 /usr/bin/vdr
Mo 16. Mär 04:44:06 CET 2015 : 3122812 897480 /usr/bin/vdr
Mo 16. Mär 04:54:06 CET 2015 : 3122812 905172 /usr/bin/vdr
Mo 16. Mär 05:04:07 CET 2015 : 3122812 912440 /usr/bin/vdr
Mo 16. Mär 05:14:07 CET 2015 : 3122812 919848 /usr/bin/vdr
Mo 16. Mär 05:24:07 CET 2015 : 3122812 927540 /usr/bin/vdr
Mo 16. Mär 05:34:07 CET 2015 : 3188348 934900 /usr/bin/vdr
Mo 16. Mär 05:44:07 CET 2015 : 3188348 942780 /usr/bin/vdr
Mo 16. Mär 05:54:07 CET 2015 : 3188348 950356 /usr/bin/vdr
Mo 16. Mär 06:04:07 CET 2015 : 3188348 957992 /usr/bin/vdr
Mo 16. Mär 06:14:07 CET 2015 : 3188348 965408 /usr/bin/vdr
Mo 16. Mär 06:24:07 CET 2015 : 3188348 973036 /usr/bin/vdr
Mo 16. Mär 06:34:07 CET 2015 : 3188348 980408 /usr/bin/vdr
Mo 16. Mär 06:44:07 CET 2015 : 3188348 987952 /usr/bin/vdr
Mo 16. Mär 06:54:07 CET 2015 : 3253884 995628 /usr/bin/vdr
Mo 16. Mär 07:04:07 CET 2015 : 3253884 1002976 /usr/bin/vdr
Mo 16. Mär 07:14:07 CET 2015 : 3253884 1010616 /usr/bin/vdr
Mo 16. Mär 07:24:07 CET 2015 : 3253884 1018080 /usr/bin/vdr
Mo 16. Mär 07:34:07 CET 2015 : 3253884 1025552 /usr/bin/vdr
Mo 16. Mär 07:44:07 CET 2015 : 3253884 1033676 /usr/bin/vdr
Mo 16. Mär 07:54:07 CET 2015 : 3253884 1040848 /usr/bin/vdr
Mo 16. Mär 08:04:07 CET 2015 : 3253884 1048360 /usr/bin/vdr
Mo 16. Mär 08:14:07 CET 2015 : 3253884 1055964 /usr/bin/vdr
Mo 16. Mär 08:24:07 CET 2015 : 3319420 1063652 /usr/bin/vdr
Mo 16. Mär 08:34:07 CET 2015 : 3319420 1070820 /usr/bin/vdr
Mo 16. Mär 08:44:07 CET 2015 : 3319420 1078364 /usr/bin/vdr
Mo 16. Mär 08:54:07 CET 2015 : 3319420 1085804 /usr/bin/vdr
Mo 16. Mär 09:04:07 CET 2015 : 3319420 1081564 /usr/bin/vdr
Mo 16. Mär 09:14:07 CET 2015 : 3319420 1089056 /usr/bin/vdr
Mo 16. Mär 09:24:07 CET 2015 : 3319420 1096820 /usr/bin/vdr
--> detach
Mo 16. Mär 09:34:07 CET 2015 : 3281680 1095420 /usr/bin/vdr
Mo 16. Mär 09:44:07 CET 2015 : 3281680 1095436 /usr/bin/vdr
Mo 16. Mär 09:54:07 CET 2015 : 3281680 1095432 /usr/bin/vdr
Mo 16. Mär 10:04:07 CET 2015 : 3281680 1094912 /usr/bin/vdr
Mo 16. Mär 10:14:07 CET 2015 : 3281680 1094716 /usr/bin/vdr
Mo 16. Mär 10:24:07 CET 2015 : 3281680 1094796 /usr/bin/vdr
Mo 16. Mär 10:34:07 CET 2015 : 3281680 1095028 /usr/bin/vdr
Mo 16. Mär 10:44:07 CET 2015 : 3281680 1095052 /usr/bin/vdr
Mo 16. Mär 10:54:07 CET 2015 : 3281680 1095040 /usr/bin/vdr
Mo 16. Mär 11:04:07 CET 2015 : 3281680 1095052 /usr/bin/vdr
Mo 16. Mär 11:14:07 CET 2015 : 3281680 1095164 /usr/bin/vdr
Mo 16. Mär 11:24:07 CET 2015 : 3281680 1095168 /usr/bin/vdr
Mo 16. Mär 11:34:07 CET 2015 : 3281680 1095180 /usr/bin/vdr
Mo 16. Mär 11:44:07 CET 2015 : 3281680 1095156 /usr/bin/vdr
Mo 16. Mär 11:54:07 CET 2015 : 3281680 1095184 /usr/bin/vdr
Gruß,
Space
Kann es Speicherfragmentation sein?
Ich habe nun dummydevice http://phivdr.dyndns.org/vdr/v…vdr-dummydevice-2.0.0.tgz gebaut.
Ich habe die Funktionen die ich normal nicht verwende auskommentiert.
//virtual int PlayTsVideo(const uchar *Data, int Length) {return Length;}
//virtual int PlayTsAudio(const uchar *Data, int Length) {return Length;}
//virtual int PlayTsSubtitle(const uchar *Data, int Length) {return Length;}
//virtual int PlayPes(const uchar *Data, int Length, bool VideoOnly = false) {return Length;}
//virtual int PlayTs(const uchar *Data, int Length, bool VideoOnly = false) {return Length;}
Mmm vdr ist nicht plain, er enthält den mainmenuhooks Patch.
Ich sehe einen leichten Speicheranstieg auf HD = H264.
3581 root 20 0 424468 12288 7252 S 0.0 0.2 0:07.65 vdr
...
3581 root 20 0 498200 12444 7252 S 0.0 0.2 0:11.68 vdr
Nun läuft nicht sehr lang, könnte sich noch einpendeln.
Johns
Ein Anstieg am Anfang ist völlig normal, irgendwann muß das allerdings aufhören.
Bei mir wächst der Speicherbedarf endlos weiter. Fragmentierung kommt als Ursache nicht in Frage, denn auch da ist irgendwann mal Schluß, da alte Blöcke schließlich wiederverwendet werden.
Bisher habe ich nur irrelevante Leaks gefunden, da muß noch irgendwo ein größeres Problem stecken.
Gibt es ein Tool, mit dem man Allokationen in Shared Libraries tracken kann und das vernünftige Symbolinformationen liefert?
CU
Oliver
Nun ein paar Stunden später. Es wächst immer noch. (Edit: wer denkt es ist nun kleiner, es ist nun 6stellig)
valgrind ist gut und macht es. Bei Gentoo kann ich alles mit Debuginformationen bauen.
Dann zeigt valgrind auch alles mit schönen Namen an.
Edit: es müsst mal noch jemand ohne streamdev testen, dann könnten wir dies auch ausschliessen.
Johns
Edit: es müsst mal noch jemand ohne streamdev testen, ...
Hab es hier mal mit TV-Karte und auch mit SatIP getestet und es steigt auch da stetig an.
streamdev habe ich noch nie verwendet. Ich verwendet satip. Dort habe ich ein kleines Leak in Verbindung mit TinyXML gefunden. (Rolf hat es im GIT gefixt.)
Funktioniert denn vdr mit valgrind auf dem Banana Pi noch so, dass vdr noch benutzbar ist?
Ich experimentiere momentan mit gperftools,
CU
Oliver
Die obigen Tests waren aber auf Intel 64 Bit Archetektur.
Wenn man softhddevice nimmt, ist die Ausgabe auch hier mit valgrind Einzelbilder und dadurch vielleicht der Leakcheck verfälscht.
Und ich hoffe mal, ohne Ausgabedevice, daß dann dort die Rechenleistung reicht.
Also im Moment scheint der Fehler doch irgendwo im VDR 2.x.x zuliegen.
Johns
Ich tippe momentan eher auf ffmpeg oder vdpau.
Btw, welche ffmpeg-Version empfiehlst Du?
CU
Oliver
Ich tippe momentan eher auf ffmpeg oder vdpau.
Ich wiederhole: VDR mit mainmenuhooks Patch und nur 2 (ZWEI) Plugins dummydevice und streamdevclient auf Intel 64 Bit Platform zeigt ein stetiges anwachsen des Speichers bei ARD HD. EPG Daten sind im streamdevclient deaktiviert.
Also ffmpeg und VDPAU sind unschuldig, die könnten zwar auch Speicher verlieren, sind aber hier nicht beteiligt.
Btw, welche ffmpeg-Version empfiehlst Du?
1.2.12 oder 2.5.4.
Johns
Intel 64 BIT nun mit plain VDR ohne irgendwelche Patche und plain dummydevice (ohne meine obigen Änderungen).
Und streamdev von 2 Devices auf 1 Device reduziert.
4993 root 20 0 353500 12012 7288 S 0.0 0.1 0:00.04 vdr
4993 root 20 0 352140 11704 7096 S 6.2 0.1 0:03.50 vdr
4993 root 20 0 352140 11704 7096 S 0.0 0.1 0:07.00 vdr
4993 root 20 0 352140 11700 7096 S 0.0 0.1 0:10.34 vdr
4993 root 20 0 352140 11904 7096 S 0.0 0.1 0:13.57 vdr
...
4993 root 20 0 352140 11904 7096 S 0.0 0.1 0:39.50 vdr
Scheint nun konstanten Speicherbedarf zu haben.
Eine der drei Änderungen scheint die Ursache beseitigt zuhaben.
Da TT 6400 geht, ist meine Vermutung es liegt an PlayVideo bzw. den Weg dorthin.
Johns
Mein letzer Test:
5525 root 20 0 352356 12160 7136 S 0.0 0.2 0:00.05 vdr
5525 root 20 0 426204 12148 7136 S 0.0 0.2 0:04.91 vdr
5525 root 20 0 426204 12028 7136 S 0.0 0.1 0:09.43 vdr
5525 root 20 0 426300 12256 7136 S 0.0 0.2 0:13.92 vdr
5525 root 20 0 426300 12324 7136 S 0.0 0.2 0:18.22 vdr
5525 root 20 0 426300 12492 7136 S 0.0 0.2 0:22.96 vdr
5525 root 20 0 426300 12428 7136 S 0.0 0.2 0:27.62 vdr
5525 root 20 0 426300 12244 7136 S 0.0 0.2 0:32.18 vdr
5525 root 20 0 426300 12404 7136 S 0.0 0.2 0:36.85 vdr
5525 root 20 0 426300 12424 7136 S 0.0 0.2 0:41.52 vdr
5525 root 20 0 426300 12308 7136 S 0.0 0.2 0:46.15 vdr
Alles anzeigen
Wie immer Intel 64 BIT und nur zwei Plugins steamdevclient und dummydevice.
//virtual int PlayTsVideo(const uchar *Data, int Length) {return Length;}
//virtual int PlayTsAudio(const uchar *Data, int Length) {return Length;}
//virtual int PlayTsSubtitle(const uchar *Data, int Length) {return Length;}
//virtual int PlayPes(const uchar *Data, int Length, bool VideoOnly = false) {return Length;}
//virtual int PlayTs(const uchar *Data, int Length, bool VideoOnly = false) {return Length;}
Dummydevice abgeändert das diese Funktionen nicht verwendet werden und meiner Meinung nach dann PlayVideo und PlayAudio verwendet werden.
Irgendwo dort liegt eine Ursache.
Ich bin nun erstmal raus,
Johns
Hi. Someone told me this thread has to do with a memory leak. Has there been any progress figuring out the root cause? I've been struggling with a memory leak here as well.
Yes we are searching memory leaks.
One is in the vdr core, when the cDevice plugin function PlayVideo is used.
Johns
Scheint komplizierter:
Wie immer Intel 64 bit, ARD HD, dummydevice patched. plain vdr.
LANG="de_DE.UTF-8" valgrind --log-file=val.log --track-origins=yes /usr/bin/vdr -l 3 -u root -Pdummydevice -Pstreamdev-client
==2264== HEAP SUMMARY:
==2264== in use at exit: 279,322 bytes in 2,429 blocks
==2264== total heap usage: 95,181 allocs, 92,752 frees, 712,536,872 bytes allocated
==2264==
==2264== LEAK SUMMARY:
==2264== definitely lost: 0 bytes in 0 blocks
==2264== indirectly lost: 0 bytes in 0 blocks
==2264== possibly lost: 0 bytes in 0 blocks
==2264== still reachable: 279,322 bytes in 2,429 blocks
==2264== suppressed: 0 bytes in 0 blocks
==2264== Rerun with --leak-check=full to see details of leaked memory
Alles anzeigen
Irgendein Puffer oder Liste wird immer größer.
Johns
Hi fellas. Was wondering if there was any progress tracking down this memory leak?
Thanks!
Nachdem ich doch 10s in die Source geguckt habe.
remux.c
if (length + Length > size) {
int NewSize = max(KILOBYTE(2), length + Length);
if (uchar *NewData = (uchar *)realloc(data, NewSize)) {
data = NewData;
size = NewSize;
}
else {
esyslog("ERROR: out of memory");
Reset();
return;
}
}
Alles anzeigen
Der obige realloc ist schuld.
Nach 1 Stunde am laufen.
realloc(424477)
realloc(12880)
realloc(13064)
realloc(13248)
realloc(13432)
realloc(13616)
realloc(13800)
realloc(13804)
realloc(13968)
realloc(13984)
realloc(14168)
realloc(14352)
realloc(14426)
realloc(424560)
Alles anzeigen
Intressant ist der Spung auf klein und dann wieder groß. Dies wiederholt sich monoton wachsend.
Johns
Hilf mir mal: was ist daran falsch?
Sind die geloggten realloc-Aufrufe alle vom gleichen Objekt oder sind das verschiedene?
Lars.
Deinen printf zeigst du ja nicht. Ich vermute, dass du da NewSize protokollierst?
Kannst du da noch "this" als %p davor ausgeben, damit man sieht, ob es unterschiedliche Objekte sind?
Dort werden ja die TS-Pakete gesammelt, bis ein PES-Paket vollständig ist. Ich würde dann eher einen Fehler in GetPes vermuten, dass da vielleicht einige Längen, Offsets o.ä. nicht richtig zurückgesetzt werden. Vermutest du auch was in die Richtung?
Lars.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!