Bug 30864 - SEGV in SQLite binding during SGen GC collection
Summary: SEGV in SQLite binding during SGen GC collection
Alias: None
Product: Runtime
Classification: Mono
Component: GC (show other bugs)
Version: 3.2.x
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2015-06-06 05:56 UTC by Mirco Bauer
Modified: 2017-10-11 17:43 UTC (History)
5 users (show)

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

gdb output (different sample/run though) (49.22 KB, text/plain)
2015-06-06 06:00 UTC, Mirco Bauer
full thread-dump of another run (3.03 KB, text/plain)
2015-06-06 06:07 UTC, Mirco Bauer

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 GitHub or Developer Community 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 Mirco Bauer 2015-06-06 05:56:53 UTC
It looks that the SQLite binding of Mono triggers a SEGV during SGEn compaction. At least that is my understanding of the stack trace shown below. This issue is only reproducible if more than one thread tries to access 2 independent SQLite databases. Each thread owns its own SQLite connection and database. Also adding locks to guarantee only one thread accesses the database at a time (to not rely on SQLite's threading defaults) has not solved this issue.

This bug is tracked in Smuxi here:

Thread 12 (Thread 0x7fffeeb0b700 (LWP 18136)):
#0  0x00007ffff74bf101 in __pthread_kill (threadid=<optimized out>, signo=signo@entry=24) at ../nptl/sysdeps/unix/sysv/linux/pthread_kill.c:61
#1  0x000000000063bfb9 in mono_threads_pthread_kill (info=info@entry=0x7fffc40b1fe0, signum=signum@entry=24) at mono-threads-posix.c:177
#2  0x00000000005d8e9d in sgen_thread_handshake (suspend=suspend@entry=0) at sgen-os-posix.c:191
#3  0x0000000000606f26 in sgen_restart_world (generation=generation@entry=0, timing=timing@entry=0x7fffeeb09a60) at sgen-stw.c:260
#4  0x00000000005e3037 in sgen_perform_collection (requested_size=4096, generation_to_collect=0, reason=<optimized out>, wait_to_finish=<optimized out>) at sgen-gc.c:3544
#5  0x00000000005f9f44 in mono_gc_alloc_obj_nolock (vtable=vtable@entry=vtable("System.Char[]"), size=size@entry=1776) at sgen-alloc.c:288
#6  0x00000000005fa154 in mono_gc_alloc_vector (vtable=vtable("System.Char[]"), size=1776, max_length=872) at sgen-alloc.c:491
#7  0x0000000040021929 in (wrapper managed-to-native) object:__icall_wrapper_mono_gc_alloc_vector (param0=12546016, param1=1776, param2=872) at <unknown>:41
#8  0x00000000400150a8 in (wrapper alloc) object:AllocVector (param0=12546016, param1=872) at <unknown>:300
#9  0x00000000400d6578 in System.Text.Encoding:GetChars (this=..., bytes=byte [872], index=0, count=872) at <unknown>:299
#10 0x00000000400d6516 in System.Text.Encoding:GetString (this=..., bytes=byte [872], index=0, count=872)
#11 0x00000000401c3e20 in System.Text.UTF8Encoding:GetString (this=..., bytes=byte [872], index=0, count=872)
#12 0x00000000401c3d99 in Mono.Data.Sqlite.SqliteConvert:UTF8ToString (nativestring=140736420612504, nativestringlen=872)
#13 0x00000000401d87cc in Mono.Data.Sqlite.SQLite3:GetText (this=<optimized out>, stmt=..., index=0)
#14 0x00000000401c8788 in Mono.Data.Sqlite.SQLite3:GetValue (this=..., stmt=..., index=0, typ=...)
#15 0x00000000401c7cb6 in Mono.Data.Sqlite.SqliteDataReader:GetValue (this=..., i=0)
#16 0x0000000040202c50 in Mono.Data.Sqlite.SqliteDataReader:get_Item (this=..., name="JSON")
#17 0x0000000040202a02 in Smuxi.Engine.SqliteMessageBuffer:GetRange (this=..., offset=1187, limit=6999)
    at /home/felipe/smuxi/src/Engine/MessageBuffers/SqliteMessageBuffer.cs:242
#18 0x00000000401e2d0d in Smuxi.Engine.ChatModel:GetSyncMessages (this=...) at /home/felipe/smuxi/src/Engine/Chats/ChatModel.cs:271
#19 0x00000000401e2780 in Smuxi.Engine.ChatModel:get_Messages (this=...) at /home/felipe/smuxi/src/Engine/Chats/ChatModel.cs:83
#20 0x00000000401baed7 in (wrapper runtime-invoke) <Module>:runtime_invoke_object__this__ (this=Smuxi.Engine.ProtocolChatModel = {...}, params=<optimized out>, exc=0, 
    method=1075717968) at <unknown>:235
#21 0x0000000000426718 in mono_jit_runtime_invoke (method="Smuxi.Engine.ChatModel:get_Messages ()", obj=0x7ffff6c77cb8, params=0x7fffeeb0a240, exc=0x0) at mini.c:6654
#22 0x00000000005b8a8d in mono_runtime_invoke (method=method@entry="Smuxi.Engine.ChatModel:get_Messages ()", obj=obj@entry=0x7ffff6c77cb8, params=params@entry=0x7fffeeb0a240, 
    exc=exc@entry=0x0) at object.c:2828
#23 0x00000000005bbaa1 in mono_runtime_invoke_array (method=<optimized out>, obj=obj@entry=0x7ffff6c77cb8, params=params@entry=0x7ffff6d814a8, exc=exc@entry=0x0)
    at object.c:4265
#24 0x000000000053a862 in ves_icall_InternalExecute (method=<optimized out>, this=0x7ffff6c77cb8, params=0x7ffff6d814a8, outArgs=0x7fffeeb0a420) at icall.c:2959
#25 0x000000004016c84f in (wrapper managed-to-native) System.Runtime.Remoting.RemotingServices:InternalExecute (param0=..., param1=Smuxi.Engine.ProtocolChatModel = {...}, 
    param2=System.Object [0], param3=140737197941792) at <unknown>:67
#26 0x000000004016c198 in System.Runtime.Remoting.RemotingServices:InternalExecuteMessage (target=..., reqMsg=...)
    at /tmp/buildd/mono-3.2.8+dfsg/mcs/class/corlib/System.Runtime.Remoting/RemotingServices.cs:162
#27 0x000000004016b960 in System.Runtime.Remoting.Messaging.StackBuilderSink:SyncProcessMessage (this=..., msg=...)
    at /tmp/buildd/mono-3.2.8+dfsg/mcs/class/corlib/System.Runtime.Remoting.Messaging/StackBuilderSink.cs:59
#28 0x000000004016b7bb in System.Runtime.Remoting.Messaging.ServerObjectTerminatorSink:SyncProcessMessage (this=..., msg=...)
    at /tmp/buildd/mono-3.2.8+dfsg/mcs/class/corlib/System.Runtime.Remoting.Messaging/ServerObjectTerminatorSink.cs:54
#29 0x000000004016b616 in System.Runtime.Remoting.Lifetime.LeaseSink:SyncProcessMessage (this=..., msg=...)
#30 0x000000004016b1cb in System.Runtime.Remoting.ClientActivatedIdentity:SyncObjectProcessMessage (this=..., msg=...)
    at /tmp/buildd/mono-3.2.8+dfsg/mcs/class/corlib/System.Runtime.Remoting/ServerIdentity.cs:191
#31 0x000000004016b089 in System.Runtime.Remoting.Messaging.ServerContextTerminatorSink:SyncProcessMessage (this=<optimized out>, msg=...)
#32 0x000000004016a08e in System.Runtime.Remoting.Contexts.CrossContextChannel:SyncProcessMessage (this=<optimized out>, msg=...)
    at /tmp/buildd/mono-3.2.8+dfsg/mcs/class/corlib/System.Runtime.Remoting.Contexts/CrossContextChannel.cs:62
#33 0x00000000401693cc in System.Runtime.Remoting.Channels.ChannelServices:SyncDispatchMessage (msg=...) at <unknown>:395
#34 0x00000000401691e8 in System.Runtime.Remoting.Channels.ChannelServices:DispatchMessage (sinkStack=<optimized out>, msg=..., replyMsg=140737197943312)
    at /tmp/buildd/mono-3.2.8+dfsg/mcs/class/corlib/System.Runtime.Remoting.Channels/ChannelServices.cs:191
#35 0x000000004016919c in System.Runtime.Remoting.Channels.ServerDispatchSink:ProcessMessage (this=<optimized out>, sinkStack=..., requestMsg=..., 
    requestHeaders=<optimized out>, requestStream=<optimized out>, responseMsg=140737197943312, responseHeaders=140737197943328, responseStream=140737197943320)
#36 0x00000000401565bb in ?? ()
#37 0x00000000401529c7 in ?? ()
#38 0x0000000040150e84 in ?? ()
#39 0x0000000040150d00 in ?? ()
#40 0x00000000400ebeab in System.Threading.Thread:StartInternal (this=...) at /tmp/buildd/mono-3.2.8+dfsg/mcs/class/corlib/System.Threading/Thread.cs:693
#41 0x000000004001ac83 in (wrapper runtime-invoke) object:runtime_invoke_void__this__ (this=System.Threading.ThreadStart = {...}, params=<optimized out>, exc=0, 
    method=1074491376) at <unknown>:111
#42 0x0000000000426718 in mono_jit_runtime_invoke (method="System.Threading.ThreadStart:Invoke ()", obj=0x7ffff6fee878, params=0x7fffeeb0ae30, exc=0x0) at mini.c:6654
#43 0x00000000005b8a8d in mono_runtime_invoke (method="System.Threading.ThreadStart:Invoke ()", obj=obj@entry=0x7ffff6fee878, params=params@entry=0x7fffeeb0ae30, 
    exc=exc@entry=0x0) at object.c:2828
#44 0x00000000005b98c1 in mono_runtime_delegate_invoke (delegate=delegate@entry=0x7ffff6fee878, params=params@entry=0x7fffeeb0ae30, exc=exc@entry=0x0) at object.c:3539
#45 0x0000000000591879 in start_wrapper_internal (data=0x7fffd8009cb0) at threads.c:649
#46 start_wrapper (data=0x7fffd8009cb0) at threads.c:688
#47 0x000000000062ba1d in thread_start_routine (args=args@entry=0xa16978) at wthreads.c:294
#48 0x000000000063bd93 in inner_start_thread (arg=0x7fffd8008190) at mono-threads-posix.c:49
#49 0x00007ffff74ba0a4 in start_thread (arg=0x7fffeeb0b700) at pthread_create.c:309
#50 0x00007ffff71ef04d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Comment 1 Mirco Bauer 2015-06-06 05:59:03 UTC
PS: I tried to find potential bugs in the Mono.Data.Sqlite binding but the code that awful that I consider using a different binding. I don't think that binding is fixable, _if_ the binding is the causing this bug and its not SGen's fault.
Comment 2 Mirco Bauer 2015-06-06 06:00:13 UTC
Created attachment 11489 [details]
gdb output (different sample/run though)
Comment 3 Mirco Bauer 2015-06-06 06:01:04 UTC
Also we can reproduce this issue in Smuxi with a specific dataset and workload. If you need more details, please say!
Comment 4 Mirco Bauer 2015-06-06 06:07:35 UTC
Created attachment 11490 [details]
full thread-dump of another run
Comment 5 Mirco Bauer 2015-06-11 22:54:44 UTC
One thing I haven't mentioned yet that I can't reproduce this issue if Mono runs with the Boehm GC (mono --gc=boehm)
Comment 6 Vlad Brezae 2016-12-15 22:48:54 UTC
Hello Mirco

The attached stack trace is not of a crash but of a SIGPWR signal which is used as part of sgen's stop the world. Is the original crash issue still existing with recent releases (4.6) ? Could you attach a stack trace for that if it is ?

Comment 7 Rodrigo Kumpera 2017-10-11 17:43:54 UTC
We have not received the requested information. If you are still experiencing this issue please provide all the requested information and reopen the bug report.

Thank you!