[issue1134] Parsing a simple script eats all of your memory

Amaury Forgeot d'Arc added the comment: Corrected in revision 59001, with a modified patch. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ __

[issue1134] Parsing a simple script eats all of your memory

Viktor Ferenczi added the comment: In response to Guido: According to pythonmeister's post (2007-09-10): "Same under Linux with Python 3.0a1. Eats all cpu + memory" I found the bug with this version: [EMAIL PROTECTED]:~$ python3.0 --version Python 3.0a1 AFAIK it is the latest alpha released.

[issue1134] Parsing a simple script eats all of your memory

Amaury Forgeot d'Arc added the comment: fp_readl is indeed broken in several ways: - decoding_buffer should be reset to NULL when all data has been read (buflen <= size). - the (buflen > size) case will cause an error on the next pass, since the function cannot handle PyBytesObject. IOW, the fun

[issue1134] Parsing a simple script eats all of your memory

Guido van Rossum added the comment: Is this also broken in the 3.0a1 release? If not, it might be useful to try to find the most recent rev where it's not broken. __ Tracker <[EMAIL PROTECTED]> __

[issue1134] Parsing a simple script eats all of your memory

Christian Heimes added the comment: I've already raised the priority to draw more attention to this bug. So far I'm not able to solve the bug but I've nailed down the issue to a short test case: HANGS: # -*- coding: ascii -*- """ """ The problem manifests itself only in the combination of the

[issue1134] Parsing a simple script eats all of your memory

Viktor Ferenczi added the comment: This bug prevents me and many others to do preliminary testing on Py3k, which slows down it's development. This bug is _really_ hurts. I've a completely developed new module for Py3k that cannot be released due to this bug, since it's unit tests are affected by

[issue1134] Parsing a simple script eats all of your memory

Guido van Rossum added the comment: Amaury, can you have a look at this? I think it's a bug in tok_nextc() in tokenizer.c. -- assignee: nnorwitz -> amaury.forgeotdarc nosy: +amaury.forgeotdarc __ Tracker <[EMAIL PROTECTED]>

[issue1134] Parsing a simple script eats all of your memory

Christian Heimes added the comment: The issue isn't fixed yet. The script is still eating precious memory. -- nosy: +gvanrossum, tiran priority: high -> urgent __ Tracker <[EMAIL PROTECTED]> _

[issue1134] Parsing a simple script eats all of your memory

Neil Schemenauer added the comment: It looks to me like fp_readl is no longer working as designed and the patch is not really the right fix. The use of "decoding_buffer" is tricky and I think the conversion to bytes screwed it up. It might be clearer to have a separate "decoding_overflow" struc

[issue1134] Parsing a simple script eats all of your memory

Changes by Sean Reifschneider: -- assignee: -> nnorwitz nosy: +nnorwitz __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Un

[issue1134] Parsing a simple script eats all of your memory

Sean Reifschneider added the comment: Confirmed problem (used 4.5GB before I killed it), and that the second patch resolved the problem. I'm uploading the inline patch as an attachment, with the directory name in it as well (from svn diff). Bumping the priority to high because the side effect

[issue1134] Parsing a simple script eats all of your memory

Alexey Suda-Chen added the comment: Oops, i see there are two bugs. Previously i have fixed multiline strings only. I think it will be: Index: tokenizer.c === --- tokenizer.c (revision 58161) +++ tokenizer.c (working copy) @@ -395,

[issue1134] Parsing a simple script eats all of your memory

Brett Cannon added the comment: Note the patch is inlined in a message. -- keywords: +patch, py3k nosy: +brett.cannon __ Tracker <[EMAIL PROTECTED]> __

[issue1134] Parsing a simple script eats all of your memory

Alexey Suda-Chen added the comment: --- tokenizer.c (revision 58161) +++ tokenizer.c (working copy) @@ -402,6 +402,8 @@ if (allocated) { Py_DECREF(bufobj); } + Py_XDECREF(tok->decoding_buffer); + tok->decoding_buffer = 0; return s; -- nosy: +alex

[issue1134] Parsing a simple script eats all of your memory

Stefan Sonnenberg-Carstens added the comment: Same under Linux with Python 3.0a1. Eats all cpu + memory -- nosy: +pythonmeister __ Tracker <[EMAIL PROTECTED]> __ __

[issue1134] Parsing a simple script eats all of your memory

Alan McIntyre added the comment: Confirmed that this happens on Mac OS X with a fresh build of py3k from svn. -- nosy: +alanmcintyre __ Tracker <[EMAIL PROTECTED]> __ _

[issue1134] Parsing a simple script eats all of your memory

Viktor Ferenczi added the comment: Errata: In the first line of my original post I mean Python3.0a1 and not 3.0a2, certainly. __ Tracker <[EMAIL PROTECTED]> __ _

[issue1134] Parsing a simple script eats all of your memory

Viktor Ferenczi added the comment: Works fine (does nothing) with Python 2.4.4 and Python 2.5.1 under Windows, so this bug must be caused by some new code in Python3.0a1. The bug depends on the contents of the doc string. There's another strange behavior if you write the word "this" in the doc

[issue1134] Parsing a simple script eats all of your memory

Viktor Ferenczi added the comment: Confirmed on Windows: OS: Windows XP SP2 ENG Python: Python3.0a1 MSI installer, default installation __ Tracker <[EMAIL PROTECTED]> __ __

[issue1134] Parsing a simple script eats all of your memory

New submission from Viktor Ferenczi: Read the WARNING below, then run the attached script with Python3.0a2. It will eat all of your memory. WARNING: Keep a process killing tool or an extra command line at your fingertips, since this script could render your machine unusable in about 10-20 second