This looks like a bug in mono's qsort.
It should not need more than 18-36 levels of recursion.
Vlad/John, could you look at this issue?
--
Rodrigo
On Tue, Nov 1, 2016 at 9:35 AM, Burkhard Linke <
bli...@cebitec.uni-bielefeld.de> wrote:
> 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
>
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.dot.net
http://lists.dot.net/mailman/listinfo/mono-devel-list
