Bug 7667 - Uncatchable exceptions in sqlite3
Summary: Uncatchable exceptions in sqlite3
Alias: None
Product: iOS
Classification: Xamarin
Component: Xamarin.iOS.dll ()
Version: 6.0.x
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
: 7134 ()
Depends on:
Reported: 2012-10-04 21:20 UTC by bugzilla
Modified: 2012-10-19 06:52 UTC (History)
4 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description bugzilla 2012-10-04 21:20:42 UTC
Hi There,

I am getting some uncatchable exceptions originating from within the Sqlite3 library. In particular, I am seeing exceptions originating from calls to:
    (wrapper managed-to-native) SQLite.SQLite3.Step
    (wrapper managed-to-native) SQLite.SQLite3.Prepare2

I have tried wrapping the offending code in try/catch blocks to catch the errors and then handle them, but the error is not caught and the app continues to crash.

You can find a code example that causes a crash in the Step method at: https://github.com/perkof/SqliteUncatchableException - this error can be reproduced in the simulator and on an actual device - I have not yet managed to make a simplified example that causes the Prepare2 crash.

Start up the sample project and click the 'Start' button - it will begin to populate a database and count the records. Sometimes it can take a little while to crash, but it generally crashes before the count gets to 10,000.

Current environment (This has been an issue for some time, but I have only just found the time to create the sample code)
 - iOS6 
 - xCode 4.5.1
 - MonoDevelop
 - MonoTouch 6.0.2
 - Mono 2.10.9 

Below is an example of a stacktrace when one of these errors occurs:

  at (wrapper managed-to-native) SQLite.SQLite3.Step (intptr) <IL 0x00025, 0xffffffff>
  at SQLite.SQLiteCommand.ExecuteScalar<int> () [0x00031] in /Users/username/Desktop/Personal/SqlLite/Problems/Problems/SQL/SqlLite.cs:1674
  at SQLite.TableQuery`1.Count () [0x00000] in /Users/username/Desktop/Personal/SqlLite/Problems/Problems/SQL/SqlLite.cs:2331
  at Problems.ProblemsViewController.<OnTimerElapsed>m__0 () [0x00006] in /Users/username/Desktop/Personal/SqlLite/Problems/Problems/ProblemsViewController.cs:28
  at MonoTouch.Foundation.NSActionDispatcher.Apply () [0x00000] in /Developer/MonoTouch/Source/monotouch/src/shared/Foundation/NSAction.cs:53
  at (wrapper runtime-invoke) object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) <IL 0x0004e, 0xffffffff>
  at (wrapper managed-to-native) MonoTouch.UIKit.UIApplication.UIApplicationMain (int,string[],intptr,intptr) <IL 0x0009f, 0xffffffff>
  at MonoTouch.UIKit.UIApplication.Main (string[],string,string) [0x0004c] in /Developer/MonoTouch/Source/monotouch/src/UIKit/UIApplication.cs:38
  at Problems.Application.Main (string[]) [0x00000] in /Users/username/Desktop/Personal/SqlLite/Problems/Problems/Main.cs:17
  at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object (object,intptr,intptr,intptr) <IL 0x00050, 0xffffffff>

Native stacktrace:

	0   Problems                            0x0009152c mono_handle_native_sigsegv + 284
	1   Problems                            0x000062b8 mono_sigsegv_signal_handler + 248
	2   libsystem_c.dylib                   0x9736186b _sigtramp + 43
	3   ???                                 0xffffffff 0x0 + 4294967295
	4   libsqlite3.dylib                    0x05214646 sqlite3VdbeExec + 56758
	5   libsqlite3.dylib                    0x05181be1 sqlite3_step + 3169
	6   ???                                 0x1575e3cf 0x0 + 360047567
	7   ???                                 0x1575db94 0x0 + 360045460
	8   ???                                 0x1575cbcc 0x0 + 360041420
	9   ???                                 0x1575a81c 0x0 + 360032284
	10  ???                                 0x1575a798 0x0 + 360032152
	11  ???                                 0x0b7dfb98 0x0 + 192805784
	12  Problems                            0x0000a672 mono_jit_runtime_invoke + 722
	13  Problems                            0x0016c0ae mono_runtime_invoke + 126
	14  Problems                            0x0020eb48 monotouch_trampoline + 3688
	15  libobjc.A.dylib                     0x0402e6b0 -[NSObject performSelector:withObject:] + 70
	16  Foundation                          0x0199a035 __NSThreadPerformPerform + 327
	17  CoreFoundation                      0x012c2f3f __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15
	18  CoreFoundation                      0x012c296f __CFRunLoopDoSources0 + 239
	19  CoreFoundation                      0x012e5734 __CFRunLoopRun + 964
	20  CoreFoundation                      0x012e4f44 CFRunLoopRunSpecific + 276
	21  CoreFoundation                      0x012e4e1b CFRunLoopRunInMode + 123
	22  GraphicsServices                    0x04d0c7e3 GSEventRunModal + 88
	23  GraphicsServices                    0x04d0c668 GSEventRun + 104
	24  UIKit                               0x0272265c UIApplicationMain + 1211
	25  ???                                 0x10da5bb5 0x0 + 282745781
	26  ???                                 0x10da37f8 0x0 + 282736632
	27  ???                                 0x10da2b90 0x0 + 282733456
	28  ???                                 0x10da2ce6 0x0 + 282733798
	29  Problems                            0x0000a672 mono_jit_runtime_invoke + 722
	30  Problems                            0x0016c0ae mono_runtime_invoke + 126
	31  Problems                            0x00170234 mono_runtime_exec_main + 420
	32  Problems                            0x00175625 mono_runtime_run_main + 725
	33  Problems                            0x000678c5 mono_jit_exec + 149
	34  Problems                            0x00203e51 main + 2209
	35  Problems                            0x00003675 start + 53

Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
Comment 1 Rolf Bjarne Kvinge [MSFT] 2012-10-05 07:00:16 UTC
You're creating records on one thread (Timer.Elapsed occurs on a different thread, you're handling it in ProblemsViewController.cs, but not in SqliteHelper.cs) - and Sqlite isn't thread-safe by default.

Try doing everything sql-related on one thread, and the crash should go away.
Comment 2 Rolf Bjarne Kvinge [MSFT] 2012-10-05 07:03:30 UTC
Correction: Sqlite in iOS is multi-threaded by default, which means that you can use different threads as long as you use separate connections - only one thread per connection.
Comment 3 Sebastien Pouliot 2012-10-05 09:05:29 UTC
You can change sqlite default to be "more" thread-safe by calling, very early in tyour application (i.e. before any other use of sqlite) this code:

    SqliteConnection.SetConfig (SQLiteConfig.Serialized);

This will serialize all the calls, so it might not be as fast as the default "SQLiteConfig.MultiThread", but it will ensure you won't run into threading issues.

[1] http://monotouch.2284126.n4.nabble.com/SQLite-sqlite-net-and-threads-td4657122.html
[2] http://stackoverflow.com/questions/8325601/sqlite3-database-in-iphone-gets-locked-how-to-avoid/8327682#8327682
Comment 4 bugzilla 2012-10-06 00:13:07 UTC
Hi Guys,

Thanks for your feedback and information, it was very helpful -- setting the connection to serialized has fixed the issue in my sample app. I will apply this to my real app over the next few days and hopefully it will fix it up.

Out of curiosity - why can I not catch the exceptions coming back?
Comment 5 Sebastien Pouliot 2012-10-06 10:37:01 UTC
This is not an exception, it's a native crash. While it could be catch (and it is, control goes back to mono_sigsegv_signal_handler) the application state, at this point, is unknown (e.g. in your case libsqlite structures are corrupted from being written from several threads).

Further execution would crash anyway (e.g. the stack it could be bad). Also crashing right-away reduce the probability of using corrupt data and breaking even more your application (and it's data).

Closing bug. Please re-open it if this does not solve the issue in your real application.
Comment 6 Rolf Bjarne Kvinge [MSFT] 2012-10-19 06:52:37 UTC
*** Bug 7134 has been marked as a duplicate of this bug. ***