Description:
We’re experiencing sudden core dumps during service startup when using mimalloc 2.1.2 in physical machine-hosted containers. This issue began recently after approximately 1 year of stable operation.
Environment:
mimalloc version: 2.1.2
Deployment: Multiple containers on physical hosts
Launch command:
nohup env MIMALLOC_ALLOW_LARGE_OS_PAGES=1 MIMALLOC_PURGE_DELAY=100 ./server
Error Details:
Program received signal SIGBUS, Bus error.
0x0000000000e6cac9 in mi_segment_os_alloc (os_tld=0x12cd710 <tld_main+944>, tld=0x12cd380 <tld_main+32>, commit=, pinfo_slices=0x7fffffffe190, ppre_size=0x7fffffffe198,
psegment_slices=, req_arena_id=, eager_delayed=, page_alignment=0, required=0)
at external/com_github_microsoft_mimalloc/src/segment.c:843
843 external/com_github_microsoft_mimalloc/src/segment.c: No such file or directory.
Missing separate debuginfos, use: debuginfo-install glibc-2.17-106.el7_2.8.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.13.2-12.el7_2.x86_64 libcom_err-1.42.9-7.el7.x86_64 libselinux-2.2.2-6.el7.x86_64 openssl-libs-1.0.2k-26.el7_9.x86_64 pcre-8.32-15.el7_2.1.x86_64 xz-libs-5.1.2-12alpha.el7.x86_64 zlib-1.2.7-17.el7.x86_64
(gdb) bt
#0 0x0000000000e6cac9 in mi_segment_os_alloc (os_tld=0x12cd710 <tld_main+944>, tld=0x12cd380 <tld_main+32>, commit=, pinfo_slices=0x7fffffffe190,
ppre_size=0x7fffffffe198, psegment_slices=, req_arena_id=, eager_delayed=, page_alignment=0, required=0)
at external/com_github_microsoft_mimalloc/src/segment.c:843
#1 mi_segment_alloc (required=required@entry=0, page_alignment=page_alignment@entry=0, req_arena_id=, tld=tld@entry=0x12cd380 <tld_main+32>,
os_tld=os_tld@entry=0x12cd710 <tld_main+944>, huge_page=huge_page@entry=0x0) at external/com_github_microsoft_mimalloc/src/segment.c:876
#2 0x0000000000e6d805 in mi_segment_reclaim_or_alloc (os_tld=0x12cd710 <tld_main+944>, tld=0x12cd380 <tld_main+32>, block_size=640, needed_slices=,
heap=0x12cc760 <_mi_heap_main>) at external/com_github_microsoft_mimalloc/src/segment.c:1474
#3 mi_segments_page_alloc (heap=0x12cc760 <_mi_heap_main>, page_kind=, required=, block_size=640, tld=0x12cd380 <tld_main+32>,
os_tld=0x12cd710 <tld_main+944>) at external/com_github_microsoft_mimalloc/src/segment.c:1493
#4 0x0000000000e6f253 in mi_page_fresh_alloc (heap=heap@entry=0x12cc760 <_mi_heap_main>, pq=pq@entry=0x12ccd68 <_mi_heap_main+1544>, block_size=640,
page_alignment=page_alignment@entry=0) at external/com_github_microsoft_mimalloc/src/page.c:280
#5 0x0000000000e7055b in mi_page_fresh (pq=0x12ccd68 <_mi_heap_main+1544>, heap=0x12cc760 <_mi_heap_main>) at external/com_github_microsoft_mimalloc/src/page.c:301
#6 mi_page_queue_find_free_ex (heap=0x12cc760 <_mi_heap_main>, pq=0x12ccd68 <_mi_heap_main+1544>, first_try=) at external/com_github_microsoft_mimalloc/src/page.c:752
#7 0x0000000000e70669 in mi_find_free_page (size=, heap=0x12cc760 <_mi_heap_main>) at external/com_github_microsoft_mimalloc/src/page.c:789
#8 mi_find_page (heap=0x12cc760 <_mi_heap_main>, size=, huge_alignment=) at external/com_github_microsoft_mimalloc/src/page.c:887
#9 0x0000000000e70846 in _mi_malloc_generic (heap=0x12cc760 <_mi_heap_main>, size=568, zero=, huge_alignment=0) at external/com_github_microsoft_mimalloc/src/page.c:913
#10 0x00007ffff62dd96d in __fopen_internal () from /lib64/libc.so.6
#11 0x00007ffff50c49b6 in selinuxfs_exists () from /lib64/libselinux.so.1
#12 0x00007ffff50bf6cc in init_lib () from /lib64/libselinux.so.1
#13 0x00007ffff7dea3a3 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#14 0x00007ffff7ddc46a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#15 0x0000000000000002 in ?? ()
#16 0x00007fffffffe7b8 in ?? ()
#17 0x00007fffffffe7ec in ?? ()
#18 0x0000000000000000 in ?? ()
Works normally when:
Not using MIMALLOC_ALLOW_LARGE_OS_PAGES=1
Some containers run without issues
Previously stable for 1 year with same configuration
Questions:
What could cause this sudden regression?
Could host-level container interactions affect mimalloc’s large page allocation?
How to systematically debug this inconsistency between containers?
find it is fixed in version 3.1.5
version 3.1.5 use too much memory；how can I fix this core dump in version 2.1.2？
microsoft
