Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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)
- xCode 4.5.1
- MonoDevelop 220.127.116.11
- 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>
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.
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.
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.
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:
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.
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?
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.
*** Bug 7134 has been marked as a duplicate of this bug. ***