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]
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.
On Mon, Nov 12, 2012 at 5:49 PM, Brooke McKim <brooke.mc...@gmail.com>wrote:
> 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]
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!
On Mon, Nov 12, 2012 at 8:49 PM, Brooke McKim <brooke.mc...@gmail.com>wrote:
> 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]
On Monday, November 12, 2012 8:49:47 PM UTC-5, Brooke McKim wrote:
> 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]
> I should also note that if I use Net::HTTP.get_response( URI.parse(url) )
> instead of .read it works fine.
> On Monday, November 12, 2012 8:49:47 PM UTC-5, Brooke McKim wrote:
>> Hello All,
>> I am not sure if this is a Rubinius bug or Celluloid bug, but
>> https://gist.github.com/**4063344 <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]
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.
On Mon, Nov 12, 2012 at 8:56 PM, Brooke McKim <brooke.mc...@gmail.com>wrote:
> I should also note that if I use Net::HTTP.get_response( URI.parse(url) )
> instead of .read it works fine.
> On Monday, November 12, 2012 8:49:47 PM UTC-5, Brooke McKim wrote:
>> Hello All,
>> I am not sure if this is a Rubinius bug or Celluloid bug, but
>> https://gist.github.com/**4063344 <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]
On Mon, Nov 12, 2012 at 6:02 PM, Joseph Fredette <jfred...@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):
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
On Nov 12, 2012, at 9:05 PM, Tony Arcieri <tony.arci...@gmail.com> wrote:
> On Mon, Nov 12, 2012 at 6:02 PM, Joseph Fredette <jfred...@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):
On Monday, November 12, 2012 9:05:57 PM UTC-5, Tony Arcieri wrote:
> On Mon, Nov 12, 2012 at 6:02 PM, Joseph Fredette <jfre...@gmail.com<javascript:> > > 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):
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)
On Nov 13, 2012, at 12:39 PM, Brooke McKim <bmc...@telvue.com> wrote:
> Out of my own curiosity: What would cause it to start working after you call .read from outside Celluloid?
> On Monday, November 12, 2012 9:05:57 PM UTC-5, Tony Arcieri wrote:
> 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):
On Tue, Nov 13, 2012 at 12:44 PM, Joe Fredette <jfred...@gmail.com> wrote:
> 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)
> On Nov 13, 2012, at 12:39 PM, Brooke McKim <bmc...@telvue.com> wrote:
> Out of my own curiosity: What would cause it to start working after you
> call .read from outside Celluloid?
> On Monday, November 12, 2012 9:05:57 PM UTC-5, Tony Arcieri wrote:
>> 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):
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.
On Tuesday, 13 November 2012 18:47:11 UTC+1, Brooke McKim wrote:
> 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.
> On Tue, Nov 13, 2012 at 12:44 PM, Joe Fredette <jfre...@gmail.com<javascript:> > > wrote:
>> 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)
>> On Nov 13, 2012, at 12:39 PM, Brooke McKim <bmc...@telvue.com<javascript:>> >> wrote:
>> Out of my own curiosity: What would cause it to start working after you >> call .read from outside Celluloid?
>> On Monday, November 12, 2012 9:05:57 PM UTC-5, Tony Arcieri wrote:
>>> 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):
