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.
> 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.)
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.
15 or so years ago I had a similar journey - a single python interpreter "impossible" segfault in production that turned out to be a bug in glibc realloc, that had already been fixed in an update, we just didn't figure out to even look for one until we'd narrowed it down that far. (We were shipping custom Debian installs on DVD, a fair number of our customer installs weren't internet accessible so casual upgrades were both impossible and unwanted, but it was also a process mistake on my part to not notice the existence of the upgrade sooner.)
Never wrote it up externally because it was already solved and "Debian updates to existing releases are so rare that you really want to pay attention to all of them" (1) was already obvious (2) was only relevant to a really small set of people (3) this somewhat tortured example wasn't going to reach that small set anyway. (Made a reasonable interview story, though.)
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?
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.
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.
People like reading LLM slop less than either of those. So it should become a common understanding not to waste your (or our) time to "write" this. It's frustrating to give it a chance then get rug-pulled with nonsense and there's really no reason to excuse it.
I read it just fine and everything made sense in it.
I would spend similar time debugging this if I were the author. It's a pretty serious bug, a non obvious issue, and would be impossible to connect to the ffi fix unless you already knew the problem.
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.
Sorry, why is this LLM slop? I only got about halfway through because I don’t care about this enough to finish the read, but I don’t see the “obvious LLM” signal you do.
I feel like the “this is AI” crowd is getting ridiculous. Too perfect? Clearly AI. Too sloppy? That’s clearly AI too.
Rarely is there anything concrete that the person claiming AI can point to. It’s just “I can tell”. Same confident assurance that all the teachers trusting “AI detectors” have.
I feel like it’s on every other article now. The “this is ai” comments detract way more from the conversation than whatever supposed ai content is actually in the article.
These ai hunters are like the transvestigators who are certain they can always tell who’s trans.
That's your issue not ours. It's obvious; if you don't have a problem with it, enjoy reading slop; many people can't stand it and we don't have to apologize for recognizing or not liking it.
I don’t believe you can recognize anything. Like everyone else claiming they can clearly identify AI you can’t actually point to why it’s AI or what parts are clearly AI.
If you could actually identify AI deterministically you would have a very profitable product.
Parts of it were 100% LLM written. Like it or not, people can recognize LLM-generated text pretty easily, and if they see it they are going to make the assumption that the rest of the article is slop too.
I can point to individual sentences that were clearly generated by AI (for example, numerous instances of this parallel construction, "No warning. No error. Just different methods that make no sense.", "Not corrupted. Not misaligned. Not reading wrong offsets.", "Not a segfault. Not the T_NONE error from #1079. There it is, the exact error from production"). The style is list-heavy, including lists used for conditionals, and full of random bolding, both characteristic of AI-generated text. And there are a number of other tells as well.
The reason I don't usually bother to bring these specific things up is that I already know the response, which is just going to be you arguing that a human could have written this way, too. Which is true. The point is that if you read the collective whole of the article, it is very clear that it was composed with the aid of AI, regardless of whether any single part of it could be defensibly written by a human. I'd add that sometimes, the writing of people who interact heavily with LLMs all day starts to resemble LLM writing (a phenomenon I don't think people talk enough about), but usually not to this extent.
This doesn't mean that the entire article was written by an LLM, nor does it mean that there's not useful information in it. Regardless, given the amount of low effort LLM-generated spam that makes it onto HN, I think it is fairly defensible to use "this was written with the help of an LLM, and the person posting it did not even bother to edit the article to make that less obvious" as a heuristic to not bother wasting more time on an article.
“not A, not B, not C” and “not A, not B, but C” are extremely common constructions in general. So common in fact that you did it in this exact reply.
“This doesn't mean that the entire article was written by an LLM, nor does it mean that there's not useful information in it. Regardless, given the amount of low effort LLM-generated spam that makes it onto HN, I think it is fairly defensible”
> The style is list-heavy, including lists used for conditionals, and full of random bolding, both characteristic of AI-generated text
This is just blogspam-style writing. Short snippets that are easy to digest with lists to break it up and bold keywords to grab attention. This style was around for years before ChatGPT showed up. LLMs probably do this so much specifically because they were trained on so much blog content. Hell I’ve given feedback to multiple humans to cut out the distracting bold stuff in their communications because it becomes a distraction.
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.
"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.