Good places to look would be:
ExceptionHelpers.UpdateStackTrace is where the frame should be
remembered
PythonOps.CreateTraceBack should be where we actually pull the current
set of frames for exceptions and build up the stack trace
ScriptingRuntimeHelpers.GetDynamicStackFrames is where we actually
figure out the frames associated with a particular exception. Those can
come from either a thread static or the exception object it's self.
I'd guess the bug is somehow related to the thread static
(ExceptionHelpers.DynamicStackFrames) tracking extra frames and not being
cleared at some appropriate time. I look forward to seeing what you find :)
-----Original Message-----
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Dan Eloff
Sent: Friday, January 16, 2009 11:18 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Odd tracebacks
This extraneous stack trace seems to happen on every exception. I've
confirmed that it's an IronPython problem, not silverlight. It only
ever consists of these two, and the debugger confirms that they aren't
called on the error path.
at pairwise in game/utils\functions.py, line 46
at __getattr__ in game\models\__init__.py, line 145
It's baffling. I tried again to make a repro, using duplicates of
these two functions, in the same package structure, but failed. I'm
going to try putting break points into the IronPython exception
formatting code and running under the debugger later today. I'd really
appreciate if I had some function names or places where I should put
break points, because I have no idea. I'll have to dig through the
IronPython code for hours to find appropriate places.
Thanks,
-Dan
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
