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.

Logged In: YES 
user_id=6656

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

Logged In: YES 
user_id=738814

So sorry!  Yes, os.utime().

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

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.

Logged In: YES 
user_id=6656

Can you try the attached patch?

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)

Logged In: YES 
user_id=6656

> Might this not be a larger problem in Python, however?

No, not really.

> Or
> is it normal for non-caught errors in C modules to be able
> to confuse the interpreter?

Yes.

(I don't care about 2.2 any more, sorry).

Logged In: YES 
user_id=738814

I tried the patch (actually on 2.4.1 source), and it works.

Logged In: YES 
user_id=6656

OK, this is fixed in

Misc/NEWS revision 1.1310
Modules/posixmodule.c revision 2.337

Thanks for the report and the test!

Logged In: YES 
user_id=738814

Cool - glad to be of help!