sehr komische fehler mit xlib+qt

soul_rebel

ist immer auf der flucht
ich hab eine kde-anwendung und öffne in einen thread eine pipe aus der ich dann daten auslese und diese blockweise in ein KTextEdit schreibe. das sieht so aus:
Code:
char buffer[1500]="";
char prebuffer[1500]="";
			
while (!feof(installPipe))
{
	fgets(buffer, 300, installPipe);
	if (strcmp(buffer,prebuffer)!=0)
	m_parent2->tOutput->append(buffer);
				
	strcpy(prebuffer,buffer);
}
da fgets kontinuierlich daten ausließt prüft das if argument in der mitte noch ob die daten wirklich neu sind bevor es sie in das textedit schreibt. so weit so gut, ABER qt verursacht seltsame fehler dabei; das programm friert ein, d.h. alles friert ein außerdem textedit, dafür sehen die scrollbars vom textedit sehen aus wie ein bildstörung im fernsehen...
das programm stürtzt aber nicht ab, kein segfault oder buserror oder so also hilft gdb auch nciht weiter. auf der konsole krieg ich dafür ein
xlib: unexpected async reply (sequence 0xdd9d1)!
uns SEHR viele:
QPixmap::operator=: Cannot assign to pixmap during painting
also bin ich davon ausgegangen dass das widget einfach zu oft neugezeichnet wird und hab (da das ganze ja in nem thread abläuft) einfach ein msleep(1000) (1 sekunde) in schleife vor das append gepackt aber es hilft nciht....
hat jemand eine idee?
 
Guten Morgen soul_rebel,

xlib: unexpected async reply (sequence 0xdd9d1)!
Diese Meldung kenne ich von GTK/GDK-Programmen.
Sie bedeutet, dass Du dem Widget "textedit" die Daten zu schnell lieferst, ein anderer Thread die Funktion gerade benutzt oder dass ein Pointer, der von QT an die Xlib weitergegeben wurde nicht mehr gültig ist.
Da ich die QT-Funktionen nicht kenne, versuche ich mittels GTK/GDK-Funktionen zu umschreiben was Du machen mußt.

Im GDK gibt es zwei Funktionen "gdk_threads_enter()" und "gdk_threads_leave()". Diese sollen in einer multithreaded application den Zugriff auf die Xlib steuern. Die beiden Funktionen kontrollieren eine mutex-semaphore.
Die Wirkungsweise ist folgende: sobald ein Widget beschäftigt ist, ist der Zugriff auf die Xlib blockiert (meist nur ein paar Millisekunden). Dadurch wird eine gewisse "Reentranz" erzeugt.

Zu Deinem Problem:
Du mußt also so eine Funktionalität um "m_parent2->tOutput->append(buffer);" herum aufbauen. Ein msleep(bla) bringt garnichts, weil mit ihr der Thread blockiert wird und somit auch das Widget.

Ich hoffe es ist einigermaßen verständlich geworden.

Viele Grüße

Jürgen
 
hm hab das konkrete problem irgendwie gelöst bekommen hab aber unregelmäßig weiter dies fehler auch an anderen stellen bekommen. habe jetzt ein qmutex eingebaut, das ist in qt recht einfach... und einfach ein
Code:
mutex.lock();
codederirgendwasamguimacht();
mutex.unlock();
an allen stellen in threads ingebaut in denen die oberfläche verändert wird. soweit habe ich jetzt keine probleme mehr.
vielen dank!
 
Zurück
Oben