Ramaze 100% CPU usage with static files on Ruby 1.9.1p0
Phrogz
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.
Slim2:ObjJob phrogz$ ruby -v
ruby 1.9.1p0 (2009-01-30 revision 21907) [i386-darwin9.6.0]
Slim2:ObjJob phrogz$ gem list # not all of these are, of course,
needed to reproduce
*** LOCAL GEMS ***
abstract (1.0.0)
daemons (1.0.10)
erubis (2.6.3)
gem_plugin (0.2.3)
rack (0.9.1)
ramaze (2009.01)
sequel (2.10.0)
Slim2:ObjJob phrogz$ ls -Fla
total 8
drwxr-xr-x 4 phrogz staff 136 Feb 11 08:18 ./
drwxr-xr-x+ 15 phrogz staff 510 Feb 11 08:16 ../
drwxr-xr-x 3 phrogz staff 102 Feb 11 08:18 public/
-rw-r--r--@ 1 phrogz staff 71 Feb 11 08:19 start.rb
Slim2:ObjJob phrogz$ ls -Fla public/
total 8
drwxr-xr-x 3 phrogz staff 102 Feb 11 08:18 ./
drwxr-xr-x 4 phrogz staff 136 Feb 11 08:18 ../
-rw-r--r--@ 1 phrogz staff 23 Feb 11 08:18 static.css
Slim2:ObjJob phrogz$ cat public/static.css
/* content doesn't matter */
body { background:red }
Slim2:ObjJob phrogz$ ruby start.rb &
[1] 669
Slim2:ObjJob phrogz$ [2009-02-11 08:22:07] INFO Starting up Ramaze
(Version 2009.01)
[2009-02-11 08:22:07] WARN View root: 'view' doesn't exist
[2009-02-11 08:22:07] DEBUG mapped Controllers: {"/"=>MainController}
[2009-02-11 08:22:07] INFO Ramaze is ready to run on: 0.0.0.0:7000
using Ramaze::Adapter::WEBrick
[2009-02-11 08:22:07] INFO WEBrick 1.3.1
[2009-02-11 08:22:07] INFO ruby 1.9.1 (2009-01-30) [i386-
darwin9.6.0]
[2009-02-11 08:22:07] DEBUG TCPServer.new(0.0.0.0, 7000)
[2009-02-11 08:22:07] DEBUG Rack::Handler::WEBrick is mounted on /.
[2009-02-11 08:22:07] INFO WEBrick::HTTPServer#start: pid=669
port=7000
curl http://localhost:7000/static.css
[2009-02-11 08:22:18] DEBUG accept: 127.0.0.1:49654
[2009-02-11 08:22:18] DEBUG Rack::Handler::WEBrick is invoked.
[2009-02-11 08:22:18] DEBUG Serving static: public/static.css
^C
At the end there, you can let the machine sit for minutes at 100% CPU
usage with no results.
Phrogz
like this:
Slim2:ObjJob phrogz$ cat start.rb
require 'rubygems'
require 'ramaze'
Ramaze.start :adapter=>:webrick
(but I'm typing that by hand, so there may be a minor typo)
jesusisramaz...@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. :)
--
Pistos
http://blog.purepistos.net
Michael Fellinger
Does this happen every time?
^ manveru
jesusisramaz...@geoshell.com
> Does this happen every time?
Yes, 100% reproducible. For example, with code like this:
http://gist.github.com/61840
--
Pistos
http://blog.purepistos.net
Gavin Kistner
wrote:
> 2009/2/12 Michael Fellinger - m.fel...@gmail.com:
>> Does this happen every time?
>
> Yes, 100% reproducible. For example, with code like this:
> http://gist.github.com/61840
My discovery is that you don't even need the index page or the
controller. Simply request the static css file directly.
Michael Fellinger
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.
^ manveru
Michael Fellinger
OK, fixed and pushed:
http://github.com/manveru/ramaze/commit/244b7a6e97ea1c196e9a3302d43c98e5de469843
^ manveru
ara.t.howard
On Feb 12, 2009, at 11:43 PM, Michael Fellinger wrote:
> OK, fixed and pushed:
> http://github.com/manveru/ramaze/commit/244b7a6e97ea1c196e9a3302d43c98e5de469843
>
> ^ manveru
care to explain that? very interesting ;-)
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
Michael Fellinger
>
>
> On Feb 12, 2009, at 11:43 PM, Michael Fellinger wrote:
>
>> OK, fixed and pushed:
>> http://github.com/manveru/ramaze/commit/244b7a6e97ea1c196e9a3302d43c98e5de469843
>>
>> ^ manveru
>
> care to explain that? very interesting ;-)
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.
^ manveru
ara.t.howard
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.
Gavin Kistner
> http://github.com/manveru/ramaze/commit/244b7a6e97ea1c196e9a3302d43c98e5de469843
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?
Michael Fellinger
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
ara.t.howard
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.
jesusisramaz...@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.
--
Pistos
http://blog.purepistos.net
Michael Fellinger
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.
http://github.com/manveru/ramaze/commit/8d82a6c70787bf53a087bc725d93f65a95ac09af
http://github.com/manveru/ramaze/commit/1f6a3e193d85d646f9d93383239a10b772ac81b6
The problem seems to be that the header.each while assigning would
result in an endless loop in 1.9.1.
^ manveru
Phrogz
> On Fri, Feb 13, 2009 at 3:43 PM, Michael Fellinger
> >http://github.com/manveru/ramaze/commit/244b7a6e97ea1c196e9a3302d43c9...
> 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 problem seems to be that the header.each while assigning would
> result in an endless loop in 1.9.1.
and a working application using Thin.
Nice work :)
sam carr
modify the comment for the patched code, so the comment is now wrong
and would confuse readers.
Michael Fellinger
Patches welcome :)
^ manveru
tama
On Sat, 14 Feb 2009 21:42:18 +0900, Michael Fellinger
<m.fel...@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.
>
> http://github.com/manveru/ramaze/commit/8d82a6c70787bf53a087bc725d93f65a95ac09af
> http://github.com/manveru/ramaze/commit/1f6a3e193d85d646f9d93383239a10b772ac81b6
>
> The problem seems to be that the header.each while assigning would
> result in an endless loop in 1.9.1.
>
> ^ manveru
Nice work!!
My application is working on Windows XP/Mac OS X.
Using servers are WEBrick and Mongrel.
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.
Umm...
tama
--
tama <repea...@gmail.com>
http://profile.livedoor.com/repeatedly/
メンバー募集中
http://sites.google.com/site/tpfreaks/
Phrogz
> 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.
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.
Phrogz
> 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.
>
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.
Max
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