Any idea if it's been fixed again in 4.2? On 27 November 2015 at 23:26, River Satya <river.sa...@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 <mvcal...@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.sa...@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.sa...@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@lists.ximian.com >>> http://lists.ximian.com/mailman/listinfo/mono-list >>> >>> >> >
_______________________________________________ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list