Nikolaus Rath <nikol...@rath.org> writes: > ... > Is there a way to produce a stacktrace without using the interactive > debugger?
There is the "threadframe" package (on "PyPI"). It has helped me much to analyse problems in multithreaded programs (e.g. as part of "haufe.requestmonitoring"). However, I doubt that it will help in your case: I also have used interactive debugging for multithreaded programs; it is true that is sometimes very difficult (especially when the debugger gets activated in several threads at once and I no longer know which debugger instance gets my input) but I never observed that stack frames have been lost: in fact, I do not see any reason why the debugger could do that: the debugger activity is part of the thread being debugged and the stack frames are thread local, i.e. they cannot be modified by other threads -- thus, the debugger should see a consitent stack, independently of what other threads do. C extensions can cause stack frames to (apparently) be missed. The Python stack is a linked list of frames the head of which is maintained in the thread description. When Python calls a Python function, it pushes a new stack frame onto this stack. However, when a C function is called, this usually does not have an associated stack frame. When the C function calls a Python function, a stack frame for it is pushed and looking at the stack frames, it appears as if the Python function has been called at the place of the C function. >From the information you have provided in this discussion, I cannot see whether this can explain your observations: In your case, "C" extensions may be involved but they should not call back to Python functions. Someone else already mentioned that the "close" call can come from a destructor. Destructors can easily be called at not obvious places (e.g. "s = C(); ... x = [s for s in ...]"; in this example the list comprehension calls the "C" destructor which is not obvious when one looks only locally). The destructor calls often have intervening C code (which one does not see). However, in your case, I do not see why the "cgi" module should cause a destructor call of one of your server components. To summarize: I am as confused by your observations as you are and cannot give a satisfactory explanation. -- https://mail.python.org/mailman/listinfo/python-list
