Hi Sebastien,

I made a small test where one Task would constantly read and another one would 
constantly write.

Task oTask = Task.Factory.StartNew(delegate {
while(true)
{
        
AppDelegateBase.MasterDatabase.ReadConfigValue(CONFIG_CONSTANTS.CalendarShowAllAppointments,
 "");
        Console.WriteLine("Reading.");
}
} );

Task oTask2 = Task.Factory.StartNew(delegate {
while(true)
{
        
AppDelegateBase.MasterDatabase.WriteConfigValue(CONFIG_CONSTANTS.CalendarShowAllAppointments,
 "1");
        Console.WriteLine("Writing.");
}
} );

Than I played with the config. Without any specific config, I get after a short 
while: 

2012-08-30 20:28:07.862 BrainloopBrowser[3400:5203] Reading.
2012-08-30 20:28:07.863 BrainloopBrowser[3400:5203] Reading.
Stacktrace:

  at (wrapper managed-to-native) 
Mono.Data.Sqlite.UnsafeNativeMethods.sqlite3_prepare 
(intptr,intptr,int,intptr&,intptr&) <IL 0x0002a, 0xffffffff>
  at Mono.Data.Sqlite.SQLite3.Prepare 
(Mono.Data.Sqlite.SqliteConnection,string,Mono.Data.Sqlite.SqliteStatement,uint,string&)
 [0x00287] in 
/Developer/MonoTouch/Source/mono/mcs/class/Mono.Data.Sqlite/Mono.Data.Sqlite_2.0/SQLite3.cs:355

And that seems to be exactly what I reported in the bug  
https://bugzilla.xamarin.com/show_bug.cgi?id=6680.

Using

SqliteConnection.SetConfig( SQLiteConfig.Serialized ); 

fixes the issue, while SQLiteConfig.MultiThreaded doesn't - but as you 
explained, I share the connection.

Serialized access is exactly what I want. Even if there are more threads, I 
don't want them to access the DB at the same time.
However, now I'll have to check for deadlocks, but so far it's all looking 
great.

So as most of the time: your analysis was correct! Thanks a lot!

René

Am 29.08.2012 um 22:34 schrieb Sebastien Pouliot <[email protected]>:

> Hello René,
> 
> On Wed, Aug 29, 2012 at 2:49 PM, René Ruppert <[email protected]> wrote:
>> Thanks for the analysis. So the quick fix would be to set Sqlite to 
>> multithread mode?
> 
> Yes, that's the first thing to try. Now sqlite multithread mode [1]
> does not allow you to share the same connection across threads.
> 
> <quote>
> Multi-thread. In this mode, SQLite can be safely used by multiple
> threads provided that no single database connection is used
> simultaneously in two or more threads.
> </quote>
> 
>> If I set it to support multi threading, can I share the connection or is a 
>> new connection required for every query?
> 
> Only if you use `serialized` mode.
> 
> <quote>
> Serialized. In serialized mode, SQLite can be safely used by multiple
> threads with no restriction.
> </quote>
> 
> Note that the document can be misleading (fwiw it's not an iOS-related
> document) since `serialized` is the "generic" default for sqlite, but
> that's not how it was compiled (by Apple) for iOS [2].
> 
> Also you need to set this config very early in your process (before
> anything else use sqlite) or it will return an error (and it will be
> ignored). The API to do set this configuration was added in MT 5.1+
> [3].
> 
> Please let us know if this fix your issue (and also if you stop seeing
> bug #6680 [4] which could be related to this).
> 
> Regards,
> Sebastien
> 
> [1] http://www.sqlite.org/threadsafe.html
> [2] http://stackoverflow.com/q/11058098/220643
> [3] http://stackoverflow.com/a/8327682/220643
> [4] https://bugzilla.xamarin.com/show_bug.cgi?id=6680
> 
>> René
>> 
>> Am 29.08.2012 um 14:59 schrieb Sebastien Pouliot <[email protected]>:
>> 
>>> On Wed, Aug 29, 2012 at 4:18 AM, René Ruppert <[email protected]> 
>>> wrote:
>>>> Hi,
>>>> 
>>>> after upgrading from 5.2.13 to 5.3.6, this crash is the first thing I see 
>>>> in the 5.1 Simulator on Mountain Lion and this time I can reproduce it.
>>>> I have pasted the full log to a Gist: https://gist.github.com/3508383
>>> 
>>> Inside your gist note that both thread #0 and thread #11 (crasher) are
>>> running SQLite code at the same time. That's a bad sign if they are
>>> working on the same instance / data.
>>> 
>>>> I'm using Sqlite3 from another thread, not the UI main thread. I have not 
>>>> specified any special options in Sqlite (like multithreading) but I know 
>>>> that there is alway exactly one addtional thread and that is querying the 
>>>> DB, so this should not be an issue.
>>> 
>>> *one additional* means more than one. That's not ok if there's a
>>> single connection and that access to it are not controlled (or
>>> serialized) either by your code or by setting sqlite configuration.
>>> 
>>>> Can somebody see what might be going on?
>>>> 
>>>> René
>>>> 
>>>> at (wrapper managed-to-native) 
>>>> Mono.Data.Sqlite.UnsafeNativeMethods.sqlite3_step (intptr) <IL 0x00025, 
>>>> 0xffffffff>
>>>> at Mono.Data.Sqlite.SQLite3.Step (Mono.Data.Sqlite.SqliteStatement) 
>>>> [0x0001a] in 
>>>> /Developer/MonoTouch/Source/mono/mcs/class/Mono.Data.Sqlite/Mono.Data.Sqlite_2.0/SQLite3.cs:166
>>>> at Mono.Data.Sqlite.SqliteDataReader.NextResult () [0x00129] in 
>>>> /Developer/MonoTouch/Source/mono/mcs/class/Mono.Data.Sqlite/Mono.Data.Sqlite_2.0/SQLiteDataReader.cs:913
>>>> at Mono.Data.Sqlite.SqliteDataReader..ctor 
>>>> (Mono.Data.Sqlite.SqliteCommand,System.Data.CommandBehavior) [0x00051] in 
>>>> /Developer/MonoTouch/Source/mono/mcs/class/Mono.Data.Sqlite/Mono.Data.Sqlite_2.0/SQLiteDataReader.cs:89
>>>> at (wrapper remoting-invoke-with-check) 
>>>> Mono.Data.Sqlite.SqliteDataReader..ctor 
>>>> (Mono.Data.Sqlite.SqliteCommand,System.Data.CommandBehavior) <IL 0x00021, 
>>>> 0xffffffff>
>>>> at Mono.Data.Sqlite.SqliteCommand.ExecuteReader 
>>>> (System.Data.CommandBehavior) [0x00006] in 
>>>> /Developer/MonoTouch/Source/mono/mcs/class/Mono.Data.Sqlite/Mono.Data.Sqlite_2.0/SQLiteCommand.cs:539
>>>> at Mono.Data.Sqlite.SqliteCommand.ExecuteReader () [0x00000] in 
>>>> /Developer/MonoTouch/Source/mono/mcs/class/Mono.Data.Sqlite/Mono.Data.Sqlite_2.0/SQLiteCommand.cs:551
>>>> at (wrapper remoting-invoke-with-check) 
>>>> Mono.Data.Sqlite.SqliteCommand.ExecuteReader () <IL 0x00038, 0xffffffff>
>>>> at BrainloopMobile.Items.LocalServer.GetServer (int) [0x00024] in 
>>>> /Users/rene/Documents/Develop/Projects/BrainloopMobile/220/BrainloopMobile/BrainloopMobile/Items/LocalServer.cs:202
>>>> at BrainloopMobile.Items.LocalServer.GetAPIManager 
>>>> (BrainloopMobile.ServerUniqueDataroomID) [0x00043] in 
>>>> /Users/rene/Documents/Develop/Projects/BrainloopMobile/220/BrainloopMobile/BrainloopMobile/Items/LocalServer.cs:468
>>>> at BrainloopMobile.ProgressPreviewItem.ProgressLoop 
>>>> (BrainloopMobile.Progress.IProgressContext) [0x00000] in 
>>>> /Users/rene/Documents/Develop/Projects/BrainloopMobile/220/BrainloopMobile/BrainloopMobile/Progress/ProgressPreviewItem.cs:160
>>>> at BrainloopMobile.Progress.ModalProgressController.StartProgress () 
>>>> [0x00014] in 
>>>> /Users/rene/Documents/Develop/Projects/BrainloopMobile/220/BrainloopMobile/BrainloopMobile/Progress/Base/ModalProgressController.cs:329
>>>> at System.Threading.Thread.StartInternal () [0x0001d] in 
>>>> /Developer/MonoTouch/Source/mono/mcs/class/corlib/System.Threading/Thread.cs:697
>>>> at (wrapper runtime-invoke) object.runtime_invoke_void__this__ 
>>>> (object,intptr,intptr,intptr) <IL 0x0004e, 0xffffffff>
>>>> 
>>>> Native stacktrace:
>>>> 
>>>>       0   BrainloopBrowser                    0x001b877c 
>>>> mono_handle_native_sigsegv + 284
>>>>       1   BrainloopBrowser                    0x0012f108 
>>>> mono_sigsegv_signal_handler + 248
>>>>       2   libsystem_c.dylib                   0x9924286b _sigtramp + 43
>>>>       3   ???                                 0xffffffff 0x0 + 4294967295
>>>>       4   libsqlite3.dylib                    0x03c58b5d sqlite3_step + 
>>>> 2989
>>> 
>>> ^ that's SQLite (#4, native iOS library) calling an invalid pointer
>>> (#3), triggering the sigtramp (#2, OS), catched/handled by the mono
>>> runtime (#1, #0).
>>> 
>>> \/ that's the managed frames (that you have above in the managed stack 
>>> trace)
>>> 
>>>>       5   ???                                 0x138a97d7 0x0 + 327849943
>>>>       6   ???                                 0x138a94c0 0x0 + 327849152
>>>>       7   ???                                 0x138a62ab 0x0 + 327836331
>>>>       8   ???                                 0x138a5caa 0x0 + 327834794
>>>>       9   ???                                 0x138a5b20 0x0 + 327834400
>>>>       10  ???                                 0x138a4f04 0x0 + 327831300
>>>>       11  ???                                 0x138ad4f8 0x0 + 327865592
>>>>       12  ???                                 0x138ad494 0x0 + 327865492
>>>>       13  ???                                 0x13eb95d4 0x0 + 334206420
>>>>       14  ???                                 0x13bc3234 0x0 + 331100724
>>>>       15  ???                                 0x13bc1954 0x0 + 331094356
>>>>       16  ???                                 0x13ff0264 0x0 + 335479396
>>>>       17  ???                                 0x13f60d26 0x0 + 334892326
>>>>       18  ???                                 0x0afb5be4 0x0 + 184245220
>>>>       19  BrainloopBrowser                    0x001334c2 
>>>> mono_jit_runtime_invoke + 722
>>>>       20  BrainloopBrowser                    0x00296b9e 
>>>> mono_runtime_invoke + 126
>>>>       21  BrainloopBrowser                    0x00296d0c 
>>>> mono_runtime_delegate_invoke + 140
>>>>       22  BrainloopBrowser                    0x002f6e52 start_wrapper + 
>>>> 482
>>>>       23  BrainloopBrowser                    0x00328d6a 
>>>> thread_start_routine + 154
>>>>       24  BrainloopBrowser                    0x002d38f0 gc_start_thread + 
>>>> 80
>>>>       25  libsystem_c.dylib                   0x99256557 _pthread_start + 
>>>> 344
>>>>       26  libsystem_c.dylib                   0x99240cee thread_start + 34
>>>> 
>>>> _______________________________________________
>>>> MonoTouch mailing list
>>>> [email protected]
>>>> http://lists.ximian.com/mailman/listinfo/monotouch
>> 

_______________________________________________
MonoTouch mailing list
[email protected]
http://lists.ximian.com/mailman/listinfo/monotouch

Reply via email to