[Mono-dev] crash with nunit

Greg Young gregoryyoung1 at gmail.com
Tue Mar 25 16:10:34 UTC 2014


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 <david at 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 at 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 at entry=0, generation_to_collect=
>> generation_to_collect at entry=1,
>>     reason=reason at entry=0x705072 "user request",
>> wait_to_finish=wait_to_finish at 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 at 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 <david at dasz.at
>> <mailto:david at 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 at lists.ximian.com
>>     <mailto:Mono-devel-list at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20140325/56bd1fc6/attachment.html>


More information about the Mono-devel-list mailing list