IRC Logs for #zfx


2022-05-17

05:11:57 Magister joined the channel
06:30:47 xq: moin die herren
06:31:01 xq: IceMichael: nice!
07:09:54 Schrompf joined the channel
07:31:54 IceMichael: moin
07:32:01 IceMichael: xq: oh, ein nice von dir, das ist aber selten :D
07:32:30 IceMichael: tatsächlich kann ich mir gut vorstellen, dass NATS prima ist, um mit Hilfe von Websockets ein C++ Backend an ein Web-Frontend anzuschließen
07:33:12 IceMichael: also wenn mein kleines Projekt hier jetzt so läuft wie ich mir wünsche, dann wird man das daran auch sehen
07:33:24 IceMichael: (NATS kann man mit irgendnem anderen Kommunikations-Lib cross-language austauschen)
07:39:09 Magister: moin
07:41:33 IceMichael: moin Magister
07:41:55 IceMichael: ich find auch nach wie vor die Diskussion von exceptions vs. error-return-values interessant. Es gibt ja de facto einfach keinen Konsens sondern beide Lager
07:42:10 IceMichael: und diejenigen, die irgendwie beides ok finden und es einfach nach der Community der jeweiligen Sprache machen wie mich
07:43:05 xq: ich finde, exceptions sind unglaublich schwer zu handhaben
07:46:59 IceMichael: ich hätte auch gerne mal eine schöne, ausführliche Diskussion, wo der Autor nicht komplett biased ist
07:47:08 IceMichael: es gibt irgendwie fast nur totale Verfechter von einem und vom anderen
07:47:55 IceMichael: ich meine, Kritik an error-return-codes ist, dass man den ganzen Code voll mit error handling hat. Aber wenn man das bei Exceptions sauber macht, ist es da 1. auch nicht anders und 2. muss das ja auch so sein? Man kann ja schlecht nur gegen den happy path programmieren, das ist irgendwie coder-rookie-Denken
07:48:21 IceMichael: und dann haben wir so einen wie Google, der bei C++ sagt "no exceptions!" in den guidelines und ein Golang (auch von Google, ja gut), wo die bewusst sagen "geht nicht, gibt's nicht"
07:48:39 IceMichael: oder Zig, wo es ja quasi so ähnlich wie bei Go ist, oder?
07:49:52 xq: zig hat error return codes nahe der convenience von exceptions
07:49:59 IceMichael: jetzt ist viel Code in Java/C# ja nicht automatisch voller Probleme, also vll ist das einfach ne Frage von API vs. Business-App... na ja, kA
07:50:03 xq: weit weniger painful als Go oder C++
07:50:04 IceMichael: hm, was ist das für ne convenience?
07:50:12 IceMichael: ja gut, in C++ ist es super-painful
07:50:22 xq: `var file = try openFile("foo.txt");`
07:50:23 IceMichael: in Go sind tuple-return-types halt sehr angenehm eingebaut
07:50:45 xq: Zig hat first-class error unions (also Result aus Rust oder Go multiple return values)
07:50:56 xq: error unions kannst du mit diversen operatoren unwrappen
07:51:08 xq: wir haben das `if`:
07:51:26 xq: if(openFile(…)) |success_value| { … } else |err| { … }
07:51:41 xq: das |x| ist hier ein "capture" oder "unwrap", kein lambda
07:52:01 xq: dann gibt es `catch`:
07:52:13 xq: var success_value = openFile(…) catch |err| { … };
07:52:32 xq: catch muss entweder irgendwie "noreturn" sein (also continue, break, return, panic, …)
07:52:40 xq: oder einen wert vom typ der success_value zurückgeben
07:52:45 IceMichael: ah!
07:52:55 IceMichael: bis zu dem Punkt dachte ich, das ist jetzt ja nur bisschen syntactical sugar
07:53:04 xq: und `try x` ist effektiv `x catch |e| return e`
07:53:23 xq: was heißt: gib mir den wert bei erfolg oder returne den fehler bei fehler
07:53:31 xq: was halt fucking convenient ist
07:53:51 IceMichael: ja, klingt gut
07:53:53 xq: was halt auch nice ist: "var value = parseInt(u32, string, 10) catch 0;"
07:54:05 xq: also "wenn parsen fehlschlägt, gib mir einfach ne 0 und jut"
07:54:16 IceMichael: ja, das ist in Go etwas ätzend lang
07:54:17 xq: jetzt bau das mal mit exceptions *rofl*
07:54:25 IceMichael: ne danke :/
07:54:33 xq: vorallem muss `value` dann sogar IMMER var sein und DARF NICHT const sein
07:54:37 xq: ^^
07:54:37 IceMichael: ich glaube, was mir dann fehlt sind tatsächlich die Argumente für Exceptions
07:54:57 IceMichael: ja, stimmt, geht nur mit wrapper
07:55:02 xq: Das Error Handling in Zig ist tatsächlich fucking sweet ^^
07:55:12 xq: vorallem weil du noch `defer` und `errdefer` hast
07:55:26 xq: defer wird immer beim ende des blocks ausgeführt
07:55:32 xq: errdefer nur, wenn im block ein fehler zurückgegeben wird
07:55:32 IceMichael: als Sprachbauer sollte das irgendwie auch der Fokus sein, find ich. Große Software, die dann wegen schlechtem error handling breaked, ist einfach ein riesen organisatorisches Problem und sauteuer
07:55:38 xq: yes
07:55:50 xq: ich nutze ja in C# auch exceptions und so
07:55:57 xq: aber mein größter Kritikpunkt ist die intransparenz
07:56:11 xq: C++Builder dokumentiert gerne seine API über Exceptions *rofl*
07:56:21 xq: comboBox->Items->Add("Foo");
07:56:40 xq: sieht gut aus, nur wirft halt Add ab und an exceptions, wenn die comboBox noch nicht vollständig initialisiert ist
07:56:49 xq: da steht dann drin:
07:57:18 xq: Message="Cannot add items to combobox when window handle is not created yet. please add the combobox to a form, then add items"
07:58:20 Schrompf: ich mag exceptions eigentlich, zumindest für gespräche mit dem OS. aber es ist halt ne gratwanderung: wenn man die exception nicht fängt, klappert sie transparent weiter, das ist super
07:58:45 Schrompf: wenn man sie fängt, ist es ne menge syntax, und da sind zigs shortcuts viel cooler
07:59:39 Schrompf: Go's error handling ist so stumpf, wie die sprache per design auch ist
07:59:49 IceMichael: xq, gutes Beispiel
07:59:50 IceMichael: ja, nur...
07:59:54 IceMichael: sollte man nicht jede exception fangen?
08:00:02 Schrompf: das einzige, was die rettet, ist dass die IDE den ganzen syntax hinter kleinen icons versteckt und ausblendet
08:00:04 IceMichael: ich meine, in dem Add-Fall.. man macht es nicht und dann hat man ein kaputtes UI
08:00:17 IceMichael: den Zustand muss man doch um jeden Preis vermeiden
08:00:29 IceMichael: gut, man sollte vll die richtige Precondition schaffen
08:00:32 Schrompf: das Add() ist ein exception misuse. das ist ein coder-fehler, das muss ein assert sein
08:00:49 IceMichael: nutzt man in C#/Java denn asserts oder sind das auch immer exceptions?
08:01:19 xq: java/c# machen den müll auch
08:01:24 Schrompf: gute frage. nach meinem wissen mis-usen auch Java und C# exceptions für coder-fehler
08:01:32 xq: "InvalidArgumentException" oder "ArgumentNullException" ist halt eigentlich nen assert
08:01:39 Schrompf: jupp
08:01:40 xq: und sollte nicht fangbar sein
08:01:44 xq: aber: die sprachen haben keine asserts
08:02:09 xq: aber wie gesagt: mein größtes problem ist, dass man halt nicht *sieht*, ob dinge eine exception werfen
08:02:13 IceMichael: na ja, aber wenn das komplett nach oben delegiert wird, zeigt es den Coderfehler doch klar an, erfüllt das dann nicht den Zweck?
08:02:14 xq: JAva hat seine checked exceptions
08:02:33 xq: IceMichael: nein, denn ich kann programmierfehler plötzlich behandeln.
08:02:36 xq: wie "FileNotFound"
08:02:43 xq: das ist plötzlich die selbe abstraktionsebene
08:03:01 Schrompf: ja, das ist mift.
08:03:09 IceMichael: ja, wenn man das macht, kann man aber den Coder blamen
08:03:15 Schrompf: ArgumentNllException: junge, zurück in die IDE und mach Deine Arbeit
08:03:28 Schrompf: FileNotFoundException: kann passieren, geh damit im Code um
08:03:32 IceMichael: also catch all oder wenn man das bewusst fängt und dann was andres macht, ist halt doof
08:03:57 IceMichael: hm, ich brauch vll nochmal ne Wiederholung von checked exception
08:04:04 IceMichael: MUSS man das Ding fangen oder kann es einfach nach ganz oben fliegen?
08:04:13 IceMichael: weil wenn es das Programm crashen lässt, ist doch gut
08:04:14 xq: checked exception: du musst deklarieren, dass eine funktion diese exception wirft
08:04:17 xq: sonst: compiler fehler
08:04:25 IceMichael: ok, das ist ja nur dokumentation
08:04:29 Schrompf: kann man so sehen. ich finde die existenz einer ArgumentNullException bereits als falsch
08:05:01 Schrompf: weil's in einer idealen welt gar kein laufzeitfehler wäre, sondern dir beim compilieren um die ohren fliegen sollten
08:05:04 IceMichael: na ja, es gibt https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.debug.assert?view=net-6.0
08:05:15 Schrompf: oh hübsch
08:05:16 IceMichael: aber geil: zeigt im Fehlerfall ne Msgbox :D
08:05:26 Schrompf: Windows <3
08:05:47 IceMichael: wieso ist das denn einfach so schon eingebaut, was ist denn, wenn das headless service ist
08:07:16 xq: IceMichael: ne, checked exceptions sind tatsächlich keine doku, sondern enforcement
08:07:33 xq: wenn deine funktion nicht deklariert, dass sie X wirft, musst du X fangen, falls du etwas aufrufst, was X wirft
08:07:36 xq: sonst compiler fehler
08:07:41 xq: das ist schon ziemlich nice
08:07:56 xq: macht aber nur Java, und auch nur für "Exception", nicht "RuntimeException" (aka: NullPointer)
08:08:01 IceMichael: ach sorum, ja stimmt
08:08:18 IceMichael: ah gut, also sind für coding fehler das keine checked exceptions
08:08:22 IceMichael: dann erfüllt das ja den zweck
08:08:35 IceMichael: man braucht nur eben coding conventions, die sagen, dass man die dann echt nicht fangen darf, dann ist man safe
08:08:50 xq: jo
08:09:19 IceMichael: hm, aber dennoch, wo liegt der Vorteil von exceptions... wenn man eh alle (bis auf die unchecked ones) fangen muss/soll...
08:09:21 xq: finde aber, dass error codes generell zu besserem fehlerhandling führen
08:09:24 xq: also, vorallem weniger lazy
08:09:24 IceMichael: ok, es erzwingt error handling
08:09:43 xq: ich weiß es nicht, ehrlich gesagt
08:09:50 xq: exceptions sind halt bei sloppy coding weniger aufwand
08:10:00 xq: und bei sauberem error handling mit unrolling usw definitiv mehr aufwand
08:10:24 xq: vorallem weil es syntaktisch mehr aufwand ist
08:10:31 IceMichael: ja, eben...
08:10:47 IceMichael: also na ja, wenn man sagt, zig hat auch exceptions, dann ist java/C# style exception handling halt einfach kacke, nicht exceptions selbst
08:11:03 IceMichael: und wie gesagt: nett ist ja, dass exception handling durch checked exceptions erzwungen wird, das ist schon ne gute Sache
08:11:18 IceMichael: Go erzwingt es nicht, C++ eh nicht. War das bei Zig jetzt erzwungen?
08:11:52 xq: yes
08:12:04 xq: zig zwingt dich, alle values entweder zu benutzen oder zu ignorieren
08:12:12 xq: ignorieren geht durch "_ = …;"
08:12:20 xq: nur: du darfst error values nicht ignorieren
08:12:24 xq: sprich:
08:12:29 xq: _ = openFile("foo");
08:12:58 xq: ist illegal, weil openFile ein "OpenFileError!FileHandle" zurück gibt (das ist ein error union, also entweder OpenFileError oder FileHande)
08:14:00 xq: übrigens ein schönes beispiel wie convenient error handling sein kann: https://github.com/MasterQ32/zero-graphics/blob/master/src/main/wasm.zig#L141-L149
08:14:10 xq: ich packe ein mouse down event in eine queue
08:14:29 xq: und die abwägung hier war: egal, was schief geht. ein verlorenes mausevent ist weniger schlimm als ein app crash
08:14:42 xq: also logge ich hier nur den fehler auf die konsole und sag fuck it, wenns nicht klappt
08:15:13 IceMichael: nett
08:15:13 xq: input_handler.pushEvent(…) catch |e| logInputError(e)
08:15:19 IceMichael: Einzeiler, die sich gut lesen
08:15:24 xq: yes
08:16:01 IceMichael: ok, aber zurück dazu, was exceptions nett macht... C# hat ja überall unchecked exceptions, also mein Argument dafür, dass man jede exception handlen muss, fällt da weg
08:16:13 xq: yep
08:16:17 IceMichael: irgendwie wirkt es so, als würde C# es dann am schlechtesten machen. Wirkt erstmal aber un-intuitiv
08:16:28 xq: ja, ist auch mein argument
08:16:35 xq: C# hat tatsächlich kein schönes error handling modell
08:16:49 xq: using(var foo = CreateFile("blah")) { foo.Write("hello"); }
08:16:50 xq: hift schon
08:16:59 xq: weil using die datei sauber schließt
08:18:15 IceMichael: na ja, was C++ mit RRID halt von Haus aus mitbringt, aber gut
08:18:31 IceMichael: https://yosefk.com/blog/error-codes-vs-exceptions-critical-code-vs-typical-code.html ist kein schlechtes Argument, FALLS error return codes ignoriert werden dürfen wie in Go
08:18:41 IceMichael: trifft aber nicht auf Zig zu, das ist auch da safe
08:20:06 xq: was übrigens richtig witzig ist:
08:20:21 xq: if file_exists("foo.txt"):
08:20:27 xq: f = open_file("foo.txt");
08:20:35 xq: print(f.readAllText())
08:20:41 xq: siehst du den bug in diesem pseudocode?
08:20:49 IceMichael: hm, na ja, dann les ich oft das Argument, dass man den main flow eben besser sieht bei exceptions, wenn man eben das handling davon brav ganz nach unten in den Code packt... kann stimmen, aber hängt echt vom Code ab, geht ja oft nicht so glatt auf
08:21:14 IceMichael: ist das Python und eingerückt?
08:21:30 IceMichael: vermutlich
08:21:45 IceMichael: na ja, open_file kann ja auch fehlschlagen wegen Berechtigungen?
08:23:40 IceMichael: oder racing-Kram
08:23:45 IceMichael: oder was meinst?
08:24:03 xq: racing-kram
08:24:19 IceMichael: ok, jo
08:24:30 xq: es ist besser, einfach ne datei aufzumachen, als vorher zu prüfen, ob sie da ist, und dann anzunenhmen, sie wäre noch da, wenn man sie dann aufmacht
08:24:32 IceMichael: na ja, hängt halt sehr vom Kontext ab, ob das ein Bug ist
08:24:43 xq: ne, es ist immer ein bug ^^
08:24:44 IceMichael: ja, absolut
08:24:48 IceMichael: hm
08:24:54 xq: ich kann dir die datei ja zwischen file_exists und open_file unterm arsch weglöschen
08:25:08 xq: und damit einen absturz deiner software triggern
08:25:15 IceMichael: Bugs sind nur Bugs, wenn sie unerwartet laufen unter gegebenen preconditions
08:25:29 IceMichael: wenn wir ein System haben, wo writes/reads/deletes sehr privilegiert und kontrolliert durchgeführt werden, kann das schon safe sein
08:25:31 xq: gab genug reported CVEs in den letzten jahren wegen sowas
08:25:47 xq: inklusive RCE
08:26:07 IceMichael: wenn das auf irgendnem Server läuft, wo keiner Dateien in einem Ordner manuell irgendwie anfassen soll...
08:26:11 IceMichael: aber das ist halt ne Ausnahme
08:26:20 IceMichael: nur dein "immer" hat mich natürlich getriggered :D
08:26:42 IceMichael: ich mein, ich würd es stilistisch eh einfach nie so schreiben, daher hätte sich für mich die Frage gar nicht gestellt
08:26:42 xq: es ist immer ein bug
08:26:47 xq: die frage ist nur, ob er ausnutzbar ist
08:26:48 IceMichael: ne, find ich nicht
08:27:02 IceMichael: man trifft beim Coden immer Annahmen
08:27:07 xq: die existenz eines bugs impliziert nicht dessen ausführung
08:27:49 IceMichael: also immer, wenn man einen crash/attack vector formulieren kann, ist das für dich ein Bug, selbst wenn man selbst die Infrastruktur kontrolliert?
08:28:17 IceMichael: also wenn ein Kunde eine Datei NIEMALS löschen darf, ist es ein Bug, wenn unser Code UB hat, wenn der Kunde es doch tut?
08:28:33 xq: yes, weil du damit als coder eine annahme triffst, die JEDER der das system jemals benutzt, wissen muss
08:28:57 IceMichael: ja, aber jeder kann ja nur educated user bedeuten, zB weil endkunden keinen Zugriff haben, sondern nur knowledgeable admins
08:29:12 xq: kann schon reichen, dass der admin wechselt
08:29:18 xq: und sowas nich vollständig dokumentiert ist
08:29:26 IceMichael: na ja, nach dieser Logik ist jedes OS voller Bugs
08:29:29 xq: und der admin dann eine datei löscht, weil man die nicht mehr braucht
08:29:30 xq: und klong
08:29:47 xq: banking-system down und deine six-nines sind am arsch
08:29:52 IceMichael: weil du mit dem manipulieren oder löschen von system files immer alles kaputt machen kanst
08:29:59 xq: ne, eben nicht
08:30:01 xq: ^^
08:30:26 xq: die frage ist halt immer, ob es an eine stelle zu einem gewünschten absturz (sanitization) oder zu einem ungewollten absturz (bug) kommt
08:31:46 IceMichael: hm, dann ist viel Leserei von binary files auch oft ziemlich gefährlich
08:31:56 IceMichael: gut, dadurch hat man natürlich auch wirklich zig CVEs
08:32:38 IceMichael: hmmm
08:33:01 IceMichael: aber dann müsste man ja zB auch immer, wenn man mit DBs arbeitet, alle möglichen Felder ständig dagegen checken, ob sie sinnvollen Input enthalten
08:33:09 xq: yep
08:33:21 IceMichael: das ist wirtschaftlich eigentlich nicht machbar
08:33:35 IceMichael: jetzt kannst du sagen, dann nimmt man aus wirtschaftlichen Gründen Bugs in Kauf
08:33:41 xq: jop, ist so
08:33:42 xq: https://mq32.de/public/efc7fa84ed43f28a7b0ee1701cbaac630acb85f4.png
08:33:48 xq: übrigens, schönes beispiel für "sauberes error handling"
08:34:14 xq: die "Power Control" und "Wettervorhersage"-Apps haben also Icon eine PNG-Datei, aber es muss an der Stelle eine TinyVG-Datei sein
08:34:15 IceMichael: aber ich finde, wenn ein Kunde auf DB/File-Ebene Sachen kaputt macht und dadurch die software stürzt, ist das ein anderes Level von Bug als wenn in plausiblen und erwarteten Fällen was unkontrolliert kaputt geht
08:34:55 IceMichael: ich glaube, ersteres würden die wenigsten wirklich als Bug bezeichnen
08:35:27 IceMichael: zB wenn der Kunde die config-file kaputt macht, gut, das kann passieren, er darf sie anfassen
08:35:43 xq: jo, aber ne kaputte config sollte sanitized werden
08:35:45 IceMichael: aber wenn er in der DB, auf die er Zugriff hat, weil es on prem ist, was kaputt macht, ist das was andres, find ich
08:35:49 xq: und nicht einfach "as good" akzeptiert
08:36:02 IceMichael: ja sicher, da bin ich ja bei dir
08:36:04 xq: ist halt trotzdem die frage, was das korrekte verhalten ist ;)
08:36:15 IceMichael: aber das ist ne file, die der Kunde anfasst, da wäre es ein Bug, wenn man es nicht sanitized oder graceful handled
08:36:19 xq: nen six-nines-vertrag braucht halt stabile software
08:36:26 IceMichael: aber wenn der Kunde was anfasst, was er nicht darf, und dadurch was kaputt macht, kann man da nix machen
08:36:45 IceMichael: er kann ja auch mit hex editor die exe schrotten als ein andres Extrem
08:37:28 IceMichael: wo zieht man da die Grenze?
08:37:36 IceMichael: oder wo ziehst du die, ich hab das für mich getan :D
08:40:29 xq: ich nehme die exe als sane an
08:40:55 xq: jegliche zusätzlich geladenen daten können potentiell fehlen oder korrupt sein
08:41:10 xq: ich mein, in den meisten fällen tuts ja ein kontrollierter absturz
08:47:55 xq: aber mal was semi-related:
08:48:03 xq: ich nutze sehr viel VNC, auf arbeit und privat
08:48:07 xq: und ich hab keinen guten VNC-Viewer
08:48:11 xq: oder server
08:48:13 xq: die crashen dauerhaft
08:48:22 xq: x11vnc crashed alle halbe stunde mal
08:48:31 xq: vinagre explodiert komplett bei ner protocol violation
08:48:51 xq: bin jetzt *so* kurz davor, einfach nen eigenen VNC-Client zu schreiben
08:48:59 xq: server hab ich aus spaß an der freude mal implementiert
08:49:05 xq: das ist relativ gemütlich
08:49:17 xq: also, nen server core muss man dazu sagen, der hat kein screen grabbing oder sowas bisher
08:49:52 xq: der client ist halt schon aufwändiger, aber auch nur so mittel
08:51:05 IceMichael: xq: klingt natürlich nett
08:51:22 IceMichael: bei apple nutzt man ja eh noch irgendwas andres, vergessen was
08:51:34 IceMichael: oder ist das vnc hm
08:51:42 IceMichael: was auch immer läuft glaube ok stabil
08:52:21 xq: jo
08:52:25 xq: VNC ist auch net so kompliziert
08:52:26 Schrompf: ich nehm tightvnc
08:52:33 xq: jo, den hab ich auf arbeit auch
08:52:35 xq: zudem RealVNC
08:52:39 xq: privat vinagre
08:52:42 Schrompf: der crasht nur, wenn man ne nicht ganz normale auflösung nimmt
08:52:47 IceMichael: hm, aber wenn man was dynamisch linkt, können ja auch dlls insane sein. Oder bei Qt so lustige conf files. Oder ENV vars, die Qt kaputt machen
08:52:54 Schrompf: (ich hab ihn mal mit 2200x1200 zu betreiben versucht)
08:53:01 IceMichael: (aber egal, das thema ist nicht so spannend auf dem level, lieber vnc)
08:53:36 xq: jo
08:53:50 xq: auf jeden fall: VNC ist halt echt chillig für server zu implementieren
08:54:05 xq: ist halt auch cool, weil du damit headlesss anwendungen relativ einfach mit "inhalt" bestücken kannst
08:54:10 xq: falls du nen dashboard/management ui willst
08:55:21 xq: offtopic: Prey und Jotun sind im Epic Store grade gratis
09:00:43 IceMichael: hmmmmmmm, hast nen link nit artikel?
09:00:59 IceMichael: also dashboard / mgmt ui für headless klingt nett
09:02:16 xq: für vnc?
09:02:25 xq: https://datatracker.ietf.org/doc/html/rfc6143
09:02:28 xq: das hier reicht vollständig :)
09:09:10 Schrompf: Jotun fand ich cool. Bissl lang, bisweilen bissl unnötig schwer, aber cooler grafikstil
09:09:54 Schrompf: und die Synchronsprecherin des Hauptcharakters, die dieses Alt-Norwegische so herrlich schnarrt, heißt Lilja
09:10:03 Schrompf: (daher hab ich Flockes Namen)
09:11:02 IceMichael: xq: ok, tldr for now :D
09:11:45 xq: tl;dr: VNC/RFB ist halt nen dummer remote framebuffer. du kannst bitmaps übertragen und diffs davon
09:55:07 IceMichael: ah!
09:55:25 IceMichael: na ja, ich würd bei headless mittlerweile immer nen web service draufpacken, der das rendert
09:55:34 IceMichael: ist einfach zu simpel... einzelne bitmaps basteln ist mehr arbeit
09:55:48 xq: jo
11:29:22 joeydee joined the channel
11:29:30 joeydee: moin
11:37:28 xq: huhu
11:38:17 IceMichael: moin joeydee
11:38:34 Schrompf: hoeydee!
11:38:52 Schrompf: ASAN hat mir gerade erfolgreich auf die Finger gehauen
11:39:24 Schrompf: hab den noch nie funktionierend erlebt, irgendwie klingelten schon dutzende false positives, bevor ich überhaupt im eigenen code angekommen bin
11:39:54 Schrompf: aber auf linux scheint die situation besser, hier false-positivt nur der debug-build an den absurdesten stellen
11:40:12 Schrompf: im release hat genau eine stelle geklingelt, und die ist tatsächlich über's ende hinaus. danke, ASAN
11:59:27 IceMichael: Schrompf: was ist ASAN?
12:17:30 Schrompf: Address Sanatizer
12:17:58 Schrompf: Ein speziell instrumentierter Build von C/C++-Executables, wo *jeder* Speicherzugriff auf Gültigkeit überprüft wird
12:18:28 Schrompf: findet Dir "hier lese ich 10Bytes über's Ende eines Strings hinaus" oder auch "Hier schreibe ich in array[size]"
12:21:59 IceMichael: ah
12:22:02 IceMichael: nett
12:22:05 IceMichael: hmmm, grml
12:22:12 IceMichael: ich krieg immer pthread_create failed: Resource temporarily unavailable
12:22:20 IceMichael: bin auf so nem v-server von strato
12:22:37 IceMichael: google hat gezeigt, dass manche da bei strato mit nem harten Limit kämpfen, ABER ich weiß nicht, wie ich das rausfinde
12:22:54 IceMichael: ulimit scheint ok zu sein, irgendwo hab ich Maxthreads mal hochgesetzt, wird aber anscheinend ignoriert
12:53:14 Schrompf: den fehler hab ich jedenfalls noch nie gesehen
12:53:23 Schrompf: wenn threads nicht mehr gehen, ist irgendwas tiefreinböse
12:53:32 Schrompf: oder ist banal der speicher alle?
12:53:48 Schrompf: ne, das hätte seine eigene fehlermeldung
12:57:49 IceMichael: es gibt halt schon threadlimits irgendwie
12:57:53 IceMichael: kapieren, was das genau ist, tu ich aber auch nicht
16:05:30 xq: IceMichael: Strato hat üblicherweise keine "V-Server"
16:05:35 xq: sondern nur LXC-Container
16:06:00 xq: damit hast du gar keine kontrolle über ulimits, du kannst quasi ein maximum vorgeben, aber das tatsächliche limit für deinen container kommt von strato
16:06:56 xq: ergo kann pthread_create durchaus einfach nen limit für deinen container sein
16:07:04 xq: und du reizt halt den vserver komplett aus