> 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 -- http://mail.python.org/mailman/listinfo/python-list
