|
|
|
|
|
|
|
Das ist dann aber keine Helizität im Teilchenphysiksinne. Optiker... https://en.wikipedia.org/wiki/Helicity_(particle_physics)
Der Polarisationsvektor ist etwas seeeehr anderes. Und wenn der ein i hat, ist das üblicherweise zirkular polarisiert; mich interessiert eher die linear polarisierte Sache.
Ich kann nur schlecht den Leuten die Little Group um die Ohren hauen, die ist dafür echt denkbar ungeeignet. Wie man dem Wikiartikel entnehmen kann (und bei Vergleich mit Demtröder), herrscht nicht mal Einigkeit, ob die Helizität jetzt normiert auf \pm1 sein soll oder nicht. Großartig.
Aber in jedem Fall hat sie keinen Cosinus, wie es eine nicht-Operatorfassung wie beim Demtröder impliziert.
Therefore, those people who say that they can't jack off to anime must have something wrong with their brains!
|
|
|
|
|
|
|
|
|
|
|
Ja mir war nach deiner ersten Antwort schon klar, dass wir offensichtlich über andere Dinge sprechen 
|
|
|
|
|
|
|
|
|
|
|
Du programmierst Java. Sachen laufen. Der Compiler ist gut. Die JVM ist stabil.
Immer. Der Compiler hat nie Schuld. Die VM schon gar nicht.
Bis der Tag kommt, an dem das nicht mehr stimmt.
Kontext:
Wir haben ziemlich viele Websphere Server die zusammen einen Cluster bilden. Es ist quasi die Cloud aus einer Zeit, als die Cloud noch keine Cloud war, mit OSGI anstatt Containern, VMs anstatt Kubernetes/Docker. Wie das halt so ist. Alle möglichen Server und Services laufen auf verschiedenen Betriebssystemen, was bei den meisten Sachen ziemlich egal ist. Das meiste sind irgendwelche Linuxmaschinen, aber für einige Edgecases haben wir Windows als Host-OS. Alles ist managed und bli und bla. Und alles läuft. Eigentlich immer.
Vor einer Weile crasht ständig einer der Windowsserver. Blöderweise ist das eine der Buildmaschinen mit OS-Spezifischen Features, ergo eher uncool, aber vorerst auch unkritisch. Natürlich doof, dass das ein Nadelör ist, aber das ist nunmal so. Neustart dauert eine Minute, aber die crashs werden immer häufiger (haben wir erst beim Postmortem gemerkt...) und zerstören aktive Pipelines.
Natürlich wurde das nicht wirklich behandelt, ist ja irgendwas von vielem was laufend Eskalationen auslösen könnte. Und plötzlich stirbt. alles. konstant. Wie es so ist, hittet der shit den Fan an einem Freitag Morgen. Aus den normalen Serverlogs geht hervor, das einige Services ziemlich viele Exceptions werfen, was aber so weit okay ist. Sachen gehen halt schief, es sind keine unhandled exceptions und werden halt geloggt. Da auf diesem System alles mögliche deployt ist, wird allen zuständigen erstmal eine PM respektive Mail geschickt, sie sollen sich das mal anschauen und identifizieren ob ihre Software den Server crashen könnte (Chance marginal, aber man weiss ja nie).
Scheisse hittiert den Fan:
Ich bin auf der Liste, und schaue mir das mal an. Es ist eine kleine Java-API die Templatebasiertes HTML rendering für einige UIs liefert. Wird relativ viel verwendet, aber ist keine schwarze Magie und seit zwei Jahren stable. Einige Patches für Libraryupdates, zwei Bugfixes. "Ach, das wird schon nichts sein".
Jeder crash folgt auf calls zu diesem Service. Absolut jeder in der zurückverfolgbaren Historie dieser crashes. Egal ob erfolgreich, handled exception, timeout. Scheissegal. Der letzte call ist immer bei meinem Service. Dieser Moment wo dein Arschloch kalt wird? Das ist genau dieser Moment. Und jetzt fängt die Odyssee überhaupt erst richtig an.
Erster Move ist natürlich ein genereller Rollback der betroffenen Systeme. Relativ schnell haben wir die VM-Konfig isoliert wo der (wahrscheinlich gleiche...) Fehler schon eine Weile auftritt. Die "Maschine" nehmen wir isoliert aus dem Cluster und klonen das Ding um zu testen. In der gesammten Deploymentpipeline tritt der Fehler nirgends auf. Wir haben natürlich für Dev/Test/Staging nur kleine und isolierte Varianten der gesammten Infrastruktur, aber absolut fucking nirgends treten diese Fehler auf.
Ich bastel also erstmal eine docker-compose Umgebung mit, eigentlich, identischer Konfiguration (Anm: das hätte nie funktionieren können, Schuld war nämlich auch der Host...). Gleichzeitig finden wir heraus, wie wir das Problem einigermassen isoliert reproduzieren können (gar nicht mal so einfach, am Ende hilft nur Gattling mit random get/post requests konstant auf die API bis der Fehler auftritt). Nichts crasht. Nicht lokal, nicht auf dev, nicht auf test, nicht auf staging. Aber auf Prod? Genau. Da crasht es. Also erstmal logging auf Debug und nur noch bei Prod testen, da crasht es immerhin. Aus Slack:
"Was sagt das Log?"
"Nichts"
"Wie nichts?"
"Nichts"
"Kein Stacktrace, keine Debugmeldungen?"
"Nada
O...kay? Was sagt das allgemeine Monitoring? Die JVM bleibt stehen. Ein normaler Service, auf einem Appserver, in einer JVM... die es schafft die JVM zum Stillstand zu bringen... Immerhin weiss ich nun, weshalb im Log nichts auftaucht, dafür müsste ja die JVM wenigstens noch ein wenig leben.
Wir deployen eine alte Version, die bestimmt ein Jahr durchgelaufen ist. Nach 2 Minuten -> crash. JVM einfach tot. Es liegt zwar eindeutig an diesem einen Service, aber offenbar unabhängig von der Version, vom Build, alles egal. Absolut ratlos. Als nächstes haben wir dann erstmal crash dumps angeschaltet, visualvm angehängt, alles was uns so spontan in den Sinn gekommen ist zum sehen was abgeht.
Nächster Crash? Dumpfile der jvm hat 0 Byte. Denenene Watman. Also erstmal googeln wie man Dumpfiles für alle Javakomponenten richtig konfiguriert (natürlich mumbo-jumbo sondergleichen). Nächster Crash?
| |
| Code: |
1XHEXCPCODE Windows_ExceptionCode: C0000005
1XHEXCPCODE J9Generic_Signal: 00000004
1XHEXCPCODE ExceptionAddress: 00007FF89FE53C05
1XHEXCPCODE ContextFlags: 0010001F
1XHEXCPCODE Handler1: 00007FF89FE04AF0
1XHEXCPCODE Handler2: 00007FF8CD73CC60
1XHEXCPCODE InaccessibleReadAddress: FFFFFFFFFFFFFFFF NULL
1XHEXCPMODULE Module: D:\IBM\...\j9jit29.dll
|
|
Der jit crasht? Der jit crasht. Warum... crasht der jit? Das ist jetzt der Zeitpunkt wo man aufhört den Service zu debuggen und alles an die VM hängt. Ab hier habe ich etwa so viel Ahnung wie der im All schwebende Hund (guter Junge), und habe auch langsam keine Ahnung mehr was mich erwarten soll. Zu meinem Glück sind stacktraces auf der VM sogar zu entziffern... wenigstens einigermassen. Und so lese ich mir Seitenweise jvm stacktraces durch um irgendwas zu finden, und immer wieder taucht vor einem Crash, aber nicht nur da, folgendes auf:
| |
| Code: |
n18n loadaddr org/modelmapper/internal/bytebuddy/implementation/Implementation[#609 Static] [flags 0x18307 0x0 ] [0x00007FF5F75142B0] bci=[-1,11,-] rc=1 vc=11 vn=- li=- udi=- nc=0
|
|
Gefolgt von einer out-of-memory exception der JVM. Was also genau passiert hier? Die JVM hat verschiedene Optimierungsstufen: cold, warm, hot, veryHot, und zuletzt scorching. Der jitter macht Optimierungen anhand verschiedener Heuristiken, weswegen übrigens die Crashes nicht immer, sondern nur oft, und auch nicht konsistent reproduzierbar auftauchen. Abhängig der Frequenz der Calls, Last auf anderen Komponenten und geopferter Ziegen werden also die Optimierungen schneller und aufwändiger.
Ab optimierung Hot schmiert es den jit samt jvm in der Kombination von Modelmapper und diesem einen Build der JVM, und zwar mit einer out-of-memory Exception. Rekursion im Jitter? Possibly. Also tauschen wir eins nach dem anderen verschiedene Abhängigkeiten und Builds aus: Modelmapper Upgrade? Alles geht. Modelmapper downgrade? Alles geht. JVM austauschen? Alles geht. JVM der gleichen Version aber frischem Build? Alles geht. Crashende Konfiguration auf einem anderen Windows Image? Alles geht. Immerhin sind unsere Builds reproduzierbar "kaputt" mit dieser einer Modelmapperversion auf dieser einen VM Konfiguration, aber alle anderen beweglichen Teile lösen das Problem.
Das, meine Lieben, war der komischste Bug den ich jemals gesehen habe. Und ich erwarte, dass das Ding den obersten Platz für eine ganze Weile halten wird.
TL;DR: Es ist nie die VM, und auch nicht der Compiler. Ausser es ist die VM und der Compiler. Und wenn es das ist, dann ist das Problem garantiert ein Hurensohn. Und garantiert ist Monitoring nie gut genug, logging nur so gut wie die Stabilität deines Systems, und am Ende hat auch sowieso keiner eine Ahnung. Und wie schön wäre es, reproduzierbare Builds und Deployments zu haben.
Wir wissen übrigens bis heute nicht so wirklich woher das Problem kommt. IBM auch nicht. Postmortem dauert seit 2 Monaten, Problem passiert nur mit dieser einen Binarykonfiguration und Kombination. Ob das wiedermal auftaucht? Who knows.
|
|
|
|
|
|
|
|
|
|
|
wenns nicht reproduzierbar ist oder nochmal von alleine kommt ist es irrelevant und wird nicht weiter verfolgt...
|
|
|
|
|
|
|
|
|
|
|
Gibt es eine simplere version von
| |
| Code: |
if (!a && b)
{
return !c;
}
else if (a && !b)
{
return c;
} |
|
?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von wuSel
wenns nicht reproduzierbar ist oder nochmal von alleine kommt ist es irrelevant und wird nicht weiter verfolgt...
| |
Beängstigenderweise lief das über Wochen auf duzenden Maschinen und glücklicherweise nur genau auf dieser einen in der tödlichen Konstellation... Die besten Bugs tauchen halt nur in Prod auf. Und auch da nur wenn sie Lust dazu haben.
|
|
|
|
|
|
|
|
|
|
|
|
ist halt am Ende einfach ein schönes Beispiel dafür, dass du garnicht komplett bugfrei sein kannst - egal wie sehr du testest.
|
|
|
|
|
|
|
|
|
|
|
In C?
| |
| Code: |
return (a ^ b) ? a && c : !c; |
|
ohne es getestet zu haben, und wenn alles bools sind.
Allerding returnd das auch wenn a && b, was in deinem Beispiel nicht abgedeckt ist.
| |
| Code: |
#include <stdio.h>
int one(int a, int b, int c) {
return (a ^ b) ? a && c : !c;
}
int two(int a, int b, int c) {
if (!a && b)
{
return !c;
}
else if (a && !b)
{
return c;
}
}
int main(int argc, char const *argv[])
{
printf("a=%d b=%d %d == %d\n", 1, 0, one(1, 0, 1), two(1,0, 1));
printf("a=%d b=%d %d == %d\n", 0, 1, one(0, 1, 1), two(0,1, 1));
return 0;
} |
|
| |
| Code: |
$ gcc -o a a.c
$ ./a
a=1 b=0 1 == 1
a=0 b=1 0 == 0 |
|
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Oli am 10.09.2019 14:48]
|
|
|
|
|
|
|
|
|
| | Zitat von wuSel
ist halt am Ende einfach ein schönes Beispiel dafür, dass du garnicht komplett bugfrei sein kannst - egal wie sehr du testest.
| |
Und natürlich wenn man kein Windows nutzt.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Murica
Gibt es eine simplere version von
| |
| Code: |
if (!a && b)
{
return !c;
}
else if (a && !b)
{
return c;
} |
|
?
| |
Gegenfrage, warum willst du das simpler schreiben? Meistens führt simpler als so nämlich dazu, dass man es schlechter lesen kann. LoCs sparen um jeden Preis? Bitte nicht...
|
|
|
|
|
|
|
|
|
|
|
|
Danke SBI für diese schöne Geschichte, ich habe viel lachen können, auch wenn ihr wohl eher geweimt habt
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von wuSel
Gegenfrage, warum willst du das simpler schreiben? Meistens führt simpler als so nämlich dazu, dass man es schlechter lesen kann. LoCs sparen um jeden Preis? Bitte nicht...
| |
Frage für einen Freund.
Danke Oli 
Schöne Story SBI. Solche Geschichten sind super.
Irgendwas crasht irgendwo in nem Treiber, aber nur mit einer gewissen Hardware, gewissen installierten Treibern und installierten proprietären SDK.
Während NVidia die Schuld auf Intel schiebt, Intel die Schuld auf Epic schiebt, und Epic die Schuld auf Nvidia schiebt sitzt du da und versuchst irgendwas aus den Crashdumps zu saugen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
In C?
| |
| Code: |
return (a ^ b) ? a && c : !c; |
|
ohne es getestet zu haben, und wenn alles bools sind.
Allerding returnd das auch wenn a && b, was in deinem Beispiel nicht abgedeckt ist.
| |
Und auch wenn !a && !b
Vielleicht sowas (natürlich auch nicht getestet):
| |
| Code: |
if (a ^ b)
return a ? c : !c;
|
|
Ob das wirklich einfacher ist, ist natürlich stark diskussionswürdig. Würde mich da wuSels Frage anschließen.
|
|
|
|
|
|
|
|
|
|
|
|
Zwei Zeilen ist eine zuviel.
|
|
|
|
|
|
|
|
|
|
|
Ok, hier ist der bug fix:
| |
| Code: |
if (a ^ b) return a ? c : !c; |
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
Zwei Zeilen ist eine zuviel.
| |
So Leute kann ich leiden...
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Murica
Schöne Story SBI. Solche Geschichten sind super.
Irgendwas crasht irgendwo in nem Treiber, aber nur mit einer gewissen Hardware, gewissen installierten Treibern und installierten proprietären SDK.
Während NVidia die Schuld auf Intel schiebt, Intel die Schuld auf Epic schiebt, und Epic die Schuld auf Nvidia schiebt sitzt du da und versuchst irgendwas aus den Crashdumps zu saugen.
| |
Ich finde es halt besonders erstaunlich, weil wir für das ganze Infrastrukturzeug nur so dermassen stabile Komponenten verwenden, dass man dazu auch problemlos altbacken sagen könnte. Das war der erste Bug in doch schon 5 Jahren hier, den wir nicht auf unsere eigene Unfähigkeit zurückführen konnten. Das passiert andauernd
Es wurde also nicht nur geweimt, sondern definitiv auch geschwitzt
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 10.09.2019 16:30]
|
|
|
|
|
|
|
|
|
Ein einzelnes Bit ist im Speicher ist Stuck, aufgrund von $Custom-JVM-Allocator, der $OhneASLR läuft, landet aus der spezifischen Konfiguration exakt dieser Maschine reproduzierbar ein Längenfeld eines Objekts, das der JIT nut im Hot und höher Pfad nutzt, auf diesem Bit, weswegen er versucht 982 GB hinter dem Ende des Objekts zu lesen, und daher mit c0....5 crasht.
Easy. Next.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Siebzehn.info ist down.
Ich habe jetzt erstmal über Archive.org die PDFs zur topologischen Differentialalgebra und 17 gerettet. RIP.
Satz: Jeder Jäger ist ein Frühling.
And just remember: If your girlfriend likes your cooking - you're doin' it WROOOOONG!
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Wraith of Seth am 14.09.2019 8:20]
|
|
|
|
|
|
|
|
|
Das Problem mit dem Gerät, das eine C-Api hat, aber aus Python angesteuert werden soll, scheint fast gelöst zu sein¹
Da es aber halbwegs vollständig sein soll: Wie baut man ein C-Makro in Python nach?
Im C-Header steht sowas wie:
| |
| Code: |
#macro(param) (((param) & CONSTANT_DEFINED) >> 16) |
|
¹ist es schon länger, aber das musste noch in ein bestehendes Python-Projekt integriert werden, von dem ich wenig Ahnung habe. Das hat etwas gedauert
|
|
|
|
|
|
|
|
|
|
|
|
Spricht etwas dagegen, das einfach als Funktion zu implementieren?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Danzelot am 16.09.2019 13:36]
|
|
|
|
|
|
|
|
|
Als Einzeiler wäre es mir lieber.
Das als Funktion zu schreiben wäre aber natürlich möglich.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Rootsquash am 16.09.2019 14:20]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Es geht nicht um die bitwise operators, ich hoffte nur, dass Python 3 Makros könnte, so dass ich da keine Funktionen schreiben muss.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Warum würde man jemals für irgendwas C-Style Macros haben wollen?
|
|
|
|
|
|
|
|
|
|
C++
|
Ich komm nicht drauf: Ich will callbacks in einen std::vector schieben, allerdings sollen die callbacks verschieden viele und verschiedenartige Paramter haben. Also quais sowas: std::vector<std::function<void(Args ... args)>>
Bisher habe ich std::vector<std::function<void()>> und bastel dir Funktionen mit std::bind zusammen. Allerdings moechte ich die Parameter nicht vorher binden, sondern beim Aufruf des jeweiligen Callbacks rueberreichen.
Das muss doch mit variadic templates gehen aber ich komm nicht drauf.
|
|
|
|
|
|
|
|
|
|
|
Glaube nicht, dass das mit variadic templates geht, denn ein ist eine andere Klasse als ein [node]Callback<A, B>[/code] und kann nicht in einen
| |
| Code: |
vector<Callback<A, B>> |
|
eingefügt werden. Wenn du eine leere Basisklasse hinzufügst, von der alle Callbacks erben, sollte das möglich sein.
Disclaimer: Lange nichts mehr in C++ gemacht, die Pros sollten sich auch dazu äußern.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Wraith of Seth
Heute die beste Begrüßung eines Studenten an einen Prof in einer Email gelesen: "Hi Sir!"
Not a medical doctor! Not even the other kind. Technically.
| |
Sie verlor an Witz. Es ist wohl recht üblich an NZ-Boarding Schools. Booooooo!
|
|
|
|
|
|
|
|
| Thema: pOT-lnformatik, Mathematik, Physik XXII ( Jetzt nehmen uns Computer schon die Memes weg! ) |
