[issue11513] Infinite recursion around raising an exception in tarfile

[Evan Dandrea]

New submission from Evan Dandrea <ev at ubuntu.com>:

Using Python tip from Sunday, I noticed that tarfile does not elegantly handle ENOENT by raising a single exception:

>>> tarfile.TarFile.gzopen('fdsfd', 'r')
Traceback (most recent call last):
  File "/home/evan/hg/cpython/Lib/tarfile.py", line 1808, in gzopen
    fileobj = gzip.GzipFile(name, mode + "b", compresslevel, fileobj)
  File "/home/evan/hg/cpython/Lib/gzip.py", line 157, in __init__
    fileobj = self.myfileobj = builtins.open(filename, mode or 'rb')
IOError: [Errno 2] No such file or directory: 'fdsfd'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/evan/hg/cpython/Lib/tarfile.py", line 1812, in gzopen
    fileobj.close()
AttributeError: 'NoneType' object has no attribute 'close'

I tried to fix this in a cross-platform way, by attempting to open the file before processing it, and letting the with statement handle calling close:

diff -r 955547e57cff Lib/tarfile.py
--- a/Lib/tarfile.py	Sun Mar 13 19:32:21 2011 +0100
+++ b/Lib/tarfile.py	Mon Mar 14 19:33:21 2011 -0400
@@ -1793,6 +1793,10 @@
         if len(mode) > 1 or mode not in "rw":
             raise ValueError("mode must be 'r' or 'w'")
 
+        if mode == "r":
+            # force an exception if the file does not exist.
+            with open(name):
+                pass
         try:
             import gzip
             gzip.GzipFile

However, this produces infinite recursion:
...
  File "/home/evan/hg/cpython/Lib/tarfile.py", line 1738, in open
    return func(name, "r", fileobj, **kwargs)
  File "/home/evan/hg/cpython/Lib/tarfile.py", line 1798, in gzopen
    with open(name):
  File "/home/evan/hg/cpython/Lib/tarfile.py", line 1738, in open
    return func(name, "r", fileobj, **kwargs)
RuntimeError: maximum recursion depth exceeded

Curiously, if I force the ValueError in that same function to be triggered (by passing a three character string for the mode), that exception is raised fine.  I am therefore wondering if this is a bug in the exit processing.

Unfortunately, my attempts at producing a general test case have been unsuccessful thusfar.

----------
components: Interpreter Core
messages: 130932
nosy: ev
priority: normal
severity: normal
status: open
title: Infinite recursion around raising an exception in tarfile

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11513>
_______________________________________