dev3 crashes on Android

[Noxybot]

After fixing infinite recursion in #1057 I was able to launch a build with MI_DEBUG_FULL on Android and it's failing with such callstack:

abort (@abort:44)
_mi_assert_fail (mimalloc/src/options.c:540)
_mi_page_map_register (mimalloc/src/page-map.c:284)
mi_arenas_page_alloc_fresh (mimalloc/src/arena.c:703)
mi_arenas_page_regular_alloc (mimalloc/src/arena.c:727)
_mi_arenas_page_alloc (mimalloc/src/arena.c:766)
mi_page_fresh_alloc (mimalloc/src/page.c:305)
mi_page_fresh (mimalloc/src/page.c:335)
mi_page_queue_find_free_ex (mimalloc/src/page.c:807)
mi_find_free_page (mimalloc/src/page.c:848)
mi_find_page (mimalloc/src/page.c:929)
_mi_malloc_generic (mimalloc/src/page.c:965)
_mi_page_malloc_zero (mimalloc/src/alloc.c:42)
mi_heap_malloc_small_zero (mimalloc/src/alloc.c:151)
_mi_heap_malloc_zero_ex (mimalloc/src/alloc.c:176)
_mi_heap_malloc_zero (mimalloc/src/alloc.c:200)
mi_heap_malloc (mimalloc/src/alloc.c:204)
mi_malloc (mimalloc/src/alloc.c:208)
__register_atfork (@__register_atfork:14)
pthread_once (@pthread_once:37)
scudo_malloc_set_zero_contents (@scudo_malloc_set_zero_contents:55)
__libc_preinit_impl() (@__libc_preinit_impl():16)
__dl__ZL13call_functionPKcPFviPPcS2_ES0_ (@__dl__ZL13call_functionPKcPFviPPcS2_ES0_:38)
__dl__ZL10call_arrayIPFviPPcS1_EEvPKcPT_mbS5_ (@__dl__ZL10call_arrayIPFviPPcS1_EEvPKcPT_mbS5_:46)
__dl__ZN6soinfo17call_constructorsEv (@__dl__ZN6soinfo17call_constructorsEv:96)
__dl__ZN6soinfo17call_constructorsEv (@__dl__ZN6soinfo17call_constructorsEv:40)
__dl__ZN6soinfo17call_constructorsEv (@__dl__ZN6soinfo17call_constructorsEv:40)
__dl__ZN6soinfo17call_constructorsEv (@__dl__ZN6soinfo17call_constructorsEv:40)
__dl__ZL29__linker_init_post_relocationR19KernelArgumentBlockR6soinfo (@__dl__ZL29__linker_init_post_relocationR19KernelArgumentBlockR6soinfo:1048)
__dl___linker_init (@__dl___linker_init:129)
__dl__start (@__dl__start:5)

So the _mi_page_map is NULL in page-map.c:_mi_page_map_register. Any idea what's happening here?
Note: it's happening before mi_process_attach was called, but I suspect it's also the case on dev2.

[daanx]

Hi Eduard Voronkin (@Noxybot) : the fix in #1057 is not quite right -- the root cause is that mi_process_init is not called (which calls _mi_page_map_init which ensures the pagemap is not NULL which causes eventually the assertion to fail). But when I look at the stack trace, I see _mi_malloc_generic is called (because the thread local heap is (presumably) &_mi_heap_empty).
If you look at the start of page.c:_mi_malloc_generic it should call mi_heap_get_default which should call _mi_thread_init and then mi_process_init. Somehow that is not happening? Can you break at _mi_malloc_generic and see why the heap is not initialized / why mi_process_init is not called? (I cannot test on Android myself untfortunately :-( )

[Noxybot]

In page.c:_mi_malloc_generic mi_heap_get_default is not happening since this conidtion:

if mi_unlikely(!mi_heap_is_initialized(heap)) {
    heap = mi_heap_get_default(); // calls mi_thread_init
    if mi_unlikely(!mi_heap_is_initialized(heap)) { return NULL; }
  }

is false.
In prim.h:mi_prim_get_default_heap we call _mi_heap_main_get -> mi_heap_main_init. So that's the heap we're using later on (heap_main).
We don't call neither _mi_thread_init nor mi_process_init in mi_heap_main_init.
prim.h:mi_prim_get_default_heap is called when alloc.c:mi_malloc is called for the first time (as you see from the callstack).

[Noxybot]

Adding mi_thread_init(); to mi_heap_main_init(void) seems to help...

// Initialization of the (statically allocated) main heap, and the main tld and subproc.
static void mi_heap_main_init(void) {
  if (heap_main.cookie == 0) {
    // heap
    heap_main.cookie = 1;
    mi_thread_init(); <--------

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs in the next 14 days. Thank you for your contributions!

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale. Please feel free to reopen if this is still an active issue.