Comments on: How to leak a class you never defined http://tech.turbu-rpg.com/52/how-to-leak-a-class-you-never-defined My thoughts on Delphi programming in general, and particularly on the technical aspects of developing the TURBU engine and editor. Sun, 29 Jan 2012 00:52:04 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Barry Kelly http://tech.turbu-rpg.com/52/how-to-leak-a-class-you-never-defined/comment-page-1#comment-28 Barry Kelly Thu, 29 Oct 2009 14:36:44 +0000 http://tech.turbu-rpg.com/?p=52#comment-28 We've been aware of this issue with recursive anonymous method calls since the time they were designed. The problem comes from the limits of analysis: the call to the anonymous method is through a method reference location which is actually unassigned at the time of anonymous method construction - it's only assigned after the construction has completed and the assignment occurs. After that point, if the method reference location is not modified, it will indeed leak - but that requires figuring out when, where and if a given location will be modified. How do we know it's assigned once and never reassigned or cleared by the programmer? There could be an alias (a different name for the same location, such as a pointer), or it could be assigned multiple times (such as in a loop). Follow the analysis to its logical conclusion and you have to solve the Halting problem. At best, the compiler could give a warning that it looks like you're capturing the activation record inside the activation record itself. Or there could be some trickery done in the RTL, tracing through the object graph created by activation records, to automatically discover cycles at IInterface._Release time. Likely a runtime solution would be more robust and reliable than a compile-time one. We’ve been aware of this issue with recursive anonymous method calls since the time they were designed. The problem comes from the limits of analysis: the call to the anonymous method is through a method reference location which is actually unassigned at the time of anonymous method construction – it’s only assigned after the construction has completed and the assignment occurs. After that point, if the method reference location is not modified, it will indeed leak – but that requires figuring out when, where and if a given location will be modified. How do we know it’s assigned once and never reassigned or cleared by the programmer? There could be an alias (a different name for the same location, such as a pointer), or it could be assigned multiple times (such as in a loop). Follow the analysis to its logical conclusion and you have to solve the Halting problem.

At best, the compiler could give a warning that it looks like you’re capturing the activation record inside the activation record itself. Or there could be some trickery done in the RTL, tracing through the object graph created by activation records, to automatically discover cycles at IInterface._Release time. Likely a runtime solution would be more robust and reliable than a compile-time one.

]]>