[solved] xineliboutput: kernel segfault beim start via init

ciax · 23. Juli 2008

hallo,

wie in einem anderen thread schon kurz angedeutet, gibt's hier leider noch immer ein (gröberes) problem (--> kernel segfault), die vdr-box inklusive xineliboutput automatisiert zu starten.

folgende ausgangslage:

versionen:
-------------
* xineliboutput aus dem cvs (2 verschiedene stände getestet: 2008-07-02 & 2008-07-20)
* xine-lib aus dem HG (2 verschiedene stände getestet: 2008-06-17 & 2008-07-20)
* kernel: 2.6.25.5
* system: ubuntu / x86_64 GNU/Linux
-------------

A) ein manueller start der komponeten (vdr + graphtft-fe + sxfe/vdr-sxfe) aus der konsole funktioniert:

1) vdr-sxfe als "remote frontend" und eigener prozess (vdr läuft bereits):

Code

xinit -e /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/src/graphtft/graphtft-fe/graphtft-fe -h localhost -e 2 -n -W 640 -H 480 -f -r &  /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/src/xineliboutput/vdr-sxfe --reconnect --display=:0.1 --aspect=auto --fullscreen --post tvtime:method=Linear,cheap_mode=1,pulldown=0,use_progressive_frame_flag=1 xvdr+tcp://localhost

2) sxfe als "local frontend" (vdr setup.conf: xineliboutput.Frontend = sxfe) und separater vdr-thread (vdr läuft noch nicht)

Code

xinit -e /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/src/graphtft/graphtft-fe/graphtft-fe -h localhost -e 2 -n -W 640 -H 480 -f -r

danach wird vdr gestartet - es erscheint sauber ein bild am fernseher.

B) automatisiert über init: die box fährt immer in runlevel 2. unter /etc/rc2.d/ befinden sich links zu den start-scripten:

1) remote frontend (vdr-sxfe)

Code

S21runvdr -> ../init.d/runvdr
S99vdr_xinit -> ../init.d/vdr_xinit

vdr_xinit enthält folgendes:

Code

#! /bin/sh
#
# init.d script to start xinit with graphTFT and vdr-sxfe
#
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin


/usr/bin/xinit -e /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/src/graphtft/graphtft-fe/graphtft-fe -h localhost -e 2 -n -W 640 -H 480 -f -r & /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/src/xineliboutput/vdr-sxfe --reconnect --display=:0.1 --fullscreen xvdr+tcp://localhost


exit 0

Alles anzeigen

ergebnis ist im syslog ein:

Code

Jul 21 08:39:20 localhost kernel: [  447.105564] vdr-sxfe[6041]: segfault at 0 ip 7f5e5e518277 sp 7fff676a5e50 error 4 in libxine.so.2.0.0[7f5e5e4da000+53000]

-->

2) "local"-frontent (xineliboutput.Frontend = sxfe)

es wird udo's "runvdr-extrem" verwendet und xinliboutput nur mit dem parameter "--primary" dem vdr übergeben (sparkie erwähnte einmal, daß er das auch so macht und erst über vdr setup.conf - xineliboutput.Frontend = sxfe - mitteilt, daß das locale-fe genutzt wird. somit sollte es egal sein, ob X schon läuft oder nicht?)

vdr_xinit enthält folgendes:

Code

#! /bin/sh
#
# init.d script to start xinit with graphTFT and vdr-sxfe
#
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin


/usr/bin/xinit -e /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/src/graphtft/graphtft-fe/graphtft-fe -h localhost -e 2 -n -W 640 -H 480 -f -r


exit 0

Alles anzeigen

es wurden unter /etc/rc2.d/ auch die reihenfolge des startvorgangs geändert - sprich "runvdr" erst nach "vdr_xinit" - zB so:

Code

S55vdr_xinit -> ../init.d/vdr_xinit
S92runvdr -> ../init.d/runvdr

ergebnis ist im syslog ein:

Code

Jul 23 07:42:18 localhost kernel: [   58.654803] Local decoder/d[7301]: segfault at 0 ip 7f525a816277 sp 453d2fa0 error 4 in libxine.so.2.0.0[7f525a7d8000+53000]

-->

ich bin mit init-scripten und runlevels nicht zu gut vertraut, aber zu faslch erscheint mir der ansatz nun auch nicht. ich bin mir genauso nicht sicher, ob das phänomen wert ist, in der entsprechenden mailing-list bzgl xineliboutput nachzufragen (ist doch eher spezifisch).

.. steh jetzt wirklich einfach an und würd' mich über einen kleinen tipp bzw. workaround sehr freuen. wenn sich jemand findet?

gruß, ciax

netvista-fan · 23. Juli 2008

Hmm, alles sehr neu...
kann nur sagen mit kernel 2.6.23.x und den "standard" e-tobi / etch paketen machts keine Probleme.

ciax · 23. Juli 2008

ja eben, ich steh an .. würde das ganze schon gern "flexibel" aus den sourcen betreiben ... verflixt ist vorallem, daß es ja manuell einwandfrei läuft - eben atomatisiert nicht ???? sehr schräg!

knebb · 23. Juli 2008

Du muesstest doch waehrend des Hochfahrens sehen, welches Skript gerade ausgefuehrt wird, oder?
Dann mach einfach mal ein echo "Ich bin jetzt dran", dann weisst Du auf jeden Fall mal, dass es in der richtigen Reihenfolge ausgefuehrt wird.

Weiterhin schreibst Du, dass die Kiste in runlevel2 laeuft. Ist das Ubuntu spezifisch? Normalerweise ist Runlevel 2 ohne Netzwerk. Siehe dazu die /etc/inittab:

Code

# Default runlevel. The runlevels used by RHS are:
#   0 - halt (Do NOT set initdefault to this)
#   1 - Single user mode
#   2 - Multiuser, without NFS (The same as 3, if you do not have networking)
#   3 - Full multiuser mode
#   4 - unused
#   5 - X11
#   6 - reboot (Do NOT set initdefault to this)
#
id:3:initdefault:

Wie sieht Deine aus?

Drittens wuerde ich mal die PATH Variable nicht setzen, bzw. neue Suchpfade am Ende anfuegen

Code

PATH=$PATH:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

Aber nur so ein paar Ideen, so richtig ein Vorstellung warum das nicht klappt, habe ich auch nicht.

Vielleicht liegt's ja auch am User?
Wenn Du es manuell startest, bist Du dann root?

netvista-fan · 23. Juli 2008

Wenn es manuall geht, dann guck mal hier rein:
http://vdr-portal.de/board/thread.php?threadid=75897

Etwas abwandeln, einen 2ten x-server neben dem "ubuntu gnome" starten und diesen dann nur für ein über ein script gestartetes vdr-sxfe nutzen.
Sollte mit Ubuntu ja der Debian Variante ziemlich ähnlich sein.

ciax · 23. Juli 2008

netvista-fan: danke, den thread kannte ich schon - hilft mir diesbzgl. leider nicht weiter ..

knebb:

Zitat

Weiterhin schreibst Du, dass die Kiste in runlevel2 laeuft. Ist das Ubuntu spezifisch? Normalerweise ist Runlevel 2 ohne Netzwerk

du hast natürlich recht. das ist wieder sowas ubuntu-spezifisches (aber auch debian).

http://en.wikipedia.org/wiki/Runlevel --> link

Zitat

Debian Linux

Debian, as well as most of the distributions based on it, like Ubuntu, does not make any distinction between runlevels 2 to 5. See also the Debian FAQ on booting.

* 0 - Halt
* 1 - Single
* 2 - Full multi-user with display manager (GUI)
* 3 - Full multi-user with display manager (GUI)
* 4 - Full multi-user with display manager (GUI)
* 5 - Full multi-user with display manager (GUI)
* 6 - Reboot

Alles anzeigen

wenn ich runlevel eintippe steht "N 2" -- kann also - lt. man - keinen vorherigen runlevel aus /var/run/utmp auslesen ( --> N) und befindet sich im level 2. netzwerk ist aber up. ubuntu treibt das lt. recherche anders - inittab entspricht /etc/event.d/rc-default

Code

# rc - runlevel compatibility
#
# This task guesses what the "default runlevel" should be and starts the
# appropriate script.


start on stopped rcS


script
        runlevel --reboot || true


        if grep -q -w -- "-s\|single\|S" /proc/cmdline; then
            telinit S
        elif [ -r /etc/inittab ]; then
            RL="$(sed -n -e "/^id:[0-9]*:initdefault:/{s/^id://;s/:.*//;p}" /etc/inittab || true)"
            if [ -n "$RL" ]; then
                telinit $RL
            else
                telinit 2
            fi
        else
            telinit 2
        fi
end script

Alles anzeigen

ziemlich unübersichtlich (für mich) - die inittab sieht nichtssagend aus:

Code

#-- runit begin
SV:123456:respawn:/usr/sbin/runsvdir-start
#-- runit end

Zitat

Vielleicht liegt's ja auch am User?
Wenn Du es manuell startest, bist Du dann root?

bei meinen tests (manuell) war ich immer root - betreibe die ganze kiste nur via root (bitte nicht schimpfen )

werde das ganze nochmal mit deinen anregungen testen (frohen mutes, daß es dann funktioniert, bin ich aber leider nicht) -

gruß, ciax

gda · 23. Juli 2008

wenn du den vdr_xinit Skript in einer virtuellen Konsole startest geht es auch?

ciax · 23. Juli 2008

Zitat

Originally posted by gda
wenn du den vdr_xinit Skript in einer virtuellen Konsole startest geht es auch?

wenn ich boote, startet der xserver und graphtft-fe öffnet sein fenster und probiert sich, zum vdr-graphtft plugin zu verbinden. da passiert leider nichts (fensterinhalt bleibt weiß) - vdr wird einige male (via runvdr) durchgestartet - xinelibouput gibt den segfault aus (obwohl das 2. display des X am TV sichtbar ist)... vdr_xinit sollte also passen (ich check das aber auch noch ab).

grüße, ciax

netvista-fan · 23. Juli 2008

Also, dein genaues Problem ist das wenn Du den vdr mit xineliboutput-plugin startest...

mit in der der xineliboutput.conf
local=vdr-sxfe
Du den segfault bekommst...

und mit
local=none
remote=37890
Der VDR problemlos startet,
und ein manuelles vdr-sxfe dann ein Bild bringt.

????

Gibst Du das vdr-sxfe in einem x-terminal unter gnome ein, oder direkt in der shell?
x-terminal dürfte klappen, shell eher nicht da der x-server schon von gnome belegt ist.
Evtl. könnte das dein Problem sein ???

ciax · 23. Juli 2008

Zitat

Originally posted by netvista-fan
Also, dein genaues Problem ist das wenn Du den vdr mit xineliboutput-plugin startest...
.
.
x-terminal dürfte klappen, shell eher nicht da der x-server schon von gnome belegt ist.
Evtl. könnte das dein Problem sein ???

ich hab gdm und den automatischen start von gnome deaktiviert. es läuft kein x-server! wenn ich's manuell starte (ganz egal, ob via remote-frontend vdr-sxfe oder als thread im vdr via eintrag in vdr's setup.conf: "xineliboutput.Frontend = sxfe" --> das entspricht "-Pxinelibouput local=sxfe" als parameter, muß aber nicht mitgegeben werden, wenn's in setup.conf steht) funktioniert alles prima. der x-server fährt über xinit hoch, vdr-sxfe gebe ich ihm mittels "xinit -e vdr-sxfe mit (siehe erstes "vdr_xinit"). automatisiert gibt's die beiden oben erwähnten segfaults ab.

gruß, ciax

ciax · 24. Juli 2008

Zitat

Originally posted by gda
wenn du den vdr_xinit Skript in einer virtuellen Konsole startest geht es auch?

das funktioniert einwandfrei! hmmm ...

Zitat

Originally posted by knebb
Du muesstest doch waehrend des Hochfahrens sehen, welches Skript gerade ausgefuehrt wird, oder?
Dann mach einfach mal ein echo "Ich bin jetzt dran", dann weisst Du auf jeden Fall mal, dass es in der richtigen Reihenfolge ausgefuehrt wird.

hab nun ins "vdr_xinit" eine zeile vor aufruf von xinit ergänzt, damit im syslog genau steht, wann X beim starten ist:

Code

/usr/bin/logger __ Now starts X via vdr_xinit __

was ich weiters probiert habe ist, das system gleich in den runlevel 3 zu fahren. zuerst im runlevel 2 lasse ich X (via vdr_xinit / S99vdr_xinit) hochfahren, dann vdr selbst im runlevel 3 (via S21runvdr). das bringt leider auch nichts. im syslog sehe ich, daß X und vdr ziemlich zeitgleich starten ...

wenn ich die meldungen im syslog zwischen dem automatischen start (--> segfault) und einem manuellen start (vdr start von der console aus) vergleiche, kann ich keinen unterschied bis zum segfault erkennen. anbei noch 2 ausschnitte:

syslog: nach reboot (--> segfault):

Code

Jul 24 08:46:20 localhost vdr: [5906] VDR version 1.7.0 started
Jul 24 08:46:20 localhost vdr: [5906] codeset is 'UTF-8' - known
Jul 24 08:46:20 localhost logger: __ Now starts X via vdr_xinit __
Jul 24 08:46:22 localhost vdr: [5906] found 23 locales in /opt/src/vdr/vdr-1.7.0-ext/locale
Jul 24 08:46:22 localhost vdr: [5906] loading plugin: /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/lib/libvdr-sc.so.1.7.0
Jul 24 08:46:22 localhost vdr: [5906] loading plugin: /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/lib/libvdr-remote.so.1.7.0
Jul 24 08:46:22 localhost vdr: [5906] loading plugin: /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/lib/libvdr-skinenigmang.so.1.7.0
Jul 24 08:46:23 localhost vdr: [5906] loading plugin: /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/lib/libvdr-avards.so.1.7.0
Jul 24 08:46:24 localhost vdr: [5906] loading plugin: /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/lib/libvdr-music.so.1.7.0
Jul 24 08:46:24 localhost vdr: [5906] loading plugin: /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/lib/libvdr-femon.so.1.7.0
Jul 24 08:46:24 localhost vdr: [5906] loading plugin: /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/lib/libvdr-osddemo.so.1.7.0
Jul 24 08:46:24 localhost vdr: [5906] loading plugin: /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/lib/libvdr-pictures.so.1.7.0
.
.
Jul 24 08:46:32 localhost vdr: [5906] no DVB device found
.
.
Jul 24 08:46:33 localhost vdr: [5906] [general.debug] probing /dev/dvb/adapter0/frontend0
Jul 24 08:46:33 localhost vdr: [5906] [general.debug] capturing device 0
Jul 24 08:46:33 localhost vdr: [5906] device 1 provides: DVBS
Jul 24 08:46:33 localhost vdr: [6182] tuner on device 1 thread started (pid=5906, tid=6182)
Jul 24 08:46:33 localhost vdr: [6183] section handler thread started (pid=5906, tid=6183)
Jul 24 08:46:33 localhost vdr: [5906] [general.debug] probing /dev/dvb/adapter1/frontend0
Jul 24 08:46:33 localhost vdr: [5906] [general.debug] capturing device 1
Jul 24 08:46:33 localhost vdr: [5906] device 2 provides: DVBS DSS DVBS2
Jul 24 08:46:33 localhost vdr: [6185] tuner on device 2 thread started (pid=5906, tid=6185)
Jul 24 08:46:33 localhost vdr: [6186] section handler thread started (pid=5906, tid=6186)
Jul 24 08:46:33 localhost vdr: [5906] [general.info] captured 2 video devices
.
.
.
Jul 24 08:46:36 localhost vdr: [5906] starting plugin: xineliboutput
Jul 24 08:46:36 localhost vdr: [6240] Local decoder/display (cXinelibThread) thread started (pid=5906, tid=6240)
Jul 24 08:46:36 localhost vdr: [6240] [xine..put] xineliboutput: plugin file is /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/lib/libvdr-xineliboutput.so.1.7.0
Jul 24 08:46:36 localhost vdr: [6240] [xine..put] Searching frontend sxfe from /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/lib/
Jul 24 08:46:36 localhost vdr: [6240] [xine..put] Probing /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/lib/libxineliboutput-sxfe.so.1.0.2-cvs
Jul 24 08:46:37 localhost vdr: [6240] [xine..put] load_frontend: entry at 0x7f0e68442040
Jul 24 08:46:37 localhost vdr: [6240] [xine..put] Using frontend sxfe (X11 (sxfe)) from libxineliboutput-sxfe.so.1.0.2-cvs
Jul 24 08:46:37 localhost vdr: [6240] [xine..put] cXinelibLocal::Action - fe created
Jul 24 08:46:37 localhost vdr: [6240] [vdr-fe]    sxfe_display_open(width=1360, height=768, fullscreen=1, display=:0.1)
Jul 24 08:46:37 localhost vdr: [6240] [vdr-fe]    Display size : 705 x 390 mm
Jul 24 08:46:37 localhost vdr: [6240] [vdr-fe]                   1360 x 768 pixels
Jul 24 08:46:37 localhost vdr: [6240] [vdr-fe]                   50dpi / 48dpi
Jul 24 08:46:37 localhost vdr: [6240] [vdr-fe]    Display ratio: 1969,000000/1929,000000 = 1,020736
Jul 24 08:46:37 localhost vdr: [6240] [xine..put] cXinelibLocal::Action - fe->fe_display_open ok
Jul 24 08:46:37 localhost vdr: [6240] [xine..put] cXinelibLocal::Action - xine_init
Jul 24 08:46:37 localhost kernel: [   71.765513] Local decoder/d[6240]: segfault at 0 ip 7f0e639d8277 sp 46f6bfa0 error 4 in libxine.so.
2.0.0[7f0e6399a000+53000]

Alles anzeigen

und die meldungen beim manuellen start:

Code

Jul 24 08:48:45 localhost vdr: [8557] VDR version 1.7.0 started
Jul 24 08:48:45 localhost vdr: [8557] codeset is 'UTF-8' - known
Jul 24 08:48:45 localhost vdr: [8557] found 23 locales in /opt/src/vdr/vdr-1.7.0-ext/locale
Jul 24 08:48:45 localhost vdr: [8557] loading plugin: /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/lib/libvdr-sc.so.1.7.0
Jul 24 08:48:45 localhost vdr: [8557] loading plugin: /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/lib/libvdr-remote.so.1.7.0
Jul 24 08:48:45 localhost vdr: [8557] loading plugin: /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/lib/libvdr-skinenigmang.so.1.7.0
Jul 24 08:48:46 localhost vdr: [8557] loading plugin: /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/lib/libvdr-avards.so.1.7.0
Jul 24 08:48:46 localhost vdr: [8557] loading plugin: /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/lib/libvdr-music.so.1.7.0
Jul 24 08:48:46 localhost vdr: [8557] loading plugin: /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/lib/libvdr-femon.so.1.7.0
.
.
.
Jul 24 08:48:46 localhost vdr: [8557] no DVB device found
.
.
Jul 24 08:48:46 localhost vdr: [8557] [general.debug] probing /dev/dvb/adapter0/frontend0
Jul 24 08:48:46 localhost vdr: [8557] [general.debug] capturing device 0
Jul 24 08:48:46 localhost vdr: [8557] device 1 provides: DVBS
Jul 24 08:48:46 localhost vdr: [8561] tuner on device 1 thread started (pid=8557, tid=8561)
Jul 24 08:48:46 localhost vdr: [8562] section handler thread started (pid=8557, tid=8562)
Jul 24 08:48:46 localhost vdr: [8557] [general.debug] probing /dev/dvb/adapter1/frontend0
Jul 24 08:48:46 localhost vdr: [8557] [general.debug] capturing device 1
Jul 24 08:48:46 localhost vdr: [8557] device 2 provides: DVBS DSS DVBS2
Jul 24 08:48:46 localhost vdr: [8564] tuner on device 2 thread started (pid=8557, tid=8564)
Jul 24 08:48:46 localhost vdr: [8565] section handler thread started (pid=8557, tid=8565)
Jul 24 08:48:46 localhost vdr: [8557] [general.info] captured 2 video devices
.
.
Jul 24 08:48:46 localhost vdr: [8557] starting plugin: xineliboutput
Jul 24 08:48:46 localhost vdr: [8577] Local decoder/display (cXinelibThread) thread started (pid=8557, tid=8577)
Jul 24 08:48:46 localhost vdr: [8577] [xine..put] xineliboutput: plugin file is /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/lib/libvdr-xineliboutput.so.1.7.0
Jul 24 08:48:46 localhost vdr: [8577] [xine..put] Searching frontend sxfe from /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/lib/
Jul 24 08:48:46 localhost vdr: [8577] [xine..put] Probing /opt/src/vdr/vdr-1.7.0-ext/PLUGINS/lib/libxineliboutput-sxfe.so.1.0.2-cvs
Jul 24 08:48:46 localhost vdr: [8577] [xine..put] load_frontend: entry at 0x7f53a5e2f040
Jul 24 08:48:46 localhost vdr: [8577] [xine..put] Using frontend sxfe (X11 (sxfe)) from libxineliboutput-sxfe.so.1.0.2-cvs
Jul 24 08:48:46 localhost vdr: [8577] [xine..put] cXinelibLocal::Action - fe created
Jul 24 08:48:46 localhost vdr: [8577] [vdr-fe]    sxfe_display_open(width=1360, height=768, fullscreen=1, display=:0.1)
Jul 24 08:48:51 localhost vdr: [8577] [vdr-fe]    Display size : 705 x 390 mm
Jul 24 08:48:51 localhost vdr: [8577] [vdr-fe]                   1360 x 768 pixels
Jul 24 08:48:51 localhost vdr: [8577] [vdr-fe]                   50dpi / 48dpi
Jul 24 08:48:51 localhost vdr: [8577] [vdr-fe]    Display ratio: 1969,000000/1929,000000 = 1,020736
Jul 24 08:48:51 localhost vdr: [8577] [xine..put] cXinelibLocal::Action - fe->fe_display_open ok
Jul 24 08:48:51 localhost vdr: [8577] [xine..put] cXinelibLocal::Action - xine_init
Jul 24 08:48:51 localhost vdr: [8577] [vdr-fe]    Detected 2 CPUs
Jul 24 08:48:51 localhost vdr: [8577] [vdr-fe]    Enabling multithreaded video decoding
Jul 24 08:48:51 localhost vdr: [8577] [xine..put] cXinelibLocal::Action - fe->xine_init ok
Jul 24 08:48:51 localhost vdr: [8577] [xine..put] cXinelibLocal::Action - xine_open
Jul 24 08:48:51 localhost vdr: [8577] [input_vdr] Symbol SysLogLevel found : value 3
Jul 24 08:48:51 localhost vdr: [8577] [input_vdr] Symbol LogToSysLog found : value yes
Jul 24 08:48:51 localhost vdr: [8577] [input_vdr] init class succeeded
Jul 24 08:48:51 localhost vdr: [8577] [input_vdr] vdr_class_get_instance
Jul 24 08:48:51 localhost vdr: [8577] [input_vdr] fifo_buffer_new...
Jul 24 08:48:51 localhost vdr: [8577] [input_vdr] fifo_buffer_new done.
Jul 24 08:48:51 localhost vdr: [8577] [input_vdr] vdr_class_get_instance done.
Jul 24 08:48:51 localhost vdr: [8577] [input_vdr] vdr_plugin_open_local
Jul 24 08:48:51 localhost vdr: [8577] [xine..put] cXinelibLocal::Action - fe->xine_open ok
Jul 24 08:48:51 localhost vdr: [8577] [vdr-fe]    re-wiring post plugins
Jul 24 08:48:51 localhost vdr: [8577] [xine..put] cXinelibLocal::Action - fe->xine_play ok
Jul 24 08:48:51 localhost vdr: [8577] [input_vdr] vdr_flush_engine: stream_start, flush skipped
Jul 24 08:48:51 localhost vdr: [8577] [vdr-fe]    opening post plugin: tvtime:method=Greedy2Frame,cheap_mode=1,pulldown=none,framerate_m
ode=full,judder_correction=1,use_progressive_frame_flag=1,chroma_filter=0,enabled=1
.
.
Jul 24 08:48:51 localhost vdr: [8577] [xine..put] cXinelibLocal::Action - fe config OK
Jul 24 08:48:52 localhost vdr: [8598] [input_vdr] H.264 scanner: Possible MPEG2 start code (0xb3)
Jul 24 08:48:53 localhost vdr: [8577] [xine..put] cXinelibLocal::Action - logo sent
Jul 24 08:48:53 localhost vdr: [8577] [xine..put] cXinelibLocal:Action - Starting event loop
Jul 24 08:48:53 localhost vdr: [8557] [xine..put] cXinelibDevice::StartDevice(): Device started
Jul 24 08:48:53 localhost vdr: [8557] setting current skin to "EnigmaNG"
.
.
Jul 24 08:49:01 localhost vdr: [8598] [input_vdr] No data in 8 seconds, queuing no signal image
Jul 24 08:49:04 localhost vdr: [8557] [xine..put] Forcing primary device, original index = 1
Jul 24 08:49:04 localhost vdr: [8557] [xine..put] Forcing primary device, old OSD still open !
Jul 24 08:49:04 localhost vdr: [8598] [input_vdr] BLANK in middle of stream! bufs queue 0 , video_fifo 0
.
.
Jul 24 08:49:05 localhost vdr: [8609] cVideoRepacker: switching to MPEG1/2 mode
Jul 24 08:49:05 localhost vdr: [8609] cVideoRepacker: operating in MPEG1/2 mode
Jul 24 08:49:06 localhost vdr: [8598] [input_vdr] Audio changed -> AC3 0 (BD:80)
Jul 24 08:49:06 localhost vdr: [8609] [xine..put] Detected video size 720x576

Alles anzeigen

zu viel input erwarte ich mir von euch auch nicht mehr - ich weiß, daß ist echt verflixt!

mehr infos habe ich leider auch nicht - kann's nicht sein, daß ich nur auf der leitung stehe?

gruß, ciax

ciax · 29. Juli 2008

hallo nochmal,

wenn ich den logausschnitt zwischen den beiden versuchen (1. funktionierend aus der console und 2. den segfault aus init runlevel 2 heraus) vergleiche, fällt mir auf, daß es genau beim "xine_init" den fehler (kernel segfault) gibt.

xine_init ok:

Code

Jul 24 08:48:51 localhost vdr: [8577] [xine..put] cXinelibLocal::Action - xine_init
Jul 24 08:48:51 localhost vdr: [8577] [vdr-fe]    Detected 2 CPUs
Jul 24 08:48:51 localhost vdr: [8577] [vdr-fe]    Enabling multithreaded video decoding
Jul 24 08:48:51 localhost vdr: [8577] [xine..put] cXinelibLocal::Action - fe->xine_init ok

kernel segfault:

Code

Jul 24 08:46:37 localhost vdr: [6240] [xine..put] cXinelibLocal::Action - xine_init
Jul 24 08:46:37 localhost kernel: [   71.765513] Local decoder/d[6240]: segfault at 0 ip 7f0e639d8277 sp 46f6bfa0 error 4 in libxine.so.
2.0.0[7f0e6399a000+53000]

und zwar genau dort, wo eigentlich

Code

Jul 24 08:48:51 localhost vdr: [8577] [vdr-fe]    Detected 2 CPUs
Jul 24 08:48:51 localhost vdr: [8577] [vdr-fe]    Enabling multithreaded video decoding

multithreaded decoding "initialisiert" wird. soweit es in meiner erinnerung hängen geblieben ist, wird das über ffmpeg (??) realisiert. xine-lib wurde mit external ffmpeg übersetzt.

könnte es eventuell an der damaligen svn-version von ffmpeg liegen? würde mich über ein statement freuen, bevor ich die ganze sache (zwecklos) austeste ...

danke & gruß,
ciax

ps: dadurch begründet ist natürlich nicht, daß es manuell sauber funktioneirt...

ciax · 29. Juli 2008

hi,

des rätsels lösung - eine antwort von Morfsta aus der linuxtv maillist:

Zitat

Original by Morfsta - linuxtv.org
It's a known bug that's been there for years - try starting the files
using su (e.g. su - -c <COMMAND> <USER>), that should setup a proper
environment and it shouldn't segfault.

--> referenz: www.linuxtv.org/pipermail/vdr/2008-July

somt läßt sich das frontend auch via init-script im runlevel 2 starten.

ich bin bei meiner suche nicht über diesen bug gestolpert - es wundert mich auch, warum sonst niemand mit diesem problem konfrontiert wurde?

auf jeden fall könnte die lösung eventuell in zukunft auch noch dem einen oder anderen helfen!

gruß, ciax

DKVT · 6. November 2009

Genau das Problem hatte ich bis eben auch. Danke für die Antwort, hab schon ewig gesucht!

gda · 6. November 2009

Zitat

Original von ciax
ich bin bei meiner suche nicht über diesen bug gestolpert - es wundert mich auch, warum sonst niemand mit diesem problem konfrontiert wurde?

Doch, ist mir auch passiert und ich habe auch schon mehrfach geschrieben, dass

Code

export HOME=/root

das Selbe bewirkt.

Gerald

ciax · 6. November 2009

Zitat

Original von DKVT
Genau das Problem hatte ich bis eben auch. Danke für die Antwort, hab schon ewig gesucht!

.. schön, daß es geholfen hat!

Zitat
Original von gda
Doch, ist mir auch passiert und ich habe auch schon mehrfach geschrieben, dass
Code
export HOME=/root
export HOME=/root

das Selbe bewirkt.

Gerald
Alles anzeigen

hi Gerald, ist schon ewig lang her, daß ich das problem hatte .. wenn's so auch funktioniert und eine für's "vdr-sxfe" (edit: betraf auch das "lokale sxfe") geeignete umgebung für root schafft, ist das eine gute information an der richtigen stelle!

gruß, ciax

gda · 6. November 2009

Zitat

Original von ciax
hi Gerald, ist schon ewig lang her, daß ich das problem hatte .. wenn's so auch funktioniert und eine für's "vdr-sxfe" geeignete umgebung für root schafft, ist das eine gute information an der richtigen stelle!

Es hatte mir damals nicht gereicht, dass es unter einem anderen User funktioniert und habe das debugged. Vdr-sxfe versucht einfach unsere allseits bekannte und beliebte config_xineliboutput zu laden und zwar mit diesem Pfad: $HOME/.xine/config_xineliboutput. Das funktioniert auch fast immer, sogar wenn du es unter root startest. Aber beim Boot ist root nicht eingeloggt, die Prozesse laufen nur unter root, deshalb ist HOME einfach nicht gesetzt.

Gerald

Baerbel · 15. Dezember 2009

Gepriesen seinen die Retter in der Not.
Stunden des Grübelns lösen sich oft so einfach in Schall und Rauch auf, wenn man mit den richtigen Begriffen dieses Forum durchsucht.
Aber so ist das eben, man weiß gute Infos erst zu schätzen, wenn man selbst kurz vor dem Verzweifeln ist.

Ich danke euch!!!!

Gruß
Kai

[solved] xineliboutput: kernel segfault beim start via init

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema