videotext plugin fehlerhaft ??

[Nico 77]

Irgendwo hier im Thread wurde geschrieben das es einfach am zu wenigen Speicher liegt das der Tuxtxt nicht mehr läuft ich habe die Sache mal ein bißchen laufen lassen und sehe das etwas anders.

Ich kann die Box Wochen vielleicht auch Monate laufen lassen, mache ich Tuxtxt an geht er. Aber lief der Tuxtxt schon einmal dann läuft dieser am nächsten ca. Tag nicht mehr. Also sollte das nicht am vorhandenen Speicher liegen da die Box ja Wochen laufen kann und dann den Tuxtxt starten.

[Metallica]

*unwichtig*

[Nico 77]

*unwichtig*

Hmm, was war das so unwichtig?

Hat eventl. noch jemand Ideen, irgendwie haut das mit den wenigen Recurcen alles nicht hin.

Selbst mit 600kb freien Speicher und sehr wenig buffer starten alle Games, auch das Dreamchess sowies Tuxcom oder andere Plugins nur der Tuxtxt nicht mehr. Da ist was am Tuxtxt faul.

Wenn jemand Ideen hat, bin immer gerne bereit Patches oder Tipps durchzutesten.

[LazyT]

irgendwie haut das mit den wenigen Recurcen alles nicht hin.

Tja, Fakt ist nunmal imo das der Aufruf von pthread_create() fehlschlägt und dafür gibt's laut Manpage nur 2 Fehlerursachen:

1) not enough system resources to create a process for the new thread
2) more than PTHREAD_THREADS_MAX threads are already active

Das die Fehlerausgabe "Interrupted system call" vom TuxTxt falsch sein dürfte habe ich schon mal erwähnt.

Warum nun allerdings der Returnwert der aufgerufenen Funktion tuxtxt_start_thread() nicht geprüft wird und TuxTxt trotz des Fehlers fröhlich weitermacht entzieht sich meiner Kenntnis.

Da ich den Code aber nur kurz überflogen habe bin ich auch schon wieder still und überlasse das den 2 Jungs die sich da inzwischen viel besser auskennen.

[Npq]

Das die Fehlerausgabe "Interrupted system call" vom TuxTxt falsch sein dürfte habe ich schon mal erwähnt.

Ja, liegt daran, daß pthread_create nicht die errno-Variable setzt, wodurch perror nicht funktioniert. Der Fehlercode wird in dem Fall direkt zurückgegeben.

[LazyT]

Genau, soweit waren wir schonmal im Mai.

[Nico 77]

Versteh das ganze zwar nicht so ganz, aber wenn sich das ganze so schwer fixen lässt wäre es dann nicht sinnvoll das wenn tuxtxt startet dieser sich ram reservert jedesmal?

Ich habe das bei dreamchess gesehen, wenn man dieses startet und beendet sind nachher statt 600kb aufeinmal ca 2MB oder mehr frei.

[dbluelle]

Tja, ich kann das (leider) auf der Dreambox nicht nachvollziehen, da klappt das ohne Probleme .

Tritt der Fehler auch bei Enigma oder nur bei Neutrino auf?
Ghost hatte da vor einiger Zeit mal was bzgl. der Threads in Enigma gefixt. Vorher wurde bei jedem Aufruf eines Plugins (nicht nur Tuxtxt) ein Teil des Speichers nicht wieder freigegeben. Evtl. stimmt da ja bei Neutrino auch irgendwas nicht...

Läßt sich das irgendwie zeitlich eingrenzen, seit welcher Version von Tuxtxt der Fehler "existiert" ?

dbluelle

[Nico 77]

Tja, ich kann das (leider) auf der Dreambox nicht nachvollziehen, da klappt das ohne Probleme .

Tritt der Fehler auch bei Enigma oder nur bei Neutrino auf?
Ghost hatte da vor einiger Zeit mal was bzgl. der Threads in Enigma gefixt. Vorher wurde bei jedem Aufruf eines Plugins (nicht nur Tuxtxt) ein Teil des Speichers nicht wieder freigegeben. Evtl. stimmt da ja bei Neutrino auch irgendwas nicht...

Läßt sich das irgendwie zeitlich eingrenzen, seit welcher Version von Tuxtxt der Fehler "existiert" ?

dbluelle

Die ersten Probs gab es damals ab v1.57, das mit dem nicht mehr aufrufen können evtl. 1.7x. Genau kann ich das leider nicht mehr sagen, sorry.

Also Qasi eingrenzen lässt sich nicht mehr.

[Nico 77]

Tja, ich kann das (leider) auf der Dreambox nicht nachvollziehen, da klappt das ohne Probleme .

Tritt der Fehler auch bei Enigma oder nur bei Neutrino auf?

Ja, habe Enigma nun einige Zeit laufen gehabt.
Ist genau das gleiche Verhalten, Tuxtext einmal gestartet, beim nächsten Aufruf ca 1 Tag später geht dieser nicht mehr.

Tuxtxt Cache ist aus, sollte vielleicht auch Standart in Enigma dbox2 sein.

[dbluelle]

Durch eure Diskussion über den sectionsd bin ich noch auf eine Möglichkeit gekommen:

Tuxtxt arbeitet in der jetzigen Form auf der Dbox (vor allem durch die Komprimierung) viel mit malloc() und free().
Dadurch kommt es hier vielleicht auch zu einer ziemlichen Speicherfragmentierung.
Evtl. wäre es mal ganz gut, die Komprimierung auszuschalten...
(Also einfach in tuxtxt_def.h das #define TUXTXT_COMPRESS auf 0 setzen)

Falls es wirklich an der Speicherfragmentierung liegt,
gibt's da noch mehr Optimierungspotential,
aber bevor ich mich da rein kniee, wüsste ich gern, in welche "Richtung" man da gehen soll .
Also wäre es z.B. gut, die Freigabe des Cache anders zu gestalten (evtl. so in der Art eines Stacks last in-> first out) ?
Oder läuft es dann doch eher darauf hinaus, mehr oder weniger eine eigene "Speicherverwaltung" für Tuxtxt zu programmieren (Das dürfte allerdings ziemlich komplex werden ) ?

dbluelle

[mb405]

im neuen tuxtext ist wohl wieder ein fehler ??

tuxtxt.so: undefined symbol: tuxtxt_get_zipsize

[Nico 77]

Evtl. wäre es mal ganz gut, die Komprimierung auszuschalten...
(Also einfach in tuxtxt_def.h das #define TUXTXT_COMPRESS auf 0 setzen)

dbluelle

Mit #define TUXTXT_COMPRESS 0 lässt sich der tuxtxt leider nicht kompilieren.
Hat ein prob mit "(pg->pData)".

Habe jetzt mal mit compress 1 probiert.

[mb405]

bei mir funkt es jetzt. ich hatte wohl einen fehler beim compilen

[dbluelle]

@Nico 77
Nimm mal das

Code: Alles auswählen

if (pg->pData)

in tuxtxt_common.h, Zeile 81 raus, dann müsste es auch mit TUXTXT_COMPRESS 0 durchlaufen.

@mb405
Da war noch ein Fehler drin, der seit Samstag Nachmittag gefixt ist.

dbluelle

[Nico 77]

Code: Alles auswählen

81:#else
82://	if (pg->pData)
83:		memcpy(pg->data,buffer,23*40);
84:#endif
85:	pthread_mutex_unlock(&tuxtxt_cache_lock);

Du meintest das // if (pg->pData) oder? Lasse es so laufen und werde berichten(dauert aber natürlich).

[Nico 77]

Durch eure Diskussion über den sectionsd bin ich noch auf eine Möglichkeit gekommen:

Tuxtxt arbeitet in der jetzigen Form auf der Dbox (vor allem durch die Komprimierung) viel mit malloc() und free().
Dadurch kommt es hier vielleicht auch zu einer ziemlichen Speicherfragmentierung.
Evtl. wäre es mal ganz gut, die Komprimierung auszuschalten...
(Also einfach in tuxtxt_def.h das #define TUXTXT_COMPRESS auf 0 setzen)

Falls es wirklich an der Speicherfragmentierung liegt,
gibt's da noch mehr Optimierungspotential,
aber bevor ich mich da rein kniee, wüsste ich gern, in welche "Richtung" man da gehen soll .
Also wäre es z.B. gut, die Freigabe des Cache anders zu gestalten (evtl. so in der Art eines Stacks last in-> first out) ?
Oder läuft es dann doch eher darauf hinaus, mehr oder weniger eine eigene "Speicherverwaltung" für Tuxtxt zu programmieren (Das dürfte allerdings ziemlich komplex werden ) ?

dbluelle

Nach langer Zeit, Fehler bleibt auch mit TUXTXT_COMPRESS auf 0.

[dbluelle]

Auch noch mit dem neuesten Tuxtxt/libtuxtxt aus dem CVS?

dbluelle

[Nico 77]

CVS Stand war 06.02.2006.

Werde die Tage mal eine 32mb Box nehmen, hatte die letzte Zeit immer 64mb ram im Einsatz da kommts nicht vor weil mehr Speicher.

[dbluelle]

Nach langer Zeit habe ich mir den SourceCode nochmal angesehen und eine mögliche Fehlerquelle entdeckt:

Code: Alles auswählen

diff -Naur -w orig/tuxtxt_common.h ok/tuxtxt_common.h
--- orig/tuxtxt_common.h	2006-05-19 13:15:19.000000000 +0200
+++ ok/tuxtxt_common.h	2006-05-19 13:23:02.613776864 +0200
@@ -1196,6 +1196,7 @@
 	{
 		perror("TuxTxt <pthread_create>");
 		tuxtxt_cache.thread_starting = 0;
+		tuxtxt_cache.thread_id = 0;
 		return 0;
 	}
 #if 1//DEBUG
@@ -1226,6 +1227,7 @@
 			perror("TuxTxt <pthread_join>");
 			return 0;
 		}
+		tuxtxt_cache.thread_id = 0;
 	}
 	if (tuxtxt_cache.dmx != -1)
 	{

Der Patch verhindert, daß ein bereits geschlossener Thread nochmal geschlossen wird.
Ich weiß allerdings nicht, ob das überhaupt was ausmacht, also ist's mehr so ein Schuß ins Blaue...
(Schaden tut's aber nicht und ist auf jeden Fall sauberer)

dbluelle

[Nico 77]

Habs mal eingebaut, danke.

Schaue mal ob sich was ändert.

[dbluelle]

Okay, noch ein Versuch...

Code: Alles auswählen

diff -Naur -w orig/libtuxtxt.c ok/libtuxtxt.c
--- orig/libtuxtxt.c	2006-07-01 15:35:41.000000000 +0200
+++ ok/libtuxtxt.c	2006-07-06 19:01:15.000000000 +0200
@@ -17,6 +17,7 @@
 
 #include <sys/ioctl.h>
 #include <fcntl.h>
+#include <pthread.h>
 
 #include "tuxtxt_common.h"
 
@@ -30,12 +31,14 @@
  ******************************************************************************/
 
 static int tuxtxt_initialized=0;
+static pthread_mutex_t tuxtxt_control_lock = PTHREAD_MUTEX_INITIALIZER;
 
 int tuxtxt_init()
 {
 	if ( tuxtxt_initialized )
 		return 0;
 
+	pthread_mutex_lock(&tuxtxt_control_lock);
 	tuxtxt_initialized=1;
 
 	/* init data */
@@ -48,6 +51,7 @@
 	tuxtxt_cache.vtxtpid = -1;
 	tuxtxt_cache.thread_id = 0;
 	tuxtxt_cache.dmx = -1;
+	pthread_mutex_unlock(&tuxtxt_control_lock);
 	return 1;//tuxtxt_init_demuxer();
 }
 
@@ -57,13 +61,18 @@
 
 int tuxtxt_stop()
 {
+	
 	if (!tuxtxt_cache.receiving) return 1;
 	tuxtxt_cache.receiving = 0;
 
-	return tuxtxt_stop_thread();
+	pthread_mutex_lock(&tuxtxt_control_lock);
+	int res = tuxtxt_stop_thread();
+	pthread_mutex_unlock(&tuxtxt_control_lock);
+	return res;
 }
 void tuxtxt_start(int tpid)
 {
+	pthread_mutex_lock(&tuxtxt_control_lock);
 	if (tuxtxt_cache.vtxtpid != tpid)
 	{
 		tuxtxt_stop();
@@ -76,10 +85,13 @@
 	{
 		tuxtxt_start_thread();
 	}
+	pthread_mutex_unlock(&tuxtxt_control_lock);
 }
 
 void tuxtxt_close()
 {
+	pthread_mutex_lock(&tuxtxt_control_lock);
+
 #if DEBUG
 	printf ("cleaning up\n");
 #endif
@@ -89,6 +101,7 @@
 	tuxtxt_cache.dmx = -1;
 	tuxtxt_clear_cache();
 	tuxtxt_initialized=0;
+	pthread_mutex_unlock(&tuxtxt_control_lock);
 }
 
 /* Local Variables: */

Damit wird sichergestellt, das nicht 2 Threads gleichzeitig am Cache rumfummeln.

Bei mir ist sonst auch ab und zu (1-2 mal im Monat) Enigma gecrasht, seitdem ich den Patch eingebaut habe (ca. bei Beginn der WM),
hatte ich keinen Absturz mehr...

Ich verstehe allerdings nicht, wie es überhaupt dazu kommen kann, daß (unter Enigma) zwei Threads auf den Cache zugreifen.
Naja, was solls.

dbluelle

[Coronas]

Soll ich's mal vorsichtshalber einchecken?

[dbluelle]

Von mir aus gerne.
Nimm dann am Besten auch den anderen Patch (vom 19.Mai) mit dazu.

dbluelle

[__Ghost__]

Hi,

das kann durchaus passieren, da in enigma alle "nicht enigma" plugins.. sprich alle, die nicht die enigma mainloop verwenden (also auf enigma gui/fernbedienungs funktionen zugreifen) in einem eigenen Thread gestartet werden, damit die normale enigma mainloop weiterläuft und damit z.B. noch anstehende Aufnahme/Umschalt Timer ausgeführt werden.

Aber beim normalen zappen werden ja tuxtxt funktionen aus dem enigma main thread aufgerufen.. also beim setzen der neuen vtxt pids.. start/stop.

Theoretisch wird also wenn man den Tuxtxt gerade geöffnet hat.. und enigma dann im Hintergrund für einen anstehenden Timer das Programm wechselt aus zwei threads auf die libtuxtxt zugegriffen.

Bei Neutrino dürfte es aber nicht gross anders aussehen.. da sind es statt Threads halt Daemons.. was ja auch nix anderes ist..

cu