<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";
        color:black;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0cm;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";
        color:black;}
span.EmailStyle17
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;
        color:black;}
span.EmailStyle20
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=white lang=EN-NZ link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Yep &#8211; I remember that my fix was to set the &#8220;destructing&#8221; state indicator in a BeforeDestruction() override.&nbsp; This was then tested in _Release() to render it a NO-OP during execution of the destructor chain (incomplete, obviously, just to give the idea):<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&nbsp; Procedure BeforeDestruction;<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&nbsp;&nbsp;&nbsp;&nbsp; SetState(csDestroying);<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&nbsp; Function _Release;<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&nbsp;&nbsp;&nbsp; If csDestroying in State then EXIT;<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Nothing else needs be done, as long as any further BeforeDestruction overrides call inherited before doing their work, which they should do (in my framework I introduced another virtual to be overridden in my descendants, in case there were occasions when work was done to generate references during the destructor&nbsp; execution &#8211; even in your case, the FreeInstance() override is redundant I think, other than as a sanity/safety check and so could be made subject to some conditional compilation flag.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> delphi-bounces@delphi.org.nz [mailto:delphi-bounces@delphi.org.nz] <b>On Behalf Of </b>Todd<br><b>Sent:</b> Wednesday, 24 November 2010 6:15 p.m.<br><b>To:</b> NZ Borland Developers Group - Delphi List<br><b>Subject:</b> Re: [DUG] How's this for inconsistent<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>Actually, this would be better<br><br><span style='font-size:10.0pt'>function TamObject._Release: Integer;<br>begin<br>&nbsp; Result := InterlockedDecrement(FCount);<br>&nbsp; if (FCount = 0) then<br>&nbsp; begin<br>&nbsp;&nbsp;&nbsp; //add a reference count, incase an interface is acquired and released during destruction<br>&nbsp;&nbsp;&nbsp; InterlockedIncrement(FCount);<br>&nbsp;&nbsp;&nbsp; self.Destroy;<br>&nbsp; end;<br>end;&nbsp; </span><br><br><span style='font-size:10.0pt'>procedure TamObject.FreeInstance;<br>begin<br>&nbsp; //remove the reference count added in _Release</span><br><span style='font-size:10.0pt'>&nbsp; InterlockedDecrement(FCount);<br>&nbsp; assert(FCount = 0,'Destroying object with non-zero reference count');<br>&nbsp; inherited FreeInstance;<br>end;</span><br><br><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I spotted that they fixed that a while ago &#8211; I remember having to fix the issue myself many years ago so was quite pleased to see that it was now taken care of in TInterfaceObject as a matter of course.&nbsp; For some reason I never noticed the omission of the same facility in the destructor.&nbsp; And yes, it&#8217;s a [potentially] big problem.</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&nbsp;</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I need to think about this tho... setting a fake ref count during execution of the constructor is safe enough as you know precisely when construction is done and to restore the ref count back to zero.</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&nbsp;</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Setting a fake ref count during destruction strikes me as more problematic and makes me nervous, but I can&#8217;t quite put my finger on why.&nbsp; It might be nothing.&nbsp; That doesn&#8217;t mean it can&#8217;t be fixed, only that the solution put in place for construction might not work for destruction and it wasn&#8217;t felt necessary to do any extra work for a more comprehensive solution.</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&nbsp;</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&nbsp;</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Certainly in the case of my code where I fixed this I had specific &#8220;constructing&#8221; / &#8220;destructing&#8221; state markers (it wasn&#8217;t a general purpose interfacedobject class but a base class in a far richer framework that happened to also implement its own version of IUnknown) &#8211; I know I didn&#8217;t rely on side effects of a faked ref count.</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&nbsp;</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&nbsp;</span><o:p></o:p></p><div><div style='border:none;border-top:solid windowtext 1.0pt;padding:3.0pt 0cm 0cm 0cm;border-color:-moz-use-text-color -moz-use-text-color'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> <a href="mailto:delphi-bounces@delphi.org.nz">delphi-bounces@delphi.org.nz</a> [<a href="mailto:delphi-bounces@delphi.org.nz">mailto:delphi-bounces@delphi.org.nz</a>] <b>On Behalf Of </b>Todd<br><b>Sent:</b> Wednesday, 24 November 2010 16:55<br><b>To:</b> NZ Borland Developers Group - Delphi List<br><b>Subject:</b> [DUG] How's this for inconsistent</span><o:p></o:p></p></div></div><p class=MsoNormal>&nbsp;<o:p></o:p></p><p class=MsoNormal>The Delphi developer who implemented TInterfacedObject obviously considered the case when an interface reference is grabbed during construction......<br><br><span style='font-size:10.0pt'>// Set an implicit refcount so that refcounting<br>// during construction won't destroy the object.<br>class function TInterfacedObject.NewInstance: TObject;<br>begin<br>&nbsp; Result := inherited NewInstance;<br>&nbsp; TInterfacedObject(Result).FRefCount := 1;<br>end;<br><br>procedure TInterfacedObject.AfterConstruction;<br>begin<br>// Release the constructor's implicit refcount<br>&nbsp; InterlockedDecrement(FRefCount);<br>end;</span><br><br>but didn't consider applying the same logic during destruction. So grabing an interface reference during destruction causes all hell to break loose, as the _Release method tries to free the object again and again recursively.<br><br><span style='font-size:10.0pt'>procedure TInterfacedObject.BeforeDestruction;<br>begin<br>&nbsp; if RefCount &lt;&gt; 0 then<br>&nbsp;&nbsp;&nbsp; Error(reInvalidPtr);<br>end;</span><br><br><span style='font-size:10.0pt'>function TInterfacedObject._Release: Integer;<br>begin<br>&nbsp; Result := InterlockedDecrement(FRefCount);<br>&nbsp; if Result = 0 then<br>&nbsp;&nbsp;&nbsp; Destroy;<br>end;</span><br><br>Todd.<o:p></o:p></p><pre><o:p>&nbsp;</o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>_______________________________________________<o:p></o:p></pre><pre>NZ Borland Developers Group - Delphi mailing list<o:p></o:p></pre><pre>Post: <a href="mailto:delphi@delphi.org.nz">delphi@delphi.org.nz</a><o:p></o:p></pre><pre>Admin: <a href="http://delphi.org.nz/mailman/listinfo/delphi">http://delphi.org.nz/mailman/listinfo/delphi</a><o:p></o:p></pre><pre>Unsubscribe: send an email to <a href="mailto:delphi-request@delphi.org.nz">delphi-request@delphi.org.nz</a> with Subject: unsubscribe<o:p></o:p></pre><p class=MsoNormal><o:p>&nbsp;</o:p></p></div></body></html>