Neutrino-Images

Ich habe auch keine Coredumps mehr hinbekommen. Ich muss zugeben, schon ewig nicht mehr debugged zu haben.
Die coredump-Unterstützung in unserem Image passt nicht (mehr). Ich kümmere mich gerade darum.

Bevor du das Debug-Neutrino startest, musst du zwingend an der Shell "ulimit -c unlimited" starten. Dann bekommst du auch Coredumps erstellt.

Nachtrag: ulimit setzt die Limitgröße nur für die gerade aktive Shell. Das heißt, startest du das Neutrino-Binary per Telnet in einer eigenen Shell, muss dort "ulimit -c unlimited" vorher eingegeben werden. Die Coredump-Unterstützung im Image funktioniert noch (was ich da oben geschrieben habe, stimmt also nicht), allerdings muss nach Einspielen des Debug-Binaries die Box neu gestartet werden. Das ist seinerzeit mal ins Image gekommen, als wir komplette Debug-Images gebaut haben.

man kann core size auch so prüfen:
cat /proc/$(pidof neutrino)/limits

Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size unlimited unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 2969 2969 processes
Max open files 1024 4096 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 2969 2969 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us

NI (master von Heute) und Hinweise von vanhofen haben Erfolg gezeigt:

############## CBouquetManager::makeRemainingChannelsBouquet: numbers start at: tv 1 radio 1 ############
[zapit] bouquet loading took: 325 msec
[zapit] parsing pmt pid 0x13EC (_eins)
[subtitles] DVBSub: PID=0x13f1, lang=deu, cpageid=0001, apageid=0001
ShowText 'Kanallisten neu laden'
Segmentation fault (core dumped)

Das war der Fehler, den ich schon ganz zu Anfang hatte. (vor dem Umbenennen von dem hint-Icon)

In /media/sdb1/logs gibt es nun ein FIle core.cGLCD::Run.2502.1599391149

Und Backtrace gibt:

Code: Alles auswählen

(gdb) bt
#0  0xb6ed481c in memcpy () from /lib/libdvbsi++.so.1
#1  0x001d3d70 in std::char_traits<char>::copy (__n=16777215, __s2=0xffffff <error: Cannot access memory at address 0xffffff>, __s1=<optimized out>)
    at /home/janus/development/ni/duo4k/cross/arm-linux-4.1.45-1.17/arm-cortex-linux-gnueabihf/include/c++/6.5.0/bits/char_traits.h:290
#2  std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_copy (__n=16777215, __s=0xffffff <error: Cannot access memory at address 0xffffff>, 
    __d=<optimized out>) at /home/janus/development/ni/duo4k/cross/arm-linux-4.1.45-1.17/arm-cortex-linux-gnueabihf/include/c++/6.5.0/bits/basic_string.h:300
#3  std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_copy_chars (__k2=<optimized out>, 
    __k1=0xffffff <error: Cannot access memory at address 0xffffff>, __p=<optimized out>)
    at /home/janus/development/ni/duo4k/cross/arm-linux-4.1.45-1.17/arm-cortex-linux-gnueabihf/include/c++/6.5.0/bits/basic_string.h:342
#4  std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*> (this=0xb2a901b8, 
    __beg=0xffffff <error: Cannot access memory at address 0xffffff>, __end=<optimized out>)
    at /home/janus/development/ni/duo4k/cross/arm-linux-4.1.45-1.17/arm-cortex-linux-gnueabihf/include/c++/6.5.0/bits/basic_string.tcc:225
#5  0xaaaaaaaa in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

Tja, das sieht für mich nach "das muss sich mal Jemand anders ansehen" aus.
Ich versuche derweil mal, noch weitere "Fälle" von Neuladen-Bugs zu protokolieren.

p.s.
Gibt es ein GDB-HowTo für Anfänger ?
Vielleicht auch mit externer Remote-Nutzung von Werkzeugen im grafischen Linux-UI ? (wie z.B. mit VisualStudio unter Windows)
War da ganz praktisch: Breakpoint setzen - Variablen checken/ändern - Step durch Anweisung ...

edit Nachtrag:
Nach "GDB for Dummies" gesucht...
... und leicht versteckt in einer Linkliste was gefunden: http://www.unknownroad.com/rtfm/gdbtut/gdbtoc.html
Knapp und übersichtlich.

Leider sagt das uns grade wenig.
Hast Du das auch mit pzapit -c ?

Es sagt uns jedenfalls, dass es aus dem GraphLCD-Thread kommt.

dass es aus dem GraphLCD-Thread kommt

Ich habe mal unter Themes > "Position und Größen" die Anzeige der Logos ausgeschaltet => Erstmal kein SegFault bei der o.g. Ausführung von "Kanallisten neu laden" mehr. (Theme: Advanced)

Die anderen Anzeigen (OSD-Menü und VideoBild) sind hier auch abgeschaltet.

Hast Du das auch mit pzapit -c ?

Nein! Ist mir bisher nicht untergekommen, obwohl ich das in meinen "Wechsel_Scripten" immer zum Neuladen nach der Umstellung verwende!

Vermutlich weil das keine Ausgaben über das UI oder das Frontpaneel macht ?!?

Dann ist wohl der Übeltäter GLCD.
Man kann es abschalten.

Ich habe keine Box mit GLCD.
Was für GLCD wird bei deiner VU verwendet?
Du kannst noch versuchen paar segfaults zu provozieren, vielleicht kommt die richtige Stelle in log.
Und schreib in glcd.cpp
#define GLCD_DEBUG 1
Dann siehst mehr in log.

Warten wir mal ab, was der Author der recht neuen GLCD-Routinen für die Duo4K da rausfindet.
Die "Zielansprache" ist ja schon etwas genauer als Gestern.

Da ich inzwischen mit der abgeschalteten Logo-Darstellung im GLCD keinen einzigen Segfault mehr hatte (auch nicht per leerer oder gefüllter "currentservices.xml" und auch nicht mit ein paar Versuchen, das Ganze über WebTV/WebRadio-Änderungen zu provozieren) wird der Fehler hoffentlich zeitnah ingekreist werden.

Ich denke, wenn da demnächst ein Fix ansteht oder nach Etwas ausprobiert werden muss, werde ich das testen können und dann kommt's ins GIT.

Ich habe ein fix versuch commitet.
https://github.com/neutrino-images/ni-n ... 3dc57e2ec9

Der segfault kommt von glcd hier:

Code: Alles auswählen

diff --git a/src/driver/glcd/glcd.cpp b/src/driver/glcd/glcd.cpp
index 59109c2f4..b3e91a329 100644
--- a/src/driver/glcd/glcd.cpp
+++ b/src/driver/glcd/glcd.cpp
@@ -1500,7 +1500,7 @@ bool cGLCD::showImage(uint64_t cid, std::string cname, uint32_t dx, uint32_t dy,
        std::string logo;
        int sw, sh;
 
-       if (g_PicViewer->GetLogoName(cid, cname, logo, &sw, &sh))
+       if (cid != 1 && (g_PicViewer->GetLogoName(cid, cname, logo, &sw, &sh)))
        {
                return showImage(logo, (uint32_t) sw, (uint32_t) sh, dx, dy, dw, dh, transp, maximize);
        }

Das könnte man auch noch commiten, aber ich habe kein GLCD und weiss nicht für was alles cGLCD::showImage benutzt wird.
Gruß

satbaby hat geschrieben: ↑Mo 14. Sep 2020, 17:55ein fix versuch

Bis jetzt auf die Schnelle keine Fehler mehr.
Test mit 'Nachladen' von currentservices.xml fehlt noch.

Danke, sieht also erstmal gut aus...

Die Darstellung der Tuner-Bezeichner in der Infobar müsste für die FBC-/Multituner noch an die "Buchstaben-Regel" angepasst werden.
Für Sat werden "I" und "II" (also römische Zählung) angezeigt, bei dem Kabeltuner sehe ich auch wieder "I" (was allerdings auch ein großes i sein könnte).

In der Boxinfo stehen die - auch unter Enigma verwendeten - Buchstaben nur als Ergänzung zur numerischen Bezeichnung.

Ich fände es besser, für diese Menge an Tunern, Subtunern usw. eine flexiblere Indexierung zu verwenden.
Mit der 'neuen' Buchstaben-Auflistung wären Kennzeichnungen von bis zu 24 Frontends möglich.
Das Hinzufügen von zusätzliche USB-Tunern oder weiteren Frontend-Kategorien (DVB-T-Tuner, zusätzlich USB-Tuner, ka- oder C- Band Tuner etc.) würde diese Grenze in Zukunft evtl. überschreiten.
Übersichtlich würde ich das dann auch nicht mehr nennen.

Wenn man Buchstaben und Ziffern kombinieren würde, könnte man besser gruppieren.
Den Buchstaben für das hardwäremäßig vorhandene Tunermodul, eine nachfolgende Ziffer für eventuelle "Subtuner".

Bei meiner Duo4K wäre das dann:

A1 .. A8 wenn die FBC-Subtuner identisch belegt sind (eine Anschluss-Option)
oder
A1 .. Ax
B1 .. Bx wenn - wie hier - die Subtuner auf zwei Anschlussoptionen geschalten werden könnten

Der Kabeltuner bekäme dann den nächsten freien Buchstaben mit 8 unabhängigen Subtunern, also
C1.. C8

Bei Tunern, die mehrere Delivery-System abdecken, z.B. DVB-C/T2 - Sticks kämen dann, auch bei entsprechender Umschaltung einer "einzigen" Anschlussoption
D1 und E1 dazu.

Mein TBS 5520 SE (USB) würde dann hier mit

D1 ==> für den DVB-S2 EIngang
E1 ==> für den Antennen-Eingang im Kabelmodus, und
F1 ==> für den Antennen-Eingang im T2-Betrieb

In die Frontend-Auflistung aufgenommen.

Nur mal als Idee, wenn man wegen der Buchstaben sowieso an den Code ranmuss...

Janus hat geschrieben: ↑Mo 12. Okt 2020, 14:28Für Sat werden "I" und "II" (also römische Zählung) angezeigt, bei dem Kabeltuner sehe ich auch wieder "I" (was allerdings auch ein großes i sein könnte).

Hmm, das muß aber was NI spezifisches sein, habe ich hier nicht bei der Ultimo4K (16x S + 4x C/T). Wahrscheinlich meinst Du eher die Grafik in der Infobar, das muß NI halt noch ändern. Ich habe bei mir A..X auch bei der Infobar/L4L usw.

Janus hat geschrieben: ↑Mo 12. Okt 2020, 14:28Mit der 'neuen' Buchstaben-Auflistung wären Kennzeichnungen von bis zu 24 Frontends möglich.

Was auch ausreichend sein sollte. Zudem müsste dann auch noch an anderer Stelle einiges angepasst werden, denn die "interne Hauptgrenze" ist derzeit 32, 24 sind aber maximal nur nutzbar (auch bei E2, T unterstützt nur 12).

Genausogut kann man auch AA..ZZ, AAA...ZZZ oder mehr davon nehmen, das wäre egal. Letztlich weiß eh keiner wirklich, welcher Tuner am Ende welcher ist (außer T/C/S selbst). Daher sehe ich die Bezeichner als nebensächlich an. Wer auch noch zusätzlich (warum?!) USB-Tuner benutzt, sieht auch hier anhand des Tunernamens schon welcher dabei welcher ist, da ist das interne A..Z oder 1..32 doch eher nebensächlich. Aber würde eh nicht funktionieren, denn es ist nur ...adapter0... möglich, externe Tuner verwenden aber adapter > 0. Von daher ist das mit den externen Tunern derzeit komplett unwichtig - nicht böse gemeint und daher bitte nicht falsch verstehen. Ich habe zwar einen variablen ...adapterX... vorbereitet, aber auf 0 noch blockiert. Dafür muß noch einiges gemacht werden damit das funktioniert. Allerdings sehe ich noch immer erstmal ganz andere Probleme die behoben werden sollten statt sich auf externe Tuner zu konzentrieren.

was NI spezifisches sein

Hätte ich vielleicht dazuschreiben sollen!

Was meine Ideen betrifft, sind das hier meist (Verbesserungs-) Vorschläge, deren Umsetzung auch früher schonmal Jahre gedauert hat. Also keine Einflussnahme auf Prioritäten-Listen.

Eher was für den Hinterkopf, falls Jemand dann mal an einer passenden Stelle rumbastelt...

Naja, ich weiß schon, wo wir hier sind.

Ich dachte nur, daß NI vielleicht nicht alles komplett übernommen hatte vom DDT als ich das da eingebaut hatte. So meine Annahme - ABER, ich habe auch im DDT das bei den 4 Standard-Tuner-Icons belassen und nicht erweitert oder Grafiken erstellt, wobei die dort zumindest Bild

heißen.
Lokal benutze ich hingegen die Buchstaben A..X.

So, nachdem ich mich nochmal rangesetzt habe, habe ich auch das Problem gefunden. Viel Spaß damit: https://github.com/Duckbox-Developers/n ... 8ac9de5bd0

habe ich auch das Problem gefunden

Das kann ich bestätigen.

Mit der seit Gestern verfügbaren Version 18915 des BPanther-Images sind auch mit neuen Treiberversionen komplette Sat-Scans mit dem S2X Twin-FBC-Tuner möglich. (Getestet mit Astra1, Hotbird und Astra 3)

Da gleichzeitig auch an der S2X-Erweiterung gearbeitet wurde, muss bei diesen Multistream-Transpondern der Eintrag für das Empfangssystem auf "S2X" gestellt werden. (Getestet mit ESat 5W)

Wäre schön, wenn das auch in das NI-Repo einfließen könnte.
Falls ich das vorab testen soll, wäre ein entsprechender Patch für mein lokales NI-Repo ganz sinnvoll...

Was im DDT-BS wohl noch fehlt, ist die Formulierung für das System DVB-S2X (oder nur für MIS ?) in satellites.xml für die Übernahme per getservices.cpp.

Auf Grund der vorhandenen Auflistung wäre wohl system="12" für 'DVB-S2X' in der satellites.xml angebracht. Passt jedenfalls schonmal zur delsys-Enumeration. Und mit 12 == erste eXtension zu DVB-S2 könnte man es sich sogar merken...

Die Logik => system="2" (0 = S, 1= S2. 2=S2X) wäre eine 'schönere' Alternative, dann müssten aber in ParseSatTransponders() die weiteren Optionen DSS, Turbo und ISDBS "auf 3, 4, und 5 verschoben" werden.
Artet wohl in Arbeit aus und führt darüberhinaus zu Inkompaibilitäten mit generierten Scanlisten.

Habs erstmal so gelöst:
https://github.com/TangoCash/neutrino-t ... 5123019c8f

Mit diesem Revert der Frontend-/Scan-Anpassungen scheint die alte Treiber-Problematik (Test mit Duo4K-Selbstbau vom 24.11.) wieder da zu sein !?!

Bei dieser Test-Aktion - und dafür notwendigem Tausch der Anschlusskabel - ist mir aufgefallen, dass möglicherweise bei meinem Quad-LNB an der Motorschüssel mindestens einer der 4 Ausgänge nicht einwandfrei 'liefert'.

Der schonmal erwähnte Unterschied zwischen dem Scanergebnis (auf 5E) von HD51 und Duo4K scheint an diesem Quad-LNB zu liegen und nicht an den Änderungen zur Treiberanpassung. Muss aber erst noch die Empfangsanlage umbauen, um das zu endgültig verifizieren.

Neutrino-Images

Duo4K - Fehler und Vorschläge

Re: Duo4K - Fehler und Vorschläge

Re: Duo4K - Fehler und Vorschläge

Re: Duo4K - Fehler und Vorschläge

Re: Duo4K - Fehler und Vorschläge

Re: Duo4K - Fehler und Vorschläge

Re: Duo4K - Fehler und Vorschläge

Re: Duo4K - Fehler und Vorschläge

Re: Duo4K - Fehler und Vorschläge

Re: Duo4K - Fehler und Vorschläge

Re: Duo4K - Fehler und Vorschläge

Re: Duo4K - Fehler und Vorschläge

Re: Duo4K - Fehler und Vorschläge

Re: Duo4K - Fehler und Vorschläge

Re: Duo4K - Fehler und Vorschläge

Re: Duo4K - Fehler und Vorschläge

Re: Duo4K - Fehler und Vorschläge

Re: Duo4K - Fehler und Vorschläge

Re: Duo4K - Fehler und Vorschläge

Re: Duo4K - Fehler und Vorschläge

Re: Duo4K - Fehler und Vorschläge