GM-Reloaded / pzapit / Absturz / rev6325

[DboxOldie]

Was heißt ändern ?
Du schickst andere per ftp/Script auf die Box ?

[DaMulda]

Per FTP bringe ich die Dateien auf die Box und es reicht schon ein simples überschreiben, also ohne Änderungen an den Dateien.
Beim ersten Mal (also nach dem Hochfahren der Box) funktioniert's meist ohne Absturz. Jeder weitere Versuch kann zum Absturz führen (passiert sporadisch).

[DboxOldie]

Ok....
Versuch mal nach dem Hochladen im Telnet 2 oder 3 mal ein 'sync'.
Das sollte sicherstellen, dass die Dateien auch wirklich gespeichert sind und nicht halb im Cache hängen.
Und dann erst das 'pzapit -c'

[BPanther]

Hmm, hier ist die Methode relativ egal. Ob man nun pzapit -c, Service Menü oder (später dann) das via WebIf macht, kommt es sporadisch zum Crash mit Fehler 13x (unterschiedlich, 135 und 139 am häufigsten). Dabei ist auch die NMP Version egal, also ob NMP von mir oder das CST (da wurde einiges über Threads/Mutex gemacht), es crasht überall sporadisch. Das Problem gab es aber sogar schon in den alten "original Neutrino-SD-Versionen" der DBox2. Konnte wohl bislang noch keiner wirklich herausfinden was genau da das Problem ist.

[BPanther]

Anbei mal ein experimenteller Bau der neutrino binary mit dem reloadchannels als WebIf Befehl von der Konsole aus. Ist komplett ungetestet, da ich keine Pingulux mehr hier habe. Datei auspacken und die neutrino erstmal zum testen nach /tmp kopieren (Rechte 755) und Neutrino über das Extras Menü neu starten (NICHT im Service Menü, das startet Neutrino nicht wirklich neu). Wenn es läuft wie es soll kannst Du die org. neutrino in /usr/local/bin ersetzen damit es dauerhaft wirkt.

EDIT: Anhang entfernt.

[TangoCash]

Bin mir nicht sicher ob das passt.
Übers webif reloadchannels werden vorher die noch evtl im RAM befindlichen Chanlisten gespeichert und dann neu eingelesen.

Code: Alles auswählen

		/* save if changed, to make sure NEW/REMOVED/... flags are updated */
		CServiceManager::getInstance()->SaveServices(true, true);

ein "simples"

Code: Alles auswählen

		g_Zapit->reinitChannels();
		CNeutrinoApp::getInstance ()->SDTreloadChannels = false;

sollt es da tun.

Das überschreiben geht auch nicht immer, wenn die Dateien grad in verwendung sind.
Einfach vorher umbenennen (services.xml nach services.old) dagegen funktoniert.
Nach dem reload + sync dann halt die *.old löschen.

[DaMulda]

Ok....
Versuch mal nach dem Hochladen im Telnet 2 oder 3 mal ein 'sync'.
Das sollte sicherstellen, dass die Dateien auch wirklich gespeichert sind und nicht halb im Cache hängen.
Und dann erst das 'pzapit -c'

Ich hatte mich schon gefreut, da dies einige Male tatsächlich ohne Absturz funktionierte, jedoch ist es dann leider erneut passiert.

Anbei mal ein experimenteller Bau der neutrino binary mit dem reloadchannels als WebIf Befehl von der Konsole aus. Ist komplett ungetestet, da ich keine Pingulux mehr hier habe. Datei auspacken und die neutrino erstmal zum testen nach /tmp kopieren (Rechte 755) und Neutrino über das Extras Menü neu starten (NICHT im Service Menü, das startet Neutrino nicht wirklich neu). Wenn es läuft wie es soll kannst Du die org. neutrino in /usr/local/bin ersetzen damit es dauerhaft wirkt.

Leider ist es hier wie mit "pzapit -c", d.h. es kommt sporadisch zum Absturz.
Wie hast du das im Code umgesetzt? Lediglich ein reinitChannels() oder auch die restlichen Aufrufe, die das Service-Menü durchführt?
Übrigens... Ich habe erneut massenhaft den Reload übers Menü getestet, bei mir ist die Box in keinem Fall abgeschmiert.

Das überschreiben geht auch nicht immer, wenn die Dateien grad in verwendung sind.
Einfach vorher umbenennen (services.xml nach services.old) dagegen funktoniert.
Nach dem reload + sync dann halt die *.old löschen.

Das habe ich jedes Mal überprüft, also ob die Dateien tatsächlich überschrieben wurden. Und wie bereits erwähnt, treten die Abstürze auch auf, wenn keine Änderungen durchgeführt werden.

[BPanther]

Ich habe die 3 Zeilen von oben (im Ursprung aus der scan_setup.cpp) übernommen - und es führt, wie ich auch schon oben geschrieben hatte, des öfteren zum Crash.

EDIT: Alternativ kann man natürlich statt der 3 Zeilen auch nur eine Zeile als Direktaufruf der Funktion einbauen - so wie es das Service Menü macht. Ich schreibe das mal eben um und hänge eine neue neutrino dann hier ran. Dauert nen paar Minuten...

Anhang gelöscht...

[DaMulda]

Leider treten auch hierbei Abstürze auf, es ist jedoch (gefühlt) besser.
Ich hab' nun auch mal den Menü-Reload massenhaft über ein Script abgesetzt (vorher hatte ich das immer nur per Hand gemacht) und tatsächlich... auch hier kommt es zu Abstürzen.

Somit glaube ich nun, dass da etwas bei der Verarbeitung der Senderliste schief geht.

[BPanther]

Wenn es so zumindest etwas besser erscheint, lasse ich diese Variante erstmal so drin. Ich werde bei Gelegenheit mal in der scan_setup.cpp ein paar printf einbauen um zu schauen, wer von den 3 eigentlich den Crash auslöst um dann das weiter verfolgen zu können. Wird sich zeigen, ob vielleicht doch rauszubekommen ist, wo und warum das crasht. Aber wie gesagt, da das schon beim alten Neutrino problematisch war, würde ich mich wundern, wenn sich das so leicht finden lassen würde...

[BPanther]

Habs mal kurz probiert über das Service Menü, den Crash löst die Funktion g_Zapit->reinitChannels(); aus:

Code: Alles auswählen

[zapit.cpp:PrepareChannels:1079] LoadServices: success
[bouquets.cpp:parseBouquetsXml:371] reading bouquets from /var/tuxbox/config/zapit/bouquets.xml
[bouquets.cpp:parseBouquetsXml:437] total: 89 bouquets
*** glibc detected *** /tmp/neutrino: munmap_chunk(): invalid pointer: 0x00980b18 ***
Aborted

So würde es erfolgreich aussehen, diesmal via pzapit -c ausgeführt:

Code: Alles auswählen

[zapit.cpp:PrepareChannels:1079] LoadServices: success
[bouquets.cpp:parseBouquetsXml:371] reading bouquets from /var/tuxbox/config/zapit/bouquets.xml
[bouquets.cpp:parseBouquetsXml:437] total: 89 bouquets
[bouquets.cpp:parseBouquetsXml:371] reading bouquets from /var/tuxbox/config/zapit/ubouquets.xml
[bouquets.cpp:parseBouquetsXml:437] total: 113 bouquets
############## CBouquetManager::makeRemainingChannelsBouquet: numbers start at: tv 1 radio 1 ############
[zapit] bouquet loading took: 2708 msec
CServiceManager::SaveServices: total channels: 1841
CServiceManager::SaveServices: processed channels: 1841
[zapit] parsing pmt pid 0x63 (Discovery HD)
atevio7500:~# NeutrinoMessages::EVT_SERVICESCHANGED
[neutrino] Creating channels lists...
[neutrino] got 1599 TV and 242 RADIO channels
[neutrino] all channels took: 15 msec
[neutrino] created Astra 1KR/1L/1M/1N (19.2E) (192) bouquet with 1264 TV and 170 RADIO channels
[neutrino] sat took: 24 msec
[neutrino] created Telecolumbus Berlin (3870) bouquet with 335 TV and 72 RADIO channels
[neutrino] sat took: 115 msec
[neutrino] got 98 new TV channels
[neutrino] got 72 new RADIO channels
[neutrino] got 6 removed TV channels
[neutrino] sats took: 132 msec
[neutrino] got 89 TV and 35 RADIO bouquets
[neutrino] took: 141 msec
CNeutrinoApp::SetChannelMode 0 [tv]
[neutrino.cpp:SetChannelMode:1785] newmode 0 sort old -1 new 0
CChannelList::adjustToChannelID me 0x8b80b8 [Alle Kanäle] list size 1599 channel_id bae8000600850082

Demnach könnte das Problem eher hier liegen: bouquets.cpp:parseBouquetsXml

Ich habe da mal was verändert und wieder eine neue neutrino angehangen. Scheint nun stabiler zu funktionieren auch mit pzapit -c, aber auch noch immer nicht zu 100% - oder war nur Zufall. Es gibt da aber wohl noch andere/weitere Stellen...

Noch ein kleiner Nachtrag. g_Zapit->reinitChannels() ruft seinerseits über die MSG CMD_REINIT_CHANNELS die Funktion PrepareChannels() auf, die ihrerseits die Funktionen g_bouquetManager->loadBouquets() sowie danach CServiceManager::getInstance()->SaveServices(true, true) aufruft - welche also dann nicht mehr extra angegeben werden muß. Evtl. ist das mit den erneuten SaveServices zuviel oder das Problem liegt doch noch davor...

EDIT: Anhang entfernt.

[DaMulda]

Getestet... Es scheint stabiler zu sein, jedoch, wie auch schon von dir erwähnt, kommt es dennoch zu Abstürzen.

Code: Alles auswählen

[zapit.cpp:PrepareChannels:1079] LoadServices: success
[bouquets.cpp:parseBouquetsXml:371] reading bouquets from /var/tuxbox/config/zapit/bouquets.xml
[bouquets.cpp:parseBouquetsXml:437] total: 89 bouquets
*** glibc detected *** /tmp/neutrino: munmap_chunk(): invalid pointer: 0x00980b18 ***
Aborted

An deinem Beispiel-Crash ist auch sehr schön zu sehen, an welcher Stelle dieser auftritt. In loadBouquets() wird zunächst die bouquets.xml eingelesen, dies gelingt auch. Anschließend müsste die ubouquets.xml eingelesen werden, dies scheitert jedoch.
Somit müsste sich der in der Fehlermeldung genannte Pointer an dieser Stelle (in parseBouquetsXml) befinden:

Code: Alles auswählen

xmlDocPtr parser;

parser = parseXmlFile(fname);
if (parser == NULL)
	return;

xmlNodePtr root = xmlDocGetRootElement(parser);
xmlNodePtr search = root->xmlChildrenNode;
xmlNodePtr channel_node;

if (search) {
	t_original_network_id original_network_id;
	t_service_id service_id;
	t_transport_stream_id transport_stream_id;
	int16_t satellitePosition;
	freq_id_t freq = 0;

Evtl. ist das mit den erneuten SaveServices zuviel oder das Problem liegt doch noch davor...

Das könnte natürlich sein und letztendlich der Grund dafür sein, dass der Parser abschmiert.


EDIT:
Bei mir tritt der Fehler bzw. Absturz übrigens meistens nach "parsing pmt pid..." auf:

[zapit.cpp:PrepareChannels:1079] LoadServices: success
[bouquets.cpp:parseBouquetsXml:371] reading bouquets from /var/tuxbox/config/zapit/bouquets.xml
[bouquets.cpp:parseBouquetsXml:437] total: 65 bouquets
[bouquets.cpp:parseBouquetsXml:371] reading bouquets from /var/tuxbox/config/zapit/ubouquets.xml
[bouquets.cpp:parseBouquetsXml:437] total: 68 bouquets
############## CBouquetManager::makeRemainingChannelsBouquet: numbers start at: tv 1 radio 1 ############
[zapit] bouquet loading took: 841 msec
CServiceManager::SaveServices: total channels: 1539
CServiceManager::SaveServices: processed channels: 1539
[zapit] parsing pmt pid 0x61 (NatGeo HD)
Segmentation fault

Selten mal an anderen Stellen, so wie hier:

[zapit.cpp:PrepareChannels:1079] LoadServices: success
[bouquets.cpp:parseBouquetsXml:371] reading bouquets from /var/tuxbox/config/zapit/bouquets.xml
[bouquets.cpp:parseBouquetsXml:437] total: 65 bouquets
[bouquets.cpp:parseBouquetsXml:371] reading bouquets from /var/tuxbox/config/zapit/ubouquets.xml
[CBasicClient] receive failed: /tmp/zapit.sock
Bus error

[BPanther]

Der Crash tritt an unterschiedlichen Stellen auf, das mit dem zapit.sock bekommt man fast immer, wenn man mehrfach hintereinander das neu laden startet. Da scheint zapit wohl noch nicht soweit zu sein.
Die Minimierung der Crashs selbst hatte ich über die xmlinterface.h anscheinend etwas bewirkt, als ich bei der inline Funktion xmlFreeDoc einfach nochmal einen Check eingebaut habe ob die Variable "doc" auch wirklich != NULL ist. Was ich aber gesehen hatte im Source wo wie Funktion verwendet wird, war das meist zuvor schon überprüft worden, was dann eigentlich nichts wirklich bewirken hätte dürfen. Daher habe ich das auch erstmal wieder bei mir entfernt.

Ich werde da wohl einfach nochmal den genauen Weg der Funktionen durchgehen und alles mit printf vollstopfen um rauszubekommen, wo das Teil überall crasht. Anders gehts wohl nicht.

Danke auf jeden Fall für die Tests.