Xerox hat anscheinend bei ein paar Kopierer-Modellen einen unpassenden/schlecht konfigurierten Kompressionsalgorithmus verwendet:
http://www.dkriesel.com/blog/2013/0802_ ... n_scanning
Wenn man Vorlagen als komprimiertes jpg scannt, nimmt der Algorithmus schon mal Bildteile mehrfach her, die grade noch ähnlich genug sind.. so wird aus einer kleinen 6 schon mal ne kleine 8, wenn diese auch im Text vorkommt. Funktioniert für Bilder, bei Text führt das dazu dass im Scan dann Zahlen/Kosten/Größenangaben/.. plötzlich 'Tippfehler' enthalten, ziemlich heftig für nen Bürokopierer. Wär spannend das mal auszuprobieren.
Best of Bugs
-
mastastefant
- Schnapsbar
- Beiträge: 3856
- Registriert: Sa Dez 04, 2004 1:00 pm
- Kontaktdaten:
Best of Bugs
I find your lack of platform support disturbing.
-
mastastefant
- Schnapsbar
- Beiträge: 3856
- Registriert: Sa Dez 04, 2004 1:00 pm
- Kontaktdaten:
Ich find das immer wieder krass, wie hoch da die Auflagen sind wenn man ein Flugzeug baut, was da alles getestet und berücksichtigt wird, dass man dann tatsächlich die Auflagen meist noch um eine 10er-Potenz unterbieten kann bei den Ausfallraten (die Wahrscheinlichkeit für einen Fehler mit möglicherweise katastrophalen Auswirkungen (i.e, Verlust von Menschenleben) in einem Flieger muss bei 10^-9 liegen.. Eine einzelne (!) Lötstelle hat bereits ne Ausfallswahrscheinlichkeit von 10^-6, zum Vergleich eine Glühbirne von 10^-3.. ) .. und an welchen Fehlern es dann am Ende dann wirklich scheitert:
http://www.welt.de/wirtschaft/article11 ... escht.html
Kabel der Löschanlage falschrum angesteckt, die Löschanlage hätte beim Triebwerksbrand das falsche Triebwerk gelöscht.. Macht wahrscheinlich nicht so viel in Wirklichkeit weil die Triebwerke trotz Löschung wohl weiterlaufen können müssen, dann löscht man halt einfach alles, trotzdem ein echter Murphy.
Zu dem Xerox Bug: auf der Xerox Webpage gibts mitterweile auch was, das liest sich ein bissl nach "Uups, da hilft nur wegschmeißen, alles neu machen.. "
http://realbusinessatxerox.blogs.xerox. ... g6kMkBgjNs
Vielleicht erklärt das auch, wo die eine oder andere Million hingekommen ist, oder wieso ein U-Boot am Ende 70t zu schwer ist und nur in eine Richtung funktioniert, oder wieso man einen Wolkenkratzer mit zu kleinen Fahrstuhlschächten baut ..
Auf der anderen Seite ermöglicht das auch ganz neue Verteidigungsmöglichkeiten wenn da wer wegen Bilanzfälschung vorm Richter steht .. "Da muss ihre Kopie falsch sein, bei uns passt das alles.."
Ziemlich arg eigentlich, wie weitreichende Auswirkungen so ein einzelner Bug haben kann ..
http://www.welt.de/wirtschaft/article11 ... escht.html
Kabel der Löschanlage falschrum angesteckt, die Löschanlage hätte beim Triebwerksbrand das falsche Triebwerk gelöscht.. Macht wahrscheinlich nicht so viel in Wirklichkeit weil die Triebwerke trotz Löschung wohl weiterlaufen können müssen, dann löscht man halt einfach alles, trotzdem ein echter Murphy.
Zu dem Xerox Bug: auf der Xerox Webpage gibts mitterweile auch was, das liest sich ein bissl nach "Uups, da hilft nur wegschmeißen, alles neu machen.. "
http://realbusinessatxerox.blogs.xerox. ... g6kMkBgjNs
Vielleicht erklärt das auch, wo die eine oder andere Million hingekommen ist, oder wieso ein U-Boot am Ende 70t zu schwer ist und nur in eine Richtung funktioniert, oder wieso man einen Wolkenkratzer mit zu kleinen Fahrstuhlschächten baut ..
Auf der anderen Seite ermöglicht das auch ganz neue Verteidigungsmöglichkeiten wenn da wer wegen Bilanzfälschung vorm Richter steht .. "Da muss ihre Kopie falsch sein, bei uns passt das alles.."
Ziemlich arg eigentlich, wie weitreichende Auswirkungen so ein einzelner Bug haben kann ..
I find your lack of platform support disturbing.
-
mastastefant
- Schnapsbar
- Beiträge: 3856
- Registriert: Sa Dez 04, 2004 1:00 pm
- Kontaktdaten:
Hier ein klein bissl was für Insider, aber gehört zu meinen All-Time Lieblings-Bugs:
Nicht unbedingt der konkrete Bug selbst, aber einfach diese Kategorie an Bugs: Ich hatte genau so einen Bugfix selbst auch schon mal machen dürfen:
http://sourceware.org/ml/glibc-cvs/2013 ... 00115.html
In meinem Fall war static const int THREE = 2; definiert .. das kommt öfter vor als man denkt, dass Leute Konstanten wie TWO, THREE, .. definieren, und dann auch noch falsch. Weiß der Geier wieso man nur auf so ne Idee kommen kann, solche Leute sollten lebenslanges Programmier-Verbot bekommen.
In der guten alten Zeit habs wenigstens noch richtige Programmiersprachen für Männer wie FORTRAN, dort konnte man (durch einen Compiler-Bug) tatsächlich '4' als '2' definieren, wenn man nicht aufpasst
Dass der Bug in glibc ist, ist dafür ein doppelter Insider, denn glibc-Code ist bekannt dafür, das Tor zur Hölle zu sein, und der Big Boss war bis vor kurzem Ulrich Drepper, bekannt für seine Aussagen ala "meine Unicode Definition ist korrekter als die vom unicode.org Konsortium", oder "Die glibc sourcen kompiliert nicht" "glibc soll man ja auch nicht kompilieren, sondern von der Distribution nehmen", oder "So was funktioniert aber nicht auf ARM" "ARM ist mir egal, kein Mensch verwendet ARM" ..
glibc ist *die* Basis-Bibliothek auf praktisch jedem Linux-PC, auf der *alles* aufbaut, zumindest war sie das bis vor kurzem, bis ein paar Leute beschlossen haben, sie schreiben die gesamte libc einfach neu, zum teil wegen dem furchtbaren Code, größtenteils aber einfach wegen Ulrichs Ego-Problemen (das ist eine riesen-Menge code!), und die ganze restliche Linux-Welt ist fast geschlossen drauf aufgesprungen, aus demselben Grund. Drepper ist jetzt bei Goldmann Sachs.
Dieser Bug hier geht noch mehr in die Tiefe, aber zeigt sehr schön womit man sich rumplagt wenn man an Compilern oder Kernel oder generell größeren, komplexen C/C++ Programmen arbeitet. Die Menge an Zeit die da reingeflossen sein muss um das zu finden macht das zu einem meiner Favorits:
http://lwn.net/Articles/478657/
Wenn man den btrfs Dateisystem (!) Linuxtreiber mit einer bestimmten Version von GCC für eine bestimmte 64bit Architektur übersetzt, dann optimiert der Compiler (formal legal) den Zugriff auf einen Wert in einer Datenstruktur im generierten Assembly so um, dass das danebenliegende Synchronisationsflag zurückgesetzt wird, wenn zeitgleich (!) ein anderer (!) Prozess das Flag setzt.
D.h., der Bug tritt nur auf, wenn man einen bestimmten Prozessor hat, mit einem bestimmten Compiler mit bestimmten Optimierungen übersetzt, und zufällig grad mehrere Prozesse zur gleichen Zeit lesen und schreiben, und alles was man davon beobachtet ist, dass dann irgendwo in einem Experimental-Dateisystem Daten durcheinandergewürfelt werden. Wenn man sich mit dem Debugger reinhängt und durchsteppt, lauft das ganze nicht mehr wirklich gleichzeitig ab und alles funktioniert.. Der C Code schaut absolut korrekt aus, der C Standard lässt aber offen was da passieren kann, damit kann man nicht mal wirklich gut argumentieren, wo jetzt überhaupt der Bug ist.
Ich hatte aber auch schon schon mal z.B. den Fall, dass Parameterübergabe von 64bit Werten funktioniert hat oder nicht, je nachdem ob man vorher eine gerade oder ungerade Anzahl an Variablen in seinem Programm verwendet hat (64bit Variablen zählen doppelt) .. je nachdem wie man seinen Code hinschreibt optimiert der Compiler allerdings ein paar der Variablen weg. Dadurch hat das Testprogramm zB. je nachdem ob man eine IF-Bedingung reinschreibt oder nicht den Wert 6.0 entweder als 6.00000 oder 6.00002 ausgegeben. Schuld war dass eine Compiler-Konfiguration zwar an einer Stelle richtig gesetzt war, für den Code hat er aber ne andere undokumentierte Variable verwendet, die er nicht aus der Konfiguration befüllt sondern die man zusätzlich setzen musste.. Hat mich auch ne gute Woche gekostet
Gut, so was kommt in den besten Familien vor .. Die Ariane 5 hat sich beim ersten Testflug auch selbst gesprengt, weil das Guidance System einen Overflow beim Geschwindigkeitswert hatte. Da wurde nämlich Software von der Ariane 4 wiederverwendet. Die Ariane 5 ist aber schneller.
Nicht unbedingt der konkrete Bug selbst, aber einfach diese Kategorie an Bugs: Ich hatte genau so einen Bugfix selbst auch schon mal machen dürfen:
http://sourceware.org/ml/glibc-cvs/2013 ... 00115.html
(bei einem Diff werden die Zeilen mit '-' am Anfang durch jene mit '+' am Anfang ersetzt ... )Fix the value of TWO
#define MONE -1.0 /* -1 */
-#define TWO -2.0 /* -2 */
+#define TWO 2.0 /* 2 */
#define TWO5 0x1.0p5 /* 2^5 */
In meinem Fall war static const int THREE = 2; definiert .. das kommt öfter vor als man denkt, dass Leute Konstanten wie TWO, THREE, .. definieren, und dann auch noch falsch. Weiß der Geier wieso man nur auf so ne Idee kommen kann, solche Leute sollten lebenslanges Programmier-Verbot bekommen.
In der guten alten Zeit habs wenigstens noch richtige Programmiersprachen für Männer wie FORTRAN, dort konnte man (durch einen Compiler-Bug) tatsächlich '4' als '2' definieren, wenn man nicht aufpasst
Beim Call wird dann i auf '7' gesetzt, und '7' bekommt 3 zugewiesen womit danach alle 7er durch 3er ersetzt werden, und das Programm gibt 'j = 3' aus..subroutine munge (i)
i = 3
return
j = 7
call munge (7)
write (6, 11) j
11 format ('j = ', i6)
Dass der Bug in glibc ist, ist dafür ein doppelter Insider, denn glibc-Code ist bekannt dafür, das Tor zur Hölle zu sein, und der Big Boss war bis vor kurzem Ulrich Drepper, bekannt für seine Aussagen ala "meine Unicode Definition ist korrekter als die vom unicode.org Konsortium", oder "Die glibc sourcen kompiliert nicht" "glibc soll man ja auch nicht kompilieren, sondern von der Distribution nehmen", oder "So was funktioniert aber nicht auf ARM" "ARM ist mir egal, kein Mensch verwendet ARM" ..
glibc ist *die* Basis-Bibliothek auf praktisch jedem Linux-PC, auf der *alles* aufbaut, zumindest war sie das bis vor kurzem, bis ein paar Leute beschlossen haben, sie schreiben die gesamte libc einfach neu, zum teil wegen dem furchtbaren Code, größtenteils aber einfach wegen Ulrichs Ego-Problemen (das ist eine riesen-Menge code!), und die ganze restliche Linux-Welt ist fast geschlossen drauf aufgesprungen, aus demselben Grund. Drepper ist jetzt bei Goldmann Sachs.
Dieser Bug hier geht noch mehr in die Tiefe, aber zeigt sehr schön womit man sich rumplagt wenn man an Compilern oder Kernel oder generell größeren, komplexen C/C++ Programmen arbeitet. Die Menge an Zeit die da reingeflossen sein muss um das zu finden macht das zu einem meiner Favorits:
http://lwn.net/Articles/478657/
Wenn man den btrfs Dateisystem (!) Linuxtreiber mit einer bestimmten Version von GCC für eine bestimmte 64bit Architektur übersetzt, dann optimiert der Compiler (formal legal) den Zugriff auf einen Wert in einer Datenstruktur im generierten Assembly so um, dass das danebenliegende Synchronisationsflag zurückgesetzt wird, wenn zeitgleich (!) ein anderer (!) Prozess das Flag setzt.
D.h., der Bug tritt nur auf, wenn man einen bestimmten Prozessor hat, mit einem bestimmten Compiler mit bestimmten Optimierungen übersetzt, und zufällig grad mehrere Prozesse zur gleichen Zeit lesen und schreiben, und alles was man davon beobachtet ist, dass dann irgendwo in einem Experimental-Dateisystem Daten durcheinandergewürfelt werden. Wenn man sich mit dem Debugger reinhängt und durchsteppt, lauft das ganze nicht mehr wirklich gleichzeitig ab und alles funktioniert.. Der C Code schaut absolut korrekt aus, der C Standard lässt aber offen was da passieren kann, damit kann man nicht mal wirklich gut argumentieren, wo jetzt überhaupt der Bug ist.
Ich hatte aber auch schon schon mal z.B. den Fall, dass Parameterübergabe von 64bit Werten funktioniert hat oder nicht, je nachdem ob man vorher eine gerade oder ungerade Anzahl an Variablen in seinem Programm verwendet hat (64bit Variablen zählen doppelt) .. je nachdem wie man seinen Code hinschreibt optimiert der Compiler allerdings ein paar der Variablen weg. Dadurch hat das Testprogramm zB. je nachdem ob man eine IF-Bedingung reinschreibt oder nicht den Wert 6.0 entweder als 6.00000 oder 6.00002 ausgegeben. Schuld war dass eine Compiler-Konfiguration zwar an einer Stelle richtig gesetzt war, für den Code hat er aber ne andere undokumentierte Variable verwendet, die er nicht aus der Konfiguration befüllt sondern die man zusätzlich setzen musste.. Hat mich auch ne gute Woche gekostet
Gut, so was kommt in den besten Familien vor .. Die Ariane 5 hat sich beim ersten Testflug auch selbst gesprengt, weil das Guidance System einen Overflow beim Geschwindigkeitswert hatte. Da wurde nämlich Software von der Ariane 4 wiederverwendet. Die Ariane 5 ist aber schneller.
I find your lack of platform support disturbing.