Rubunius - URI.parse(url).read fails inside actor unless it is called first outside an actor

[Brooke McKim]

Hello All, 

I am not sure if this is a Rubinius bug or Celluloid bug, but https://gist.github.com/4063344. If I have a class with Celluloid included that calls URI.parse(url).read the actor will die with the stacktrace in the gist. If I then, outside of a Celluloid class, call URI.parse(url).read (which completes sucessfully) and then go back and try it on my Celluloid class it works fine. 

I am using rubinius 2.0.0rc1 (1.9.3 d2326d8e 2012-11-02 JI) [x86_64-apple-darwin12.2.0]

This works fine in CRuby 1.9.3. 

[Tony Arcieri]

I think this is an issue with the limited stack depth of fibers (I'm not sure what the limit is on Rubinius) and a recursive algorithm. Let me poke the rbx people and see what they say.

--
Tony Arcieri

[Joseph Fredette]

I'm not 100%, but the fact that it only happens in RBX indicates an rbx bug to me, the folks in #rubinius on freenode are quite helpful, I'm sure they could point you in the direction of the rbx-source. Great opportunity to write a patch!

[Brooke McKim]

I should also note that if I use Net::HTTP.get_response( URI.parse(url) ) instead of .read it works fine. 

[Tony Arcieri]

It looks like URI#read uses open-uri which takes a different code path than Net::HTTP

--
Tony Arcieri

[Joseph Fredette]

The apparently infinite call to #create_parts seems to indicate a real bug -- probably a broken/underspecced conditional. Which indicates an actual bug w/ RBX-- though I wonder how such a thing could get by -- does it cause an issue w/o the Celluloid stuff in the way? It seems like something that would be common enough to cause trouble prior to now.

[Tony Arcieri]

On Mon, Nov 12, 2012 at 6:02 PM, Joseph Fredette <jfre...@gmail.com> wrote:

The apparently infinite call to #create_parts seems to indicate a real bug -- probably a broken/underspecced conditional. Which indicates an actual bug w/ RBX-- though I wonder how such a thing could get by -- does it cause an issue w/o the Celluloid stuff in the way? It seems like something that would be common enough to cause trouble prior to now.

It's not an infinite call to #create_parts. It's breaking here, likely due to Celluloid's use of fibers in conjunction with a deeply recursive algorithm (probably exacerbated by rbx's propensity to use pure Ruby wherever possible):

SystemStackError: SystemStackError
kernel/common/string.rb:1050:in `modify!'

kernel/common/string19.rb:418:in `<<'

kernel/common/regexp.rb:111:in `<<'

kernel/common/regexp.rb:277:in `push_current_character!'

kernel/common/regexp.rb:271:in `process_until_group_finished'

kernel/common/regexp.rb:272:in `process_until_group_finished'

kernel/common/regexp.rb:272:in `process_until_group_finished'

kernel/common/regexp.rb:272:in `process_until_group_finished'

kernel/common/regexp.rb:272:in `process_until_group_finished'

kernel/common/regexp.rb:272:in `process_until_group_finished'

kernel/common/regexp.rb:272:in `process_until_group_finished'

kernel/common/regexp.rb:272:in `process_until_group_finished'

kernel/common/regexp.rb:272:in `process_until_group_finished'

kernel/common/regexp.rb:272:in `process_until_group_finished'

kernel/common/regexp.rb:272:in `process_until_group_finished'

kernel/common/regexp.rb:272:in `process_until... 78 levels...

_group_finished'

kernel/common/regexp.rb:272:in `process_until_group_finished'

kernel/common/regexp.rb:272:in `process_until_group_finished'

kernel/common/regexp.rb:272:in `process_until_group_finished'

kernel/common/regexp.rb:272:in `process_until_group_finished'

kernel/common/regexp.rb:221:in `process_group'

kernel/common/regexp.rb:201:in `create_parts'

--
Tony Arcieri

[Joe Fredette]

Interesting. My experience in debugging code with fibers involved is pretty limited, so the big stack of #create_parts called out louder than the stuff above it. Still, looking at the #create_parts code, it is prone to unbounded recursion (see the last line recursive call) when @source isn't being properly updated (perhaps it's not locked appropriately? But that wouldn't make sense since it's not shared.). Looking at it now, I understand better  your theory that the Fiber stack depth is just insufficient (or at least different) on RBX to cause issue.

/Joe

[Brooke McKim]

Out of my own curiosity: What would cause it to start working after you call .read from outside Celluloid?

[Joe Fredette]

My thought was that perhaps it wasn't Celluloid (though looking at it now, I think otherwise). My suggestion was intended to verify that assertion (eg, to rule out Celluloid as part of the problem)

[Brooke McKim]

No, I mean I know it works outside Celluloid, but also if you first call it outside Celluloid and then inside Celluloid it works fine.

[Julien Ammous]

it may just be some caching involved causing the first call to require a larger stack space (it may also be a stupid idea, it did not look at the code).

I am currently mainly using fibers for concurrency on my current project and until now the only time I hit the fiber stack size problem is when using rails with the asset pipeline which resulted in at least call blowing up everything...

Most of the time you will never notice the limited fiber stack size but it would be nice to have a way to change it, there is a feature request on the ruby tracker opened in... 2010, and still open... 

(http://bugs.ruby-lang.org/issues/3187)

I doubt we get anything useful before a looooooong time.