Vor einiger Zeit ging Final Term durch die Newsseiten. Ein moderner Terminalermulator, der mit modernen Features und Aussehen punkten will, aber noch Alpha-Software ist. Durch Zufall an das Projekt erinnert, prüfte ich vor drei Tagen den aktuellen Stand.
Neu ist, dass sie auf Bountysource Preise fürs Bugfixen verteilen. Sehr sympathisch, der Hauptentwickler verzichtet auf Spenden, das soll nur neuen Entwicklern zugute kommen, die das Projekt brauche. Eine der Bugs ist mir ins Auge gefallen: Segfaults, GTK errors and hangs with NestingContainer. Absurde Abstürze, damit habe ich seit Simdock ein bisschen Erfahrung, daher schien mir der Versuch eines Bugfixes wie ein guter Weg, etwas neues zu lernen.
Tatsächlich ist Final Term derzeit komplett instabil. Einen Tab zu schließen führt zu Absturz oder Freeze. Interessant, denn der in Vala geschriebene Code ist nicht wirklich hässlich, höchstens fehlen ein paar Kommentare und ausgerechnet der NestingContainer ist teilweise eher verkompliziert als elegant.
Etwas Debugging später hatte ich eine Absturzursache gefixt: Das Programm sendet ein kill-Signal an den pty-Prozess und wartete danach nicht. Ich bin mir nicht völlig sicher, warum das zu Problemen führt, ich hatte nur eine Ahnung. Tatsächlich hilft ein Timeout, seitdem können zumindest auf meinem System Tabs ohne Abstürze geschlossen werden.
Freudig sendete ich den Pull-Request, nur um darauf hingewiesen zu werden, dass dies noch lange nicht alles sei: Ein Strg+D führe regelmäßig ebenfalls zu Abstürzen und Freezes, sogar noch häufiger. Und das stimmt, auch bei mir, auch mit meinem Fix. Eine Menge Debugging später fand ich heraus, wo genau er einfriert: Beim Entfernen des Tabs aus dem GTK-Notebook per
notebook.remove_page(notebook.page_num(child));
Er scheint dort aus irgendeinem Grund in eine Race-Condition(?) zu laufen und hängt sich in einem Mutex-Lock fest:
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb7012d4b in pthread_cond_wait@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:187
#2 0xb72648ec in __pthread_cond_wait (cond=0x80db7d0, mutex=0x80da6fc)
at forward.c:149
#3 0xb6a70607 in ?? () from /usr/lib/i386-linux-gnu/libxcb.so.1
#4 0xb6a70a88 in ?? () from /usr/lib/i386-linux-gnu/libxcb.so.1
#5 0xb6a70b2a in xcb_writev () from /usr/lib/i386-linux-gnu/libxcb.so.1
#6 0xb6f0a130 in _XSend () from /usr/lib/i386-linux-gnu/libX11.so.6
#7 0xb6f0a70a in _XReply () from /usr/lib/i386-linux-gnu/libX11.so.6
#8 0xb6f05f5b in XSync () from /usr/lib/i386-linux-gnu/libX11.so.6
#9 0xb774df26 in ?? () from /usr/lib/i386-linux-gnu/libgdk-3.so.0
#10 0xb772a7ae in gdk_display_sync ()
from /usr/lib/i386-linux-gnu/libgdk-3.so.0
Hat jemand den Fehler schonmal gesehen? Ich versuche mich derzeit an Workarounds.
Ein Wort hier zu Vala: Das erscheint mir ziemlich kompliziert. Es ist nett, objektorientiert schreiben zu können, aber wenn am Ende doch auf Speicherverwaltung geschaut werden muss und die zusätzliche Abstraktion vom C-Code eine Hürde beim Bugfixen ist, erscheint mir das ziemlich sinnlos. Ich sehe nicht, wo finalterm einen Fehler gemacht hat, es sollte durch die Verwendung moderner Frameworks nicht so instabil sein, wie es derzeit ist. Vielleicht war GTK/Clutter/Mx/Vala einfach die falsche Wahl.
Finalterm selbst macht einen guten Eindruck. Frühe Alpha-Software zwar, und ich weiß nicht, ob der Ansatz mit seinen Animationen und Menüs etwas für mich ist. Aber ich würde darauf wetten, dass es einen bleibenden Platz in der Linuxwelt bekommen wird, falls es bald genug etwas stabiler und kompletter wird.
Edit: Inzwischen hab ich den Bug meiner Meinung nach gelöst.
