Hotshot has a bug that manifests when using start/stop
instead of run(), however it appears to only occur in
the interactive interpreter or in an embedded application.

If you run the attached program like "python
hotshotbug.py" it works just fine.  However, if you
start an interactive session and paste each line one by
one into the shell, you get the following exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/hotshot/stats.py",
line 12, in load
    return StatsLoader(filename).load()
  File "/usr/local/lib/python2.3/hotshot/stats.py",
line 29, in load
    for event in log:
  File "/usr/local/lib/python2.3/hotshot/log.py", line
110, in next
    return what, self._pop(), tdelta
IndexError: pop from empty list

We discovered this when trying to profile an embedded
application which doesn't have a single entrypoint
suitable for run().  Unfortunately, I can't provide
that application, but it shouldn't matter, since the
interpreter crash is the same.

Logged In: YES 
user_id=12800

Could this be related to 900092?

Logged In: YES 
user_id=967320

I get the same traceback even when not running
interactively. I can provide .prof files if needed.

fumanchu@amor.org

Logged In: YES 
user_id=86307

Not sure about the embedded application, but I believe the
problem with the interactive interpreter is that you're
executing a code snippet ("p.start()") which calls the
function to enable the profiler, and then does a return from
PyEval_EvalFrame.  This means the first event the profiler
sees will be the return, without having previosly seen a
call (since when PyEval_EvalFrame was entered, profiling was
not yet started).  The LogReader class assumes that a return
event must have been preceeded by a corresponding call event
so that it can pop the previously pushed information.  You
can get the same crash with a simple:

>>> p.start()
>>> p.stop()

and then try to load the stats.

By the way, with Python2.4b1, the example does not crash
when executed non-interactively from the command line (at
least on my Windows XP system).

Logged In: YES 
user_id=21804

So does this mean there is no decent way to use start() or
stop() if they are not called within the same stackframe? 

I've noticed this by trying to analyze prof files with
external python scripts - i.e. I generate the profile in one
program, and try to open it in another for analysis. Its the
2nd program that tries to open it that gets the crash.

Confirmed on trunk (interactive session only), might be considered a
historical limitation by now :)