IOError

[llopez]

IOError

[markevans]

Hi - where and when does this happen?

[markevans]

also, what's your configuration? or are you using 'dragonfly/rails/images' ?

[llopez]

yes, I am using dragonfly/rails/images

[llopez]

the error does not happen all the time. only sometimes.

[llopez]

this is the complete stack
http://pastie.org/1160936

[markevans]

Do you have a backtrace? Also what environment is it running on? Is it passenger?
Thanks

[llopez]

locally I'm using mongrel, but the error also occurs on passenger + nginx.

Thank you.

[llopez]

this line is shooting the error, sometimes.
= image_tag featured.photos.first.image.thumb("70x70#").url

[scottnicolson]

i am getting this error also. using rails 3 webrick. can't work out the pattern to make it fail all the time. it happens often though.

[markevans]

I've seen this once or twice, but can't for the life of me work out what's causing it...
One test fails with it when running 'rake spec', but not when running the file on its own.
It seems to always happen in Tempfile#close
Any help would be appreciated! :)

[markevans]

Annoyingly, this appears to be a bug in Tempfile (which is fixed in Ruby 1.9.2)
http://redmine.ruby-lang.org/issues/show/3119

This post:
http://labnotes.org/2009/09/01/ruby-1-9-1-p234passenger-2-2-5-tempfile-rb-fix/

points out a fix
http://redmine.ruby-lang.org/repositories/diff/ruby-19/lib/tempfile.rb?rev=23494

which seems to work for me:
putting

require 'tempfile'
class Tempfile

  def unlink
    # keep this order for thread safeness
    begin
      if File.exist?(@tmpname)
        closed? or close
        File.unlink(@tmpname)
      end
      @@cleanlist.delete(@tmpname)
      @data = @tmpname = nil
      ObjectSpace.undefine_finalizer(self)
    rescue Errno::EACCES
      # may not be able to unlink on Windows; just ignore
    end
  end

end

in an initializer hopefully does the trick.

Ideally I don't really want to have to include this fix in Dragonfly. I don't know if there's another way around it...

[scottnicolson]

I put this inside the dragonfly initialisation file and i still get the error. i am using ruby ee "ruby 1.8.7 (2010-04-19 patchlevel 253) [i686-darwin10.4.0], MBARI 0x6770, Ruby Enterprise Edition 2010.02"
it is annoying that it isn't consistently repeatable.

[markevans]

It is indeed very annoying.

I see that Rack has a patch for this http://rack.rubyforge.org/doc/Rack/RewindableInput/Tempfile.html

What happens if, instead of putting the patch I pasted above, you include this patch?

require 'tempfile'
class Tempfile
  def _close
    @tmpfile.close if @tmpfile
    @data[1] = nil if @data
    @tmpfile = nil
  end
end

Please let me know and if it fixes it I'll use it in the next version

[shirzad]

I have the same problem using rvm ruby-1.8.7-p174 with Rails 2.3.9
I used both patch methods, it did not work.
I still get this error.
Read error: #<IOError: closed stream>
/.rvm/rubies/ruby-1.8.7-p174/lib/ruby/1.8/tempfile.rb:167:in close' /.rvm/rubies/ruby-1.8.7-p174/lib/ruby/1.8/tempfile.rb:167:incallback'
/.rvm/gems/ruby-1.8.7-p174/gems/builder-2.1.2/lib/blankslate.rb:84:in call' /.rvm/gems/ruby-1.8.7-p174/gems/builder-2.1.2/lib/blankslate.rb:84:inmethod_added'

[scottnicolson]

Sorry mark still no dice. i will do some digging and let you know if i find anything that may help

[benaldred]

I also have the same problem

./.rvm/rubies/ruby-1.8.7-p249/lib/ruby/1.8/tempfile.rb:167:in `close'
/.rvm/rubies/ruby-1.8.7-p249/lib/ruby/1.8/tempfile.rb:167

seems to happen randomly. but seemed to occur maore when i was copying images in a callback

one.image = two.image
one.save

both patches did not work

[lcowell]

I experience this issue on my OS X workstation, but I don't see it on my FreeBSD. It could be the different between the platforms or just that I run in dev mode locally and production mode on the server.

[benaldred]

I am seeing it on my engine yard server which runs in production mode, not sure what platform that runs on

[benaldred]

Hi,

Sorry to be a moaner but is this issue being looked at. I was definitely not getting this error until I updated to the current version of dragonfly (from 0.5.2)

I am trying to go live in the next couple of weeks and the intermittent errors are making that hard.

I may just roll back to 0.5.2 until this gets fixed or I get time to look at the bug.

Again sorry to be a moaner, I know how hard it can be maintaining software and it is a really great library!

[markevans]

Hi
I've looked at it a few times but with no luck - the problem is it's not easily reproduceable because it only happens sporadically. I assume it's something to do with tempfile closing on garbage collection but can't be sure.
I haven't had much time recently and still intend to fix it of course, but would really appreciate any other help on it

[fabiotc]

I've got the same error:
Started GET "/refinery/dialogs/Link" for 127.0.0.1 at Wed Oct 06 12:38:26 -0300 2010

IOError (closed stream):

Using ree1.8.7 with MacOSx

[lcowell]

Mark, would it be helpful to create a ruby script that is able to reproduce this problem ? It could help in making some realizations about what exactly is going wrong. It would also mean that, if needed, we have a snippet of code that we could have some ruby maven look at.

Luke

[alturalabs]

Same problem here, I have this error when trying to upload images from a web url using open(url).read

[benaldred]

That's interesting. I also have a few:

open(url).read

lines in my code. Could it be that these are being left open then the error is triggered on garbage collection?

[benaldred]

Does that mean we need to use a block to close the read?

And why do my error stacks always reference tempfile?

[fabiotc]

In the Rack lib...
When I commented the line 167 in tempfile.rb everything works well....

[benaldred]

@fabiotc

Did you mean you commented out line 167 in tempfile.rb in Rack?
Have you got more details, maybe a gist?

[fabiotc]

I'm using refinerycms (that use drangonfy to manipulate the size of images) and the IOError stopped when I commented that line (167).
In my case: /Users/fabio/.rvm/rubies/ree-1.8.7-2010.01/lib/ruby/1.8/tempfile.rb

[markevans]

@lcowell - yes that would be very helpful thanks for the suggestion. I've already created one which I can now consistently recreate the error, however it needs rails runner to reproduce the error - plain old ruby works fine, even though it's not using rails at all.
It's still tricky to track down though.

@fabiotc - thanks for the tip, though I imagine getting rid of tempfile.close could have some other unwanted side effects? (e.g. tempfiles not getting cleaned up properly?)

[hez]

+1

[benaldred]

@markevans Did you have a gist of the script to reproduce the error. Maybe some of us may be able to help figure it out

[markevans]

@ben - I can reproduce it on my computer by doing the following:

1. create a new rails app

2. create a file in the app test.rb with contents:

   require 'tempfile'

   1000.times do
   Tempfile.new('a').open.close
   end

3. "rails runner test.rb"

As you can see, this happens without dragonfly even being in the project.
I got to this script by using dragonfly and gradually taking away things which were irrelevant.
I get the impression it's some kind of bug with Tempfile that using dragonfly exposes more than usual due to its use of Tempfile.

By the way, you might be able to get round it anyway by using

app.configure_with(:rmagick, :use_filesystem => false)

in your config (see http://markevans.github.com/dragonfly/file.Configuration.html RMagick section)
This use of RMagick is more memory intensive but might be better for some projects.

[markevans]

or even

require 'tempfile'
"a"
Tempfile.new('a').open.close
Tempfile.new('a').open.close
GC.start

reproduces the error (when run with rails runner - can't make it happen with ruby only)

[benaldred]

Cheers for the tip. A combination of using memory and caching should buy me some more time until the problem is solved.

Sounds like this should be submitted as a bug in ruby 1.8.7

[scottnicolson]

@mark do you still get the error if you change your script above to:

require 'tempfile'
"a"
a = Tempfile.new('a')
a.open.close
b = Tempfile.new('a')
b.open.close
GC.start

your script above does fail reliably on my machine however when changed to the above it doesn't. I don't know why this would be. But food for thought.

[markevans]

@snicolson - I get the same as you. I imagine it's because GC.start doesn't garbage-collect the tempfiles as they're assigned to still used variables (a and b)

[mdeering]

Skipping tmp files worked like a charm!

app.configure_with(:rmagick, :use_filesystem => false)

For those using Rails the following works to get the configuration set inside of your rails application.
config/initializers/dragonfly.rb

require 'dragonfly/rails/images'

app = Dragonfly[:images]
app.configure_with(:rmagick, :use_filesystem => false)

http://gist.github.com/647677

[alturalabs]

sadly for me when I set it my app is crashing after 40-70 requests for too many open files... this error is appearing only on my development platform (osx), so it's ok, i just restart my local server

[markevans]

Right - I think I've managed to fix this - check out version 0.7.7 (on rubygems)

It arises from closing the File object returned by tempfile.open, instead of closing the Tempfile object itself (which in turn closes the File object).
I don't know whether that's a ruby 1.8.7 bug or not, but closing the Tempfile itself seems to have fixed the problem.

PLEASE let me know if this fixes it and then I will close this ticket!!!
Thanks

[parndt]

Haven't seen this not once since using 0.7.7 on my RefineryCMS app

So far so good Mark! I'll let you know the minute I see one (which hopefully means never)

[markevans]

awesome! good to hear.

[markevans]

this seems to be fixed so I'm going to close this ticket

[alturalabs]

I haven't seen the problem at all since upgrading to 0.7.7, great!

[mark100net]

Just a heads up. I started experiencing this error with every image upload when I installed the meta_request gem. The upload completes successfully though. I have been unable to determine which gem is at 'fault'.

[jturolla]

I'm also experiencing this issue as @mark100net commented. I'm removing meta_request for now waiting for a fix.

[suciuvlad]

Had the same issue. Removing meta_request from the gemfile fixed it.

[elfassy]

+1 Removing meta_request from the gemfile fixed it.

[djmaze]

Updating to meta_request-0.3.0 seems to have fixed the problem for me.