Path: csiph.com!usenet.pasdenom.info!dedibox.gegeweb.org!gegeweb.eu!nntpfeed.proxad.net!proxad.net!feeder1-2.proxad.net!usenet-fr.net!nerim.net!novso.com!newsfeed.xs4all.nl!newsfeed3a.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: dieter <dieter@handshake.de>
Subject: Re: Missing stack frames?
Date: Thu, 05 Jun 2014 08:24:31 +0200
References: <87fvjlv22v.fsf@vostro.rath.org> <CAPTjJmqzgZnziz3+yZb-4bsYtfxT2AG5HQ9Pb3Ya8AWDW8+oHA@mail.gmail.com> <87oay8pobi.fsf@rath.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.22 (linux)
Cancel-Lock: sha1:BKptWMzNL0/YnR34/GfCI3Uhoyg=
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.10725.1401949488.18130.python-list@python.org>
Lines: 52
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:72681

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.