I kind of branded it a bit "douchey" at first too but then as I thought about it, it seemed remarkably restrained considering he debugged this issue. It's not like this happened all the time, had to get kind of lucky and build and calibrate a system just right to capture it.

I don't intend this to be an inflammatory question, I'm sort of a perpetual ruby novice, it's never been my day job and I've never managed to sort of catch up with the community, as soon as I feel pretty good with something I find it's been obsoleted a couple times. I like it but how does the community at large deal with stuff like this? This guy found a real bug and invested some time in it, do other rubyists just deal with crashes and restart their stuff? Do they just consider it part of "being on the cutting edge?" Or do they not even notice?

In practice crashes due to this issue simply do not occur very often. I think I've had the VM segfault twice in the last two or three years.

That's what makes the hyperbolic tone of this article so douchey; he wrote up an interesting dissection of an edge case issue as though it were an ongoing catastrophe, mostly just to inject a bunch of chest-thumping rock-star bravado that added nothing of value to the discussion.

I've actually had an ungodly metric ton of ruby segfaults in the past month or so, and almost never before that. At least one of them has definitely been GC-related - see "therubyracer is not thread safe" for one problem I've been running into. You also have to use PassengerSpawnMethod conservative to avoid GC-related failures in passenger with rails 3.1.

I'm not sure if those are both related to this or not, but I've had drastically more segfaults lately than in my past 6 years of ruby programming. It's getting pretty bad imo.

but how much of that is the interpreter's fault?

I know I can't run typhoeus + thin on 1.9.2 on OSX as it reliably crashes every ten minutes and I have no clue on how to debug it, but it is not a problem with the interpreter, it's a problem with external libraries.

Agreed. As pointed out by others, this is a perennial problem with GCs in general. Obviously it doesn't happen very often, otherwise the business risk would have forced Matz or the Ruby community to fix it, else no one would have ever deployed on Rails, because, you know, there's that Fatal Ruby VM Bug that crashes your applications constantly and costs people lots of time and money.

The analysis was good, but the tone was ludicrous. It sounds far too much like: "Hey! everyone in the world should abandon MRI because of a bug I found!! That's right, me!!"

You are totally missing the point, bro.

The question really is: how much data corruption is occurring that _does not_ cause world ending segfaults? THAT is what you need to worry about. Check yourself before you wreck yourself.

That is some amazingly selective memory corruption, homeboy. How whack is it that it is causing neither widespread segfaults nor widespread reports of creeping data corruption despite these VMs having logged billions of hours of CPU time in production all over the planet, dawg?

And yo check this: maybe this "fatal flaw" is actually just an edge case bug that isn't cropping up much in practice. Fo'shizzle!

And maybe we can drop the ridiculously asinine slang and douchey bravado, "bro".

the gzip bug mentioned did not segfault. it simply corrupted the gzip file in memory. not that selective son.

imma talk the way i talk and dont give a fuck if you like it or not.

I get that. It's probably related to how many libraries you use and a lot of other things? There might be pathological ways to make it happen more frequently. It all depends on how and when it happens though.

Well, we're using a large number of gems, a number of which rely on native code.

This issue is no doubt a pain in the ass for gem authors to debug, but it's definitely not something that library users are running into with any sort of frequency.