<div dir="ltr">Hello,<div><br></div><div>Wanted to follow up to Neale's comment, as he clarified an important point that I overlooked.</div><div><br></div><div>There are two ref parameters that are being passed to unmanaged code, both point to fields inside the OciDefineHandle managed type.   </div>

<div><br></div><div>Neale's analysis is correct: the object might move and with it, the two short variables that were passed to OciDefineByPos.   This would explain the crashes that developers are experiencing with the OracleClient provider and Sgen.</div>

<div><br></div><div>The proposed fix is one possible solution: to allocate the values outside of the managed heap for both the short values.</div><div><br></div><div>There is another suspicious use that we should look into.  The OciDefineByPos method is actually a set of overloaded methods, with different types for the "value" parameter.    It is often a handle that is usually allocated via an unmanaged API.   But there are a few troubling uses:</div>

<div><ul><li>ref value: used in DefineTimeStamp</li><li>ref value: when passing the reference to a Handle defined in a separate class, DefineLob, DefineInterval</li></ul><div>The above does not look very easy to fix.</div>

</div><div><br></div><div>Given that these are resources that should be explicitly disposed, perhaps what we should do is allocate a GCHandle for the OciDefineHandle object (from OciStatementHandle, the one place that creates these objects) and also create GCHandles for the objects that we use their Handle fields from (in DefineTimeStamp, DefineLob, DefineInterval) and release the GCHandles in the respective Dispose methods.</div>

<div><br></div><div>Miguel</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 21, 2014 at 6:58 PM, 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've been looking at OciDefineHandle and the OciDefineByPos call it uses in particular. Currently two of the parameters passed to this call are short variables. They are passed as "ref" fields as Oracle uses their address to put size and indicator data once the data is fetched. However, being defined as short means that they are eligible for being moved during garbage collection. Thus if that field is moved between the OciDefineByPos call and the fetch of the data then what Oracle is pointing to may no longer be variable. I'm thinking it may be better to define these fields as IntPtr and allocate them and retrieve their values via Marshal.ReadInt16. I'm currently testing these changes and so far I'm not getting the failures I had been encountering. If this is a valid analysis then the OciBindxxxx calls will also need attention as it uses a ref indp parameter as well - these appear to be used in OracleParameter.cs.<br>


<br>
Neale<br>
_______________________________________________<br>
Mono-devel-list mailing list<br>
<a href="mailto:Mono-devel-list@lists.ximian.com">Mono-devel-list@lists.ximian.com</a><br>
<a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
</blockquote></div><br></div>