Segfault mit vdpau beseitigen

    Nabend zusammen,


    hin und wieder habe ich einen segfault beim Umschalten von HD-Sendern auf ARD oder ZDF und nur da.


    Ich denke ich brauche nicht Erwähnen, dass der VDR dann immer ganz abstürzt und damit auch laufende Aufnahmen weg sind.


    Da ich jetzt schon etliche Nvidia-Treiber und auch vdpau-Versionen durch habe und eigentlich immer die selben Stellen im backtrace auftauchen, stelle ich das hier jetzt mal in einen Thread, in der Hoffnung das jemand mir beim Lösen helfen kann.


    Hier mal die einzelnen Meldungen:


    1. dmesg auf der Konsolse:


    Code
    Local decoder/d[13437]: segfault at a59b000 ip b7c4d18f sp adbf4f30 error 4 in libc-2.9.so[b7bd9000+13c000]


    2. Das Ende der Ausgabe gdb/bt:




    System ist das Intel-System aus meiner Signatur, Nvidia-Treiber 185.18.14 - egal auch der 180.51 hat den segfault, xine-vdpau-r271 mit durchflieger-patch v6.


    In der Hoffnung das mir da jetzt ein fähiger Coder helfen kann, kann ich auch die entsprechenden Codepassagen oder Files zur Verfügung stellen.
    Wenn man mehr Infos benötigt, kein Problem.


    Im Anhang mal die oben betroffenen Files video_out.c und video_out_vdpau.c.


    Gruß
    Wolfgang

    Zitat

    Original von wbreu
    hin und wieder habe ich einen segfault beim Umschalten von HD-Sendern auf ARD oder ZDF und nur da.


    Ich denke ich brauche nicht Erwähnen, dass der VDR dann immer ganz abstürzt und damit auch laufende Aufnahmen weg sind.


    Wie ist dein Xineliboutput konfiguriert? Startest Du ein localfrontend oder läuft die Ausgabe per remote Fronend (vdr-sxfe)?


    Letzteres ist nämlich meiner Meinung nach die bessere Wahl. Unabhängig von VDPAU hatte ich mit dem Xineliboutput zeugs auch immer mal Abstürze des Frontends. Wenn man xinelibpoutput mit loca lfrontend laufen lässt, tötest dann auch gleich den VDR. Setzt man sich aber mit nem Remotefrontend auf den VDR, stürtzt dann nur das Frontend ab, aber der VDR läuft weiter, weil das Frontend ja in nem eigenen Thread läuft. Ich hatte seinerzeit dann einfach ein kleines Shellscript gebastet das das Frontend gleich wieder startet wenn es abgestürzt ist. Ist nur ein Workarround, aber bei der Stabilität von Xinelib und Kohorten wohl angebracht. ;)

    Zitat

    Original von Ioannis


    Wie ist dein Xineliboutput konfiguriert? Startest Du ein localfrontend oder läuft die Ausgabe per remote Fronend (vdr-sxfe)?


    Letzteres ist nämlich meiner Meinung nach die bessere Wahl. Unabhängig von VDPAU hatte ich mit dem Xineliboutput zeugs auch immer mal Abstürze des Frontends. Wenn man xinelibpoutput mit loca lfrontend laufen lässt, tötest dann auch gleich den VDR. Setzt man sich aber mit nem Remotefrontend auf den VDR, stürtzt dann nur das Frontend ab, aber der VDR läuft weiter, weil das Frontend ja in nem eigenen Thread läuft. Ich hatte seinerzeit dann einfach ein kleines Shellscript gebastet das das Frontend gleich wieder startet wenn es abgestürzt ist. Ist nur ein Workarround, aber bei der Stabilität von Xinelib und Kohorten wohl angebracht. ;)


    Moin Ioannis,


    jepp lokalfrontend.


    Mir gehts auch nicht um alternative Startformen, die sind mir bekannt, btw. hat der VDR einen watchdog, sondern vielmehr darum, dass der lästige Segfault endlich beseitigt wird.


    Merci trotzdem für die Antwort.


    Gruß
    Wolfgang

    Hallo,


    Zitat

    Original von Ioannis
    Ich hatte seinerzeit dann einfach ein kleines Shellscript gebastet das das Frontend gleich wieder startet wenn es abgestürzt ist.


    Könntest Du das ggf. zu Verfügung stellen, falls Du es noch hast? Ich habe mir auch so ein Skript gebaut (siehe Beitrag hier), aber evtl. kann ich ja noch etwas verbessern/vereinfachen mit Hilfe Deines Skriptes...


    Danke & Gruss
    Marcus

    My VDRs:

    Zitat

    Original von wbreu
    Mir gehts auch nicht um alternative Startformen, die sind mir bekannt, btw. hat der VDR einen watchdog, sondern vielmehr darum, dass der lästige Segfault endlich beseitigt wird.


    Yo, trotzdem bin ich der Meinung das es besser ist vdr-sxfe (auch wenns auf dem gleichen Rechner) läuft, als Remoteclient zu verwenden und nicht als localfrontend direkt innerhalb des VDR Prozesses laufen zu lassen. Der vdr watchdog, wie auch eine Exception in einem local laufenden xineliboutput, sind nun mal Gift für fehlerfrei Aufnahmen.


    Das Du der eigentlichen Exception auf den Grund gehen willst ist sehr löblich, aber aus Erfahrung kann ich wohl sagen das die bestimmt nicht der letzte Fehler im xineliboutput bzw. vdrpau sein wird. Und wenn man Wert darauf legt nicht bei jeder kleinen Exception des Frontends seine laufenden Aufnahmen zu ruinieren, ist das halt für nen produktiv eingesetzen VDR empfehlenswerter. Denn Callstack wirst Du auch mit nem remote Frontend haben und kannst denn immer noch debuggen, der Unterschied wird nur sein das deine Aufnahmen nicht bei jedem Absturz gleich nen Aussetzer haben.


    Das wird schwierig, habe ich alles seinerzeit gefrustet weggehauen weil Xinelib&Deinterlacing auf meiner Kiste nicht wirklich zufriedenstellen liefen, von der Stabilität des ganzen und gelegentlich grünen Streifen im Bild ganz zu schweigen.... Hab das ganze dann mit ne reel eHD gelöst und bin seitdem soweit Glücklich. ;)


    Als Basis dafür hatte ich aber auch nur die Scripte aus der Zendeb Distribution von Egalus verwendet (für die SMT 7020s), kannst da ja mal reinschauen.

    Hallo Wolfgang,


    keine Chance. Zwar ist klar, dass eine der Adressen, mit der memcpy aufgerufen wird, ins Nirwana zeigt, aber der Aufruf ist im Nivida-Treiber. Dafür habe ich noch keine Quellen gesehen. Der Funktions-Aufruf in Zeile 1410 in video_out_vdpau.c hilft nicht weiter. Das ist ein Fall für einen BUG-Report an Nvidia.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

    Zitat

    Original von gda
    Hallo Wolfgang,


    keine Chance. Zwar ist klar, dass eine der Adressen, mit der memcpy aufgerufen wird, ins Nirwana zeigt, aber der Aufruf ist im Nivida-Treiber. Dafür habe ich noch keine Quellen gesehen. Der Funktions-Aufruf in Zeile 1410 in video_out_vdpau.c hilft nicht weiter. Das ist ein Fall für einen BUG-Report an Nvidia.


    Gerald


    Hallo Gerald,


    danke dir fürs drüberschauen, dann werde ich da mal einen Bug-Report einstellen.


    Gruß
    Wolfgang


    Und schon gibts einen bugfix in xine-vdpau, r272 ist draussen.


    Und was soll ich sagen, der fix behebt das Problem insoweit, dass bisher selbst bei wildester Zapperei von HD auf SD und zurück kein segfault mehr autritt.


    Gruß
    Wolfgang

    Sry, bin mal wieder zu blöd r272 zu finden...


    http://www.jusst.de/vdpau/file…b-1.2-vdpau-r272.diff.bz2 fehlt irgendwie.

    VDR1.7.12 + ExtPatch on openSuSE 11.1 2.6.27.45-0.1-default (x86_64) gcc 4.3.2 r141291
    1xNexus (fw:f12623) ** 3xTeVii S650 ** Alphacrypt/SKY ** DVB-Treiber 7.6.09cvs ** 7" GraphTFT ** VOMP on MediaMVP ** zendeb 0.4.0.b1 on S100 ** 4ch Atmolight
    Xine-lib-1.2 20100412(vdpau) +DFextPatch ** XINE-UI ** Nvidia GT240 (260.19.36) ** Samsung LE46C650 ** istreamdev-git_20110216 to IPhone

    Hallo,


    Also ich bekomme die 273 einfach nicht zu laufen.


    Jun 23 02:51:49 vdr1.naw vdr: [32139] vdr-fritzbox - CallList.cpp: parser skipped line in calllist
    Jun 23 02:51:49 vdr1.naw vdr: [32139] vdr-fritzbox - CallList.cpp: parser skipped line in calllist
    Jun 23 02:51:49 vdr1.naw vdr: [32139] vdr-fritzbox - CallList.cpp: parser skipped line in calllist
    Jun 23 02:51:49 vdr1.naw vdr: [32139] vdr-fritzbox - CallList.cpp: CallList -> read 100 entries.
    Jun 23 02:51:49 vdr1.naw vdr: [32139] vdr-fritzbox - PThread++.cpp: CallList: thread ended (pid=32114, tid=32139)
    Jun 23 02:51:49 vdr1.naw vdr: [32144] buffer usage: 70% (tid=32145)
    Jun 23 02:51:49 vdr1.naw vdr: [32144] buffer usage: 80% (tid=32145)
    Jun 23 02:51:49 vdr1.naw vdr: [32144] buffer usage: 90% (tid=32145)
    Jun 23 02:51:50 vdr1.naw vdr: [32145] ERROR: TS packet not accepted in Transfer Mode
    Jun 23 02:51:50 vdr1.naw vdr: [32144] buffer usage: 100% (tid=32145)
    Jun 23 02:51:50 vdr1.naw vdr: [32147] EnigmaNG effects thread ended (pid=32114, tid=32147)
    Jun 23 02:51:51 vdr1.naw vdr: [32114] max. latency time 1 seconds
    Jun 23 02:51:52 vdr1.naw vdr: [32145] ERROR: TS packet not accepted in Transfer Mode
    Jun 23 02:51:54 vdr1.naw vdr: [32145] ERROR: TS packet not accepted in Transfer Mode
    Jun 23 02:51:56 vdr1.naw vdr: [32145] ERROR: TS packet not accepted in Transfer Mode
    Jun 23 02:51:58 vdr1.naw vdr: [32145] ERROR: TS packet not accepted in Transfer Mode
    Jun 23 02:52:00 vdr1.naw vdr: [32145] ERROR: TS packet not accepted in Transfer Mode
    Jun 23 02:52:02 vdr1.naw vdr: [32145] ERROR: TS packet not accepted in Transfer Mode
    Jun 23 02:52:03 vdr1.naw vdr: [32136] EPGSearch: timer conflict check started
    Jun 23 02:52:03 vdr1.naw vdr: [32136] EPGSearch: timer conflict check finished
    Jun 23 02:52:04 vdr1.naw vdr: [32145] ERROR: TS packet not accepted in Transfer Mode
    Jun 23 02:52:06 vdr1.naw vdr: [32145] ERROR: TS packet not accepted in Transfer Mode
    Jun 23 02:52:06 vdr1.naw vdr: [32135] Streamdev: Connected to server 192.168.1.2:2004 using capabilities TSPIDS,FILTERS
    Jun 23 02:52:06 vdr1.naw vdr: [32135] Streamdev: Filter 3100, 2, 255 not available from 192.168.1.21:44864
    Jun 23 02:52:07 vdr1.naw vdr: [32143] cStreamdevFilters::Action(): stream disconnected ?
    Jun 23 02:52:07 vdr1.naw vdr: [32142] ERROR (device.c,1873): Ungültiger Dateideskriptor
    Jun 23 02:52:07 vdr1.naw vdr: [32142] TS buffer on device 1 thread ended (pid=32114, tid=32142)
    Jun 23 02:52:07 vdr1.naw vdr: [32143] buffer stats: 44744 (4%) used
    Jun 23 02:52:07 vdr1.naw vdr: [32143] StreamdevFilters::Action() ended
    Jun 23 02:52:07 vdr1.naw vdr: [32143] streamdev-client: sections assembler thread ended (pid=32114, tid=32143)
    Jun 23 02:52:08 vdr1.naw vdr: [32145] ERROR: TS packet not accepted in Transfer Mode




    Gar kein Bild mehr, nur noch massenhaft Fehlermeldungen.
    Mit 261 geht es bei mir noch gut, bis auf die segfaults.


    Wie kann man eigentlich via svn beispielsweise die 272 beziehen?


    Peter

    VDR1: ASUS N100I-D D4 + IP TV Plugin + Flirc + softhddevice-git VAAPI + vdr-2.6.5 + 3 weitere Plugins + Debian Bookworm via M2 + Kernel 6.1.0


    VDR2: ASUS AT3IONT-I + PCTV USB Stick 461e + Nvidia 340.108 + Flirc + softhddevice-git + vdr-2.6.4 + 8 weitere Plugins + Samsung U70 + Debian Bullseye via SSD + Kernel 6.3.6 + LG 55 Zoll

    2 Mal editiert, zuletzt von pixelpeter ()


    pixelpeter


    das kommt mir igendwie bekannt vor.


    hast du das bzw. das und ff schon getestet?


    Gruß, tomas

    Hallo Tomas,


    Hebe xine mit der Kompileroption übersetzt, leider ist das Problem immer noch vorhanden. Die Pufferüberläufe sind zwar nicht mehr da, dafür aber diese Meldung:



    Jun 23 02:51:50 vdr1.naw vdr: [32145] ERROR: TS packet not accepted in Transfer Mode



    Scheint, als würde es hier auch noch Probleme mit streamdev geben.




    Peter

    VDR1: ASUS N100I-D D4 + IP TV Plugin + Flirc + softhddevice-git VAAPI + vdr-2.6.5 + 3 weitere Plugins + Debian Bookworm via M2 + Kernel 6.1.0


    VDR2: ASUS AT3IONT-I + PCTV USB Stick 461e + Nvidia 340.108 + Flirc + softhddevice-git + vdr-2.6.4 + 8 weitere Plugins + Samsung U70 + Debian Bullseye via SSD + Kernel 6.3.6 + LG 55 Zoll

    Hallo Peter,


    du hast außer xine-vdpau nichts verändert bzw. wenn du auf xine-vdpau r261 zurückgehst bekommst du die Fehlermeldung


    Zitat

    ERROR: TS packet not accepted in Transfer Mode


    nicht???


    edit: deine Signatur stimmt so?


    Gruß, tomas

    Hallo Tomas,


    261 keine Probleme, 273 obige Fehlermeldung. Weiter nichts verändert.



    Peter

    VDR1: ASUS N100I-D D4 + IP TV Plugin + Flirc + softhddevice-git VAAPI + vdr-2.6.5 + 3 weitere Plugins + Debian Bookworm via M2 + Kernel 6.1.0


    VDR2: ASUS AT3IONT-I + PCTV USB Stick 461e + Nvidia 340.108 + Flirc + softhddevice-git + vdr-2.6.4 + 8 weitere Plugins + Samsung U70 + Debian Bullseye via SSD + Kernel 6.3.6 + LG 55 Zoll

    Jo, das Problem kann ich bestätigen.


    Da ich unter openSuSE nicht auch noch unbedingt die libX11 austauschen will ( oder mich eher nicht traue ), muss ich mit dem LOCK auch unter r273 arbeiten.


    ( wenn ich den LOCK wieder rausnehme, stürzt xine bei Kanalwechsel auch bei sd-sd ab. )


    1FestivalHD als Referenz:
    * Bild bleibt stabil
    * Ton setzt ständig aus
    * bei Aufnahme steigt er ab und an aus und beendet die wiedergabe.


    nach einiger Zeit fabgen die : buffer usage meldungen an.


    Hat einer nen Tip für mich? ( PS: xine-lib1.2+vdpau r273 ), ausgabe über xine ( bob ).
    ( Will net stressen, aber mir gehen so langsam die Suchbegriffe aus, evtl hat ja jemand ne lösung ).

    VDR1.7.12 + ExtPatch on openSuSE 11.1 2.6.27.45-0.1-default (x86_64) gcc 4.3.2 r141291
    1xNexus (fw:f12623) ** 3xTeVii S650 ** Alphacrypt/SKY ** DVB-Treiber 7.6.09cvs ** 7" GraphTFT ** VOMP on MediaMVP ** zendeb 0.4.0.b1 on S100 ** 4ch Atmolight
    Xine-lib-1.2 20100412(vdpau) +DFextPatch ** XINE-UI ** Nvidia GT240 (260.19.36) ** Samsung LE46C650 ** istreamdev-git_20110216 to IPhone

    Einmal editiert, zuletzt von DrBoon ()

    Hallo,


    Zitat

    Original von DrBoon


    Da ich unter openSuSE nicht auch noch unbedingt die libX11 austauschen will



    Das musst du auch nicht. Als Alternative bietet dir xine-vdpau ab r263 ja das Aktivieren von *LOCKDISPLAY* an.


    Bis r262 war XLockDisplay/XUnlockDisplay fest in xine-vdpau integriert, ab r263 ist es jetzt optional zu aktivieren, wenn es Probleme mit der jeweils verwendeten libX11/libxcb-Version gibt.


    Ob deine und Peters Probleme überhaupt bzw. nur von dem ab r263 verändertem Handling von XLockDisplay/XUnlockDisplay verursacht werden, muss ja noch geklärt werden. Bei pixelpeter wird mit *LOCKDISPLAY* zumindest das Vollaufen des Buffers beseitigt.


    Beim Versuch mich über die Hintergründe von *LOCKDISPLAY* etwas schlau zu machen (bin ja eigentlich absoluter Laie), bin ich jetzt bei nvnews.net auf einen Thread vom Januar mit dem Titel VDPAU: multithreading issues gestoßen. Darin wird die Problematik auch in Beziehung zur verwendeten libX11/libxcb-Version behandelt. Siehe Posting von Stepen Warren



    btw: da das Ursprungsproblem dieses Threads gelöst ist, wäre es da nicht auch im Hinblick auf die Übersichtlichkeit sinnvoll einen neuen Thread aufzumachen? Ich denke, dass inzwischen auch der Hauptthread mit seinen 51 Seiten zumindest für Neueuinsteiger nicht unbedingt einladend ist.


    Ich hatte mir bei meinem Problem letzte Woche auch zuerst überlegt einen neuen Thread aufzumachen, war mir aber unsicher.......... :schiel



    Gruß, tomas

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden