[0.2] plötzlich komische segfaults hsetroot

Das hsetroot segfault hab ich bei mir auch schon in den logs gesehen, allerdings kann ich nix weiter beitragen, da mein System noch überhaupt kein HDTVBild zeigt, was aber ein anderes Thema ist.

ist schon gefixt !
gibtz aber leider noch kein paketupdate ....
kommt noch !!

Versuche mal folgendes in Section "Screen" für screen0

Option "ConnectedMonitor" "CRT-0, DFP-1"
Option "UseDisplayDevice" "CRT-0, DFP-1"

eintragen. Die Werte musst du natürlich anpassen.

v_r

Aber das sollte nicht die Aufnahme verhindern. VDR startet unabhängig vom X11.

Aber ein Versuch ist es wert. Wenn es geht, dann übernehmen wir das.

v_r

Ich hatte das Problem heute Nacht auch. ca 6 min lang sekündlich die segfaults, danach hing die Kiste komplett. Die Aufnahme hatte angefangen, aber ist nach gut einer Minute abgebrochen.

Es könnte tatsächlich das erste mal gewesen sein, dass der TV komplett ausgeschaltet war (also nicht nur im standby).

hotzenplotz5
Das Update müsste also schon seit langer Zeit "drin" sein? Ich hatte vor ein paar Wochen noch ein Update gemacht. Worin besteht die Änderung?

@v_r (oder jeder der es weiss)
Wo muss man diese Einträge machen? In /etc/X11/xorg.conf.yavdr? (bzw. per Templating..)

Im Moment ist leider dauernd was anderes, warum die Aufnahmen nicht funktionieren. Ein VDR, der nicht absolut zuverlässig aufnimmt, ist kein VDR. Bin gespannt wann ich hier endlich einen habe.

Nachtrag: wenn ich obige Options-Einträge in der xorg.conf mache, sind zwar die segfaults ohne TV weg (vorausgesetzt das ist immer reproduzierbar) - aber ich habe kein Bild mehr! Im X-log sagt er mir so in etwa, dass er nur CRT-0 verwendet..

Also was bedeuten diese Options genau, und könnten sie bei mir anders aussehen müssen?

Darf ich das nochmal nach oben pushen..

Wie ist denn nun hier die Situation? Das Problem besteht offensichtlich unverändert.

Wenn ich das CRT-0 bei den Options weglasse und nur DFP-1 (=HDMI, DFP-0 wäre DVI) setze, sind die Segfaults bei fehlendem TV genauso da wie ganz ohne Options. Die Theorie ist wohl also, dem X-Server mit den Options ein Gerät am VGA-Ausgang vorzugaukeln, für das er kein EDID braucht? Leider führt das bei mir wie gesagt dazu, dass auch bei laufendem TV dann HDMI gar nicht angesprochen wird..

Einzige Lösung im Moment ist also, den TV immer im Standby zu lassen, wenn man eine nächtliche Aufnahme geplant hat..

Komische Sache ist das. Ich hatte bisher keine Problem dieser Art, wobei ich die die o.g. Einträge in der schon lange drin habe.

Heute sehe ich im Log über ca. 45 Minuten massenhaft:

Sep 8 19:23:04 ubuntu kernel: [ 2864.020937] vdr[11415]: segfault at 448bcc ip 081304c2 sp bfb7b0d0 error 4 in vdr[8048000+1

Die geplante Aufnahme hat nur eine 0-Byte Datei erzeugt.

Nachdem ich den VDR manuell gestoppt und wieder gestartet habe, waren die Fehlermeldungen weg.

rkp

Deine segfaults sind aber nicht von hsetroot, sondern von vdr selbst (laut Log-Ausgabe). Mit nicht angeschaltetem TV beim VDR-Start hat es also vermutlich auch nichts zu tun? Das ist aber hier recht konkret das Problem, und die offene Frage ist, ob das von hotzenplotz5 angekündigte "Paket-Update" denn nun "drin" ist oder nicht? Und bei mir, wieso die Vorab-Lösung mit den Options nicht hilft bzw. (gegen die segfaults hilfts ja tatsächlich) dann kein Bild gibt.

Klar, auch Dein Fehler wäre interessant zu klären, scheint mir aber mit dem Thread hier nichts zu tun zu haben. Segfaults generell können ja immer und überall mal auftreten, ohne Reproduzierbarkeit dürfte es schwierig werden der Sache nachzugehen. Ausser jemand kann tatsächlich was mit den Werten aus der Log-Zeile anfangen.

Hast Recht, habe ich leider übersehen. Sorry.

Es wäre schön wenn ihr lernen würdet wie man solche Daten auch mal selbst interpretiert. Sicherlich ist solch eine Zeile ohne einen Debugger wenig hilfreich, aber manchmal hilft es, wenn man weiß was der Thread/Prozess denn getan hat, als es ihm noch gut ging. Häufig ist man dem wirklichen Problem dann deutlich näher.

Zitat

Original von rkp
Sep 8 19:23:04 ubuntu kernel: [ 2864.020937] vdr[11415]: segfault at 448bcc ip 081304c2 sp bfb7b0d0 error 4 in vdr[8048000+1

Hier sind die beiden Zahlen in den eckigen Klammern interessant. Die erste Zahl ist der Zeitpunkt an dem es passierte. Die zweite Zahl ist die Prozess-ID des Threads/Prozesses. Wenn man jetzt die Prozess-ID im Syslog zurückverfolgt, dann kann man erkennen was der Prozess gemacht hat, als es ihm noch gut ging und was kurz vor dem Absturz passierte. Daran kann man oft erkennen ob es ein Thread ist, der zu einem VDR-Plugin, oder sonst irgendwas anderem gehört. Erst gestern haben wir so herausfinden können, dass ein Segfault durch eepg ausgelöst wurde. Das heißt aber nicht, dass eepg auch hier das Problem ist!

Andersherum bedeutet das, eine solche Zeile allein gepostet ist absolut wertlos. Damit wird nur die Zeit der Helfer hier im Portal verschwendet. Wer das hier liest und nun meint er müsste jedes mal das ganze Syslog posten, den halte ich für stinkend faul, weil er jetzt das Wissen hat die entscheidenden Zeilen heraus zu finden. Die Argumentation, man sei kein Programmierer, zieht nicht, weil hierfür keine Programmierkenntnisse erforderlich sind, logisches Denken reicht schon.

Gerald