classification
Title: time.asctime segfaults when given a time in the far future
Type: behavior Stage: resolved
Components: Extension Modules Versions: Python 3.2
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: belopolsky Nosy List: SilentGhost, Trundle, belopolsky, georg.brandl, haypo, ned.deily, sandro.tosi, wsanchez
Priority: normal Keywords: patch

Created on 2010-02-24 17:15 by wsanchez, last changed 2011-01-04 16:56 by georg.brandl. This issue is now closed.

Files
File name Uploaded Description Edit
issue8013.diff Alexander.Belopolsky, 2010-02-24 18:35 Patch against revision 78430 review
issue8013_py3k.diff Trundle, 2011-01-02 02:19
issue8013_27.diff ned.deily, 2011-01-02 03:48 patch updated for 2.7-maint
issue8013-pre-check.diff belopolsky, 2011-01-03 20:19
issue8013-long-year.diff belopolsky, 2011-01-04 02:06
Messages (44)
msg100048 - (view) Author: Wilfredo Sanchez (wsanchez) Date: 2010-02-24 17:15
time.asctime segfaults when given a time in the far future (5+ digit year)

>>> import time
>>> time.asctime(time.gmtime(1e12))
Segmentation fault
msg100049 - (view) Author: Wilfredo Sanchez (wsanchez) Date: 2010-02-24 17:17
I get this on Python 2.6, not 2.5.

And it seems to be limited to 64-bit.
msg100050 - (view) Author: Wilfredo Sanchez (wsanchez) Date: 2010-02-24 17:17
(On Mac OS X)
msg100056 - (view) Author: Alexander Belopolsky (Alexander.Belopolsky) Date: 2010-02-24 17:50
Looks like a case of missing null check.  Patch attached.
msg100064 - (view) Author: Alexander Belopolsky (Alexander.Belopolsky) Date: 2010-02-24 18:35
New patch with tests and using reentrant functions.
msg125007 - (view) Author: Sandro Tosi (sandro.tosi) * (Python committer) Date: 2011-01-01 21:26
Hi Alexander, can you confirm this bug is MacOs specific? I tried with python2.6 on a Debian sid @64 bit but I can't replicate it. Also, do you see it only on 2.6? if so, I doubt that it will ever be fixed; f.e. on release2.7 branch I have:

Python 2.7.1+ (release27-maint, Dec 31 2010, 20:16:57) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.asctime(time.gmtime(1e12))
'Fri Sep 27 01:46:40 33658\n'
msg125012 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2011-01-01 22:36
It's still a problem on OS X at least and is 64-bit related:

$ arch -i386 /usr/local/bin/python3.2 -c 'import time;print(time.asctime(time.gmtime(1e12)))'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ValueError: timestamp out of range for platform time_t
$ arch -x86_64 /usr/local/bin/python3.2 -c 'import time;print(time.asctime(time.gmtime(1e12)))'
Segmentation fault
msg125013 - (view) Author: Sandro Tosi (sandro.tosi) * (Python committer) Date: 2011-01-01 22:47
Hi Ned, thanks for the fast check! I tried to applied the patch (it failed, so it required a bit of manual editing) but when compiling I got:


/home/morph/python-dev/py3k/Modules/timemodule.c: In function ‘time_asctime’:
/home/morph/python-dev/py3k/Modules/timemodule.c:626: warning: implicit declaration of function ‘PyString_FromStringAndSize’
/home/morph/python-dev/py3k/Modules/timemodule.c:626: warning: return makes pointer from integer without a cast
*** WARNING: renaming "time" since importing it failed: build/lib.linux-x86_64-3.2/time.cpython-32m.so: undefined symbol: PyString_FromStringAndSize

and my knowledge of C ends there :)

Alexander, would you like to revamp your patch? ;)
msg125025 - (view) Author: Andreas Stührk (Trundle) Date: 2011-01-02 02:19
Updated patch against py3k branch.
msg125029 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2011-01-02 03:48
Thanks for the py3k patch.  I am also attaching a refreshed patch for current 2.7.  They both fix the segfaults when built and run on OS X 10.6 64-bit.  Since the patches change timemodule to use asctime_r, which AFAICT is not used elsewhere in the standard library, one concern might be if this change introduces a regression on any other platforms, something for the buildbots to test.
msg125056 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2011-01-02 14:37
The patch is wrong: it hardcodes the number of characters that the time string has, but it can be more than 24 if the year is > 9999.  (Of course, the check for \n currently in the code is wrong too and must be fixed.)

Also, shouldn't the issue be handled as in ctime()?  There is a NULL check there, and by just doing that check we wouldn't depend on asctime_r().
msg125060 - (view) Author: Andreas Stührk (Trundle) Date: 2011-01-02 15:36
The real problem with years >= 9999 is that it is undefined behaviour anyway (see e.g. http://pubs.opengroup.org/onlinepubs/9699919799/functions/asctime.html: "the behavior is undefined if the above algorithm would attempt to generate more than 26 bytes of output (including the terminating null)").
msg125061 - (view) Author: Andreas Stührk (Trundle) Date: 2011-01-02 15:38
Sorry, I meant " years > 9999" of course.
msg125062 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2011-01-02 15:52
Well, then I would have no problem with checking for that condition beforehand and raising ValueError.

On the other hand, it seems that implementations either return a correct string or NULL, so just erroring out in case of NULL would be fine as well.
msg125070 - (view) Author: Alexander Belopolsky (Alexander.Belopolsky) Date: 2011-01-02 18:52
On Sun, Jan 2, 2011 at 10:52 AM, Georg Brandl <report@bugs.python.org> wrote:
..
> Well, then I would have no problem with checking for that condition beforehand and raising
> ValueError.
>

IIRC, there was a similar bug report about ctime where pre-condition
checking was required because platform ctime would crash for huge
values of time.  I'll try to find the ticket.

> On the other hand, it seems that implementations either return a correct string or NULL,
> so just erroring out in case of NULL would be fine as well.

This is true on the platforms that I have access to: OSX, Linux, and
Solaris.  I think asctime_r is available and behaves this way on
Python supported platforms.  I'll check this in and watch the bots.
msg125071 - (view) Author: Alexander Belopolsky (Alexander.Belopolsky) Date: 2011-01-02 18:59
On Sun, Jan 2, 2011 at 1:52 PM, Alexander Belopolsky
<report@bugs.python.org> wrote:
..
>> Well, then I would have no problem with checking for that condition beforehand and raising
>> ValueError.
>>
>
> IIRC, there was a similar bug report about ctime where pre-condition
> checking was required because platform ctime would crash for huge
> values of time.  I'll try to find the ticket.

Hmm. My search brought up issue 10563, but the last message on that
issue says that "a change has been recently made to time.asctime() to
reject year > 9999.  See r85137 and issue6608."  I wonder if that
change made this issue moot.
msg125085 - (view) Author: Alexander Belopolsky (Alexander.Belopolsky) Date: 2011-01-02 19:57
On Sun, Jan 2, 2011 at 1:59 PM, Alexander Belopolsky
<report@bugs.python.org> wrote:
..
> Hmm. My search brought up issue 10563, but the last message on that
> issue says that "a change has been recently made to time.asctime() to
> reject year > 9999.  See r85137 and issue6608."  I wonder if that
> change made this issue moot.

It turns out the check added in r85137 does not cover tm_year even
though CERT recommends it (see msg107605).  These are separate issues
though. I think given where we are in the release cycle, the most
conservative solution would be to simply add a null check as follows.
(I did check that it fixes the crash on OSX.)

===================================================================
--- timemodule.c        (revision 87556)
+++ timemodule.c        (working copy)
@@ -620,6 +620,10 @@
     } else if (!gettmarg(tup, &buf) || !checktm(&buf))
         return NULL;
     p = asctime(&buf);
+    if (p == NULL) {
+        PyErr_SetString(PyExc_ValueError, "invalid time");
+        return NULL;
+    }
     if (p[24] == '\n')
         p[24] = '\0';
     return PyUnicode_FromString(p);
msg125095 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2011-01-02 20:49
Committed in revision 87648.
msg125099 - (view) Author: SilentGhost (SilentGhost) Date: 2011-01-02 21:14
Sasha, commit is not working. It doesn't pass test on Ubuntu and returns the string with a trailing \n. Seems like that hunk of code is misplaced.
msg125109 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-01-02 21:53
> Sasha, commit is not working.

I suppose that the fix for the segfault is correct. The problem on Linux is the new test: asc

>>> import time; time.asctime((12345, 1, 0, 0, 0, 0, 0, 0, 0))
'Mon Jan  1 00:00:00 12345\n'

asctime() of the GNU libc doesn't fail. The test should maybe just calls the function without checking the result and ignores the exception.
msg125112 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2011-01-02 22:35
Tests fixed to ignore ValueError in r87656.

Both asctime() and ctime() fixed to remove newline no matter how many digits the year has in r87657.  I also took the liberty of making the error messages consistent.
msg125117 - (view) Author: Alexander Belopolsky (Alexander.Belopolsky) Date: 2011-01-02 22:53
On Sun, Jan 2, 2011 at 5:35 PM, Georg Brandl <report@bugs.python.org> wrote:
..
> Both asctime() and ctime() fixed to remove newline no matter how many
> digits the year has in r87657.  I also took the liberty of making the error
> messages consistent.

Georg,

I disagree with your solution.  According to relevant standards,
asctime is undefined for year > 9999.  A compliant implementation can
do anything in this case including not null-terminating the internal
buffer.  With your change, time.strftime  will happily replace the
first unrelated '\n' with '\0' that it will find beyond the internal
buffer.

I was considering raising an ValueError if '\n' is not found at 24th
position, but this (or a precondition check solution) should wait
until 3.3.
msg125119 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2011-01-02 23:01
In that case however, it's equally unsafe to not replace a \n, but still use PyUnicode_FromString() without a size given -- you will read from random memory.

Since all implementations we have or can test have a defined behavior in one way or the other, I think an example of an implementation that exhibits such undefined behavior is required first.
msg125120 - (view) Author: Alexander Belopolsky (Alexander.Belopolsky) Date: 2011-01-02 23:06
On Sun, Jan 2, 2011 at 6:01 PM, Georg Brandl <report@bugs.python.org> wrote:
..
>
> Since all implementations we have or can test have a defined behavior in one way or the other,
> I think an example of an implementation that exhibits such undefined behavior is required first.

No.  A CERT recommendation on how to write secure and portable code
should be enough.  See msg107605.
msg125121 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2011-01-02 23:10
All right, then I wonder why your checktm() doesn't check the tm_year?
msg125123 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2011-01-02 23:17
(What I mean is that overwriting \n or not, the code is unsafe, so the check must be done beforehand.  Why should that be left to 3.3?)
msg125124 - (view) Author: Alexander Belopolsky (Alexander.Belopolsky) Date: 2011-01-02 23:17
On Sun, Jan 2, 2011 at 6:10 PM, Georg Brandl <report@bugs.python.org> wrote:
..
> All right, then I wonder why your checktm() doesn't check the tm_year?

It is not mine.  I thought it did.  I might have missed that when I
reviewed the patch or there was a reason for that at the time.  Note
that there is a comment that says:

"""
tm_year: [0, max(int)] (1)
..
(1) gettmarg() handles bounds-checking.
"""

If you are ok with introducing stricter bounds checking in beta, I'll
try to get to the bottom of it shortly.
msg125125 - (view) Author: Alexander Belopolsky (Alexander.Belopolsky) Date: 2011-01-02 23:22
On Sun, Jan 2, 2011 at 6:17 PM, Georg Brandl <report@bugs.python.org> wrote:
..
> (What I mean is that overwriting \n or not, the code is unsafe, so the check must be
> done beforehand.  Why should that be left to 3.3?)

Reading beyond a buffer is somewhat safer than writing, but I agree
that checks must be done before calling asctime/ctime.   I thought it
would have to wait because it is a feature.  Some Linux users may
expect year 10000 to work.  (Maybe as a sentinel value somewhere.)
But you are the RM, so it is your call.
msg125126 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2011-01-02 23:29
You cannot have both: a safe implementation and the correct behavior with glibc (not Linux!) -- except if you start special-casing.  Not sure that's worth it.

Note that time.asctime() is documented in time.rst to return a 24-character string, so what it currently returns with glibc is violating our docs as well.
msg125130 - (view) Author: Alexander Belopolsky (Alexander.Belopolsky) Date: 2011-01-02 23:43
On Sun, Jan 2, 2011 at 6:29 PM, Georg Brandl <report@bugs.python.org> wrote:
..
> You cannot have both: a safe implementation and the correct behavior with glibc
> (not Linux!) -- except if you start special-casing.  Not sure that's worth it.
>
That's the reason why this and the related ctime issue were lingering
for so long.

My plan was to pick the low-hanging fruit (the null check) for 3.3 and
leave proper bounds checking and possibly switch to reentrant APIs for
the next release.   There is a long tradition in keeping OS functions'
wrappers thin with an expectation that application programmers will
know the limitations/quirks of their target OSes.  Given that datetime
module does not have these issues, I don't see this as "must fix."
msg125131 - (view) Author: Alexander Belopolsky (Alexander.Belopolsky) Date: 2011-01-02 23:43
..
> My plan was to pick the low-hanging fruit (the null check) for 3.3 and

s/3.3/3.2/
msg125132 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2011-01-02 23:46
> There is a long tradition in keeping OS functions'
> wrappers thin with an expectation that application programmers will
> know the limitations/quirks of their target OSes.

Sorry, but that does not apply if we trigger undefined behavior which
is inherently unsafe, as you rightly insist.

I don't see the range checking as particularly challenging; I'm sure you can get it done in time for 3.2.
msg125133 - (view) Author: Alexander Belopolsky (Alexander.Belopolsky) Date: 2011-01-02 23:48
On Sun, Jan 2, 2011 at 6:46 PM, Georg Brandl <report@bugs.python.org> wrote:
..
> I don't see the range checking as particularly challenging; I'm sure you can get it done in time for 3.2.

Will do.
msg125134 - (view) Author: SilentGhost (SilentGhost) Date: 2011-01-02 23:51
I'm not sure that whether it's related to the current issue, but asctime doesn't seem to accept years < 1900. Which might be fair enough, has this been documented.
msg125137 - (view) Author: Andreas Stührk (Trundle) Date: 2011-01-02 23:56
It's documented under "Year 2000 (Y2K) issues": http://docs.python.org/library/time.html#time-y2kissues
msg125138 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2011-01-03 00:02
Backported in r87664 (2.6), r87663 (2.7) and r87662 (3.1).

Reopening to implement bounds checking for 3.2.  Note that for time.asctime, checking the year range is trivial, but for time.ctime it is not because year is not computed in python code.  One solution may be to check bounds of the time_t timestamp, but those depend on the timezone.  Maybe it is easiest to simply call mktime(), check year and call asctime() bypassing OS ctime completely.
msg125139 - (view) Author: SilentGhost (SilentGhost) Date: 2011-01-03 00:03
yes, sorry. what I meant to say is that fixing only upper bound for the year (according to CERT recommendation cited above) and leaving the lower bound in its current state is somewhat unsatisfactory.
msg125161 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-01-03 12:27
> http://docs.python.org/library/time.html#time-y2kissues
> "Values 100–1899 are always illegal."

Why are these values illegal? The GNU libc accepts year in [1900-2^31; 2^31-1] (tm_year in [-2147483648; 2147481747]). If time.accept2dyear=False, we should at least accept years in [1; 9999]. The system libc would raise an error (return NULL) if it doesn't know how to format years older than 1900.
msg125173 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-01-03 14:06
test_time fails with an (C) assertion error on Windows: see issue #10814.
msg125229 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2011-01-03 20:19
Attached patch, issue8013-pre-check.diff, checks for year range before calling system asctime and replaces a call to ctime with a asctime(localtime(..)).
msg125239 - (view) Author: SilentGhost (SilentGhost) Date: 2011-01-03 20:58
All tests pass and all works as documented with the latest patch on Ubuntu (glibc 2.11).
msg125281 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2011-01-04 02:06
Following Guido's response [1] to my inquiry on python-dev, I am attaching a new patch that makes time.asctime and time.ctime produce longer than 24-character strings for large years. 

[1] http://mail.python.org/pipermail/python-dev/2011-January/107187.html
msg125340 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2011-01-04 16:51
Committed in r87736.  I opened a separate issue #10827 to address the lower bound.
msg125342 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2011-01-04 16:56
Thanks!
History
Date User Action Args
2011-01-04 16:56:03georg.brandlsetnosy: georg.brandl, belopolsky, wsanchez, haypo, ned.deily, Trundle, SilentGhost, sandro.tosi
messages: + msg125342
2011-01-04 16:51:20belopolskysetstatus: open -> closed
nosy: georg.brandl, belopolsky, wsanchez, haypo, ned.deily, Trundle, SilentGhost, sandro.tosi
messages: + msg125340

resolution: fixed
stage: commit review -> resolved
2011-01-04 02:06:44belopolskysetfiles: + issue8013-long-year.diff
nosy: georg.brandl, belopolsky, wsanchez, haypo, ned.deily, Trundle, SilentGhost, sandro.tosi
messages: + msg125281
2011-01-03 20:58:17SilentGhostsetnosy: georg.brandl, belopolsky, wsanchez, haypo, ned.deily, Trundle, SilentGhost, sandro.tosi
messages: + msg125239
2011-01-03 20:19:10belopolskysetfiles: + issue8013-pre-check.diff

messages: + msg125229
nosy: georg.brandl, belopolsky, wsanchez, haypo, ned.deily, Trundle, SilentGhost, sandro.tosi
stage: needs patch -> commit review
2011-01-03 20:02:25georg.brandllinkissue10563 superseder
2011-01-03 14:06:20hayposetnosy: georg.brandl, belopolsky, wsanchez, haypo, ned.deily, Trundle, SilentGhost, sandro.tosi
messages: + msg125173
2011-01-03 12:27:06hayposetnosy: georg.brandl, belopolsky, wsanchez, haypo, ned.deily, Trundle, SilentGhost, sandro.tosi
messages: + msg125161
2011-01-03 03:18:19l0nwlfsetnosy: - l0nwlf
2011-01-03 00:03:31SilentGhostsetnosy: georg.brandl, belopolsky, wsanchez, haypo, ned.deily, Trundle, SilentGhost, sandro.tosi, l0nwlf
messages: + msg125139
2011-01-03 00:02:12belopolskysetstatus: closed -> open

type: crash -> behavior
components: + Extension Modules, - Library (Lib)
versions: - Python 3.1, Python 2.7
nosy: - Alexander.Belopolsky

messages: + msg125138
resolution: fixed -> (no value)
stage: patch review -> needs patch
2011-01-02 23:56:58Trundlesetnosy: georg.brandl, belopolsky, wsanchez, haypo, ned.deily, Trundle, SilentGhost, sandro.tosi, Alexander.Belopolsky, l0nwlf
messages: + msg125137
2011-01-02 23:51:59SilentGhostsetnosy: georg.brandl, belopolsky, wsanchez, haypo, ned.deily, Trundle, SilentGhost, sandro.tosi, Alexander.Belopolsky, l0nwlf
messages: + msg125134
2011-01-02 23:48:18Alexander.Belopolskysetnosy: georg.brandl, belopolsky, wsanchez, haypo, ned.deily, Trundle, SilentGhost, sandro.tosi, Alexander.Belopolsky, l0nwlf
messages: + msg125133
2011-01-02 23:46:23georg.brandlsetnosy: georg.brandl, belopolsky, wsanchez, haypo, ned.deily, Trundle, SilentGhost, sandro.tosi, Alexander.Belopolsky, l0nwlf
messages: + msg125132
2011-01-02 23:43:43Alexander.Belopolskysetnosy: georg.brandl, belopolsky, wsanchez, haypo, ned.deily, Trundle, SilentGhost, sandro.tosi, Alexander.Belopolsky, l0nwlf
messages: + msg125131
2011-01-02 23:43:12Alexander.Belopolskysetnosy: georg.brandl, belopolsky, wsanchez, haypo, ned.deily, Trundle, SilentGhost, sandro.tosi, Alexander.Belopolsky, l0nwlf
messages: + msg125130
2011-01-02 23:29:07georg.brandlsetnosy: georg.brandl, belopolsky, wsanchez, haypo, ned.deily, Trundle, SilentGhost, sandro.tosi, Alexander.Belopolsky, l0nwlf
messages: + msg125126
2011-01-02 23:22:42Alexander.Belopolskysetnosy: georg.brandl, belopolsky, wsanchez, haypo, ned.deily, Trundle, SilentGhost, sandro.tosi, Alexander.Belopolsky, l0nwlf
messages: + msg125125
2011-01-02 23:17:59Alexander.Belopolskysetnosy: georg.brandl, belopolsky, wsanchez, haypo, ned.deily, Trundle, SilentGhost, sandro.tosi, Alexander.Belopolsky, l0nwlf
messages: + msg125124
2011-01-02 23:17:31georg.brandlsetnosy: georg.brandl, belopolsky, wsanchez, haypo, ned.deily, Trundle, SilentGhost, sandro.tosi, Alexander.Belopolsky, l0nwlf
messages: + msg125123
2011-01-02 23:10:25georg.brandlsetnosy: georg.brandl, belopolsky, wsanchez, haypo, ned.deily, Trundle, SilentGhost, sandro.tosi, Alexander.Belopolsky, l0nwlf
messages: + msg125121
2011-01-02 23:06:03Alexander.Belopolskysetnosy: georg.brandl, belopolsky, wsanchez, haypo, ned.deily, Trundle, SilentGhost, sandro.tosi, Alexander.Belopolsky, l0nwlf
messages: + msg125120
2011-01-02 23:01:16georg.brandlsetnosy: georg.brandl, belopolsky, wsanchez, haypo, ned.deily, Trundle, SilentGhost, sandro.tosi, Alexander.Belopolsky, l0nwlf
messages: + msg125119
2011-01-02 22:53:47Alexander.Belopolskysetnosy: georg.brandl, belopolsky, wsanchez, haypo, ned.deily, Trundle, SilentGhost, sandro.tosi, Alexander.Belopolsky, l0nwlf
messages: + msg125117
2011-01-02 22:35:01georg.brandlsetstatus: open -> closed

messages: + msg125112
resolution: fixed
nosy: georg.brandl, belopolsky, wsanchez, haypo, ned.deily, Trundle, SilentGhost, sandro.tosi, Alexander.Belopolsky, l0nwlf
2011-01-02 21:53:53hayposetnosy: + haypo
messages: + msg125109
2011-01-02 21:14:12SilentGhostsetnosy: + SilentGhost
messages: + msg125099
2011-01-02 20:49:00belopolskysetnosy: georg.brandl, belopolsky, wsanchez, ned.deily, Trundle, sandro.tosi, Alexander.Belopolsky, l0nwlf
messages: + msg125095
2011-01-02 19:57:57Alexander.Belopolskysetnosy: georg.brandl, belopolsky, wsanchez, ned.deily, Trundle, sandro.tosi, Alexander.Belopolsky, l0nwlf
messages: + msg125085
2011-01-02 18:59:09Alexander.Belopolskysetnosy: georg.brandl, belopolsky, wsanchez, ned.deily, Trundle, sandro.tosi, Alexander.Belopolsky, l0nwlf
messages: + msg125071
2011-01-02 18:52:34Alexander.Belopolskysetnosy: georg.brandl, belopolsky, wsanchez, ned.deily, Trundle, sandro.tosi, Alexander.Belopolsky, l0nwlf
messages: + msg125070
2011-01-02 15:52:52georg.brandlsetnosy: georg.brandl, belopolsky, wsanchez, ned.deily, Trundle, sandro.tosi, Alexander.Belopolsky, l0nwlf
messages: + msg125062
2011-01-02 15:38:09Trundlesetnosy: georg.brandl, belopolsky, wsanchez, ned.deily, Trundle, sandro.tosi, Alexander.Belopolsky, l0nwlf
messages: + msg125061
2011-01-02 15:36:37Trundlesetnosy: georg.brandl, belopolsky, wsanchez, ned.deily, Trundle, sandro.tosi, Alexander.Belopolsky, l0nwlf
messages: + msg125060
2011-01-02 14:37:42georg.brandlsetassignee: belopolsky

messages: + msg125056
nosy: + belopolsky, georg.brandl
2011-01-02 03:48:46ned.deilysetfiles: + issue8013_27.diff

messages: + msg125029
nosy: wsanchez, ned.deily, Trundle, sandro.tosi, Alexander.Belopolsky, l0nwlf
stage: patch review
2011-01-02 02:19:02Trundlesetfiles: + issue8013_py3k.diff
nosy: + Trundle
messages: + msg125025

2011-01-01 22:47:39sandro.tosisetnosy: wsanchez, ned.deily, sandro.tosi, Alexander.Belopolsky, l0nwlf
messages: + msg125013
2011-01-01 22:38:17ned.deilysetnosy: wsanchez, ned.deily, sandro.tosi, Alexander.Belopolsky, l0nwlf
versions: + Python 3.1, Python 2.7, Python 3.2, - Python 2.6
2011-01-01 22:36:36ned.deilysetnosy: + ned.deily
messages: + msg125012
2011-01-01 21:26:37sandro.tosisetnosy: + sandro.tosi
messages: + msg125007
2010-02-25 02:32:59l0nwlfsetnosy: + l0nwlf
2010-02-24 18:35:24Alexander.Belopolskysetfiles: - issue8013.diff
2010-02-24 18:35:12Alexander.Belopolskysetfiles: + issue8013.diff

messages: + msg100064
2010-02-24 17:50:58Alexander.Belopolskysetfiles: + issue8013.diff

nosy: + Alexander.Belopolsky
messages: + msg100056

keywords: + patch
2010-02-24 17:17:38wsanchezsettype: crash
2010-02-24 17:17:24wsanchezsetmessages: + msg100050
2010-02-24 17:17:14wsanchezsetmessages: + msg100049
2010-02-24 17:15:11wsanchezcreate