Romain Slootmaekers wrote at 2003-10-30 08:47 +0100:
> No you did not, but the problem was prpbably not that sever:
> apparantly, from what I understand from your bug report, you get a
> "Exception Bad call ... ignored"
> In my particular case, that exception is not "...ignored", but cascades
> upwards, to the top level.
In our case, the complete time from the occurrence of the exception
until the end of profiling was assigned to a completely harmless
funtion. This was very confusing...
> > Should the problem come back with Python 2.2 or Python 2.3
> > and you do not find the patch in Python's bug tracker, come
> > back. I can send you the patch in this case.
> So you have a patch ?
--- :profile.py 2001-10-19 17:13:51.000000000 +0200
+++ profile.py 2003-05-30 07:38:50.000000000 +0200
@@ -236,6 +236,19 @@
def trace_dispatch_call(self, frame, t):
if self.cur and frame.f_back is not self.cur[-2]:
+ if getattr(frame.f_back,'f_back',None) is self.cur[-2]:
+ # this can happen becauses at the end
+ # of a function call Python's main interpreter loop
+ # calls "call_trace(...,'Return',...)" (which pops "self.cur")
+ # and then "reset_exc_info". When "reset_exc_info" calls
+ # a destructor, we observe the resulting inconsistency
+ # between runtime stack (function frame not popped)
+ # and profiler stack (function frame popped)
+ # We simply fall through and associate the destructor with
+ # the function's caller
rt, rtt, rct, rfn, rframe, rcur = self.cur
if not isinstance(rframe, Profile.fake_frame):
if rframe.f_back is not frame.f_back:
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -