A little strange to write up a bug hunt that was resolved by the ffi upstream already, and not by the hunt itself. OP didn't fix the bug, though identifying that the upgrade was relevant is of some interest. Writing could have been clearer.
LLM slop. Why do people (presumably) take the time to debug something like this, do tests and go to great lengths, but are too lazy to do a little manual writeup? Maybe the hour saved makes up for being associated with publishing AI slop under your own name? Like there is no way the author would have written a text that reads more convoluted than what we have here.
I have no idea whether the text was generated from an LLM, but “slop” it absolutely is not - it’s clearly a very logically ordered walkthrough about a very thorough debugging process.
If you call anything that comes out of a model “slop” the term uses all meaning.
Had me in the first half. But from the "The Microsecond Window" chapter and on...;
> No warning. No error. Just different methods that make no sense.
> This is why write barriers exist. They're not optional extras for C extension authors. They're how you tell the garbage collector: "I'm holding a reference. Don't free this
It's all ChatGPT LinkedIn and Instagram spam type slop. An unfortunate end to an otherwise interesting writeup.
I don’t understand why people are saying this article was AI generated. Do you think the author told chatgpt “Write me an article (with diagrams) about a Ruby hash race condition” and pasted that to their blog?
So they turned on GC after every allocate ("GC stress"), and
"With GC.stress = true, the GC runs after every possible allocation. That causes immediate segfaults because objects get freed before Ruby can even allocate new objects in their memory slots."
That would seem to indicate a situation so broken that you can't expect anything to work reliably. The wrong-value situation would seem to be a subset of a bigger problem.
It's like finding C code that depends on use-after-free working and which fails when you turn on buffer scrubbing at free.
That’s exactly what it was. He discovered the customer was using a version of ffi that had this “use-after-free” (ish) bug, but the question “is this actually what my customer was seeing or is there _another_ bug lurking” still needed to be answered.
If I see another AI-written trash article I am going to scream. Overlong, overwritten garbage. People used to write, and there was personality in that writing. Now people believe it's acceptable to generate reams of utter formless shite and post it on the internet.
If you cannot be bothered to write something, why on God's good earth would you expect anyone to be bothered to read it?
I'd normally agree, but this is a case I don't see often -- despite the form being terrible the content is good. I certainly would strongly prefer the same post with better writing, but if the entire 2019 internet were replaced with articles like this (on orthogonal topics/micro-topics) I think it'd be a better place.
> Million-to-one bugs are real, not theoretical. They happen during initialization and restart, not runtime. When they trigger, they cascade - 2,500 errors from one root cause. In high-restart environments, rare becomes routine.
Million-to-one bugs are not only real but high enough to matter, depending on which million. Many years ago I had a rare bug that corrupted timestamps in the logs, with an emperical probability of about one to 3--5 million (IIRC). Turned out that that seemingly benign bug was connected to a critical data corruption issue with real consumer complaints. (I have described this bug in detail in the past, see my past comment for details.)
15 comments
[ 2.7 ms ] story [ 40.2 ms ] threadIf you call anything that comes out of a model “slop” the term uses all meaning.
> No warning. No error. Just different methods that make no sense.
> This is why write barriers exist. They're not optional extras for C extension authors. They're how you tell the garbage collector: "I'm holding a reference. Don't free this
It's all ChatGPT LinkedIn and Instagram spam type slop. An unfortunate end to an otherwise interesting writeup.
"With GC.stress = true, the GC runs after every possible allocation. That causes immediate segfaults because objects get freed before Ruby can even allocate new objects in their memory slots."
That would seem to indicate a situation so broken that you can't expect anything to work reliably. The wrong-value situation would seem to be a subset of a bigger problem. It's like finding C code that depends on use-after-free working and which fails when you turn on buffer scrubbing at free.
If you cannot be bothered to write something, why on God's good earth would you expect anyone to be bothered to read it?
Million-to-one bugs are not only real but high enough to matter, depending on which million. Many years ago I had a rare bug that corrupted timestamps in the logs, with an emperical probability of about one to 3--5 million (IIRC). Turned out that that seemingly benign bug was connected to a critical data corruption issue with real consumer complaints. (I have described this bug in detail in the past, see my past comment for details.)