Process crash with no reason

Stephen Hansen apt.shansen at gmail.com
Sun Feb 8 10:31:14 EST 2009


> Thanks a lot and sorry for the late response. My main suspect is the
> CherryPy.
> I'm still investigating it.

You're asking for advice but not listening to what people are saying
here -- why is CherryPy on the top of your list?

What version of CherryPy is it? 1 or 2?

If its 2, then its pure python and there's a really, really low chance
that its provoking a hard crash w/o a traceback printing before it
dies out. A hard crash which isn't printing an error message is
possible in pure Python I suppose, but I've never seen it. A "Bus
error" for example will kill the interpreter before it can do any
error handling. But I've only ever seen that when interfacing with
third party libraries.

If its 1, there is some C so you can bump it up ... and for that I'd
probably attempt to run the application in a console or with stdout
manually redirected instead of relying on the logging alone, to see if
anything useful gets put out.. like "Bus error", at the time it exits.

But why do you keep discarding the Sybase module?

Its most definitely *not* written in python. What Philip and Tim were
trying to tell you is you are *not* using "python's functions to run
sybase sql commands"

The Sybase module is a python wrapper around code written in C module
which is interfacing with a third party library to talk to Sybase. Are
you at the latest version of Sybase(0.39 if its the same module I'm
aware of?) How about the library underneath it? FreeTDS or Sybase ASE
(whatever that is) or whatever else is being used? A bug in /any/ of
those C layers (notice its *multiple* layers) could propagate up and
provoke a hard crash that Python doesn't catch. So if you look into
those versions perhaps one has a new release that fixes bugs.

--S



More information about the Python-list mailing list