You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using an example ecsv file from the astropy documentation:
# %ECSV 0.9
# ---
# datatype:
# - {name: a, unit: m / s, datatype: int64, format: '%03d'}
# - {name: b, unit: km, datatype: int64, description: This is column b}
a b
001 2
004 3
(although this works for anything I tried, including rdb files) when I try to read it with a python with warnings enabled (e.g. python -Wd) I get a resource warning:
My hunch is that something done during the guessing game wasn't closed properly. And since disabling fast reader did not get rid of the warning, it is probably some Python reader in the "things to guess with" list. I tried code diving but got lost in 🐰 🕳 . @taldcroft , any ideas?
Also, it seems like this warning only appears when used with python -Wd or explicitly caught in IPython session. Otherwise, you won't see it. I also wonder why our CI didn't catch this, as we have --open-files check.
Yes, maybe I buried the -Wd in my initial report. I always run with warnings maximally enabled so that I can stay ahead of problems. I'm pretty sure that ResourceWarning is telling you that python eventually works it out and closes the file for you. open-files only looks for files that have been left open which haven't been automatically closed by Python. It's warning us to ensure that we can work out we have a potential problem.
Here is what I've figured out. The issue is primarily related to get_readable_fileobj (in astropy/utils/data.py), which appears to not be closing files in its context manager when the input is itself a file handle. Here is the upshot of I/O that happens during the Table.read() call:
ctx = get_readable_fileobj('junk.ecsv', encoding='binary')
fileobj = ctx.__enter__()
with get_readable_fileobj(fileobj, encoding='UTF-8') as fileobj2:
out = fileobj2.read()
print(fileobj2.closed) # prints False, I would have expected True
ctx.__exit__(*sys.exc_info())
print(fileobj2.closed) # prints True at this point
I confirmed with print statements in the actual code that the io.ascii file object used to read the file is not closed after the context manager returns. The __exit__ for the get_readable_fileobj context manager is looping over some lists of file descriptors that are to be closed, but that list is empty in this case.
So one thing relates to the very end the get_readable_fileobj which has a list of file descriptors to close. In the code above one does not actually get a ResourceWarning and the list of FDs to close is [<_io.FileIO name='junk.ecsv' mode='rb' closefd=True>]. But in the actual Table.read('junk.ecsv') call that final list is [<_io.FileIO [closed]>] . So maybe that fileobj is getting closed somewhere else and mucking things up.
I came into get_readable_fileobj as well, and I think that the TextIOWrapper created in the needs_textio_wrapper block must be closed:
--- a/astropy/utils/data.py
+++ b/astropy/utils/data.py
@@ -295,6 +295,7 @@ def get_readable_fileobj(name_or_obj, encoding=None, cache=False,
fileobj = io.BufferedReader(fileobj)
fileobj = io.TextIOWrapper(fileobj, encoding=encoding)
+ close_fds.append(fileobj)
# Ensure that file is at the start - io.FileIO will for
# example not always be at the start:
With this I no more have the warning, and tests pass (I didn't run the full test suite, but io seems ok).
I won't have much more time to investigate, if you want to try with this @taldcroft .
Just a note to say that this is still a problem for us and we worry that it's showing a real problem. We are reading hundreds of these files and the warnings are overwhelming so we've finally cracked and now mask them all (lsst/meas_algorithms#192).
@timj - I'll try looking into this again. And likewise the astropy.utils maintainers since the root cause seems to be get_readable_fileobj. I remember my head hurting the last time looking at that code.
Activity
timj commentedon May 7, 2019
This is with astropy 3.1.2 from conda.
timj commentedon May 7, 2019
Fast reader does not seem to be the issue:
pllim commentedon May 7, 2019
My hunch is that something done during the guessing game wasn't closed properly. And since disabling fast reader did not get rid of the warning, it is probably some Python reader in the "things to guess with" list. I tried code diving but got lost in 🐰 🕳 . @taldcroft , any ideas?
pllim commentedon May 7, 2019
Also, it seems like this warning only appears when used with
python -Wdor explicitly caught in IPython session. Otherwise, you won't see it. I also wonder why our CI didn't catch this, as we have--open-filescheck.timj commentedon May 7, 2019
Yes, maybe I buried the
-Wdin my initial report. I always run with warnings maximally enabled so that I can stay ahead of problems. I'm pretty sure thatResourceWarningis telling you that python eventually works it out and closes the file for you.open-filesonly looks for files that have been left open which haven't been automatically closed by Python. It's warning us to ensure that we can work out we have a potential problem.taldcroft commentedon May 7, 2019
Here is what I've figured out. The issue is primarily related to
get_readable_fileobj(inastropy/utils/data.py), which appears to not be closing files in its context manager when the input is itself a file handle. Here is the upshot of I/O that happens during theTable.read()call:I confirmed with print statements in the actual code that the
io.asciifile object used to read the file is not closed after the context manager returns. The__exit__for theget_readable_fileobjcontext manager is looping over some lists of file descriptors that are to be closed, but that list is empty in this case.So one thing relates to the very end the
get_readable_fileobjwhich has a list of file descriptors to close. In the code above one does not actually get a ResourceWarning and the list of FDs to close is[<_io.FileIO name='junk.ecsv' mode='rb' closefd=True>]. But in the actualTable.read('junk.ecsv')call that final list is[<_io.FileIO [closed]>]. So maybe that fileobj is getting closed somewhere else and mucking things up.saimn commentedon May 7, 2019
I came into
get_readable_fileobjas well, and I think that theTextIOWrappercreated in theneeds_textio_wrapperblock must be closed:With this I no more have the warning, and tests pass (I didn't run the full test suite, but
ioseems ok).I won't have much more time to investigate, if you want to try with this @taldcroft .
saimn commentedon May 7, 2019
And I just see your PR after pushing the comment button 😁
bsipocz commentedon May 7, 2019
Two of you coming to the same conclusion means something :)
Could you then review/approve the PR?
timj commentedon Apr 9, 2020
Just a note to say that this is still a problem for us and we worry that it's showing a real problem. We are reading hundreds of these files and the warnings are overwhelming so we've finally cracked and now mask them all (lsst/meas_algorithms#192).
taldcroft commentedon Apr 9, 2020
@timj - I'll try looking into this again. And likewise the astropy.utils maintainers since the root cause seems to be
get_readable_fileobj. I remember my head hurting the last time looking at that code.taldcroft commentedon Apr 9, 2020
Or not, just looking at #8675 again as well. Ugh.
bnavigator commentedon Oct 22, 2020
These messages still appear when testing 4.1:
And more of the same type for many different file type tests.