Hi,
the allocation indeed is caused by mmap being unable to create
additional mappings.
With more mapping the application is able to continue, but runs into
another problem:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f5afe3b8700 (LWP 55986)]
0x000000000061cd37 in memcpy (__src=0x7f5ab2e147f8, __dest=0x7f5afe3b6c30,
__len=8) at /usr/include/x86_64-linux-gnu/bits/string3.h:52
52 }
(gdb) bt
#0 0x000000000061cd37 in memcpy (__src=0x7f5ab2e147f8,
__dest=0x7f5afe3b6c30,
__len=8) at /usr/include/x86_64-linux-gnu/bits/string3.h:52
#1 partition (swap_tmp=0x7f5afe3b6c20 "", pivot_tmp=0x7f5afe3b6c30 "",
compar=
0x60ae60 <block_usage_comparer>, width=8, nel=4517,
base=0x7f5ab2e10168)
at sgen-qsort.c:31
#2 qsort_rec (base=base@entry=0x7f5ab2e10168, nel=nel@entry=4517,
width=width@entry=8, compar=compar@entry=0x60ae60
<block_usage_comparer>,
pivot_tmp=pivot_tmp@entry=0x7f5afe3b6c30 "",
swap_tmp=swap_tmp@entry=0x7f5afe3b6c20 "") at sgen-qsort.c:52
#3 0x000000000061ce7b in qsort_rec (base=base@entry=0x7f5ab2e10168,
nel=nel@entry=4518, width=width@entry=8, compar=compar@entry=
0x60ae60 <block_usage_comparer>,
pivot_tmp=pivot_tmp@entry=0x7f5afe3b6c30 "",
swap_tmp=swap_tmp@entry=0x7f5afe3b6c20 "") at sgen-qsort.c:53
#4 0x000000000061ce7b in qsort_rec (base=base@entry=0x7f5ab2e10168,
nel=nel@entry=4519, width=width@entry=8, compar=compar@entry=
0x60ae60 <block_usage_comparer>,
pivot_tmp=pivot_tmp@entry=0x7f5afe3b6c30 "",
swap_tmp=swap_tmp@entry=0x7f5afe3b6c20 "") at sgen-qsort.c:53
...
(gdb) bt -20
#18349 0x000000000061ce7b in qsort_rec (base=0x7f5ab2dbc030,
base@entry=0x7f5ab2dbc000, nel=184426, nel@entry=184432,
width=width@entry=8, compar=compar@entry=0x60ae60
<block_usage_comparer>,
pivot_tmp=pivot_tmp@entry=0x7f5afe3b6c30 "",
swap_tmp=swap_tmp@entry=0x7f5afe3b6c20 "") at sgen-qsort.c:53
#18350 0x000000000061ce7b in qsort_rec (base=base@entry=0x7f5ab2dbc000,
nel=nel@entry=184433, width=width@entry=8, compar=compar@entry=
0x60ae60 <block_usage_comparer>,
pivot_tmp=pivot_tmp@entry=0x7f5afe3b6c30 "",
swap_tmp=swap_tmp@entry=0x7f5afe3b6c20 "") at sgen-qsort.c:53
#18351 0x000000000061ce7b in qsort_rec (base=base@entry=0x7f5ab2dbc000,
nel=nel@entry=229138, width=width@entry=8, compar=compar@entry=
0x60ae60 <block_usage_comparer>,
pivot_tmp=pivot_tmp@entry=0x7f5afe3b6c30 "",
swap_tmp=swap_tmp@entry=0x7f5afe3b6c20 "") at sgen-qsort.c:53
#18352 0x000000000061cedd in sgen_qsort (base=base@entry=0x7f5ab2dbc000,
nel=nel@entry=229138, width=width@entry=8, compar=compar@entry=
0x60ae60 <block_usage_comparer>) at sgen-qsort.c:69
#18353 0x000000000060b7df in sgen_evacuation_freelist_blocks (
block_list=0x7f5b8576b300, size_index=10) at sgen-marksweep.c:1860
#18354 0x000000000060d319 in major_start_major_collection ()
at sgen-marksweep.c:1898
#18355 0x0000000000604f59 in major_start_collection (
---Type <return> to continue, or q <return> to quit---
reason=reason@entry=0x702fb1 "LOS overflow",
concurrent=concurrent@entry=0,
old_next_pin_slot=old_next_pin_slot@entry=0x7f5afe3b6d28) at
sgen-gc.c:1923
#18356 0x0000000000607678 in major_do_collection (forced=0, is_overflow=0,
reason=0x702fb1 "LOS overflow") at sgen-gc.c:2082
#18357 major_do_collection (reason=0x702fb1 "LOS overflow", is_overflow=0,
forced=0) at sgen-gc.c:2065
#18358 0x0000000000607d44 in sgen_perform_collection (requested_size=43344,
generation_to_collect=1, reason=0x702fb1 "LOS overflow",
wait_to_finish=0,
stw=1) at sgen-gc.c:2279
#18359 0x000000000060823c in sgen_ensure_free_space (size=<optimized out>,
generation=<optimized out>) at sgen-gc.c:2232
#18360 0x000000000060a259 in sgen_los_alloc_large_inner (
vtable=vtable@entry=0xe004a8, size=size@entry=43344) at sgen-los.c:379
#18361 0x00000000005fb580 in sgen_alloc_obj_nolock (
vtable=vtable@entry=0xe004a8, size=size@entry=43344) at
sgen-alloc.c:175
#18362 0x00000000005e8da1 in mono_gc_alloc_string (vtable=vtable("string"),
size=size@entry=43344, len=len@entry=21661) at sgen-mono.c:1833
#18363 0x00000000005c5025 in mono_string_new_size_checked (domain=0xdd2fe0,
len=len@entry=21661, error=error@entry=0x7f5afe3b6eb0) at object.c:6074
#18364 0x0000000000597899 in ves_icall_System_String_InternalAllocateStr (
length=21661) at string-icalls.c:41
#18365 0x00000000405fbed2 in ?? ()
---Type <return> to continue, or q <return> to quit---
#18366 0x00007f5b016fdd78 in ?? ()
#18367 0x00007f5aaa5c6930 in ?? ()
#18368 0x0000000000000000 in ?? ()
Stack overflow due to 18368 stack frames caused by the recurvise
quicksort implementation in sgen-qsort.c. The application is creating a
high number of short lived objects, and the memory is badly fragmented
(229138 entries in freelist...). Stack size has already been increased
to 16M, and GC nursery size is set to 2G to cope with the high number of
temporary objects, which keeps the number of mmap'ed fragments lower (~
60.000 instead of ~120.000).
Does mono honor the system stack size limit (and thus allows larger
stacks for larger values of ulimit -s)?
Regards,
Burkhard
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.dot.net
http://lists.dot.net/mailman/listinfo/mono-devel-list
