[ python-Bugs-1232517 ] OverflowError in time.utime() causes strange traceback

SourceForge.net noreply at sourceforge.net
Tue Jul 5 16:08:13 CEST 2005


Bugs item #1232517, was opened at 2005-07-04 22:35
Message generated for change (Comment added) made by skyrush
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232517&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Peterson (skyrush)
Assigned to: Nobody/Anonymous (nobody)
Summary: OverflowError in time.utime() causes strange traceback

Initial Comment:
When time.utime() is called with a number larger than
an int, it will fail, but the traceback will not show
the line containing the utime() call.  Instead, the
error will be reported sometime later, depending on the
conditions.

In the attached example (note the file "foo_test_file"
must exist first), a number one larger than maxint is
passed, causing the following error:

Exception exceptions.OverflowError: 'long int too large
to convert to int' in 'garbage collection' ignored
Fatal Python error: unexpected exception during garbage
collection
Aborted

My original discovery of this problem was in a larger
program, and in this original case, I was generating
the large integer via a call to mktime_tz in the rfc822
module in which an out-of-range timezone value was
used.  The call was near the end of a "for" block, and
the OverflowError was reported as coming from the for
statement of the block itself (which did not make sense).

I produced a small test case, which moved the reported
error to "garbage collection".  Thanks to some folks on
the python mailing list for helping to further simplify
the test case.


----------------------------------------------------------------------

>Comment By: Joe Peterson (skyrush)
Date: 2005-07-05 08:08

Message:
Logged In: YES 
user_id=738814

I will have to get the python source - using binary right
now, but I'll try the patch and let you know.

Might this not be a larger problem in Python, however?  Or
is it normal for non-caught errors in C modules to be able
to confuse the interpreter?  For example, someone from the
mailing list submitted the following result on Python 2.2,
which shows a different thing happening, but clearly also
strangeness, given that the passed argument *is* a tuple:

Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import os, sys
>>> os.utime("foo_test_file", (0, float(sys.maxint+1)))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: utime() arg 2 must be a tuple (atime, mtime)



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-07-05 07:27

Message:
Logged In: YES 
user_id=6656

Can you try the attached patch?

----------------------------------------------------------------------

Comment By: Joe Peterson (skyrush)
Date: 2005-07-05 07:18

Message:
Logged In: YES 
user_id=738814

Oh, guess it's not enough to fill in the upload type-in
field - that pesky little checkbox needs to be checked. 
Sneaky...  OK, it should be attached now.

----------------------------------------------------------------------

Comment By: Joe Peterson (skyrush)
Date: 2005-07-05 07:17

Message:
Logged In: YES 
user_id=738814

So sorry!  Yes, os.utime().

And I thought I attached the file - trying again...


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-07-05 05:18

Message:
Logged In: YES 
user_id=6656

You mean os.utime (gawd, that confused me) and there's no
attached file...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232517&group_id=5470


More information about the Python-bugs-list mailing list