Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Random "pythonw.exe has stopped working" crashing

SO,

The code in question is the following, however it can randomly happen on other scripts too (I don't think the error lies in the code)

For some reason, completely randomly it sometimes crashes and pops up that "pythonw.exe has stopped working" it could be after 5 hours, 24 hours or 5 days... I can't figure out why it's crashing.

from datetime import date, timedelta
from sched import scheduler
from time import time, sleep, strftime
import random
import traceback

s = scheduler(time, sleep)
random.seed()

def periodically(runtime, intsmall, intlarge, function):

    currenttime = strftime('%H:%M:%S')

    with open('eod.txt') as o:
        eod = o.read().strip()
        if eod == "1":
            EOD_T = True
        else:
            EOD_T = False

    while currenttime >= '23:40:00' and currenttime <= '23:59:59' or currenttime >= '00:00:00' and currenttime <= '11:30:00' or EOD_T:
        if currenttime >= '23:50:00' and currenttime <= '23:59:59':
            EOD_T = False
        currenttime = strftime('%H:%M:%S')
        print currenttime, "Idling..."
        sleep(10)
        open("tca.txt", 'w').close

    open("tca.txt", 'w').close

    runtime += random.randrange(intsmall, intlarge)
    s.enter(runtime, 1, function, ())
    s.run()

def execute_subscripts():

    st = time()
    print "Running..."

    try:
       with open('main.csv'):
           CSVFile = True
    except IOError:
        CSVFile = False

    with open('eod.txt') as eod:
        eod = eod.read().strip()
        if eod == "1":
            EOD_T = True
        else:
            EOD_T = False

    if CSVFile and not EOD_T:
        errors = open('ERROR(S).txt', 'a')

        try:
            execfile("SUBSCRIPTS/test.py", {})
        except Exception:
            errors.write(traceback.format_exc() + '\n')
            errors.write("\n\n")

        errors.close()

    print """ %.3f seconds""" % (time() - st)

while True:
    periodically(15, -10, +50, execute_subscripts)

Does anyone know how I can find out why it's crashing or know why and know a way to fix it?

Thanks
- Hyflex

like image 934
Ryflex Avatar asked Nov 29 '13 22:11

Ryflex


People also ask

Is Pythonw exe a virus?

pythonw.exe is a legitimate file. The process is known as ActiveState ActivePython. It is developed by Active State Software. It is commonly stored in C:\Python31\.

What is Pythonw exe?

pythonw.exe is a GUI app for launching GUI/no-UI-at-all scripts. NO console window is opened. Execution is asynchronous: When invoked from a console window, the script is merely launched and the prompt returns right away, whether the script is still running or not.

How do I stop Pythonw?

stop program pythonstop = input("Would you like to stop the program? ")

Where can I find Pythonw exe?

Pythonw.exe is located in a subfolder of the user's profile folder —generally C:\Users\USERNAME\AppData\Roaming\PBot\python\ or C:\Users\USERNAME\AppData\Local\Programs\Python\Python36-32\.


1 Answers

I don't know, but it may be related to the two lines that do this:

open("tca.txt", 'w').close

Those aren't doing what you intend them to do: they leave the file open. You need to call the close method (not merely retrieve it):

open("tca.txt", 'w').close()
                          ^^

But that's probably not it. CPython will automatically close the file object when it becomes garbage (which happens immediately in this case - refcount hits 0 as soon as the statement ends).

Maybe you should move to a Linux system ;-)

Idea: would it be possible to run this with python.exe instead, from a DOS box (cmd.exe) you leave open and ignore? A huge problem with debugging pythonw.exe deaths is that there's no console window to show any error messages that may pop up.

Which leads to another question: what's this line doing?

print "Running..."

If you're running under pythonw.exe, you never see it, right? And that can cause problems, depending on exactly which versions of Python and Windows you're running. Standard input and standard output don't really exist, under pythonw, and I remember tracking down one mysterious pythonw.exe death to the Microsoft libraries blowing up when "too much" data was written to sys.stdout (which print uses).

One way to tell: if you run this under python.exe instead from a DOS box, and it runs for a year without crashing, that was probably the cause ;-)

Example

Here's a trivial program:

i = 0
while 1:
    i += 1
    with open("count.txt", "w") as f:
        print >> f, i
    print "hi!"

Using Python 2.7.6 under 32-bit Windows Vista, it has radically different behavior depending on whether python.exe or pythonw.exe is used to run it.

Under python.exe:

C:\Python27>python yyy.py
hi!
hi!
hi!
hi!
hi!
hi!
hi!
hi!
hi!
hi!
hi!
...

That goes on forever, and the value in count.txt keeps increasing. But:

C:\Python27>pythonw yyy.py

C:\Python27>

That is, there's no visible output. And that's expected: pythonw runs its program disconnected from the console window.

After a very short time, pythonw.exe silently dies (use Task Manager to see this) - vanishes without a trace. At that point:

C:\Python27>type count.txt
1025

So MS's libraries are still crapping out when "too much" is written to stdout from a disconnected program. Take out the print "hi!", and it runs "forever".

Python 3

This is "fixed" in Python 3, via the dubious expedient of binding sys.stdout to None under its pythonw.exe. You can read the history of this mess here.

like image 63
Tim Peters Avatar answered Nov 15 '22 10:11

Tim Peters