"long int..." exception reported with strange traceback location

[Joe Peterson]

I could not find another example of this via internet searches, so here
it is... I am wondering if this is a python bug or otherwise. The
first example of this happened in a larger program of mine, and the
traceback reports the problem at the start of a "for" loop (making no
sense), but I cannot easily include the full code and instructions here.

So I wrote a small test program containing the offending code, and in
this case the traceback reports the problem happening "during garbage
collection." So in either case, there's something funny going on here.
The call the causes it is "os.utime()". Note that the trigger is a
rediculous timezone value that causes an overflow. But the surprize is
that the traceback does not report its happening in utime.

If anyone has a clue what's really happening, I'd love to know.

Anyway, here is the sample program:

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

import os
import rfc822

fp = file("foo_test_file", "w")
fp.write("hi")
fp.close()

tt = rfc822.parsedate_tz("Fri, 01 Jul 2005 05:04:23 -4000000000000")
t = rfc822.mktime_tz(tt)

print tt
print t

os.utime("foo_test_file", (t, t))

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


Running this gives:

(2005, 7, 1, 5, 4, 23, 0, 0, 0, -144000000000000L)
1.44001120194e+14
Exception exceptions.OverflowError: 'long int too large to convert to
int' in 'garbage collection' ignored
Fatal Python error: unexpected exception during garbage collection



I am running Fedora Core 3, and it is Python version 2.3.4 [GCC 3.4.2
20041017 (Red Hat 3.4.2-6.fc3)].

Thanks, Joe

 

[Michael Hoffman]

I could not find another example of this via internet searches, so here
it is... I am wondering if this is a python bug or otherwise. The
first example of this happened in a larger program of mine, and the
traceback reports the problem at the start of a "for" loop (making no
sense), but I cannot easily include the full code and instructions here.

So I wrote a small test program containing the offending code, and in
this case the traceback reports the problem happening "during garbage
collection." So in either case, there's something funny going on here.
The call the causes it is "os.utime()". Note that the trigger is a
rediculous timezone value that causes an overflow. But the surprize is
that the traceback does not report its happening in utime.

I came up with a simpler testcase. Strangely, the exception occurs in
the statement *following* the os.utime() call:
OverflowError: long int too large to convert to int

Looks like a bug. You should report it on the SourceForge tracker.

 

[Terry Reedy]

I came up with a simpler testcase. Strangely, the exception occurs in
the statement *following* the os.utime() call:

OverflowError: long int too large to convert to int

Looks like a bug. You should report it on the SourceForge tracker.

Please include this simpler test, which make clear that bug not just in
deprecated (I believe) rfc module. Also note:

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.Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: utime() arg 2 must be a tuple (atime, mtime)

which is quite sane. So maybe bug was introduced in 2.3 which you were
running.

 

[Peter Otten]

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: utime() arg 2 must be a tuple (atime, mtime)

which is quite sane.  So maybe bug was introduced in 2.3 which you were
running.

But arg 2 *is* a tuple. So a least the error message is wrong, too.

Peter

 

[Joe Peterson]

Yep, my thinking too. Well, maybe it's all related to the same bug
somehow. OK, I submitted a bug report, and I included a slight
modification of the test case you guys suggested:

----------------
import sys
import os

t = 2147483648L
os.utime("foo_test_file", (t, t))

print "hi"