[Mono-list] Frequent segfaults in c# running on mono
River Satya
river.satya at gmail.com
Mon Nov 30 04:30:35 UTC 2015
I just installed the 4.2 kernel and we get the same issue in our code.
Interestingly, I wasn't able to reproduce it against 4.1 or 4.2 using the
repro test case linked to from that bug.
Running 4.09 though, all seems well.
Any idea why the fix got rolled back? And when/whether it will be fixed
properly?
Thanks,
River
On 27 November 2015 at 23:32, River Satya <river.satya at gmail.com> wrote:
> Any idea if it's been fixed again in 4.2?
>
> On 27 November 2015 at 23:26, River Satya <river.satya at gmail.com> wrote:
>
>> Ah, of course, thank-you!! We had seen this in the past but not for a
>> while now. It resurfaced when we moved to a new instance, which still had
>> the old kernel. D'oh. Super unfortunate that this appears to be back in 4.1
>> :(.
>>
>> On 27 November 2015 at 23:10, Matt Calder <mvcalder at gmail.com> wrote:
>>
>>> River,
>>>
>>> We see seg-faults in multi-threaded code on Ubuntu 14.04 and 14.10.
>>> These can be reproduced relatively easily. We believe it is this bug:
>>>
>>> https://bugzilla.xamarin.com/show_bug.cgi?id=29692
>>>
>>> The discussions there will lead you to some discussions about kernel
>>> versions. We still see this bug using 3.13 or 3.19 kernels.
>>>
>>> Matt
>>>
>>>
>>> On Fri, Nov 27, 2015 at 5:31 AM, River Satya <river.satya at gmail.com>
>>> wrote:
>>>
>>>>
>>>> Stack trace flavour 3:
>>>>
>>>> --
>>>> :Stacktrace:
>>>> -
>>>> - at <unknown> <0xffffffff>
>>>> - at (wrapper managed-to-native)
>>>> System.Delegate.CreateDelegate_internal
>>>> (System.Type,object,System.Reflection.MethodInfo,bool) <IL 0x00010,
>>>> 0xffffffff>
>>>> - at System.Delegate.CreateDelegate
>>>> (System.Type,object,System.Reflection.MethodInfo,bool,bool) <0x0071a>
>>>> - at System.Delegate.CreateDelegate
>>>> (System.Type,object,System.Reflection.MethodInfo) <0x00021>
>>>> - at System.Reflection.Emit.DynamicMethod.CreateDelegate
>>>> (System.Type,object) <0x00043>
>>>> - at System.Linq.Expressions.Compiler.LambdaCompiler.CreateDelegate ()
>>>> <IL 0x00022, 0x00094>
>>>> - at System.Linq.Expressions.Compiler.LambdaCompiler.Compile
>>>> (System.Linq.Expressions.LambdaExpression,System.Runtime.CompilerServices.DebugInfoGenerator)
>>>> <IL 0x0001e, 0x000d6>
>>>> - at System.Linq.Expressions.Expression`1.Compile () <IL 0x00002,
>>>> 0x00016>
>>>> - at ServiceStack.OrmLite.SqlExpressionVisitor`1.VisitMemberAccess
>>>> (System.Linq.Expressions.MemberExpression) <IL 0x000fe, 0x003a6>
>>>> - at ServiceStack.OrmLite.SqlExpressionVisitor`1.Visit
>>>> (System.Linq.Expressions.Expression) <IL 0x000e3, 0x000e1>
>>>> - at ServiceStack.OrmLite.SqlExpressionVisitor`1.VisitBinary
>>>> (System.Linq.Expressions.BinaryExpression) <IL 0x0016d, 0x00736>
>>>> - at ServiceStack.OrmLite.SqlExpressionVisitor`1.Visit
>>>> (System.Linq.Expressions.Expression) <IL 0x000fd, 0x0016b>
>>>> - at ServiceStack.OrmLite.SqlExpressionVisitor`1.VisitLambda
>>>> (System.Linq.Expressions.LambdaExpression) <IL 0x0005a, 0x00169>
>>>> - at ServiceStack.OrmLite.SqlExpressionVisitor`1.Visit
>>>> (System.Linq.Expressions.Expression) <IL 0x000d6, 0x0009c>
>>>> - at
>>>> ServiceStack.OrmLite.SqlExpressionVisitor`1.ProcessInternalExpression ()
>>>> <IL 0x0001a, 0x00073>
>>>> - at ServiceStack.OrmLite.SqlExpressionVisitor`1.And
>>>> (System.Linq.Expressions.Expression`1<System.Func`2<T, bool>>) <IL 0x00027,
>>>> 0x000f4>
>>>> - at ServiceStack.OrmLite.SqlExpressionVisitor`1.Where
>>>> (System.Linq.Expressions.Expression`1<System.Func`2<T, bool>>) <IL 0x00005,
>>>> 0x00028>
>>>> - at ServiceStack.OrmLite.ReadExtensions.Select<T>
>>>> (System.Data.IDbCommand,System.Linq.Expressions.Expression`1<System.Func`2<T,
>>>> bool>>) <IL 0x0000d, 0x0006e>
>>>> - at
>>>> ServiceStack.OrmLite.ReadConnectionExtensions/<>c__DisplayClassd`1.<Select>b__c
>>>> (System.Data.IDbCommand) <IL 0x00007, 0x00046>
>>>> --
>>>> :Native stacktrace:
>>>> -
>>>> - /usr/bin/mono() [0x4b23dc]
>>>> - /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340) [0x7fc516460340]
>>>> - /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39) [0x7fc5160c1cc9]
>>>> - /lib/x86_64-linux-gnu/libc.so.6(abort+0x148) [0x7fc5160c50d8]
>>>> - /usr/bin/mono() [0x629999]
>>>> - /usr/bin/mono() [0x629ba7]
>>>> - /usr/bin/mono() [0x629cf6]
>>>> - /usr/bin/mono(mono_class_from_mono_type+0x37) [0x519b07]
>>>> - /usr/bin/mono() [0x42a69a]
>>>> - /usr/bin/mono() [0x42b301]
>>>> - /usr/bin/mono() [0x42c89f]
>>>> - /usr/bin/mono() [0x42d29b]
>>>> - /usr/bin/mono() [0x5398f8]
>>>> - [0x4115956d]
>>>> -
>>>> -Debug info from gdb:
>>>> -
>>>> -Could not attach to process. If your uid matches the uid of the target
>>>> -process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or
>>>> try
>>>> --
>>>>
>>>>
>>>> Stack trace flavour 4 (no non-native stacktrace):
>>>> These vary a bit, but look pretty much like the below.
>>>>
>>>> --
>>>> :Stacktrace:
>>>> -
>>>> -
>>>> :Native stacktrace:
>>>> -
>>>> - /usr/bin/mono() [0x4b23dc]
>>>> - /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340) [0x7fb78e49c340]
>>>> - /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39) [0x7fb78e0fdcc9]
>>>> - /lib/x86_64-linux-gnu/libc.so.6(abort+0x148) [0x7fb78e1010d8]
>>>> - /usr/bin/mono() [0x629999]
>>>> - /usr/bin/mono() [0x629ba7]
>>>> - /usr/bin/mono() [0x629cf6]
>>>> - /usr/bin/mono() [0x6194dc]
>>>> - /usr/bin/mono() [0x422086]
>>>> - /usr/bin/mono() [0x5a7012]
>>>> - /usr/bin/mono() [0x5b0720]
>>>> - /usr/bin/mono() [0x5a1d99]
>>>> - /usr/bin/mono() [0x5a1dd0]
>>>> - /usr/bin/mono() [0x5a226d]
>>>> - /usr/bin/mono() [0x5875f8]
>>>> - /usr/bin/mono() [0x623b66]
>>>> - /lib/x86_64-linux-gnu/libpthread.so.0(+0x8182) [0x7fb78e494182]
>>>> - /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fb78e1c147d]
>>>> -
>>>>
>>>> On 27 November 2015 at 20:31, River Satya <river.satya at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi mono list,
>>>>>
>>>>> We see a lot of segfaults (~10 / day) in our program running on Ubuntu
>>>>> Wheezy. I was hoping that upgrading to mono 4.2 would resolve it, but we're
>>>>> still seeing them.
>>>>>
>>>>> The stack traces take a few different forms, so it's possible that
>>>>> they're actually separate issues.
>>>>>
>>>>> We mostly see #1 and #4. #2 and #3 have only been seen in isolation,
>>>>> but have more interesting stack traces.
>>>>>
>>>>> These look to me like mono bugs. Are any of these known issues? Is
>>>>> there anything I can do to either work around them and/or assist in
>>>>> debugging them? They're currently causing significant problems in a mission
>>>>> critical piece of software for my client.
>>>>>
>>>>> (email split into pieces as the full version was rejected by the
>>>>> maillist server).
>>>>>
>>>>> Thanks,
>>>>>
>>>>> River
>>>>>
>>>>>>
>>>>>> Stack trace 1 (empty trace):
>>>>>> :Stacktrace:
>>>>>> -
>>>>>> -
>>>>>> :Native stacktrace:
>>>>>> -
>>>>>> Stack trace 2:
>>>>>> --
>>>>>> :Stacktrace:
>>>>>> -
>>>>>> - at <unknown> <0xffffffff>
>>>>>> - at (wrapper managed-to-native)
>>>>>> object.__icall_wrapper_mono_gc_alloc_vector (intptr,intptr,intptr) <IL
>>>>>> 0x0000f, 0xffffffff>
>>>>>> - at (wrapper alloc) object.AllocVector (intptr,intptr) <IL 0x00088,
>>>>>> 0xffffffff>
>>>>>> - at System.Xml.XmlUtf8RawTextWriter..ctor
>>>>>> (System.IO.Stream,System.Xml.XmlWriterSettings) <IL 0x00039, 0x000cf>
>>>>>> - at System.Xml.XmlWriterSettings.CreateWriter (System.IO.Stream)
>>>>>> <IL 0x00067, 0x00117>
>>>>>> - at System.Xml.XmlWriter.Create
>>>>>> (System.IO.Stream,System.Xml.XmlWriterSettings) <IL 0x0000f, 0x00066>
>>>>>> - at
>>>>>> <snip> rest of stack trace is in our code</snip>
>>>>>> --
>>>>>> :Native stacktrace:
>>>>>> -
>>>>>> - /usr/bin/mono() [0x49cf0c]
>>>>>> - /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)
>>>>>> [0x7fb9e29e9340]
>>>>>> - /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39) [0x7fb9e264acc9]
>>>>>> - /lib/x86_64-linux-gnu/libc.so.6(abort+0x148) [0x7fb9e264e0d8]
>>>>>> - /usr/bin/mono() [0x62a329]
>>>>>> - /usr/bin/mono() [0x62a537]
>>>>>> - /usr/bin/mono() [0x62a5e2]
>>>>>> - /usr/bin/mono() [0x5ea7a6]
>>>>>> - /usr/bin/mono() [0x5ecfe0]
>>>>>> - /usr/bin/mono() [0x5f5af2]
>>>>>> - /usr/bin/mono() [0x5f67aa]
>>>>>> - /usr/bin/mono() [0x5ecb03]
>>>>>> - /usr/bin/mono() [0x5dbf76]
>>>>>> - /usr/bin/mono() [0x5e380d]
>>>>>> - /usr/bin/mono() [0x5f99f8]
>>>>>> - /usr/bin/mono() [0x5e5f63]
>>>>>> - /usr/bin/mono() [0x5e805f]
>>>>>> - /usr/bin/mono() [0x5db55d]
>>>>>> - /usr/bin/mono() [0x5ca11e]
>>>>>> --
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Mono-list maillist - Mono-list at lists.ximian.com
>>>> http://lists.ximian.com/mailman/listinfo/mono-list
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-list/attachments/20151130/e689adeb/attachment.html>
More information about the Mono-list
mailing list