jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • JRuby
  • JRUBY-1527

Tempfile fails to clean up because of lack of finalizer support

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: JRuby 1.0.1
  • Fix Version/s: JRuby 1.1RC3
  • Component/s: Core Classes/Modules
  • Labels:
    None
  • Environment:
    Java : version "1.6.0_02"
    OS : Linux(FedoraCore 6)

Description

After this test has finished, Some Tempfile is remained in /tmp.

0.upto(99) do
  Tempfile.new("test_tempfile")
end

see JRUBY-282

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Charles Oliver Nutter added a comment - 07/Nov/07 1:10 AM

Can you check this against JRuby 1.0.2 and 1.1b1?

Show
Charles Oliver Nutter added a comment - 07/Nov/07 1:10 AM Can you check this against JRuby 1.0.2 and 1.1b1?
Hide
Permalink
Yoshitake Hamano added a comment - 08/Nov/07 7:32 PM

This occurs on JRuby 1.0.2 and 1.1b1.

Show
Yoshitake Hamano added a comment - 08/Nov/07 7:32 PM This occurs on JRuby 1.0.2 and 1.1b1.
Hide
Permalink
Riley Lynch added a comment - 10/Nov/07 4:40 PM

I can reproduce this with trunk r4889. The problem seems to be that since the underlying IOHandlers are closed by the java finalizer when they are garbage-collected, the ruby finalizer is throwing EBADF when it tries to close the already closed file:

/Users/rlynch/Development/Projects/ruby/jruby/trunk/jruby/lib/ruby/1.8/tempfile.rb:146:in `callback': Bad file descriptor (Errno::EBADF)

JRuby then gives up on running any other finalizers, leaving behind the tempfiles.

A couple of questions to answer in resolving this:

  • Should JRuby be so aggressive about closing IOHandlers? Ruby provides the IO::open block syntax if you want to automatically close file descriptors at the end of the scope of the objects that open them. But JRuby automatically closes them whenever the IO objects fall out of scope, regardless of how they are instantiated. This bug is one example of the incompatibilities that could result, but any case where filenos are maintained separately from IO instances may see similar results – see also JRUBY-1079, where sysopen allocates a fileno without returning an IO instance. Both of these problems could be resolved by making the ioHandlers hash hold hard references, thereby keeping the file descriptors open until global destruction, or until they are explicitly closed.
  • Is this the correct behavior for finalizers at global destruction: Should an exception in one finalizer abort the execution of other finalizers?
Show
Riley Lynch added a comment - 10/Nov/07 4:40 PM I can reproduce this with trunk r4889. The problem seems to be that since the underlying IOHandlers are closed by the java finalizer when they are garbage-collected, the ruby finalizer is throwing EBADF when it tries to close the already closed file: /Users/rlynch/Development/Projects/ruby/jruby/trunk/jruby/lib/ruby/1.8/tempfile.rb:146:in `callback': Bad file descriptor (Errno::EBADF) JRuby then gives up on running any other finalizers, leaving behind the tempfiles. A couple of questions to answer in resolving this:
  • Should JRuby be so aggressive about closing IOHandlers? Ruby provides the IO::open block syntax if you want to automatically close file descriptors at the end of the scope of the objects that open them. But JRuby automatically closes them whenever the IO objects fall out of scope, regardless of how they are instantiated. This bug is one example of the incompatibilities that could result, but any case where filenos are maintained separately from IO instances may see similar results – see also JRUBY-1079, where sysopen allocates a fileno without returning an IO instance. Both of these problems could be resolved by making the ioHandlers hash hold hard references, thereby keeping the file descriptors open until global destruction, or until they are explicitly closed.
  • Is this the correct behavior for finalizers at global destruction: Should an exception in one finalizer abort the execution of other finalizers?
Hide
Permalink
Charles Oliver Nutter added a comment - 17/Mar/08 7:51 PM

I believe this has been fixed; I ran the given test case and all tempfiles were properly cleaned up. Please reopen if the issue is not actually resolved, or file new bugs if there are additional problems.

Show
Charles Oliver Nutter added a comment - 17/Mar/08 7:51 PM I believe this has been fixed; I ran the given test case and all tempfiles were properly cleaned up. Please reopen if the issue is not actually resolved, or file new bugs if there are additional problems.

People

  • Assignee:
    Charles Oliver Nutter
    Reporter:
    Yoshitake Hamano
Vote (0)
Watch (2)

Dates

  • Created:
    05/Nov/07 3:35 AM
    Updated:
    07/Apr/08 4:01 PM
    Resolved:
    17/Mar/08 7:51 PM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.