Python Crashes

[David Bolen]

koranthala <koranthala at gmail.com> writes:

>     Could anyone guide me on this? I have been facing this issue for a
> day, and cannot seem to solve it.

We had a scheduling system that had a similar "once in a long while
hard Windows-process crash" which after a bunch of work to try to
track down the source, the most robust solution was just to trap the
failure and restart, as the system ran off a persistent state that was
already engineering to be robust in the case of a hardware crash
(power outage, etc...)  While I agree with others that it's most
likely a fault in an extension that gets tickled over time, as was
likely in our case, we needed all our extensions and were using latest
versions at the time.  So if your application is such that just
restarting it is practical, it may be a sufficient temporary (or not
so temporary - our system ran for years this way) workaround for you.

What you can do is execute your script from beneath control of another
script, and trap process failures, restarting the script on
non-standard exits.  This can be in addition to any top level
exception handling of the child script itself, where it can provide
more graceful support for internal failures.

The trick, under Windows, is to ensure that you disable any pop-up
windows that may occur during the crash, otherwise the monitoring task
never gets a chance to get control and restart things.

With the pywin32 extension, something like:

    import win32api, win32con

    old_mode = win32api.SetErrorMode(win32con.SEM_FAILCRITICALERRORS |
                                     win32con.SEM_NOGPFAULTERRORBOX |
                                     win32con.SEM_NOOPENFILEERRORBOX)

Or with ctypes:

    import ctypes

    SEM_FAILCRITICALERRORS = 1
    SEM_NOGPFAULTERRORBOX  = 2
    SEM_NOOPENFILEERRORBOX = 0x8000

    old_mode = ctypes.windll.kernel32.SetErrorMode(SEM_FAILCRITICALERRORS |
                                                   SEM_NOGPFAULTERRORBOX |
                                                   SEM_NOOPENFILEERRORBOX)

at any point prior to starting the child process will ensure that hard
process errors will silently terminate the process and return control
the parent, as well as not popping up any dialog boxes that require
intervention by a person.

Should the process exit harshly, the exit code should be fairly
clear (I forget, but I think it's in the 0xC000xxxx range, maybe
0xC0000005 for a typical GPF), and you can decide on restarting the
task as opposed to just exiting normally.

This will also prevent any pop-ups in the main monitoring process.
You can restore old behavior there after starting the child by making
another call to SetErrorMode using old_mode as the argument.

-- David