[Mono-dev] OracleClient.Oci and GC

Neale Ferguson NealeFerguson at verizon.net
Fri Aug 22 13:45:19 UTC 2014

I am also wondering about the parameters in some of the OCIBindxxxx methods and the OCIDefineByPosPtr that are "ref IntPtr". There's a small window when GC could suspend the thread where the IntPtr object is also moved before the OCI call has completed and set the underlying IntPtr field.

On Aug 21, 2014, at 9:48 PM, Miguel de Icaza <miguel at xamarin.com> wrote:

> Hello,
> Wanted to follow up to Neale's comment, as he clarified an important point that I overlooked.
> There are two ref parameters that are being passed to unmanaged code, both point to fields inside the OciDefineHandle managed type.   
> 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.
> The proposed fix is one possible solution: to allocate the values outside of the managed heap for both the short values.
> 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:
> ref value: used in DefineTimeStamp
> ref value: when passing the reference to a Handle defined in a separate class, DefineLob, DefineInterval
> The above does not look very easy to fix.
> 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.
> Miguel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20140822/5f86966a/attachment.html>

More information about the Mono-devel-list mailing list