The Broken Promises of MRI/REE/YARV • Hacker News Board

Re: The Broken Promises of MRI/REE/YARV

#41

Post by evanphx » Tue, Jul 05, 2011, 9:43 PM UTC

pmjordan wrote: post #34

evanphx wrote: post #18

Earlier quoted context omitted.

Neither Rubinius nor JRuby (and probably IronRuby too) have this issue because they all use accurate garbage collection rather than conservative. Accurate requires much more bookkeeping since all pointers must always be properly identified, but if you start writing a system with accurate GC, it's pretty easy. Bugs like this are a direct result of a conservative GC strategy (and these bugs, as I'm sure you got reading…

This class of subtle bugs exists whether or not your GC is accurate as soon as you take the red pill and leave the VM environment. If you forget to add your C pointer to the accurate GC's root set, you're just as dead. Related story: http://news.ycombinator.com/item?id=217189

But that is by definition a tractable problem because the source will show that the root set isn't being used properly. (additionally, in practice this proves to be a rare and easy to fix bug)

Re: The Broken Promises of MRI/REE/YARV

#42

Post by tptacek » Tue, Jul 05, 2011, 9:55 PM UTC

iam wrote: post #40

I think this is a problem that exists across any VM that implements a GC, not just Ruby. .NET CLR has the exact same problem (perhaps a harder one, since CLR has a moving GC), so anytime they touch GC references (pointers to objects that are collectible) it's always wrapped in an explicit GC stack frame (think GC struct that lives on the stack). Furthermore, all reads/writes are carefully done with macros (which of c…

A very similar pattern bit me in the ass with the ObjC GC and libevent.

Re: The Broken Promises of MRI/REE/YARV

#43

Post by kingkilr » Tue, Jul 05, 2011, 10:02 PM UTC

[deleted] wrote: post #39

kingkilr wrote: post #37

I think this goes to a pretty simple point: anything you have to do by hand you will eventually get wrong. Thus, to a first approximation anything that can be automated, probably ought to. To show off this principle I'm going to show off some of the PyPy source code: https://bitbucket.org/pypy/pypy/src/default/pypy/module/sele... This is the implementation of `select.epoll`. Somethings you'll notice there's no GC det…

[deleted]

Nope, wrapped values are interpreter level objects, they're the kind of things that exist at the Python level, in PyPy they're called things like W_IntObject, on CPython they're PyIntObject, I'm sure Ruby has the same. Then there are unwrapped ints which are machine level integers.

Re: The Broken Promises of MRI/REE/YARV

#44

Post by [deleted] » Tue, Jul 05, 2011, 10:12 PM UTC

kingkilr wrote: post #43

[deleted] wrote: post #39

Earlier quoted context omitted.

[deleted]

Nope, wrapped values are interpreter level objects, they're the kind of things that exist at the Python level, in PyPy they're called things like W_IntObject, on CPython they're PyIntObject, I'm sure Ruby has the same. Then there are unwrapped ints which are machine level integers.

[deleted]

Re: The Broken Promises of MRI/REE/YARV

#45

Post by rbranson » Tue, Jul 05, 2011, 11:10 PM UTC

benblack wrote: post #25

phillmv wrote: post #21

Earlier quoted context omitted.

It's a bit hysterical. Shit! MRI/YARV/REE are inherently fatally flawed! All that code I have running in production must be a FIGMENT OF MY IMAGINATION! SAVE YOURSELVES

I am running this code in production, hence it cannot have bugs. QED. Yours in perpetual bogglement, Lil' B

Erlang is 100% bug free. Use that instead.

Re: The Broken Promises of MRI/REE/YARV

#46

Post by [deleted] » Tue, Jul 05, 2011, 11:26 PM UTC

benblack wrote: post #30

xpaulbettsx wrote: post #26

So, what this really seems to boil down to, is: The Ruby C API is returning objects that are not correctly reference-counted for a short period of time and are incorrectly subject to GC. This doesn't seem fatal to me, just not reasonably fixable from the GC side. It might be true, that a new API is needed to hold refs in the C side.

I am apparently in that foolish minority that believes language runtimes should not segfault/corrupt themselves while running correct code. That this problem requires significant effort just to hack around, while actually fixing it would take a major architectural change, is what elevates this from mere "lolwut?" to fatally flawed. There are good alternative runtimes for Ruby, such as the JVM and the CLR, that do not…

[deleted]

Re: The Broken Promises of MRI/REE/YARV

#47

Post by jjore » Tue, Jul 05, 2011, 11:47 PM UTC

davesims wrote: post #33

benblack wrote: post #30

Earlier quoted context omitted.

I am apparently in that foolish minority that believes language runtimes should not segfault/corrupt themselves while running correct code. That this problem requires significant effort just to hack around, while actually fixing it would take a major architectural change, is what elevates this from mere "lolwut?" to fatally flawed. There are good alternative runtimes for Ruby, such as the JVM and the CLR, that do not…

If edge case segfaults were fatal flaws Windows should never have shipped. I say 'edge case' because obviously there are millions of lines of Ruby code running for years on MRI/YARV/REE that have not encountered this error often enough to cause the kind of breathless panic you seem to think is appropriate. BTW the CLR is not a good alternative runtime for Ruby, might not ever be: http://www.zdnet.com/blog/microsoft/w…

Well, the problem here is that C using gems are going to often be memory corruptingly buggy until and unless either the gem source is updated to declare the proper parts volatile or Ruby's own C API is reworked to evolve this bug out of existence and then gems would have to be updated to use the API anyway.

Both problems are hard and the current state of affairs is apparently some random amount of the time we'll get memory corruption bugs.

Re: The Broken Promises of MRI/REE/YARV

#48

Post by KirinDave » Tue, Jul 05, 2011, 11:54 PM UTC

jjore wrote: post #47

davesims wrote: post #33

Earlier quoted context omitted.

If edge case segfaults were fatal flaws Windows should never have shipped. I say 'edge case' because obviously there are millions of lines of Ruby code running for years on MRI/YARV/REE that have not encountered this error often enough to cause the kind of breathless panic you seem to think is appropriate. BTW the CLR is not a good alternative runtime for Ruby, might not ever be: http://www.zdnet.com/blog/microsoft/w…

Well, the problem here is that C using gems are going to often be memory corruptingly buggy until and unless either the gem source is updated to declare the proper parts volatile or Ruby's own C API is reworked to evolve this bug out of existence and then gems would have to be updated to use the API anyway. Both problems are hard and the current state of affairs is apparently some random amount of the time we'll get…

It's worse than that. We don't actually know where it occurs. There are clearly some gems where it does, but it could also be occurring elsewhere in the VM.

Just figuring this out is a non-trivial project.

Re: The Broken Promises of MRI/REE/YARV

#49

Post by strmpnk » Tue, Jul 05, 2011, 11:59 PM UTC

rbranson wrote: post #45

benblack wrote: post #25

Earlier quoted context omitted.

I am running this code in production, hence it cannot have bugs. QED. Yours in perpetual bogglement, Lil' B

Erlang is 100% bug free. Use that instead.

You should see Joe's rants on Erlang too. Not as bad as MRI but there are plenty of things to gripe about in beam.

Re: The Broken Promises of MRI/REE/YARV

#50

Post by msbarnett » Wed, Jul 06, 2011, 12:19 AM UTC

strmpnk wrote: post #49

rbranson wrote: post #45

Earlier quoted context omitted.

Erlang is 100% bug free. Use that instead.

You should see Joe's rants on Erlang too. Not as bad as MRI but there are plenty of things to gripe about in beam.

I'd rather see a technical analysis of Erlang that didn't read like it was written by Kanye West and sponsored by Axe Body Spray.