Ein Build stirbt mit Exit 137. Kein Compile-Fehler, keine Meldung, kein Hinweis — der Prozess ist einfach weg. Wer das zum ersten Mal sieht, sucht im Code. Der Code ist aber in Ordnung: Das Betriebssystem hat den Build abgeschossen, weil der Speicher ausging.
Ein großer Teil unserer Arbeit entsteht auf einem MacBook Air M2 mit 8 GB RAM. Verlötet, nicht aufrüstbar. Das ist für Kotlin-Multiplatform-Builds knapp bemessen — und genau deshalb haben wir gelernt, wo der Speicher wirklich hingeht.
Warum 8 GB schneller voll sind, als man denkt
Eine Messung im Alltag, ohne dass irgendetwas „aufgeräumt" werden müsste:
- macOS-Kernel: rund 2,5 GB
- Browser mit den offenen Tabs: rund 1,5 GB
- Entwicklungswerkzeuge: rund 1,9 GB
Macht etwa 6 von 8 GB — für drei Dinge, die einfach nur laufen. Startet jetzt Xcode oder Android Studio (2 bis 4 GB), ist der Speicher voll. macOS lagert auf die SSD aus, und das System fängt an zu stocken.
Der wichtigste Punkt daran: Das ist kein Verschmutzungsproblem. Es hilft nicht, Caches zu löschen oder Programme zu deinstallieren. Es ist ein physikalisches Limit.
Erst messen, dann handeln
Bei „der Mac hängt" ist der erste Reflex, wahllos Prozesse zu beenden. Besser sind zwei Befehle, die in einer Sekunde sagen, ob wirklich der Speicher das Problem ist:
# Speicherdruck: 1 = ok, 2 = Warnung, 4 = kritisch
sysctl -n kern.memorystatus_vm_pressure_level
# Wie viel wird bereits auf die SSD ausgelagert?
sysctl vm.swapusageSteht der Druck auf 1 und der Swap ist klein, liegt das Problem woanders — dann spart man sich die Suche in die falsche Richtung.
Der größte einzelne Hebel: der Gradle-Daemon
Ein iOS-Build eines Kotlin-Multiplatform-Projekts starb reproduzierbar mitExit 137. Im Log: nichts. Kein Fehler, nur Abbruch.
Die Ursache lief im Hintergrund und tat nichts:
- Der Gradle-Daemon hielt rund 730 MB belegt — er idlete seit einem früheren Build.
- Die Simulator-Dienste liefen ebenfalls noch — obwohl der Build aufs echte Gerät ging und den Simulator gar nicht brauchte.
Zwei Zeilen davor:
xcrun simctl shutdown all; killall Simulator 2>/dev/null
./gradlew --stopDas Ergebnis war messbar: freier Speicher von 110 MB auf 1.726 MB. Danach lief derselbe Build sauber durch. Kein Codeeingriff, keine Konfiguration — nur zwei idlende Prozesse beendet.
Die Falle, die uns am meisten gekostet hat
Um visuelle Änderungen zu prüfen, lag es nahe, per Headless-Browser Screenshots zu schießen. Auf 8 GB ist das eine Sackgasse — aus drei Gründen gleichzeitig:
- Jeder Lauf startet ein vollständiges Chromium. Auf knappem Speicher schlägt bald jeder Lauf fehl.
- Bricht ein Lauf per Timeout ab, bleibt die Instanz als verwaister Prozess hängen. Nach ein paar Durchgängen stapeln sie sich — und die folgenden Läufe scheitern still. Das sieht aus wie ein Code-Bug, ist aber Speichermangel.
- Headless-Rendering nutzt Software-Rasterisierung. Das Ergebnis sieht schlechter aus als auf einer echten Grafikkarte — der Screenshot ist also nicht mal aussagekräftig.
Ein einzelner Screenshot als Beleg ist in Ordnung. Sobald daraus eine Schleife wird, prüft man nicht mehr — man verbrennt Ressourcen und bekommt trotzdem kein verlässliches Bild.
Die Alternative ist unspektakulär und funktioniert: einen leichten Webserver starten und im echten Browser draufschauen. Kostet fast keinen Speicher, nutzt die echte Grafikkarte, zeigt die Wahrheit.
Was davon für Ihr Projekt zählt
Nicht die Befehle — die sind projektspezifisch. Sondern das Prinzip dahinter:
Ein Build, der ohne Fehlermeldung stirbt, hat selten ein Code-Problem.Exit 137 heißt: Das Betriebssystem hat eingegriffen. Wer das nicht weiß, sucht stundenlang an der falschen Stelle. Wer es weiß, misst zuerst den Speicherdruck und schaut, was im Hintergrund idlet.
Und der zweite Punkt: Beschränkte Hardware ist ein guter Lehrmeister. Wer auf 8 GB entwickelt, lernt zwangsläufig, wo Ressourcen wirklich hingehen — statt es der Maschine zu überlassen.