<div dir="ltr">Finalization is not deterministic, it depends on the GC been able to collect all related objects.<div><br></div><div>Maybe you have things keeping some of those 700 objects around?</div><div><br></div><div>The way I test those things in a way that is reasonably reliable is:</div>
<div><br></div><div>var t = new Thread (myTest);</div><div><br></div><div>t.Start ();</div><div>t.Join ();<br></div><div><br></div><div>GC.Collect ();</div><div>GC.WaitForPendingFinalizers ();</div><div><br></div><div>//now verify the result.</div>
<div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 25, 2014 at 11:08 AM, Neale Ferguson <span dir="ltr"><<a href="mailto:NealeFerguson@verizon.net" target="_blank">NealeFerguson@verizon.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I implemented a Dispose method for OracleParameter:<br>
<br>
                ~OracleParameter ()<br>
                {<br>
                        Dispose(false);<br>
                }<br>
<br>
                public void Dispose ()<br>
                {<br>
                        Dispose (true);<br>
                }<br>
<br>
                void Dispose (bool disposing)<br>
                {<br>
                        if (disposing) {<br>
                                GC.SuppressFinalize(this);<br>
                        }<br>
                        if (indicator != IntPtr.Zero) {<br>
                                Marshal.FreeHGlobal (indicator);<br>
                                indicator = IntPtr.Zero;<br>
                        }<br>
                }<br>
<br>
However, when I run the test program I see 1251 constructors being run but only 572 destructors/disposals. How do I reconcile this disparity?<br>
<span class="HOEnZb"><font color="#888888"><br>
Neale<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Aug 22, 2014, at 11:40 AM, Neale Ferguson <<a href="mailto:NealeFerguson@verizon.net">NealeFerguson@verizon.net</a>> wrote:<br>
<br>
> Thanks. I've made changes to OciDefineHandle and have cured nearly all the failures I had been experiencing. I have started on OracleParameter as it has an object called indicator that is used by the OCIBindxxx calls and appears to suffer from the same problem. I was allocating the object in native memory in the constructors and was going to free them in a destructor. However, in my test runs I see I'm allocating 1200+ objects but only freeing ~900. Would you elaborate on your final comment "failing to dispose..." as I'm reading this as I don't need to Marshal.FreeHGlobal() the object I allocated in the constructors.<br>

><br>
> Neale<br>
><br>
> On Aug 22, 2014, at 11:31 AM, Rodrigo Kumpera <<a href="mailto:kumpera@gmail.com">kumpera@gmail.com</a>> wrote:<br>
><br>
>> Hey Neale,<br>
>><br>
>> You can safely pass interior pointers to pinvoke without fearing the object been collected for the duration of the call.<br>
>> Mind that you have to correctly use specify in/out/ref depending on the copy semantics you need.<br>
>><br>
>> Problems only arise when native keeps that pointer after the call finishes, this can result in the object been moved<br>
>> as the GC has no visibility into the native heap.<br>
>><br>
>> For those cases you can either create a pinning GC handle to the victim object or you can allocate a chunk of native<br>
>> memory that will be shared between managed and native to store the desired value. Both options suck, TBH.<br>
>><br>
>> I'd say go with the native chunk of code if you can't lexically scope the pinning regions, it will be more reliable as<br>
>> failing to dispose the object won't lead to permanent leaks.<br>
<br>
</div></div></blockquote></div><br></div>