[Mono-dev] OracleClient.Oci and GC

[Miguel de Icaza]

yeah, that makes sense.


On Fri, Aug 22, 2014 at 9:45 AM, Neale Ferguson <NealeFerguson at verizon.net>
wrote:

> 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/928cbd06/attachment.html>