This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Joe
Recipients Joe, terry.reedy
Date 2014-08-05.05:12:11
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <201408050512.s755C0rl023686@mail237c25.carrierzone.com>
In-reply-to <1407129280.1.0.239761292711.issue22105@psf.upfronthosting. co.za>
Content
Today the "memory" problem repeated, and I was ale to get more info:

While displaying results of program execution in IDLE, two "memory 
problem" pop-ups were displayed.  Selecting  " recovery activate" 
buttons did not help.  The lower right "Ln count" was 5,xxx,xxx, but 
had not changed for apx one hour (it won't advance unless I click on 
the IDLE window).  Estimated "Ln count" was apx 7,5xxx,xxx at time of 
computer lock up.  CTRL.ALT.DEL eventually restored control of 
Windows (WIN7-64 bit) by using the Status window which also displayed 
98% memory.  A "tk" reference was also displayed before computer 
control was re-established.

My program execution requires printing a line after an "if - else" 
statement.  If I "#comment" the line immediately following  "if" in 
order to reduce the "Ln count", execution will go to the unwanted 
"else" block.  I have not been able to work around this problem.  The 
"else" statement needs to wait for a "Ln count"of apx 10,xxx,xxx, but 
the memory problem occurs at apx 7,5xx,xxx.

Hope this info is of some use.  The only solutions I can think of are 
ones that would allow 10+ million IDLE line prints, or a way around 
the "if -else" problem.
Thanks for the help, I understand your priorities. ... Joe Gaspard

At 10:14 PM 8/3/2014, you wrote:

>Terry J. Reedy added the comment:
>
>The latest version is best. We are gradually fixing crashes, closes, 
>hangs, and other bugs.
>
>When you replay by email, please delete the quoted message, as it is 
>redundant with the message already displayed and just noise.
>
>I am closing this issue for now because there is insufficient data 
>to do anything. We can only work on semi-repeatable problems that 
>occur on more than just one user's machine. Windows, at least, is 
>prone to unrepeatable and sometimes system-specific glitches.
>
>----------
>resolution:  -> later
>stage:  -> resolved
>status: open -> closed
>type:  -> behavior
>
>_______________________________________
>Python tracker <report@bugs.python.org>
><http://bugs.python.org/issue22105>
>_______________________________________
History
Date User Action Args
2014-08-05 05:12:12Joesetrecipients: + Joe, terry.reedy
2014-08-05 05:12:12Joelinkissue22105 messages
2014-08-05 05:12:11Joecreate