System.Data.SQLite

Login
This project makes use of Eagle, provided by Mistachkin Systems.
Eagle: Secure Software Automation
Ticket Hash: 43d04ebaa4bb67d01df9075e3925854dd8f3577c
Title: 'System.Data.SQLite.SQLiteException: bad parameter or other API misuse' error when used in multithreaded environment
Status: Closed Type: Incident
Severity: Important Priority: Medium
Subsystem: Connection Resolution: Need_More_Info
Last Modified: 2018-05-28 19:22:00
Version Found In: 1.0.108
User Comments:
anonymous added on 2018-05-14 18:15:38:
Issue might be similar to fixed in this provider: https://github.com/aspnet/Microsoft.Data.Sqlite/issues/508

Stack trace:
at System.Data.SQLite.SQLite3.Prepare(SQLiteConnection cnn, String strSql, SQLiteStatement previous, UInt32 timeoutMS, String& strRemain)
   at System.Data.SQLite.SQLiteCommand.BuildNextCommand()
   at System.Data.SQLite.SQLiteDataReader.NextResult()
   at System.Data.SQLite.SQLiteDataReader..ctor(SQLiteCommand cmd, CommandBehavior behave)
   at System.Data.SQLite.SQLiteCommand.ExecuteReader(CommandBehavior behavior)
   at System.Data.Entity.Infrastructure.Interception.InternalDispatcher`1.Dispatch[TTarget,TInterceptionContext,TResult](TTarget target, Func`3 operation, TInterceptionContext interceptionContext, Action`3 executing, Action`3 executed)
   at System.Data.Entity.Infrastructure.Interception.DbCommandDispatcher.Reader(DbCommand command, DbCommandInterceptionContext interceptionContext)
   at System.Data.Entity.Core.EntityClient.Internal.EntityCommandDefinition.ExecuteStoreCommands(EntityCommand entityCommand, CommandBehavior behavior)
   --- End of inner exception stack trace ---
   at System.Data.Entity.Core.EntityClient.Internal.EntityCommandDefinition.ExecuteStoreCommands(EntityCommand entityCommand, CommandBehavior behavior)
   at System.Data.Entity.Core.Objects.Internal.ObjectQueryExecutionPlan.Execute[TResultType](ObjectContext context, ObjectParameterCollection parameterValues)
   at System.Data.Entity.Core.Objects.ObjectContext.ExecuteInTransaction[T](Func`1 func, IDbExecutionStrategy executionStrategy, Boolean startLocalTransaction, Boolean releaseConnectionOnSuccess)
   at System.Data.Entity.Core.Objects.ObjectQuery`1.<>c__DisplayClass7.<GetResults>b__5()
   at System.Data.Entity.Core.Objects.ObjectQuery`1.GetResults(Nullable`1 forMergeOption)
   at System.Data.Entity.Core.Objects.ObjectQuery`1.<System.Collections.Generic.IEnumerable<T>.GetEnumerator>b__0()
   at System.Data.Entity.Internal.LazyEnumerator`1.MoveNext()
   at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)

mistachkin added on 2018-05-14 23:05:09:
It sounds like the same SQLiteConnection, SQLiteCommand, or SQLiteDataReader object is being used from more than one thread?

anonymous added on 2018-05-15 07:06:30:
No, they aren't shared. Provider is used with Entity Framework and EF isn't thread safe itself, so EF contexts are separate per thread. Exception happens not too often, it is hard to reproduce, symptoms are like  in the bug report on the link I've added in description.

mistachkin added on 2018-05-15 23:19:58:
Is CreateFunction being used (on any thread) when the exception is thrown?

mistachkin added on 2018-05-15 23:26:15:
It would be helpful to have the SQL query that triggered this exception.

mistachkin added on 2018-05-15 23:29:47:
Is this query being executed asynchronously against a connection that has been disposed (e.g. via exiting a 'using' block, etc)?

It may be useful to see the associated C# code that is triggering this issue.

mistachkin added on 2018-05-16 00:19:22:
Another thing that would be potentially quite useful would be to capture the
detailed log messages, using something like:

System.Diagnostics.Trace.Listeners.Add(
    new System.Diagnostics.TextWriterTraceListener(
        "C:\\full\\path\\to\\some\\file.log"));

anonymous added on 2018-05-17 07:12:54:
1. Not sure about CreateFunction. As i said it is used via Entity Framework, no direct calls.
2. Basically it was some SELECT query
3. Connections are also managed by Entity Framework and not created/disposed directly and I doubt EF has connection related bug as it would be reproduced and reported by much wider public by now.

I'll record some detailed logs and will update you with more info.

mistachkin added on 2018-05-19 03:36:58:
I'm looking forward to seeing the logs.  Without more information, I suspect it's
going to be extremely difficult to reproduce this, especially since threading is
(already) extensively (stress) tested via the existing test suite.

anonymous added on 2018-05-28 11:31:36:
Logging showed nothing suspicious and problem popped in several places in non deterministic way. I downloaded SQlite provider sources, added some brake points there and tried to reproduce problem. After thorough testing I found severe problem on our side - there was a place where async code was started and not awaited that used Entity Framework context closure that was running out of scope and was about to be disposed. So basically there was a race condition between this async code block and dying EF context. After making this place sane the problem went away completely. 

Thank you for your help!

mistachkin added on 2018-05-28 19:22:00:
Thanks for the update.