[Mono-dev] OracleClient.Oci and GC

[Miguel de Icaza]

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


On Thu, Aug 21, 2014 at 6:58 PM, Neale Ferguson <NealeFerguson at verizon.net>
wrote:

> 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.
>
> Neale
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20140821/a44b02dd/attachment.html>