Page 1 of 1

AccessViolationException

Posted: Wed 05 Aug 2009 16:25
by karol
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.

Posted: Thu 06 Aug 2009 09:27
by AndreyR
We have made some fixes associated with cursors in the upcoming build.
These fixes should solve the problem.

Posted: Thu 06 Aug 2009 10:07
by karol
That's really great to hear Andrey. When can we expect the next release? Any public betas/RC?

Posted: Thu 06 Aug 2009 12:49
by AndreyR
The build is available.
Please let me know if the problem persists.

Posted: Thu 06 Aug 2009 22:32
by karol
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.

Posted: Fri 07 Aug 2009 09:02
by AndreyR
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.

Posted: Fri 07 Aug 2009 09:26
by karol
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)?

Posted: Fri 07 Aug 2009 11:49
by AndreyR
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.