On 10 January 2011 20:40, Robert Bradshaw <[email protected]>wrote:
> On Mon, Jan 10, 2011 at 11:05 AM, mark florisson > <[email protected]> wrote: > > > > > > On 10 January 2011 19:31, Robert Bradshaw <[email protected]> > > wrote: > >> > >> On Mon, Jan 10, 2011 at 3:28 AM, mark florisson > >> <[email protected]> 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 :). > > Since you're dealing with the state of objects before argument > parsing, it may be more fruitful to initialize it directly as part of > the header generation code than via the AST (whose first statement > assumes the argument parsing has been atomically done previously). Thanks that did it, but of course I was mistaken as the automatic variables still point to uninitialized stack memory until they are initialized. I will have to find another way to detect whether the scope object was initialized, I think I will take the same approach as with the other variables, in this case comparing the current line number of C code with the C line number associated with the first Cython statement in the function. Unfortunately this requires some changes in the XML as this information is currently not available. > - Robert > _______________________________________________ > Cython-dev mailing list > [email protected] > http://codespeak.net/mailman/listinfo/cython-dev >
_______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
