Duo4K - Fehler und Vorschläge

[Janus]

Wenn ich anschließend Astra 1 wieder scanne - also den gleichen Zustand wie zuvor habe - und über das Menü anschließend die Kanallisten neulade, passiert ja Nichts. Genau wie im beschriebenen Fall, dass ich das Löschen mit einem aktiven Services auf einem anderen - nicht zu löschenden - Broadcaster starte.

Im Übrigen sind zum Test da nur 4 Satpositionen und 1 Kabelanbieter im Bestand.
Im "Vollausbau" halte ich 31 Sat-Positionen (plus einem Kabelanbieter und evtl. einem T2-Sendemast) vor:

Code: Alles auswählen

<?xml version='1.0'?>
<satellites xmlns:xi="http://www.w3.org/2001/XInclude" >
    <xi:include href="/mnt/settings/834/satellites.xml" xpointer="xpointer(//sat[@name='834 Hispasat'])" />
    <xi:include href="/mnt/settings/81B/satellites.xml" xpointer="xpointer(//sat[@name='81B ISat 907'])" />
    <xi:include href="/mnt/settings/7FD/satellites.xml" xpointer="xpointer(//sat[@name='7FD ISat 905'])" />
    <xi:include href="/mnt/settings/7E4/satellites.xml" xpointer="xpointer(//sat[@name='7E4 SES 4'])" />
    <xi:include href="/mnt/settings/7D0/satellites.xml" xpointer="xpointer(//sat[@name='7D0 NSS 7'])" />
    <xi:include href="/mnt/settings/79E/satellites.xml" xpointer="xpointer(//sat[@name='79E Telstar'])" />
    <xi:include href="/mnt/settings/785/satellites.xml" xpointer="xpointer(//sat[@name='785 ESat 12'])" />
    <xi:include href="/mnt/settings/758/satellites.xml" xpointer="xpointer(//sat[@name='758 ESat 8'])" />
    <xi:include href="/mnt/settings/73A/satellites.xml" xpointer="xpointer(//sat[@name='73A ESat 5'])" />
    <xi:include href="/mnt/settings/730/satellites.xml" xpointer="xpointer(//sat[@name='730 Amos'])" />
    <xi:include href="/mnt/settings/710/satellites.xml" xpointer="xpointer(//sat[@name='710 Thor'])" />
    <xi:include href="/mnt/settings/6F5/satellites.xml" xpointer="xpointer(//sat[@name='6F5 BulSat'])" />
    <xi:include href="/mnt/settings/6EA/satellites.xml" xpointer="xpointer(//sat[@name='6EA ESat 3'])" />
    <xi:include href="/mnt/settings/6D7/satellites.xml" xpointer="xpointer(//sat[@name='6D7 SES 5'])" />
    <xi:include href="/mnt/settings/6C2/satellites.xml" xpointer="xpointer(//sat[@name='6C2 ESat 7'])" />
    <xi:include href="/mnt/settings/6AE/satellites.xml" xpointer="xpointer(//sat[@name='6AE ESat 9'])" />
    <xi:include href="/mnt/settings/6A4/satellites.xml" xpointer="xpointer(//sat[@name='6A4 ESat 10'])" />
    <xi:include href="/mnt/settings/686/satellites.xml" xpointer="xpointer(//sat[@name='686 Hotbird'])" />
    <xi:include href="/mnt/settings/668/satellites.xml" xpointer="xpointer(//sat[@name='668 ESat 16'])" />
    <xi:include href="/mnt/settings/649/satellites.xml" xpointer="xpointer(//sat[@name='649 Astra 1+'])" />
    <xi:include href="/mnt/settings/648/satellites.xml" xpointer="xpointer(//sat[@name='648 Astra 1'])" />
    <xi:include href="/mnt/settings/631/satellites.xml" xpointer="xpointer(//sat[@name='631 ESat 21'])" />
    <xi:include href="/mnt/settings/61D/satellites.xml" xpointer="xpointer(//sat[@name='61D Astra 3'])" />
    <xi:include href="/mnt/settings/5EE/satellites.xml" xpointer="xpointer(//sat[@name='5EE Astra 2'])" />
    <xi:include href="/mnt/settings/5CD/satellites.xml" xpointer="xpointer(//sat[@name='5CD Astra 5'])" />
    <xi:include href="/mnt/settings/5BE/satellites.xml" xpointer="xpointer(//sat[@name='5BE ESat 33'])" />
    <xi:include href="/mnt/settings/5A0/satellites.xml" xpointer="xpointer(//sat[@name='5A0 ESat 36'])" />
    <xi:include href="/mnt/settings/582/satellites.xml" xpointer="xpointer(//sat[@name='582 Hellas'])" />
    <xi:include href="/mnt/settings/564/satellites.xml" xpointer="xpointer(//sat[@name='564 Turksat'])" />
    <xi:include href="/mnt/settings/546/satellites.xml" xpointer="xpointer(//sat[@name='546 ISat 38'])" />
    <xi:include href="/mnt/settings/53C/satellites.xml" xpointer="xpointer(//sat[@name='53C AzerSpace'])" />
</satellites>

Ich könnte nochmal prüfen, ob sich durch den zum Settingswechsel verwendeten Symlink
ln -sf /var/tuxbox/config/test/ /var/tuxbox/config/zapit
ein Unterschied zum 'einfachen' Settingsverzeichnis /var/tuxbox/vonfig/zapit/ ergibt.

Aber ich arbeite damit schon ohne Probleme, seitdem ich Neutrino verwende.
Und - wie schon gesagt - die Fehler treten hier nur auf der Duo4K auf.
Meine anderen MultiTuner-Boxen (Neo, Tank, HD51 - alle mit Selbstbau-NI) haben da keine Last mit.

Ich habe deshalb immer noch die Inkompatibilitäten zwischen 32bit-Firmware und 64bit-CPU
bei der Parameterübergabe zwischen Prozeduren im Verdacht.

[satbaby]

@Janus
BPanther sagt, dass es alte Bug ist.
Ich kann hier nichts reproduzieren, also muss es nur auf VU mips vorkommen.

Du kannst doch Neutrino selbst bauen.
Benutze doch nicht gestripte Version, platz in Flash ist genug da.
Ich habe in hd51 immer nicht gestripte Neutrino.

Dann muss Du noch in start_neutrino so was haben:
### sda1 anpassen falls nötig
echo /media/sda1/core.%e.pid-%p.signal-%s > /proc/sys/kernel/core_pattern
echo 1 > /proc/sys/kernel/core_uses_pid
ulimit -c unlimited

und wenn segfault kommt, hast Du core.bla.bla in sda1
Dann startest Du gdb
gdb neutrino /sda1/core.bla.bla
und schreibst in gdb
bt
und Ausgabe hier posten.

Vielleicht kommt man weiter.

[BPanther]

@Janus
BPanther sagt, dass es alte Bug ist.
Ich kann hier nichts reproduzieren, also muss es nur auf VU mips vorkommen.

Hat nichts mit dem System oder der Box dabei zu tun, kenne ich schon von SH4 und Neutrino v1, die VU+ MIPS nutze ich nur zum testen der Images, nicht regulär. Die hatte ich mal von einem Kollegen bekommen, da sie defekt war (einige Chips und Kondensatoren). Sowohl das Laden der Senderliste als auch das laden der WebTV.xml-Dateien crasht realativ schnell Neutrino. Liegt vielleicht aber auch daran, daß ich ein paar WebTV-Sender mit in die normale Senderliste mit eingebunden habe und der Bug dadurch evtl. vom laden der xml Dateien verstärkt mit rüberkommt sozusagen, denn wenn die fehlen, brauchts länger bis zum Crash.

[satbaby]

Dann kann doch an System liegen. Ich habe nur arm Boxen und da segfaultet schon ewig nichts.
Ich nutze pugixml-lib aber ni-images auch. Deswegen bleib in Grunde nur System.
Wenn du hast xml's womit das reproduzieren kann, gib sie doch hier in Forum
Gruß

[Janus]

Ich habe mir gerade mit aktuellem NI-Source (master) von Gestern ein Image mit
=> Debug=yes (in config.local)
und zwischenzeitlichem
=> make dbg (zwischen make neutrino und make image)
erstellt. (.tgz über 250 MB)

Per lokalem Update (ofgwrite) über die tgz ging es nicht, das Image aus /tmp nach Bank 3 zu flashen.
Habe dann das multi.zip auf 'nur' Partition 3 optimiert und per USB-Stick/Bootloader geflasht.
Das hat dann funktioniert und ich habe die EInstellungen des Nightly von Gestern aus Partition 1 übernommen.

Boxinfo: rootfs = 646,36 MB, 287,37 MB frei

Jetzt muss ich mich erstmal in gdb einlesen und hoffen, dass das - wie oben beschrieben - macht was es soll...

[Miky]

viewtopic.php?f=51&t=129&p=267&hilit=Debug#p267

[satbaby]

@Janus
Es reich, wenn Du nur Neutino (bin) tauscht.
Ich mache es immer nur so. Wir möchten keine Libs Debuggen.

[Janus]

gdb ist im Image, läuft auch (z.B. mit --help)

Irgendwie ist das gdb (8.3) aus dem NI-BS aber hier nicht zu einer Zusammenarbeit zu übereden.

Weder mit der Konfiguration von satbaby noch mit der Verlinkten von Miky.
Aktuell ist lt. Manual eine Version 10 (Tenth Edition, for gdb version 10.0.50.20200902-git).

Habe zwei der Fehler provoziert (über WebTV-Änderung und Kanallisten neu laden nach Löschung) aber keine Datei in dem jeweils 'konfigurierten' Verzeichnis.

Muss wohl wieder mal eine Nacht drüber schlafen...

[Miky]

Aber die Datei. coredump ist angelegt?

[Janus]

/var/etc/.coredump

mit dem Inhalt (vuData ist sdb1=USB-Flash)

/media/vuData/logs

Aber - wie gesagt - ich schlaf mal drüber...

[satbaby]

@Janus
Für coredump brauchst keine gdb, die kommt erst in Spiel,wenn coredump da ist.
coredump sollte danach vorhanden sein:
echo /<dein HDD>/core.%e.pid-%p.signal-%s > /proc/sys/kernel/core_pattern
echo 1 > /proc/sys/kernel/core_uses_pid
ulimit -c unlimited

Dann kommt erst gdb.
Gruß

[vanhofen]

Ich gehe beim Debuggen immer wiefolgt vor:

make gdb
make neutrino DEBUG=yes

Auf der Box dann:

killall neutrino
echo "/pfad/zur/festplatte" > /var/etc/.coredump (Die Coredumps werden dann in /pfad/zur/festplatte abgelegt)
service coredump start

Dann buildsystem/root/bin/gdb nach /var/bin auf die Box kopieren (chmod +x nicht vergessen!)
und buildsystem/root/bin/neutrino nach /bin auf die Box kopieren.

/bin/neutrino

Wenn Neutrino dann gecrasht ist, dauert es manchmal einige Zeit, bis der Coredump geschrieben wurde.

gdb /bin/neutrino /pfad/zur/festplatte/core.xxx.yyy.zzz

In gdb dann bt full eingeben.

[Miky]

Meine. coredump ist /media/sda1. Wobei das bei mir unkritisch ist da nur ne interne HDD verbaut ist. Sicherer ist sicher das Label des Mediums. Lass doch mal das /logs weg.

[Janus]

Wie lange darf das dauern, bis eine core.xxx.yyy.zzz geschrieben wird ?

Ich habe /var/etc/.coredump nacheinander jeweils

/media/vuData/logs
/media/vuData/logs/
/media/vuData
/media/sdb1 (==vuData > USB)
/media/sda1 (HDD)
/media/sda1/

per echo... zugewiesen

Eine folgende Kontrolle mit
cat /var/etc/.coredump
hat das jeweils bestätigt.

Auch der Start des Coredump-Services hat das jeweils bestätigt.

Dann ist es mir bei jeder Pfad-Variante gelungen, das Neutrino (mit DEBUG=yes ~ 80.8 MB statt der üblichen 4.4 MB der gestrippten Version) in den Crash zu schicken.
In keinem (!!) der Fälle wurde die o.g. Datei geschrieben.

Damit wurde natürlich auch der nächste Schritt

gdb /bin/neutrino /pfad/zur/festplatte/core.xxx.yyy.zzz

sinnlos.


gdb selbst läuft jedenfalls:

Code: Alles auswählen

[vuDuo4K] / # gdb --help
This is the GNU debugger.  Usage:

    gdb [options] [executable-file [core-file or process-id]]
    gdb [options] --args executable-file [inferior-arguments ...]

Noch irgendwelche Tipps ?

[annie]

/var/etc/.coredump mal reingeschaut, ob das was du willst drin steht ?

vllt mal die Datei auch nach /etc kopieren....

mal geprüft ob der Service coredump läuft ?
service coredump start

[Janus]

Eine folgende Kontrolle mit
cat /var/etc/.coredump
hat das jeweils bestätigt.

Auch der Start des Coredump-Services hat das jeweils bestätigt.

Das hatte ich bei jeder Variante geprüft...

Ich verstehe den Unterschied zwischen dem Vorgehen von satbaby und dem von vanhofen ncht wirklich. Kann sein, dass die eine "Lösung" auf das von satbaby verwendete BS aufsetzt, die andere mehr zu dem von mir verwendeten NI-BS passen sollte.
Aber leider komme ich mit beiden Verfahren nicht zu einer "post mortem"-Ausgabe an den entsprechenden Stellen.

Vielleicht bin ich auch nicht gdb-kompatibel.
Hatte schon in ururalten Zeiten des CST_NeutrinoHD keinen Erfolg mit dem Handling des Tools.
Und mich danach nicht mehr damit beschäftigt. Wollte früher auch nie so weit in C/C++ einsteigen.
(Für WinDoofies mit C# war VisualStudio halt damals der gewohnt leichte Weg)

[vanhofen]

Der Unterschied zwischen unseren beiden Vorgehen ist der, dass Satbaby alles händisch vorgeschlagen hat. Ich hingegen habe auf die im Image integrierte Coredump-Unterstützung verwiesen.

Ob das, was du in /var/etc/.coredump angegeben hast, auch beim Kernel angekommen ist, kannst du mit "cat /proc/sys/kernel/core_pattern" prüfen.
Das geht in beiden Fällen.

[Janus]

Et kütt nix...

Code: Alles auswählen

...
 [bouquets.cpp:loadWebchannels:890] Loading webtv from /share/tuxbox/neutrino/webtv/yt_live.xml ...                      
 [bouquets.cpp:loadWebchannels:890] Loading webradio from /var/tuxbox/webradio/webradio_usr.xml ...                      
 [bouquets.cpp:parseBouquetsXml:415] reading bouquets from /var/tuxbox/config/zapit/ubouquets.xml                        
 
  Segmentation fault                                                                                                      
 
 [vuDuo4K] / # ls -al /media/sdb1                                                                                        
 drwxr-xr-x   18 root     root          4096 Aug 10 10:30 .                                                               
 drwxrwxrwt    4 root     root           200 Jan  1  2020 ..
 drwxr-xr-x    4 root     root          4096 Apr 22 13:28 apps                                                           
 drwxr-xr-x    8 root     root          4096 Jul 27 11:14 backup                                                         
 drwxr-xr-x    4 root     root          4096 Jul 31 21:30 common                                                         
 drwxr-xr-x    3 root     root          4096 Dec 23  2019 cws                                                            
 drwxr-xr-x    2 root     root         28672 Sep  1 18:11 epg                                                            
 drwxr-xr-x    7 root     root          4096 Jan 25  2020 firm                                                           
 drwxr-xr-x    3 root     root          4096 Nov 20  2019 globalData                                                     
 drwxr-xr-x    2 root     root          4096 Sep  2 12:28 images                                                         
 drwxr-xr-x    2 root     root          4096 Jul 21 15:40 logs                                                           
 drwx------    2 root     root         16384 Nov 19  2019 lost+found                                                     
 drwxr-xr-x    2 root     root          4096 Dec  5  2019 plugins                                                        
 drwxr-xr-x    2 root     root          4096 Feb  3  2020 screenshots                                                    
 drwxr-xr-x    2 root     root          4096 Aug 10 11:55 scripts                                                        
 drwxr-xr-x    3 root     root          4096 Aug 14 16:06 streaming                                                      
 drwxr-xr-x    3 root     root          4096 Jul 31 17:53 test                                                           

[vuDuo4K] / # cat /proc/sys/kernel/core_pattern                                                                         
 /media/sdb1/core.%e.%p.%t

Mmmhhmm...

[satbaby]

@Janus
Du kannst schnell testen über telnet:

[hd51] /var/root # sleep 10 &
[hd51] /var/root # killall -SIGSEGV sleep
[1]+ Segmentation fault (core dumped) sleep 10
[hd51] /var/root # ls /media/sda1/co*
/media/sda1/core.sleep.pid-1493.signal-11

Wenn nix kommt, zeig hier "ulimit -a" Ausgabe.

[Janus]

Vorbereitet nach der Methode von vanhofen:

[vuDuo4K] /var/root # echo /media/sdb1 > /var/etc/.coredump
[vuDuo4K] /var/root # service coredump start
Sep 05 19:23:55 vuDuo4K user.info coredump[3185]: dumps stored in /media/sdb1

[vuDuo4K] /var/root # cat /proc/sys/kernel/core_pattern
/media/sdb1/core.%e.%p.%t

Code: Alles auswählen

[vuDuo4K] /var/root # sleep 10 &                                                                                        
 [vuDuo4K] /var/root # killall -SIGSEGV sleep                                                                            
 [1]+  Segmentation fault         sleep 10                                                                               
 [vuDuo4K] /var/root # ls /media/sdb1/co*                                                                                
  share  var  <==   Das ist der Inhalt von /media/sdb1/common !!!                                                                                                         
==> /media/sdb1 enthält nur Directories
 
 [vuDuo4K] /var/root # ulimit -a                                                                                         
 core file size (blocks)         (-c) 0                                                                                  
 data seg size (kb)              (-d) unlimited                                                                          
 scheduling priority             (-e) 0                                                                                  
 file size (blocks)              (-f) unlimited                                                                          
 pending signals                 (-i) 4302                                                                               
 max locked memory (kb)          (-l) 64                                                                                 
 max memory size (kb)            (-m) unlimited                                                                          
 open files                      (-n) 1024                                                                               
 POSIX message queues (bytes)    (-q) 819200                                                                             
 real-time priority              (-r) 0                                                                                  
 stack size (kb)                 (-s) 8192                                                                               
 cpu time (seconds)              (-t) unlimited                                                                          
 max user processes              (-u) 4302                                                                               
 virtual memory (kb)             (-v) unlimited                                                                          
 file locks                      (-x) unlimited                                                                          
 [vuDuo4K] /var/root #

Die Variante nach satbaby mache ich Morgen...