[IronPython] Odd tracebacks

[Michael Foord]

Dan Eloff wrote:
> Well it seems that certain code that is run with exec will create the
> bad frames which then gets attached to subsequent exceptions. It isn't
> related to the Microsoft.Scripting.Silverlight code, but it could
> still be silverlight specific. Actually I'm highly suspicious of the
> big block of code in GetDyanmicStackFrames that seems to be for
> filtering bad frames out, which is ifdefed out for silverlight. Do you
> remember why that part isn't used for silverlight? I'll keep digging
> and see if I find anything more concrete.
>   

FWIW (which may not be much) we used to see a very similar problem in 
IronPython 1. We fixed it by adding an explicit sys.exc_clear whenever 
we handled exceptions and needed a reliable traceback.

Michael
> Thanks,
> -Dan
>
> On Fri, Jan 16, 2009 at 3:10 PM, Dino Viehland <dinov at microsoft.com> wrote:
>   
>> 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-bounces at lists.ironpython.com [mailto:users-bounces at 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 at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>     
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog