Austronaut schrieb:
Mein Vorschlag wäre es dort direkt den Assembler Code springen zu können und Schritt für Schritt weiter zu Debuggen.
Nur liegt der Kernel bzw. Module in der Regel nicht als menschlich lesbares Assembly vor, sondern als Binärcode. Um da ins Assembly zu springen, müsste also ein Decompiler auf die Speicherbereiche springen, wo der Fehler festgestellt wurde und nach Möglichkeit auch weiträumig auf die Speicherbereiche, die berührt worden, bevor der Fehler festgestellt wurde. Wobei der Decompiler natürlich Speicher benötigt und bei der Allokation entsprechende alte Speicherbereiche nicht berühren dürfte.
Ganz abgesehen davon, dass das System nach einem Kernelpanic noch so stabil sein müsste, dass Decompiler überhaupt noch sicher laufen.
TLDR: Ein unmöglicher Wunsch, der althergebrachte Dump vom Speicher bei Kernelpanic, sodass man im Nachhinein den Speicher auswerten kann ist deutlich sinnvoller.
GrumpyCat schrieb:
Sind die Fehlermeldungen dann auch brauchbar? Das ist ja beim BSOD unter Windows eher das Problem, dass MS an der Stelle aber auch keine Sekunde Arbeit reingesteckt hat. Wenn ein einziger fähiger Programmierer mal einen Tag Arbeit für eine bessere Fehlermeldung z.B. beim nervigen IRQL NOT LESS OR EQUAL investiert hätte, wären vermutlich Jahrzehnte Nerven bei den Anwendern verschont worden... ganz zu schweigen von den völlig unsinnigen Fehlercodes (à la "Fehlercode 0000000000002 aufgetreten" nach Windows-Update, und das ist dann nach Nachschauen im Netz "File not found", ja prima!).
Der Puritaner schrieb:
Bei Windows könnte auch einfach nur "Ops jetzt ist was schiefgelaufen, setzen sie sich hin und genießen sie den Tag", stehen.
Ob da nun ein QCR Code steht oder nicht, ist völlig egal, wenn am Ende in der Fehlerbeschreibung nichts Sinnvolles dabei herumkommt.
Ich hoffe, bei Linux wird das etwas anders.
Eternal schrieb:
"Ein unbekannter Fehler ist aufgetreten" Oder so ähnlich, ja die BS Fehler sind wirklich immer extrem Hilfreich unter Windows
Die Fehlermeldungen werden oftmals absolut technischer Natur sein und nahezu unverständlich, Linux hat da die selben Probleme wie die Kernelentwickler·innen von Windows. Zum einen ist nicht sichergestellt, dass Fehler an der Stelle gefangen werden, wo sie auftreten und auf der anderen Seite ist das Fangen von Fehlern gar nicht so simpel. Der Standard ist da in etwa so:
Code:
switch: function(foo, bar, baz)
case 0: break;
case 1: fprintf(stderr, "could not write to: %s", foo); mitigation(); break;
default: fprintf(stderr, "failure calling function(foo, bar, baz), nobody knows why"); kernelpanic(); break;
Also auf gut Deutsch, wenn function() aufgerufen wird, wird davon ausgegangen, dass etwas schief gegangen ist. Der Erfolg von function() wird explizit behandelt, bekannte Fehlerfälle werden behandelt und nach Möglichkeit in ihrer Auswirkung negiert. Gerade wenn der Kernel auf gut funktionierende Firmware, externe Treiber/Module angewiesen ist, ist es fast unmöglich, dass "default" nicht gelegentlich getroffen wird.
Fies sind dann auch die Fälle, wo ranzige Firmware, Module zwar Erfolg vermelden (also return(0)), aber eigentlich scheiße gebaut haben. Dann fällt der Fehler oftmals gar nicht auf oder halt VIEL später. Eben weil bei der späteren Fehlerbehandlung auch der "default" getroffen wurde, aber die Entwickler von diesem Code gar keine Chance haben festzustellen, wieso der Input für ihre Funktionen so kaputt ist.
Naja und all zu dicht ist die Fehlerbehandlung im Code von Programmen und Kernel meist nicht. Dichte und erschöpfende Fehlerbehandlung frisst sehr viele Prozessorzyklen und ist enorm aufwendig beim Programmieren, Testen und Dokumentieren. Da ist ganz fix ein Faktor 10 beim Aufwand vorhanden, ohne dass es im Regelfall einen Mehrwert bietet, denn normalerweise sollte Hardware, Kernel und Module gescheit funktionieren. Wobei ja durchaus bekannt ist, dass dem nicht so ist und daher größere Treiber in den Userspace verbannt werden, damit man sie abschießen kann, wenn sie sich nicht benehmen können. Das kostet auch Performance, aber es ist weniger Schlimm. Microsoft hat das mit dem NT-Kernel ja auch durchgesetzt, dass die reudigen GPU Treiber als Hauptquelle von BSODs in den Userspace verbannt wurden.
foofoobar schrieb:
[...]
RAM-Fehler ohne ECC im laufenden Betrieb erkennen? Wie stellst du dir das den vor?
Ein entsprechendes Verfahren wäre wohl ein Kandidat für den Turing-Award.
Das ginge schon, man könnte Parity auch in normalem Speicher vorhalten und bei jedem Speicherzugriff einen Softwarelayer zwischenschalten, der fröhlich prüft. Das hätte aber "kleinere" Auswirkungen auf die Performance.
Oder wie bei GPUs, da können die Memorycontroller auch ECC und Allokieren dafür "einfach" ein neuntel des verbauten Speichers und benötigen entsprechend auch ein neuntel der Speicherbandbreite.
SavageSkull schrieb:
Ich finde es gut. Mein Problem mit Linux sieht so aus, dass ich das Terminal melde und bei Problemen ohne Fehlermeldung da zu stehen.
Nicht das ich regelmäßig Bluescreens hätte.
Es gibt Logviewer auch als GUI-Anwendung. Dürfte bei den meisten grafischen Desktopumgebungen ab Werk vorhanden sein.
