← Neueste Arbeiten
💻 computer science

Where did we fail? -- Reproducing build failures in embedded open source software

Dieser Beitrag stellt PhantomRun vor, eine vereinheitlichte Abstraktionsschicht und ein Datensatz, die die Extraktion und getreue Reproduktion von CI-Build-Protokollen und Metadaten für eingebettete Open-Source-Software standardisieren und damit groß angelegte, reproduzierbare Studien historischer Build-Fehler mit hoher Rekonstruktionsgenauigkeit ermöglichen.

Ursprüngliche Autoren: Han Fu, Andreas Ermedahl, Sigrid Eldh, Kristian Wiklund, Philipp Haller, Cyrille Artho

Veröffentlicht 2026-05-01
📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

Ursprüngliche Autoren: Han Fu, Andreas Ermedahl, Sigrid Eldh, Kristian Wiklund, Philipp Haller, Cyrille Artho

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie sind ein Detektiv, der versucht, ein Geheimnis zu lösen, das letztes Jahr in einer Fabrik geschehen ist. Die Fabrik stellt komplexe Gadgets (eingebettete Software) her, die Hardware und Code kombinieren. Jedes Mal, wenn ein neues Gadget-Design getestet wird, betreibt die Fabrik eine riesige, automatisierte Montagelinie (Continuous Integration, oder CI). Manchmal bricht die Montagelinie zusammen, und die Maschine stoppt mit einer Fehlermeldung.

Das Problem? Die Fabrik ist chaotisch. Sie verwendet verschiedene Werkzeuge, verschiedene Roboter und verschiedene Baupläne für jeden einzelnen Test. Wenn ein Test fehlschlägt, druckt die Maschine einen langen, unordentlichen Kassenbon (das Build-Log), der erklärt, warum er fehlschlug. Aber hier liegt der Haken: Diese Bons werden nach wenigen Tagen weggeworfen, und der spezifische Roboter, der sie gedruckt hat, existiert möglicherweise gar nicht mehr. Wenn Sie untersuchen wollen, warum die Maschine vor sechs Monaten kaputtgegangen ist, können Sie nicht einfach den Kassenbon ansehen; Sie müssen versuchen, exakt dieselbe Fabrikeinrichtung wiederherzustellen, um zu sehen, ob sie erneut ausfällt.

Genau dieses Problem adressiert die Arbeit „Where did we fail?" („Wo sind wir gescheitert?"). Die Autoren haben ein Werkzeug namens PhantomRun entwickelt, um dies zu lösen.

Das Problem: Die „Geister"-Fabrik

In der Welt der eingebetteten Software (wie dem Code in Ihrem Auto, Thermostat oder medizinischen Gerät) ist das Erstellen der Software wie der Versuch, einen Kuchen in einer Küche zu backen, die sich bei jedem Betreten in ihrer Anordnung verändert.

  • Die Zutaten ändern sich: Die Werkzeuge (Compiler) und Teile (Abhängigkeiten) aktualisieren sich ständig.
  • Die Küche ändert sich: Die Fabrik verwendet für jeden Test verschiedene Roboter (Runner) und Baupläne (Konfigurationen).
  • Die Beweise verschwinden: Wenn ein Test fehlschlägt, ist das Fehlerprotokoll wie ein Kassenbon, der nach einer Woche zerkleinert wird.

Aus diesem Grund können Entwickler, die einen vergangenen Fehler untersuchen wollen, um zu verstehen, wie er zu beheben ist, dies oft nicht tun. Die „Küche", die sie nachbauen müssten, existiert nicht mehr.

Die Lösung: PhantomRun (Der „Zeitreisende"-Bauplan)

Die Autoren haben PhantomRun entwickelt, das wie ein magischer, standardisierter Bauplan für diese chaotischen Fabriken funktioniert. Anstatt zu versuchen, den ursprünglichen, unordentlichen Roboter zu finden, baut PhantomRun eine perfekte, isolierte „Zeitkapsel" (einen Container), die exakt die Bedingungen des ursprünglichen Fehlers nachahmt.

Stellen Sie es sich so vor:

  • Ursprüngliches Szenario: Sie versuchen, ein bestimmtes Gericht eines geschlossenen Restaurants nachzubereiten, kennen aber nicht die exakte Marke des verwendeten Mehls oder die Temperatur des Ofens. Sie raten, und das Gericht schmeckt anders.
  • PhantomRun-Szenario: PhantomRun ist eine Maschine, die den alten Bestellschein des Restaurants scannt, die exakte Mehlfarbe und Ofentemperatur ermittelt und eine temporäre, perfekte Nachbildung dieser Küche in Ihrem Keller erstellt. Anschließend kocht sie das Gericht erneut, um zu sehen, ob es auf exakt dieselbe Weise fehlschlägt.

Was sie taten

Das Team wandte dieses Werkzeug auf vier große Open-Source-Hardware-Projekte an (wie Zephyr und RTEMS, die Betriebssysteme für intelligente Geräte sind). Sie untersuchten über 4.600 fehlgeschlagene Tests aus der Vergangenheit.

Sie stellten zwei Hauptfragen:

  1. Können wir die Fabrik wiederherstellen? (Können wir den Fehler reproduzieren?)
  2. Fällt sie auf dieselbe Weise aus? (Ist der neue Fehler identisch mit dem alten?)

Die Ergebnisse

Die Ergebnisse waren überraschend erfolgreich:

  • 91,8 % Erfolgsquote: Es gelang ihnen, die „Zeitkapsel"-Fabrik erfolgreich wiederherzustellen und den Test für fast 92 % der Fehler erneut auszuführen.
  • 98 % Genauigkeit: Wenn sie es reproduzierten, war das Ergebnis fast immer dasselbe. Wenn der ursprüngliche Test fehlschlug, schlug der neue fehl. Wenn er erfolgreich war, war es der neue auch.
  • Der „Rausch"-Faktor: Die einzigen Unterschiede waren winzige, harmlose Dinge, wie der Zeitstempel im Protokoll oder die Reihenfolge, in der zwei nicht zusammenhängende Schritte stattfanden. Die eigentliche „Fehlermeldung" (der Grund, warum der Kuchen verbrannte) war identisch.

Warum einige scheiterten

Die wenigen Male, in denen sie den Fehler nicht reproduzieren konnten (etwa 8 % der Fälle), lag es nicht daran, dass ihr Werkzeug schlecht war. Es lag daran, dass die „Zutaten" für immer verschwunden waren.

  • Fehlende Hardware: Einige Tests benötigten einen spezifischen physischen Chip oder eine Platine, die es nicht mehr gibt.
  • Verlorene Werkzeuge: Einige Softwarewerkzeuge, die zum Erstellen des Codes verwendet wurden, wurden aus dem Internet gelöscht oder so stark aktualisiert, dass sie inkompatibel wurden.
  • Geheime Zutat: Einige Projekte verwendeten private, proprietäre Werkzeuge, auf die die Forscher keinen Zugriff hatten.

Die große Erkenntnis

Die Arbeit kommt zu dem Schluss, dass wir diese flüchtigen, unordentlichen Fehlerprotokolle in dauerhafte, zuverlässige Forschungswerkzeuge verwandeln können. Durch die Verwendung von PhantomRun können Entwickler und Forscher nun auf historische Fehler zurückblicken, sie in einer kontrollierten Umgebung untersuchen und daraus lernen, ohne die ursprüngliche, chaotische Fabrikeinrichtung zu benötigen.

Kurz gesagt: PhantomRun verwandelt „Ups, das Protokoll ist weg" in „Lass uns den exakten Moment, in dem es kaputtging, wiederherstellen und untersuchen." Dies hilft uns zu verstehen, warum unsere intelligenten Geräte versagen und wie wir sie in Zukunft zuverlässiger machen können.

Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?

Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.

Digest testen →