By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,713 Members | 764 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,713 IT Pros & Developers. It's quick & easy.

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

P: n/a
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
Jul 21 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Joe Peterson wrote:
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:
import os, sys
os.utime("foo_test_file", (0, float(sys.maxint+1)))
print "hi"

OverflowError: long int too large to convert to int

Looks like a bug. You should report it on the SourceForge tracker.
--
Michael Hoffman
Jul 21 '05 #2

P: n/a

"Michael Hoffman" <ca*******@mh391.invalid> wrote in message
news:da**********@gemini.csx.cam.ac.uk...
I came up with a simpler testcase. Strangely, the exception occurs in
the statement *following* the os.utime() call:
import os, sys
os.utime("foo_test_file", (0, float(sys.maxint+1)))
print "hi" 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.
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)

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

Jul 21 '05 #3

P: n/a
Terry Reedy wrote:
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)

which is quite sane.**So*maybe*bug*was*introduced*in*2.3*which*yo u*were
running.


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

Peter

Jul 21 '05 #4

P: n/a
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"
----------------

This way, there's no "float" call, simply an asignment of a long int...

Thanks, Joe
Peter Otten wrote:
Terry Reedy wrote:

>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)

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

Jul 21 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.