On 10 January 2011 19:31, Robert Bradshaw <rober...@math.washington.edu>wrote:
> On Mon, Jan 10, 2011 at 3:28 AM, mark florisson > <markflorisso...@gmail.com> wrote: > > Hello, > > There is a slight problem with the scope object in closures because it is > > not initialized to NULL in closure frames, it is instead initialized > later > > by assigning a function argument to it. For the debugger this is a > problem > > when execution of the debuggee is halted before this assignment happens, > > because there is no way to tell whether closed-over variables are valid > or > > not. For e.g. the listing of local variables this is not a big issue, as > > this is entirely safe. But for code execution this means the debugger > will > > have the debuggee try to put an invalid pointer in a dict in which the > code > > will be executed, with a near 100% chance of segfaulting the debuggee. > > So the question is, could we simply initialize the scope objects to NULL? > > I think that'd be a fine thing to do. Are there any code paths that > don't initialize this before its actually used (in which case the > initial assignment may get optimized away)? > No the scope object is always initialized (it has to be as it's only present when inner scopes access free variables from outer scopes, or when the outer scope needs to store user-variables in scope objects), but the problem is that execution may be halted by the debugger before it is initialized. When automatic variables are set to NULL and the debugger breaks on the function, accesses to such variables will return NULL even before the actual assignment and declaration happen, instead of "something random". In any case, I think automatic variables that are initialized to NULL but not used may get optimized anyway. So then we come to the next point, who wants to implement this? :) I had a brief initial attempt by assigning 'NULL' to the 'init' attribute of the scope AST entry, which was unfruitful. I could take a deeper look into this issue, if I should, please tell me (and please don't hesitate to give some pointers :). - Robert > _______________________________________________ > Cython-dev mailing list > Cython-dev@codespeak.net > http://codespeak.net/mailman/listinfo/cython-dev >
_______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
