[Mono-dev] Sgen SIGSEGV
Greg Young
gregoryyoung1 at gmail.com
Sat Mar 1 13:24:15 UTC 2014
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 at entry=0x7ffff662df90,
queue=queue at 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 at entry
=-1,
ctx=...) at sgen-gc.c:1194
#6 0x00000000005de27e in collect_nursery (unpin_queue=unpin_queue at entry
=0x0,
finish_up_concurrent_mark=finish_up_concurrent_mark at 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 at 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 at 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 at entry=0x0,
log_level=log_level at entry=G_LOG_LEVEL_ERROR,
format=format at entry=0x6418f8 "* Assertion: should not be reached at
%s:%d\n", args=args at entry=0x7fffee1f5da8) at goutput.c:175
#3 0x0000000000638ad6 in monoeg_assertion_message (
format=format at 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 at entry
=-1,
ctx=...) at sgen-gc.c:1194
#6 0x00000000005de27e in collect_nursery (unpin_queue=unpin_queue at entry
=0x0,
finish_up_concurrent_mark=finish_up_concurrent_mark at 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 at entry=0xa1ec28, size=size at 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 <gregoryyoung1 at gmail.com> wrote:
> I should add that this is on trunk.
>
> greg at 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 <gregoryyoung1 at 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 at entry=0x7ffff6683150,
>> queue=queue at 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 at entry=0x7ffff6683150,
>> queue=queue at 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 at entry
>> =-1,
>> ctx=...) at sgen-gc.c:1194
>> #4 0x00000000005df36e in collect_nursery (unpin_queue=unpin_queue at entry
>> =0x0,
>> finish_up_concurrent_mark=finish_up_concurrent_mark at 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 at entry=0xab8680, size=size at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20140301/1be44765/attachment.html>
More information about the Mono-devel-list
mailing list