Stefan Behnel wrote: > I wouldn't know why this kind of error cleanup should not be needed for > new-style temps, so I'm not sure if it's just plain wrong from my side to > put it there because of some reason I'm not aware of, or if I stumbled > over > a hidden bug here.
I must admit I felt a bit like I was using a big, blunt axe to carve out NewTempExprNode -- I only understood about half of what I did. So it is very unlikely that you fail to see something here, I think you have a much better understanding of this stuff than myself at least. (The good news is that the fixes are likely to be very small I think, I don't think there are fundamental design flaws, but in some ways it needs you to do it...at least I don't know this stuff well enough.) About the failing XDECREF in error label...hmm, nothing in particular comes to mind -- both NewTempExprNode and TempsBlockNode seem to set the temps to NULL when they are decref-ed...perhaps it is some interaction with the old temp system, that when transferring values from the new to the old temp system, the old system decides it doesn't need to incref it because it expects the reference to be transferred because the source node has is_temp set to True? But it is a wild guess. On to something related: I did find another likely memory leak though: TempsBlockNode doesn't automatically clear the temps that is used on exit of the TempsBlockNode -- so if you have two of those in a row, using temps of the same type, there will be a memory leak. Putting DECREF in the loop around line 67 in UtilNodes.py should do it. This assumes that transforms always use all the temps they ask for. (Can you have a look if you're at this already? Two dict-loop-optimizations in a row in a function should trigger it...) Perhaps one should make it more convenient to specify an initial value for the temps, the API is kind of assymetrical otherwise. Also that would allow changing the XDECREF in TempRefNode.generate_assignment_code to DECREF (the XDECREF is there so that the first SingleAssignmentNode doesn't fail). Sorry about writing rather than coding but I have exams up to read for. Which reminds me...enough procrastination, gtg :-) Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
