Pistos pared this down a good bit last night on IRC and for all I know
has already found the problem and solved it. But in case he hasn't:
Ramaze on 1.9.1p0 stalls with 100% CPU usage trying to send static
files (in my test it occurred with both CSS and SVG). This was on OS
X, but I think Pistos reproduced on another platform.
Here's a super-simple test case using Webrick, but it's been
reproduced also with Thin.
Discussion subject changed to "Ramaze 100% CPU usage with static files on Ruby 1.9.1p0 (jesusisramazing: to exclusive)" by jesusisramazing.10.pis...@geoshell.com
> Pistos pared this down a good bit last night on IRC and for all I know > has already found the problem and solved it. But in case he hasn't:
> Ramaze on 1.9.1p0 stalls with 100% CPU usage trying to send static > files (in my test it occurred with both CSS and SVG). This was on OS > X, but I think Pistos reproduced on another platform.
Gentoo Linux, 2.6 kernel, Ramaze 2009.01, Rack 0.9.1. Running strace on it showed a tonne of stuff on startup, finally ending with:
futex(0x81ad2dc, FUTEX_WAIT, 5, NULL
And then when you hit the server, there is no further strace output whatsoever until you ^C the process. I can't explain this. :)
Discussion subject changed to "Ramaze 100% CPU usage with static files on Ruby 1.9.1p0 (jesusisramazing: to exclusive)" by jesusisramazing.10.pis...@geoshell.com
On Thu, Feb 12, 2009 at 11:29 PM, Gavin Kistner <phr...@mac.com> wrote:
> On Feb 12, 2009, at 5:02 AM, jesusisramazing.10.pis...@geoshell.com > wrote: >> 2009/2/12 Michael Fellinger - m.fellin...@gmail.com: >>> Does this happen every time?
> My discovery is that you don't even need the index page or the > controller. Simply request the static css file directly.
That's so very weird... strace shows that it is caught in a "sched_yield()" loop, but the same works fine with the innate branch, will see if i can find the problem.
<m.fellin...@gmail.com> wrote: > On Thu, Feb 12, 2009 at 11:29 PM, Gavin Kistner <phr...@mac.com> wrote:
>> On Feb 12, 2009, at 5:02 AM, jesusisramazing.10.pis...@geoshell.com >> wrote: >>> 2009/2/12 Michael Fellinger - m.fellin...@gmail.com: >>>> Does this happen every time?
>> My discovery is that you don't even need the index page or the >> controller. Simply request the static css file directly.
> That's so very weird... strace shows that it is caught in a > "sched_yield()" loop, but the same works fine with the innate branch, > will see if i can find the problem.
a @ http://codeforpeople.com/ -- we can deny everything, except that we have the possibility of being better. simply reflect on that. h.h. the 14th dalai lama
Good question, but I have no idea about the real reason. I asked Matz a few months ago to let Fiber::new call #initialize like any other class. The definition of Fiber::new was needed before he merged that into 1.9. Now ::new and #initialize seem to have actual functionality wich we prevented from running. Using proper subclassing fixes that.
On Feb 13, 2009, at 12:30 AM, Michael Fellinger wrote:
> Good question, but I have no idea about the real reason. > I asked Matz a few months ago to let Fiber::new call #initialize like > any other class. > The definition of Fiber::new was needed before he merged that into > 1.9. > Now ::new and #initialize seem to have actual functionality wich we > prevented from running. > Using proper subclassing fixes that.
wow - really interesting.
thanks for sharing.
a @ http://codeforpeople.com/ -- we can deny everything, except that we have the possibility of being better. simply reflect on that. h.h. the 14th dalai lama
> Wow, nice work. Thanks! > (Haven't confirmed that it works locally, but I trust you.)
> Since I prefer official gems that I can latch onto the version over > github snapshots, any thoughts on when a next release might be coming?
You know the nice thing about our current versioning scheme? We can push out new versions whenever we want :) Will push a new version to github tomorrow, maybe Pistos can put the gem up on rubyforge then.
On Feb 13, 2009, at 8:49 AM, Michael Fellinger wrote:
> You know the nice thing about our current versioning scheme? We can > push out new versions whenever we want :) > Will push a new version to github tomorrow, maybe Pistos can put the > gem up on rubyforge then.
> ^ manveru
i had an idea the other day about installing gem installers on rubyforge - using extconf.rb one could actually install from github. so maybe ramaze and ramze-bleeding-edge are both gems on rubyforge, the later simple abuses extconf.rb and pulls from github. all this does is prevent people from hunting around and provides some connection between official projects and their respective github account-gems, but it might be nice.
a @ http://codeforpeople.com/ -- we can deny everything, except that we have the possibility of being better. simply reflect on that. h.h. the 14th dalai lama
Discussion subject changed to "Ramaze 100% CPU usage with static files on Ruby 1.9.1p0 (jesusisramazing: to exclusive) (jesusisramazing: to exclusive)" by jesusisramazing.10.pis...@geoshell.com
> Since I prefer official gems that I can latch onto the version over > github snapshots, any thoughts on when a next release might be coming?
That's actually my department; and this bugfix is probably as good a reason as any to push a release out. I'll talk it over with manveru and barring any vetoes, will aim to get 2009.02 out this weekend.
<m.fellin...@gmail.com> wrote: > On Fri, Feb 13, 2009 at 2:54 PM, Michael Fellinger > <m.fellin...@gmail.com> wrote: >> On Thu, Feb 12, 2009 at 11:29 PM, Gavin Kistner <phr...@mac.com> wrote:
>>> On Feb 12, 2009, at 5:02 AM, jesusisramazing.10.pis...@geoshell.com >>> wrote: >>>> 2009/2/12 Michael Fellinger - m.fellin...@gmail.com: >>>>> Does this happen every time?
>>> My discovery is that you don't even need the index page or the >>> controller. Simply request the static css file directly.
>> That's so very weird... strace shows that it is caught in a >> "sched_yield()" loop, but the same works fine with the innate branch, >> will see if i can find the problem.
The above wasn't the actual fix, i fear... That somehow worked temporarily for me but there was another issue that i fixed in the meanwhile. Would be nice if you guys could try it out on windows/osx since i can only confirm it for linux.
> The above wasn't the actual fix, i fear... That somehow worked
> temporarily for me but there was another issue that i fixed in the
> meanwhile. Would be nice if you guys could try it out on windows/osx
> since i can only confirm it for linux.
But if I'm going to be picky (which I usually am) the patch failed to modify the comment for the patched code, so the comment is now wrong and would confuse readers.
On Sun, Feb 15, 2009 at 6:23 AM, sam carr <samc...@gmail.com> wrote:
> But if I'm going to be picky (which I usually am) the patch failed to > modify the comment for the patched code, so the comment is now wrong > and would confuse readers.
On Sat, 14 Feb 2009 21:42:18 +0900, Michael Fellinger
<m.fellin...@gmail.com> wrote: > The above wasn't the actual fix, i fear... That somehow worked > temporarily for me but there was another issue that i fixed in the > meanwhile. Would be nice if you guys could try it out on windows/osx > since i can only confirm it for linux.
On Feb 14, 11:41 am, tama <repeate...@gmail.com> wrote:
> Maybe this problem is the same in the following code.
> h = {1 => nil, 2 => nil}
> h.each do |k, v|
> h.delete k
> h[k] = v
> end
> This code works in Ruby 1.8, but doesn't works in Ruby 1.9.
Now that hashes are ordered, I wonder if the above is by design or
not. (I could imagine that someone might think you should iterate all
keys in a hash until no more are added.) However, I'm thinking it's a
bug in 1.9, since this code does not iterate over the newly-added key:
a = [ 1, 2, 3 ]
h = { 0=>0 }
h.each{ |k,v| h[a[k]] = a[k] }
p h
#=> { 0=>0, 1=>1 }
I'll go bring this up on ruby-talk. Nice simple example, tama.
On Feb 15, 7:39 am, Phrogz <phr...@mac.com> wrote:
> On Feb 14, 11:41 am, tama <repeate...@gmail.com> wrote:
> > h = {1 => nil, 2 => nil}
> > h.each do |k, v|
> > h.delete k
> > h[k] = v
> > end
> > This code works in Ruby 1.8, but doesn't works in Ruby 1.9.
> I'll go bring this up on ruby-talk. Nice simple example, tama.
For the record on this group, the consensus on ruby-talk is that
modifying a hash during iteration is a Bad Idea with no guarantee as
to what will happen. Though not explicitly documented as such, the
'bug' is with any original code that tries to modify a hash during
iteration and expects consistent results.
So I started out with a working environment tonight, but after sudo
aptitude installing a package and rebuilding ruby 1.9.1, I'm now
getting this 100% cpu usage problem. The package? libreadline5-dev.
Not sure how that could be related, but...it might be. Ubuntu 8.10.
Max
On Feb 17, 9:48 am, Phrogz <phr...@mac.com> wrote:
> On Feb 15, 7:39 am, Phrogz <phr...@mac.com> wrote:
> > On Feb 14, 11:41 am, tama <repeate...@gmail.com> wrote:
> > > h = {1 => nil, 2 => nil}
> > > h.each do |k, v|
> > > h.delete k
> > > h[k] = v
> > > end
> > > This code works in Ruby 1.8, but doesn't works in Ruby 1.9.
> > I'll go bring this up on ruby-talk. Nice simple example, tama.
> For the record on this group, the consensus on ruby-talk is that
> modifying a hash during iteration is a Bad Idea with no guarantee as
> to what will happen. Though not explicitly documented as such, the
> 'bug' is with any original code that tries to modify a hash during
> iteration and expects consistent results.
