Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #72681 > unrolled thread

Re: Missing stack frames?

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Missing stack frames? dieter <dieter@handshake.de> - 2014-06-05 08:24 +0200

#72681 — Re: Missing stack frames?

Nikolaus Rath <Nikolaus@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.

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web