Re: [Mono-list] Frequent segfaults in c# running on mono

[River Satya]

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  wrote:

> Any idea if it's been fixed again in 4.2?
>
> On 27 November 2015 at 23:26, River Satya  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  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 
>>> wrote:
>>>

  Stack trace flavour 3:

 --
 :Stacktrace:
 -
 -  at  <0x>
 -  at (wrapper managed-to-native)
 System.Delegate.CreateDelegate_internal
 (System.Type,object,System.Reflection.MethodInfo,bool) >>> 0x>
 -  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 ()
 
 -  at System.Linq.Expressions.Compiler.LambdaCompiler.Compile
 (System.Linq.Expressions.LambdaExpression,System.Runtime.CompilerServices.DebugInfoGenerator)
 
 -  at System.Linq.Expressions.Expression`1.Compile () >>> 0x00016>
 -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.VisitMemberAccess
 (System.Linq.Expressions.MemberExpression) 
 -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.Visit
 (System.Linq.Expressions.Expression) 
 -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.VisitBinary
 (System.Linq.Expressions.BinaryExpression) 
 -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.Visit
 (System.Linq.Expressions.Expression) 
 -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.VisitLambda
 (System.Linq.Expressions.LambdaExpression) 
 -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.Visit
 (System.Linq.Expressions.Expression) 
 -  at
 ServiceStack.OrmLite.SqlExpressionVisitor`1.ProcessInternalExpression ()
 
 -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.And
 (System.Linq.Expressions.Expression`1>) >>> 0x000f4>
 -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.Where
 (System.Linq.Expressions.Expression`1>) >>> 0x00028>
 -  at ServiceStack.OrmLite.ReadExtensions.Select
 (System.Data.IDbCommand,System.Linq.Expressions.Expression`1>) 
 -  at
 ServiceStack.OrmLite.ReadConnectionExtensions/<>c__DisplayClassd`1.b__c
 (System.Data.IDbCommand) 
 --
 :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() [0x62]
 -   /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() [0x62]
 -   

Re: [Mono-list] Frequent segfaults in c# running on mono

[River Satya]

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  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 
> wrote:
>
>>
>>  Stack trace flavour 3:
>>
>> --
>> :Stacktrace:
>> -
>> -  at  <0x>
>> -  at (wrapper managed-to-native) System.Delegate.CreateDelegate_internal
>> (System.Type,object,System.Reflection.MethodInfo,bool) > 0x>
>> -  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 ()
>> 
>> -  at System.Linq.Expressions.Compiler.LambdaCompiler.Compile
>> (System.Linq.Expressions.LambdaExpression,System.Runtime.CompilerServices.DebugInfoGenerator)
>> 
>> -  at System.Linq.Expressions.Expression`1.Compile () > 0x00016>
>> -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.VisitMemberAccess
>> (System.Linq.Expressions.MemberExpression) 
>> -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.Visit
>> (System.Linq.Expressions.Expression) 
>> -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.VisitBinary
>> (System.Linq.Expressions.BinaryExpression) 
>> -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.Visit
>> (System.Linq.Expressions.Expression) 
>> -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.VisitLambda
>> (System.Linq.Expressions.LambdaExpression) 
>> -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.Visit
>> (System.Linq.Expressions.Expression) 
>> -  at
>> ServiceStack.OrmLite.SqlExpressionVisitor`1.ProcessInternalExpression ()
>> 
>> -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.And
>> (System.Linq.Expressions.Expression`1>) > 0x000f4>
>> -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.Where
>> (System.Linq.Expressions.Expression`1>) > 0x00028>
>> -  at ServiceStack.OrmLite.ReadExtensions.Select
>> (System.Data.IDbCommand,System.Linq.Expressions.Expression`1> bool>>) 
>> -  at
>> ServiceStack.OrmLite.ReadConnectionExtensions/<>c__DisplayClassd`1.b__c
>> (System.Data.IDbCommand) 
>> --
>> :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() [0x62]
>> -   /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() [0x62]
>> -   /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  wrote:
>>
>>> Hi mono list,
>>>
>>> We see a lot of segfaults (~10 / day) in our program running on Ubuntu
>>> Wheezy. I was hoping that 

Re: [Mono-list] Frequent segfaults in c# running on mono

[River Satya]

Any idea if it's been fixed again in 4.2?

On 27 November 2015 at 23:26, River Satya  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  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 
>> wrote:
>>
>>>
>>>  Stack trace flavour 3:
>>>
>>> --
>>> :Stacktrace:
>>> -
>>> -  at  <0x>
>>> -  at (wrapper managed-to-native)
>>> System.Delegate.CreateDelegate_internal
>>> (System.Type,object,System.Reflection.MethodInfo,bool) >> 0x>
>>> -  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 ()
>>> 
>>> -  at System.Linq.Expressions.Compiler.LambdaCompiler.Compile
>>> (System.Linq.Expressions.LambdaExpression,System.Runtime.CompilerServices.DebugInfoGenerator)
>>> 
>>> -  at System.Linq.Expressions.Expression`1.Compile () >> 0x00016>
>>> -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.VisitMemberAccess
>>> (System.Linq.Expressions.MemberExpression) 
>>> -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.Visit
>>> (System.Linq.Expressions.Expression) 
>>> -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.VisitBinary
>>> (System.Linq.Expressions.BinaryExpression) 
>>> -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.Visit
>>> (System.Linq.Expressions.Expression) 
>>> -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.VisitLambda
>>> (System.Linq.Expressions.LambdaExpression) 
>>> -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.Visit
>>> (System.Linq.Expressions.Expression) 
>>> -  at
>>> ServiceStack.OrmLite.SqlExpressionVisitor`1.ProcessInternalExpression ()
>>> 
>>> -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.And
>>> (System.Linq.Expressions.Expression`1>) >> 0x000f4>
>>> -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.Where
>>> (System.Linq.Expressions.Expression`1>) >> 0x00028>
>>> -  at ServiceStack.OrmLite.ReadExtensions.Select
>>> (System.Data.IDbCommand,System.Linq.Expressions.Expression`1>> bool>>) 
>>> -  at
>>> ServiceStack.OrmLite.ReadConnectionExtensions/<>c__DisplayClassd`1.b__c
>>> (System.Data.IDbCommand) 
>>> --
>>> :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() [0x62]
>>> -   /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() [0x62]
>>> -   /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]
>>> -   

Re: [Mono-list] Frequent segfaults in c# running on mono

[Matt Calder]

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  wrote:

>
>  Stack trace flavour 3:
>
> --
> :Stacktrace:
> -
> -  at  <0x>
> -  at (wrapper managed-to-native) System.Delegate.CreateDelegate_internal
> (System.Type,object,System.Reflection.MethodInfo,bool)  0x>
> -  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 ()
> 
> -  at System.Linq.Expressions.Compiler.LambdaCompiler.Compile
> (System.Linq.Expressions.LambdaExpression,System.Runtime.CompilerServices.DebugInfoGenerator)
> 
> -  at System.Linq.Expressions.Expression`1.Compile () 
> -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.VisitMemberAccess
> (System.Linq.Expressions.MemberExpression) 
> -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.Visit
> (System.Linq.Expressions.Expression) 
> -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.VisitBinary
> (System.Linq.Expressions.BinaryExpression) 
> -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.Visit
> (System.Linq.Expressions.Expression) 
> -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.VisitLambda
> (System.Linq.Expressions.LambdaExpression) 
> -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.Visit
> (System.Linq.Expressions.Expression) 
> -  at
> ServiceStack.OrmLite.SqlExpressionVisitor`1.ProcessInternalExpression ()
> 
> -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.And
> (System.Linq.Expressions.Expression`1>)  0x000f4>
> -  at ServiceStack.OrmLite.SqlExpressionVisitor`1.Where
> (System.Linq.Expressions.Expression`1>)  0x00028>
> -  at ServiceStack.OrmLite.ReadExtensions.Select
> (System.Data.IDbCommand,System.Linq.Expressions.Expression`1 bool>>) 
> -  at
> ServiceStack.OrmLite.ReadConnectionExtensions/<>c__DisplayClassd`1.b__c
> (System.Data.IDbCommand) 
> --
> :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() [0x62]
> -   /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() [0x62]
> -   /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  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 

Re: [Mono-list] Frequent segfaults in c# running on mono

[River Satya]

 Stack trace flavour 3:

--
:Stacktrace:
-
-  at  <0x>
-  at (wrapper managed-to-native) System.Delegate.CreateDelegate_internal
(System.Type,object,System.Reflection.MethodInfo,bool) 
-  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 () 
-  at System.Linq.Expressions.Compiler.LambdaCompiler.Compile
(System.Linq.Expressions.LambdaExpression,System.Runtime.CompilerServices.DebugInfoGenerator)

-  at System.Linq.Expressions.Expression`1.Compile () 
-  at ServiceStack.OrmLite.SqlExpressionVisitor`1.VisitMemberAccess
(System.Linq.Expressions.MemberExpression) 
-  at ServiceStack.OrmLite.SqlExpressionVisitor`1.Visit
(System.Linq.Expressions.Expression) 
-  at ServiceStack.OrmLite.SqlExpressionVisitor`1.VisitBinary
(System.Linq.Expressions.BinaryExpression) 
-  at ServiceStack.OrmLite.SqlExpressionVisitor`1.Visit
(System.Linq.Expressions.Expression) 
-  at ServiceStack.OrmLite.SqlExpressionVisitor`1.VisitLambda
(System.Linq.Expressions.LambdaExpression) 
-  at ServiceStack.OrmLite.SqlExpressionVisitor`1.Visit
(System.Linq.Expressions.Expression) 
-  at ServiceStack.OrmLite.SqlExpressionVisitor`1.ProcessInternalExpression
() 
-  at ServiceStack.OrmLite.SqlExpressionVisitor`1.And
(System.Linq.Expressions.Expression`1>) 
-  at ServiceStack.OrmLite.SqlExpressionVisitor`1.Where
(System.Linq.Expressions.Expression`1>) 
-  at ServiceStack.OrmLite.ReadExtensions.Select
(System.Data.IDbCommand,System.Linq.Expressions.Expression`1>) 
-  at
ServiceStack.OrmLite.ReadConnectionExtensions/<>c__DisplayClassd`1.b__c
(System.Data.IDbCommand) 
--
: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() [0x62]
-   /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() [0x62]
-   /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  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  <0x>
>> -  at (wrapper managed-to-native)
>> object.__icall_wrapper_mono_gc_alloc_vector (intptr,intptr,intptr) > 0xf, 0x>
>> -  at (wrapper alloc) object.AllocVector (intptr,intptr) > 0x>
>> -  at System.Xml.XmlUtf8RawTextWriter..ctor
>>