Begriff
Bug (Softwarefehler)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Ein Bug ist ein Fehler im Programmcode. Das Programm tut etwas, das es nicht soll (stürzt ab, berechnet 1+1=3). Der Name kommt angeblich von einer echten Motte, die 1947 in einen riesigen Computer (Mark II) flog und einen Kurzschluss verursachte. Grace Hopper klebte die Motte ins Logbuch: "First actual case of bug being found."
Merksatz: Ein Fehler in einer Software, der zu unerwartetem Verhalten oder Abstürzen führt.
Es gibt keine fehlerfreie Software. Windows hat Bugs. Dein Handy hat Bugs. Entwickler verbringen 50% ihrer Zeit mit Debugging (Käfer jagen). Wenn du einen Bug findest, melde ihn ("Bug Report"). Wichtig dabei: Reproduzierbarkeit. "Es geht nicht" hilft niemandem. "Wenn ich erst A und dann B klicke, passiert C" – das hilft.
1. Arten von Bugs
- Syntax-Fehler: Tippfehler im Code (Semikolon vergessen). Das Programm startet gar nicht erst. (Leicht zu finden).
- Logik-Fehler: Das Programm läuft, rechnet aber falsch. (Schwer zu finden).
- Race Condition: Passiert nur, wenn zwei Dinge exakt gleichzeitig passieren. (Extrem schwer zu finden, oft "Heisenbug" genannt – verschwindet, wenn man hinschaut).
2. Feature vs. Bug
Der Running Gag der IT: "It's not a bug, it's a feature." Manchmal wird seltsames Verhalten im Nachhinein als "gewollt" verkauft. Oder Nutzer gewöhnen sich an einen Bug (z. B. "Strafe-Jump" in Quake) und er wird zur Spielmechanik.
1. Stack Traces und Core Dumps
Wenn es knallt, hinterlässt das Programm meistens Müll. Entwickler untersuchen diesen Müll.
- Stack Trace: Eine Rückverfolgung. Man sieht die Kette der Funktionsaufrufe, die zum Absturz geführt hat. (
main()riefcalculate()auf, diese riefdivide()auf, und dort gab es die Division durch Null). - Core Dump: Ein komplettes Abbild des Arbeitsspeichers (RAM) im Exact-Moment des Absturzes. Entwickler können diesen Dump später in einem Debugger (wie
gdb) öffnen und die Werte aller Variablen überprüfen, als wäre die Zeit stehengeblieben.
2. Speicherlecks (Memory Leaks)
Wenn ein Programm in C oder C++ gecodet ist, muss der Entwickler manuell Speicher reservieren (malloc()) und wieder freigeben (free()).
Vergisst er das free(), bleibt der Speicher reserviert, auch wenn er nicht mehr genutzt wird. Das Programm frisst über Stunden oder Tage immer mehr RAM, bis das Betriebssystem (OS) es aus Notwehr tötet (OOM - Out of Memory Killer).
Sprachen wie Java oder C# nutzen einen Garbage Collector, der automatisch aufräumt, was diesen Bug seltener macht.
3. CI/CD und Regression Testing
Um zu verhindern, dass ein Bug-Fix einen alten Bug wieder einbaut ("Regression"), nutzen moderne Teams CI/CD-Pipelines (Continuous Integration). Sobald ein Entwickler Code pusht, feuert ein Git-Hook, und ein Server führt Tausende automatisierte Unit Tests aus:
jobs:
test:
runs-on: ubuntu-latest
steps:
- run: npm install
- run: npm run test # Bricht ab, wenn hier ein Fehler auftritt!
Erst wenn alle roten Ampeln auf Grün springen, darf der Code in die Produktion.
Quick-Check
Was ist ein "Patch"?
Ein Pflaster. Ein kleines Software-Update, das einen Bug repariert ("Hotfix").Was ist ein "Zero-Day-Exploit"?
Ein Bug, den Hacker gefunden haben, bevor der Hersteller ihn kennt (0 Tage Zeit zum Fixen). Extrem gefährlich, weil es keinen Schutz gibt, bis der Patch kommt.Warum testen Entwickler nicht besser?
Software ist unfassbar komplex. Millionen Zeilen Code. Milliarden mögliche Zustände. Man kann unmöglich alle Kombinationen testen. Nutzer finden immer Wege, die Software so zu nutzen, wie niemand gedacht hat.