Repository navigation
ValueError: I/O operation on closed file. in ZipFile destructor #81954
Description
| BPO | 37773 |
|---|---|
| Nosy | @pitrou, @vstinner, @serhiy-storchaka, @joernheissler, @tirkarthi, @akulakov |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2019-08-06.09:35:50.904>
labels = ['3.10', '3.9', 'type-crash', '3.11']
title = 'ValueError: I/O operation on closed file. in ZipFile destructor'
updated_at = <Date 2022-01-23.20:02:33.133>
user = 'https://github.com/joernheissler'bugs.python.org fields:
activity = <Date 2022-01-23.20:02:33.133>
actor = 'iritkatriel'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2019-08-06.09:35:50.904>
creator = 'joernheissler'
dependencies = []
files = []
hgrepos = []
issue_num = 37773
keywords = ['3.8regression']
message_count = 10.0
messages = ['349104', '349105', '389594', '389605', '389611', '389689', '389690', '389691', '396649', '396657']
nosy_count = 6.0
nosy_names = ['pitrou', 'vstinner', 'serhiy.storchaka', 'joernheissler', 'xtreak', 'andrei.avk']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue37773'
versions = ['Python 3.9', 'Python 3.10', 'Python 3.11']
Activity
ChrisBarker-NOAA commentedon Apr 18, 2023
(Python 3.10.10 -- excuse the noise if it's been fixed in 3.11)
What's the status of this? I'm getting similar warnings in my tests:
This is pretty buried -- I'm not using zipfile directly, it's being used by
numpy.savez(), which I am using to store a cache in a temp dir.The odd thing is that this warning does not pop up when I run that test by itself, only when it is run as part of the suite -- which makes me thing it's maybe related to this issue with the GC and old references, but ???
Anyway, I think @akulakov has the right idea -- if you put a guard around the close() call, the warning will go away. Maybe that would hide another more important error, but it seems not unlikely that an object may be deleted having been partially closed already.
serhiy-storchaka commentedon May 18, 2026
This issue is not specific for zipfile. You will get similar symptoms for buffered files with something in the buffer, and for any object with non-trivial destructor. This is how the garbage collector works. More smart garbage collector could see that the BytesIO should not be destroyed before the ZipFile which refers to it. It could also see that destroying the BytesIO and the ZipFile will not help to break the loop cause by the function. But this is a complex issue.
Recommendation: always use ZipFile as the content manager, or ensure that
close()is always called (in thefinallyblock if necessary). Do not rely on the garbage collector, it can destroy object in wrong order.cmaloney commentedon Jun 27, 2026
I Created #152354 to raise
ResourceWarningon this case in the same way that GzipFile and TextIOWrapper do which should make the source(s) more straightforward to find with tracemalloc.gh-81954: Warn when ZipFile is closed with unwritten data (#152354)
vstinner commentedon Aug 7, 2026
The zipfile module now emits a ResourceWarning if a zipfile object is not closed explicitly and it's open in write mode. I close the issue.
gh-81954: Use lazy import warnings in zipfile (#155326)
pythongh-81954: Warn when ZipFile is closed with unwritten data (pyth…
pythongh-81954: Use lazy import warnings in zipfile (python#155326)
gh-81954: Eagerly import warnings module to failure of ZipFile.__del_…