Hallo Halim, On Sat, Aug 09, 2008 at 10:01:16AM +0200, Halim Sahin wrote:
Hi, On Do, Aug 07, 2008 at 07:39:17 +0200, Klaus Knopper wrote:
Das Aussteigen von sbl hatte schon seinen sinn. Du hast die Fehlerbehandlung durch deine patches entfernt. Falls jetzt der speechd server aus irgendeinem grund abstürzt wird in deiner Version sbl mit abstürzen.
Ne, wird er nicht, er bekommt lediglich ein signal, was er ignoriert.
Signale die auf ein Problem hindeuten sollte man eigentlidch nicht ignorieren.
Macht sbl aber.
Ich habe hier das kleinere Übel gewählt. Im Original war die Sprachausgabe nach jedem Drücken einer cursorrouting-Taste an der Braillewave 40 einfach TOT, weil der sbl Müll an speechd geschickt hat, und der mit einer Fehlermeldung - nicht jedoch Disconnect von sich aus - quittiert hat. In der aktuellen version läuft alles stabil.
Nun, außer Dir hat das problem keiner. Nur wundert mich das echt wie du das hinkriegst.
Das ist kontraproduktiv. Das Problem mit dem Buffer Overflow in variolow.c hat auch "niemand" bemerkt, trotzdem war es da und wurde repariert. Weil offenbar keiner der sbl.betatester außer uns eine HT Braillewave 40 hat, die auch tatsächlich über Bluetooth angeschlossen ist, existiert das Problem bei mindestens diesem Modell trotzdem, und ich KANN es nicht ignorieren, weil wir sonst keinen funtionierenden Screenreader haben bzw. sbl nicht hätten einsetzen können.
Was für ein System hast du derzeit?
Debian etch, sbl 3.3.0 (mit dem Patch), Handytech Braillewave 40 mit Buetooth-Anbindung, speech-dispatcher aus dem SVN (auf deine Anregung hin, der "alte" aus testing hatte aber ds gleiche Problem), Rechner ist ein ASUS M2400, Problem tritt aber genauso auf anderen Notebooks auf (z.B. eeePC).
Ist dein problem auf der letzten knoppix reproduzierbar?
Nein, da ist noch das alte SBL mit dem Kernel-Sniffer-Patch drauf, der zwar nichts mit dem Sterben der Sprachausgabe beim Drücken einer Cursorrouting-Taste zu tun hat, aber bei diesem SBL klappte noch alles (Letzte 2-er Version).
Das aussteigen geschah um eventuelle speechd probleme zu umschiffen.
Das Problem ist im Moment bei sbl schlimmer als beim speechd.
Hmm seh ich anders!
Vom Anwender her gedacht ist es besser, eine Sprachausgabe mit Workaround zu haben, als gar keine. Der Fehler ist definitiv an SBL, ich seh ja im Log vom speechd, was der geschickt bekommt (hatte ich dir geschickt).
Ein Kompromiss könnte sein die Returncodes richtig auszuwerten, so dass man zwischen beendetem speechd (hatte ich seit der Umstellung auf OSS-Ausgabe nicht mehr) und von SBL provozierten Fehlern unterscheiden kann.
Afaik gibts keine Unterscheidungsmöglichkeit. Zumindest ist mir keine Möglichkeit bekannt.
Welchen Returncode haben denn die Library-Funktionen vom speech-dispatcher, wenn er ein "illegal command" meldet (der sbl-Bug), und welchen, wenn gar keiner läuft?
Zudem ist die Verwendung von oss ein nicht tragbares problem.
Also wieder auf ALSA gehen und einfah damit leben, das man alle 5 Minuten rebooten oder den speechd neustarten muss? Sorry, das ist nicht für Anwender akzeptabel, die keine Entwickler sind.
Dies führt bei den meisten soundkarten ohne softmixing zu problemen.
Weiß ich, in dem Fall habe ich aber lieber die Sprachausgabe als Musik. Dass der Bug weit nem halben Jahr bekannt ist, hilft nicht, solange ihn niemand behebt.
Warum auf deinem system so komische effekte auftreten ist mir schleierhaft.
Es ist aber absolut reproduzierbar, ich habe dir ja das Log geschickt.
Jops, ich habs gesehen.
Das Problem mit speech-dispatcher und Alsa hat im Moment JEDER Debian/etch-Anwender. Nur wissen es die wenigsten, warum sich der speech-dispatcher manchmal weghängt.
Das komische ist nur, ich rbeite täglich mit dem System und hab so was nicht.
Du bist Poweruser, der mal eben schnell die Sprachausgabe neustarten kann, hast eine andere Braillezeile, bei der das Problem nicht auftritt, und vermutlich auch eine andere Distribution, bei der der speechd bzw. die alsalib den Bug nicht hat.
Du berichtetest auch von ständigen neu initialisierungen und damit verbundener Ausgabe der copyright messages
Nein, ich habe dir nur ein Log geschickt, in der der speech-dispatcher vom sbl die Copyright-message geschickt bekommt, die eigentich nur am Anfang per puts auf die Konsole kommt, und niemals an anderer Stelle auftreten sollte. Daher vermute ich, dass es ein genereller Bug mit Pointern ist, so ähnlich wie der Overflow in variolow.c, der bisher offenbar auch "bei niemandem aufgetreten ist". Dass er trotzdem existiert hat, wird Du aufgrund des Patches bestätigen können oder?
bei dir auf dem System, was auch keiner auser dir hat.
Villeicht bin ich pingeliger. Bei uns laufen die Rechner immer durch, und werden nicht alle paar Stunden neu gestartet. Da ist es inakzeptabel, wegen Ausfall der Sprachausgabe neu starten zu müssen. Vermutich taucht das Problem auch nur bei bestimmten Braillezeilen auf, da gebe ich dir ja recht (außer dem bekannten ALSA-Bug, den gibt's IMMER in Debian, und noch keinen Bugfix).
Wie gesagt, mich würde interessieren, was da schief geht und die lösung mit einfachem ignorieren von auftretenden Fehlern gefällt mir nicht.
Prima, da sind wir wieder auf der gleichen Wellenlänge. Das problem dabei ist ein Bug, der laut Quelltext so nicht auftreten dürfte. Wie kommt es, dass der Copyright-String an speech-dispatcher gesendet wird? Das KANN eigentlich nur irgend ein blöder Pointer-Fehler sei.
Der Buffer Overflow in variolow.c it wohl auch für jeden nachvollziehbar gewesen, der war's aber nicht alleine. Ich vermute, da ist noch an anderer Stelle was faul, anders kann ich mir die völlig falschen Strings, die an speechd geschickt werden, nicht erklären.
ACK, wundert mich nur, das meine Zeile so ein Problem nicht hat (braillestar 40).
Wie gesat, Du hast ne andere als wir. Bei uns wird beim ERSTEN Druck auf eine Cursorrouting-taste auch der Wert der Taste +2000 übertragen. Beim ZWEITEN Mal hingegen der tatsächliche Wert. Das kommt mir auch komisch vor, ein Modifier wurde nicht gedrückt. Es könnte natürlich auch ein Seiteneffekt vom kbdsniffd sein, denn diesen Fehler gibts erst, seitdem vom Kernel-atch auf kbdsniffd umgestellt wurde. Aber das ist reine Spekulation.
Was mir hingegen schleierhaft ist, ist, warum die Probleme bei euch NICHT auftreten. Das ist ja das Problem. Ich arbeite Teilweise mehrere Stunden am Tag mit dem neusten sbl und speechd. Zudem habe ich eine HT Zeile, die die von Dir beschriebenen Probleme auch haben müsste.
Eigentlich nicht, Du hast ein ganz anderes Modell. Das mag die gleiche lib sein, aber es gehen andere Daten über die Verbindung. Schau doch mal, was für keycodes rüberkommen, wenn Du eine cursorrouting-Taste drückst. Gruß Klaus -- To unsubscribe, e-mail: blinux-de+unsubscribe@opensuse.org For additional commands, e-mail: blinux-de+help@opensuse.org