Swapnil Talekar swapnil...@gmail.com added the comment:
Sorry about the previous report. I should have tested it thoroughly. Yes, it
does not seem to rise but eventually it does. This time, I'v added garbage
collection right after the subinterpreter is shutdown. The memory consumption
does
Changes by Swapnil Talekar swapnil...@gmail.com:
--
resolution: invalid -
status: closed - open
versions: +Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11803
New submission from Swapnil Talekar swapnil...@gmail.com:
In the attached program, the total memory consumption of the process, goes up
each time a new subinterpreter imports a bunch of modules. When the
subinterpreter is shutdown with Py_EndInterpreter, the memory consumed with
import
Swapnil Talekar swapnil...@gmail.com added the comment:
No. This is not the same as #222684?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11803
Changes by Swapnil Talekar swapnil...@gmail.com:
Added file: http://bugs.python.org/file21579/large_import.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11803
Swapnil Talekar swapnil...@gmail.com added the comment:
Nick, the last statement,
While this is correct for most purposes, it does mean that...
can be simplified to,
It means
I had to read it several times before I realized, there is no not after
does :)
BTW, since this particular
Swapnil Talekar swapnil...@gmail.com added the comment:
As far as I know, the thread creation done in the file is not correct. While
creating threads in C extension, there are certain rules to follow. Firstly,
Python should be made thread-aware if it is not already i.e. call
Swapnil Talekar swapnil...@gmail.com added the comment:
Mark, are you sure that the above program is sure to cause a crash. I had
absolutely no problem running it with Python 3.1.2. With Python 2.6.5, PC went
terribly slow but the program managed to run till i==14 without crashing. I did
Swapnil Talekar swapnil...@gmail.com added the comment:
The problem it seems is actually in the bdb module and not in pdb. The
set_next function sets the current frame as stopframe but it does not
specify the stoplineno. Hence it's always -1. When you do c(ontinue),
set_continue just sets
