GNU des tages

WARNING, CLUSTERFUCK AHEAD!

Programmiert hier jemand in C++ und benutzt die libstdc++ von GNU und hat komische speicherlecks? Oder benutzt hier jemand einen modernen desktop und wundert sich, dass das dingens immer langsamer und plattenkratziger wird, wenn man es mal ein paar tage laufen lässt? Oder verwendet hier jemand eine in C++ geschriebene anwendung mit ganz großem speicherhunger?

The GNU C++ Library is Broken

Es ist etwas länger, aber die lektüre lohnt sich… auch, weil jeder mal bemerken kann, wie viel kopfschmerz so eine scheiße verursachen kann. Das beschriebene problem mit dem speicherleck in der libstdc++ dürfte (in geringerem maße) beinahe jeden menschen betreffen, der eine gegen die GNU-biblioteken gelinkte, in C++ geschriebene softwäjhr verwendet.

Via Fefe

Advertisements

7 Antworten zu “GNU des tages

  1. Die Idee, einmal benötigten Speicher nicht mehr zurückzugeben, gibt es als Altlast noch in mehreren Projekten. Als möglichen Allokator in der FEM-Bibliothek Deal.ii etwa, aber da war das nicht die Voreinstellung, es gab Alternativen, und alles war gut dokumentiert.

    Wenn die Funktionalität sozusagen im Zentrum aller Aktivitäten des Programms steht, kann man das machen. Denn dann braucht man den Speicher wirklich erst dann nicht mehr, wenn das Programm endet.

    Ein problematisches Exemplar dieser Gattung ist die Langzahlarithmetik-Bibliothek GMP. Problematisch, weil die Bibliothek auch in Universalprogrammen wie Ruby verwendet wird. Dort kann man nicht davon ausgehen, dass, sagen wir, 3GB für irgendeine geschickt verursachte Zwischenrechnung jemals wieder für weitere Rechnungen benötigt werden. Die 3GB fehlen dann aber an anderer Stelle.

    GMP wird auch verwendet in GNUTLS. Aber da hält sich der Speicherbedarf wegen der Zweckbeschränkung in Grenzen. 4096 Bit sind nicht wirklich viel, und die Anwendung verlangt nicht mehr.

    Das Problem mit raffgierigen Messie-Allokatoren wird verschärft dadurch, dass Prozess-Forks in Servern heutzutage als uncool gelten und jeder Entwickler sich stattdessen an Threads versucht. Viele kurzlebige Threads können tatsächlich enorme Durchsatzsteigerungen bringen. Aber wenn der Speicherhunger einzelner Threads einen unauslöschbaren Abdruck hinterlässt, ist das ganze Konzept wieder hinfällig.

    Und genau in diese Kerbe schlägt jetzt der mt_allocator hinein. „Ja, wir wollen viele kurzlebige Threads! Denn Forks sind ja blöd! Aber wir tun so, als wären es Forks, für unsere Ausrede: Der Speicher wird bei Prozessende sowieso zurück gegeben.“ Tja, die Threads laufen aber in einem langlebigen Prozess.

    Gratuliere, GCC. Die Trends der Zeit richtig erkannt und gleich substanziell behindert. Mit einem egomanischen Allokator-Verhalten, das allgemein als problematisch bekannt ist.

    Eigentlich hätten die Leute wissen müssen, was sie da tun.

    • Ich phantasiere mir gerade eine Vorstellung davon zusammen, wie das gelaufen sein könnte.

      Neuer Entwickler steht vor seinem Initiationsritual: Einmal GCC oder libgcc besudeln.

      Er versucht sich an einem Pool-basierten Allokator für eine Multi-Threading-Umgebung.

      Stellt fest, dass seine Pools eigentlich zu groß sind, denn bei echten Projekten gibt es Fragmentierung, die zur Folge hat, dass die meisten Pools nicht mehr freigegeben werden können.

      Eigentlich bräuchte er eine bessere Heuristik für die Allokation innerhalb der Pools. Die gibt es auch schon, in über Jahrzehnte entwickelten Allokatoren. Aber der Entwickler will ja was Dolles, Neues, Schnelles.

      Man könnte das Problem reduzieren, aber nicht beseitigen, indem man die Pools kleiner macht. Das würde das Leaking verlangsamen.
      Aber kleinere Pools sehen nicht so performant aus.

      Also, was tut der Entwickler?

      Er macht die Not zur Tugend! Er versucht gar nicht erst, den Speicher wieder freizugeben. Und schreibt das auch in Doku. (Darauf bestehen die GCC-Leute, sonst hätte er das wohl gerne unterlassen.)

      Wenn der Versuch nicht gemacht wird, fällt auch dessen Scheitern nicht auf. So hofft er.

      Die Benchmarks überzeugen, sein Kode wird angenommen. Und weil GCC ja schon aus Tradition alle Benutzer als Betatester ansieht, wird der neue Allokator zum standardmäßig verwendeten Allokator geadelt.

      Dass es eben doch auffällt, wenn Speicher nicht wiederverwendet werden kann, ist nun halt dumm gelaufen.

  2. Wieso benutzt 2017 noch irgendwer GNU-Scheiße zum Programmieren? Meine Fresse. Wie viel kann eine Infrastruktur upfucken, bevor es den Leuten reicht?

    • Mehr Architekturen. Auf meinem privaten PPC64-Mac sind neuere LLVM-Versionen nicht zum Laufen zu bringen.

      Was nicht heißen soll, dass die ABI-Änderungen der libstdc++ unproblematisch wären. Aber so habe ich wenigstens Unterstützung für C++11 ff.

      • Erfrischend finde ich, dass der Microsoftcompiler C++11 und C++17 schon herausragend unterstützt.

        PPC64? Eigentlich sollte LLVM da dank NetBSD gut funktionieren…?

        • Aber nicht unter Darwin / MacOS X. Das läuft auf dem alten G5 immer noch. Denn auf ordentlich gerenderte Fonts will ich nicht mehr verzichten. Server ohne Desktop betreibe ich natürlich unixoid.

  3. Es gibt ein Update. mt_allocator werde nicht mehr standardmäßig verwendet (dann ist die Doku veraltet).

    Der Entwickler ist nun verwirrt, weil GLIBCXX_FORCE_NEW das Problem behebt, obwohl er in keiner Bibliothek den String GLIBCXX_FORCE_NEW gefunden hat.

    Gefunden! Er möge in /usr/include/c++ suchen:

    $ grep -rl GLIBC.._FORCE_NEW /usr/include/
    /usr/include/c++/4.8.2/ext/pool_allocator.h
    /usr/include/c++/4.8.2/ext/mt_allocator.h
    

    Da ist Template-Code, der die Umgebungsvariable abfragt.
    Und wenn es nicht der mt_allocator ist, dann ist es eben der pool_allocator, der Probleme macht.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s