AccessViolationException

karol · Post by **karol** » Wed 05 Aug 2009 16:25

I have the following error after running my app for a few hours:

AccessViolationException
Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at OciDynamicType.nativeOCIDescriptorFree(IntPtr , Int32 )
at OciDynamicType.OCIDescriptorFree(IntPtr , Int32 )
at Devart.Data.Oracle.s.a(IntPtr A_0)
at Devart.Data.Oracle.b.m()
at Devart.Data.Oracle.b.a()
at Devart.Data.Oracle.OracleDataReader.Close()

I'm using the newest verison of dotconnect for Oracle, 64-bit basic lite instant client ver 10.2.0.3. This particular query does not use any special types but the connection is used in different queries with SDO geometries.

Really hard to reproduce, occurs "randomly".
For a time being I changed the client to ver. 11 and see if it helps - but like I said, sometimes it takes days for error to occurs.

Any help will be highly appreciated.

AndreyR · Post by **AndreyR** » Thu 06 Aug 2009 09:27

We have made some fixes associated with cursors in the upcoming build.
These fixes should solve the problem.

karol · Post by **karol** » Thu 06 Aug 2009 10:07

That's really great to hear Andrey. When can we expect the next release? Any public betas/RC?

AndreyR · Post by **AndreyR** » Thu 06 Aug 2009 12:49

The build is available.
Please let me know if the problem persists.

karol · Post by **karol** » Thu 06 Aug 2009 22:32

I'm afraid the error still exists. Moreover since the Close operation fails, garbage collector is trying to release the reader implicitly in its own thread via Finalize. And then it's even worse - since I don't have any control over garbage collector thread I cannot catch the next exception. The exception is unhandled and leaves Dispose method -> finalizer -> reaches the top of the thread stack and IIS kills the whole application.

I've noticed that this exception occurs with two others exceptions (somthing to do with reading Date/Time values).
There was another exception in nativeOCIStmtCache but since it was ThreadAbortException I assumed that it was trigger by IIS itself as a part of shutdown procedure.

AndreyR · Post by **AndreyR** » Fri 07 Aug 2009 09:02

Please make sure you execute the explicit Close() for the readers you open in your code, as it is recommended in
ADO.NET Best Practices. The problem is likely to be associated with it.

karol · Post by **karol** » Fri 07 Aug 2009 09:26

Andrey, do you mean that the following pattern is incorrect:

using(var myReader = command.ExecuteReader())
{
...
}

and I have to explicitly call .Close()?

Also I'm using a single connection which is shared across multiple threads, and spawn multiple readers at the same time. Do you think this might cause a problem (the code used to work with ODP.NET and such approach didn't cause a problem with its architecture)?

AndreyR · Post by **AndreyR** » Fri 07 Aug 2009 11:49

The "using" pattern is correct.
As for the multithreading, this can be a stumbling block, as the Connection object isn't thread-safe (by Microsoft design).
Please try to migrate to the connection-per-thread model, this should help.