testing back to 3.2.8 there are some other errors as well (I can't get
3.2.7 to build).

sgen used to be quite stable for our uses. I'm not sure what has happened.
We can normally get it to fail within a few minutes of running under load.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffed5f1700 (LWP 16236)]
0x00000000005e1270 in alloc_obj (vtable=0x7ffff662e0e8, size=-1450344072,
    pinned=0, has_references=1) at sgen-marksweep.c:740
740 int size_index = MS_BLOCK_OBJ_SIZE_INDEX (size);
(gdb) backtrace
#0  0x00000000005e1270 in alloc_obj (vtable=0x7ffff662e0e8,
size=-1450344072,
    pinned=0, has_references=1) at sgen-marksweep.c:740
#1  0x00000000005fb5f4 in alloc_for_promotion (has_references=1,
    objsize=2844623224, obj=0x7ffff662df90 "\350\340b\366\377\177",
    vtable=0x7ffff662e0e8) at sgen-simple-nursery.c:35
#2  copy_object_no_checks (obj=obj@entry=0x7ffff662df90,
    queue=queue@entry=0x983120 <gray_queue>) at sgen-copy-object.h:112
#3  0x00000000005fc382 in simple_nursery_serial_copy_object_from_obj (
    queue=0x983120 <gray_queue>, obj_slot=0x7fffd5fac5b0)
    at sgen-minor-copy-object.h:206
#4  simple_nursery_serial_scan_object (start=<optimized out>,
    queue=0x983120 <gray_queue>) at sgen-scan-object.h:64
#5  0x00000000005d8a6f in sgen_drain_gray_stack (max_objs=max_objs@entry
=-1,
    ctx=...) at sgen-gc.c:1194
#6  0x00000000005de27e in collect_nursery (unpin_queue=unpin_queue@entry
=0x0,
    finish_up_concurrent_mark=finish_up_concurrent_mark@entry=0)
    at sgen-gc.c:2631
#7  0x00000000005de749 in collect_nursery (finish_up_concurrent_mark=0,
    unpin_queue=0x0) at sgen-gc.c:3547
#8  sgen_perform_collection (requested_size=4096, generation_to_collect=0,
    reason=0x70b51a "Nursery full", wait_to_finish=0) at sgen-gc.c:3483
#9  0x00000000005f4b49 in mono_gc_alloc_obj_nolock (vtable=0x195aed8,
size=32)
    at sgen-alloc.c:288
#10 0x00000000005f4c14 in mono_gc_alloc_obj (vtable=0x195aed8, size=32)
    at sgen-alloc.c:465


and

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffee1f7700 (LWP 16125)]
0x00007ffff711bf77 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) backtrace
#0  0x00007ffff711bf77 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff711f5e8 in __GI_abort () at abort.c:90
#2  0x0000000000638995 in monoeg_g_logv (log_domain=log_domain@entry=0x0,
    log_level=log_level@entry=G_LOG_LEVEL_ERROR,
    format=format@entry=0x6418f8 "* Assertion: should not be reached at
%s:%d\n", args=args@entry=0x7fffee1f5da8) at goutput.c:175
#3  0x0000000000638ad6 in monoeg_assertion_message (
    format=format@entry=0x6418f8 "* Assertion: should not be reached at
%s:%d\n") at goutput.c:195
#4  0x00000000005fc6a6 in simple_nursery_serial_scan_object (
    start=<optimized out>, queue=0x983120 <gray_queue>)
    at sgen-scan-object.h:111
#5  0x00000000005d8a6f in sgen_drain_gray_stack (max_objs=max_objs@entry
=-1,
    ctx=...) at sgen-gc.c:1194
#6  0x00000000005de27e in collect_nursery (unpin_queue=unpin_queue@entry
=0x0,
    finish_up_concurrent_mark=finish_up_concurrent_mark@entry=0)
    at sgen-gc.c:2631
#7  0x00000000005de749 in collect_nursery (finish_up_concurrent_mark=0,
    unpin_queue=0x0) at sgen-gc.c:3547
#8  sgen_perform_collection (requested_size=4096, generation_to_collect=0,
    reason=0x70b51a "Nursery full", wait_to_finish=0) at sgen-gc.c:3483
#9  0x00000000005f4b49 in mono_gc_alloc_obj_nolock (
    vtable=vtable@entry=0xa1ec28, size=size@entry=48) at sgen-alloc.c:288
#10 0x00000000005f4d44 in mono_gc_alloc_vector (vtable=0xa1ec28, size=48,
    max_length=16) at sgen-alloc.c:491
#11 0x00000000400141c9 in ?? ()


On Sat, Mar 1, 2014 at 2:12 PM, Greg Young <gregoryyou...@gmail.com> wrote:

> I should add that this is on trunk.
>
>  greg@goblin:~/src/EventStore/bin/eventstore/release/anycpu$ mono
> --version
> Mono JIT compiler version 3.4.0 (master/9c4c295 Pn Vas 28 17:26:05 EET
> 2014)
>
> Vas=Feb
>
>
> On Sat, Mar 1, 2014 at 2:03 PM, Greg Young <gregoryyou...@gmail.com>wrote:
>
>> We can reproduce this reasonably easily under load.
>>
>> from gdb.
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 0x7fffed7f2700 (LWP 3886)]
>> copy_object_no_checks (obj=obj@entry=0x7ffff6683150,
>>     queue=queue@entry=0x9831c0 <gray_queue>) at sgen-copy-object.h:110
>> 110 gboolean has_references = SGEN_VTABLE_HAS_REFERENCES (vt);
>> (gdb) backtrace
>> #0  copy_object_no_checks (obj=obj@entry=0x7ffff6683150,
>>     queue=queue@entry=0x9831c0 <gray_queue>) at sgen-copy-object.h:110
>> #1  0x00000000005fdec3 in simple_nursery_serial_copy_object_from_obj (
>>     queue=0x9831c0 <gray_queue>, obj_slot=0x7fffcc8c09c0)
>>     at sgen-minor-copy-object.h:206
>> #2  simple_nursery_serial_scan_object (start=<optimized out>,
>>     queue=0x9831c0 <gray_queue>) at sgen-scan-object.h:64
>> #3  0x00000000005d9aff in sgen_drain_gray_stack (max_objs=max_objs@entry
>> =-1,
>>     ctx=...) at sgen-gc.c:1194
>> #4  0x00000000005df36e in collect_nursery (unpin_queue=unpin_queue@entry
>> =0x0,
>>     finish_up_concurrent_mark=finish_up_concurrent_mark@entry=0)
>>     at sgen-gc.c:2638
>> #5  0x00000000005df839 in collect_nursery (finish_up_concurrent_mark=0,
>>     unpin_queue=0x0) at sgen-gc.c:3554
>> #6  sgen_perform_collection (requested_size=4096,
>> generation_to_collect=0,
>>     reason=0x70b2e9 "Nursery full", wait_to_finish=0) at sgen-gc.c:3490
>> #7  0x00000000005f5dd9 in mono_gc_alloc_obj_nolock (
>>     vtable=vtable@entry=0xab8680, size=size@entry=576) at
>> sgen-alloc.c:288
>> #8  0x00000000005f5fe3 in mono_gc_alloc_vector (vtable=0xab8680,
>> size=576,
>>     max_length=270) at sgen-alloc.c:499
>> #9  0x00000000400147f9 in ?? ()
>> #10 0x00007fffb40025d0 in ?? ()
>> #11 0x0000000000000000 in ?? ()
>>
>>
>> --
>> Le doute n'est pas une condition agréable, mais la certitude est absurde.
>>
>
>
>
> --
> Le doute n'est pas une condition agréable, mais la certitude est absurde.
>



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

Reply via email to