"long int..." exception reported with strange traceback location
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 -4")
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, -144L)
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: "long int..." exception reported with strange traceback location
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 "", 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
>
--
http://mail.python.org/mailman/listinfo/python-list
Possible to assure no "cyclic"/"uncollectible" memory leaks?
I've been doing a lot of searching on the topic of one of Python's more disturbing issues (at least to me): the fact that if a __del__ finalizer is defined and a cyclic (circular) reference is made, the garbage collector cannot clean it up. First of all, it seems that it's best to avoid using __del__. So far, I have never used it in my Python programming. So I am safe there. Or am I? Also, to my knowledge, I have never created a cyclic reference, but we do not typically create bugs intentionally either (and there are certainly times when it is an OK thing to do). Still, it's not comforting to know that it is possible to create a situation that would create a memory leak using a language that is supposed to relieve us of that worry. I understand the problem, but it would be nice to know that as a programmer, I could be assured that Python would always deal with memory management and that memory leaks were not something I had to think about. So here's a question: if I write Python software and never use __del__, can I guarantee that there is no way to create a memory leak? What about system libraries - do any of them use __del__, and if so, are they written in such a way that it is not possible to create a cyclic reference? Thanks, Joe -- http://mail.python.org/mailman/listinfo/python-list
Re: text adventure question
On 2006-12-02, Ara Kooser wrote: > I am working on a text adventure game for python to get back > into python programming. My version 0.1 used only functions so > I could get familiar with how those work. I want to move beyond > that. I am not sure what would be a good Python way of handling > this. I was wondering if classes would help? What things > should be included in the main program? That's so funny! I did the same thing when I was learning Python! My cousin and I wrote some text adventure games when we were teenagers (the code was on a TRS-80 in BASIC back then, and the BASIC program became a kind of interpreter to interpret the adventure "program" files). I re-wrote it in C, then Java, then Python. I used it as a sort of learning tool, and since Python is so good with strings, it became very efficient. I now have the code running on one of my web pages, so you can play the games on-line: http://www.skyrush.com/explore/ -Joe -- http://mail.python.org/mailman/listinfo/python-list
