This is a slightly different one than the group we are seeing but my guess is they are related. There is a pattern of usage that causes corrupt heaps. We are also seeing dereferences of pointers in sgen going of to neverneverland.
On Tue, Mar 25, 2014 at 6:05 PM, David Schmitt <da...@dasz.at> wrote: > Thanks to guidance from Greg Young, I've been able to isolate a proper > backtrace from nunit-console: > > Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 0x7fffef97a700 (LWP 26908)] >> slow_object_get_size (o=0x7fffea860010, vtable=<optimized out>) at >> ../../mono/metadata/sgen-gc.h:722 >> 722 } else if (klass->rank) { >> (gdb) backtrace >> #0 slow_object_get_size (o=0x7fffea860010, vtable=<optimized out>) at >> ../../mono/metadata/sgen-gc.h:722 >> #1 sgen_par_object_get_size (o=0x7fffea860010, vtable=<optimized out>) >> at ../../mono/metadata/sgen-gc.h:766 >> #2 sgen_safe_object_get_size (obj=0x7fffea860010) at >> ../../mono/metadata/sgen-gc.h:777 >> #3 sgen_major_is_object_alive (object=0x7fffea860010) at sgen-gc.c:3589 >> #4 sgen_is_object_alive_for_current_gen (object=0x7fffea860010 >> "\b\020\206\352\377\177") at sgen-gc.c:3624 >> #5 mark_ephemerons_in_range (ctx=...) at sgen-gc.c:3802 >> #6 0x00000000005d1d2c in finish_gray_stack (generation=generation@entry=1, >> queue=0x972f00) at sgen-gc.c:1931 >> #7 0x00000000005d3b65 in major_finish_collection (reason=0x705072 "user >> request", old_next_pin_slot=108, scan_mod_union=0) at sgen-gc.c:3164 >> #8 0x00000000005d4182 in major_do_collection (reason=<optimized out>) at >> sgen-gc.c:3305 >> #9 major_do_collection (reason=0x705072 "user request") at sgen-gc.c:3287 >> #10 0x00000000005d7677 in sgen_perform_collection >> (requested_size=requested_size@entry=0, generation_to_collect= >> generation_to_collect@entry=1, >> reason=reason@entry=0x705072 "user request", >> wait_to_finish=wait_to_finish@entry=1) at sgen-gc.c:3499 >> #11 0x00000000005d7cf8 in mono_gc_collect (generation=1) at sgen-gc.c:4623 >> #12 0x000000000059e3bb in unload_thread_main (arg=0x4a50380) at >> appdomain.c:2334 >> #13 0x000000000061e871 in thread_start_routine (args=args@entry=0x9cfbb0) >> at wthreads.c:294 >> #14 0x000000000062e810 in inner_start_thread (arg=0x4a4d5b0) at >> mono-threads-posix.c:49 >> #15 0x00007ffff7539b50 in start_thread () from /lib/x86_64-linux-gnu/ >> libpthread.so.0 >> #16 0x00007ffff72840ed in clone () from /lib/x86_64-linux-gnu/libc.so.6 >> #17 0x0000000000000000 in ?? () >> (gdb) >> > > I'll retry with master next. > > > Regards, David > > > On 25.03.2014 15:56, Zoltan Varga wrote: > >> Hi, >> >> Could you try with master or the mono-3.4.0-branch ? If the problem >> is still there, please log a bug report with reproduction instructions/a >> testcase if possible. >> >> Zoltan >> >> >> On Tue, Mar 25, 2014 at 10:44 AM, David Schmitt <da...@dasz.at >> <mailto:da...@dasz.at>> wrote: >> >> Hi, >> >> I've finally updated to 3.2.8 (recompiled from debian experimental) >> and am now triggering the attached segfault approximately every >> second run. >> >> For further analysis I could run this under master; try to upgrade >> nunit; try to get more debugging symbols into the package; try to >> reduce the amount of code running to trigger the problem. >> >> The project is open source, so if that would be easier I can provide >> public repro steps too. >> >> >> Please advise, >> >> Thanks David >> >> >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list@lists.ximian.com >> <mailto:Mono-devel-list@lists.ximian.com> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> >> >> > -- Le doute n'est pas une condition agréable, mais la certitude est absurde.
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list