Skip to content

IOS invalid memory access when calling _mi_process_init #262

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
phthegreat opened this issue Jun 18, 2020 · 3 comments
Closed

IOS invalid memory access when calling _mi_process_init #262

phthegreat opened this issue Jun 18, 2020 · 3 comments

Comments

@phthegreat
Copy link

phthegreat commented Jun 18, 2020

I build an test app static link with the .a library. But the app crashes when calling _mi_process_init.
The backtrace is as below:

`(lldb) bt

  • thread Fix spelling errors #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    • frame #0: 0x00000001000e9550 rack_mi_process_init + 28 frame #1: 0x0000000100164a34 dyldImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 468
      frame Return usable allocation size on allocation #2: 0x0000000100164e44 dyldImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 56 frame #3: 0x000000010015f198 dyldImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 580
      frame WebAssembly support? #4: 0x000000010015d3c4 dyldImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 192 frame #5: 0x000000010015d490 dyldImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 96
      frame Windows CMake+Ninja build warning due to duplicate basename #6: 0x000000010014e744 dylddyld::initializeMainExecutable() + 220 frame #7: 0x00000001001531ec dylddyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 4588
      frame Readme contains invisible \u200b ZERO WIDTH SPACE, breaking URLs #8: 0x000000010014d22c dylddyldbootstrap::start(dyld3::MachOLoaded const*, int, char const**, dyld3::MachOLoaded const*, unsigned long*) + 432 frame #9: 0x000000010014d038 dyld_dyld_start + 56
      (lldb) `

I think mi_tls_slot does not work properly on IOS (arm64)

void** tcb; UNUSED(ofs); asm volatile ("mrs %0, tpidr_el0" : "=r" (tcb)); res = tcb[slot];

tcb equals NULL and this is the reason why it crashes.

Any idea how to fix it?

@daanx
Copy link
Collaborator

daanx commented Jun 18, 2020

ouch :-( ah, the testing I have done on macOS has been limited to OSX on a macbook. Thanks for reporting this and I hope we can make it work well on iOS as well.

  1. Can you try linking with a dynamic library for mimalloc (.so) ?

  2. I thought that the TCB should have been always initialized by the time mimalloc is initialized; here that seems not to be the case though. Not sure why.

(a) Perhaps accessing a (dummy) thread local as the first thing in process_init may force initialization? Can you try that out? [1]. e.g. in init.c change around line 448 to access a thread local on process load (which I think is inlined in _mi_process_init in your stack trace):

static mi_decl_thread uintptr_t dummy;
// Called once by the process loader
static void mi_process_load(void) {
  mi_heap_main_init();
  dummy = 1;                     // hopefully causes tcb to be initialized
  #if defined(MI_TLS_RECURSE_GUARD)
   ...

(b) If the above does not work, perhaps we need to just guard against tcb being NULL; that should work as reading the slot itself is already guarded against it being NULL (line 331 in mimalloc-internal.h). In mimalloc-internal.h change line 706 to

res = (tcb==NULL ? NULL : tcb[slot]);

and line 727 to

if (tcb != NULL) tcb[slot] = value;

(that last change may not be quite right but let's first find out if this is the root cause or not)

Apologies if this is too much trouble, but I have no easy way myself to develop on iOS. Let me know how it goes if you are able to try it out. Thanks, Daan

@daanx daanx mentioned this issue Jun 18, 2020
@phthegreat
Copy link
Author

I saw your advice on #263
Here is what I've tried:

  1. build a dynamic overide version.
  2. guard against tcb being NULL.
    3.1 comment out the #define MI_TLS_SLOT 89
    3.2 replace #define MI_TLS_SLOT 89 with #define MI_TLS_PTHREAD

But both 3.1 and 3.2 do not work :(

error of 3.1
image

error of 3.2
image

I also test mi_tls_slot alone in main to see if the register is initialized or not.
just as below

image

But tcb is still NULL :(

@daanx
Copy link
Collaborator

daanx commented Jul 27, 2020

I close this issue to consolidate porting to iOS in #263

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants