There is a timing problem between the call of 
"call_trace(profile_func,...,'return',...)" and 
"reset_exc_info" in Pythons main interpreter loop.

The main loop first calls "call_trace" (at the end of
function execution). With the
standard "profile.Profile" profiler this leads to a pop
of the current frame from the profiler stack while
the current frame is still on the interpreter stack.
Then "reset_exc_info" is called. When this call releases 
an instance with a destructor ("__del__" method), the 
"call_trace(profile_func,...'call',...)" for the destructor 
observes the inconsistency between the profiler and the 
interpreter stack and raises a "Bad call" exception. This 
exception disables profiling effectively. However, the 
exception is later ignored (as we are in a destructor) and 
program execution continues. When the profiling is later 
finished, all time after the exception is accounted for the 
last function, that was on top of the profiler stack when 
profiling was disabled. This can be extremely confusing.

The attached script reproduces the problem. Run it 
through the Python interpreter. When you see an 
"Exception Bad call ... ignored", the interpreter has the 
described problem. We observed the problem in Python 
2.1.3
(on Linux, Solaris and Windows).