posix_memalign is not available on some Android 4.1 devices

[mdmt1]

posix_memalign is declared in stdlib.h as being available since Android 4.1:

#if __ANDROID_API__ >= 16
int posix_memalign(void** __memptr, size_t __alignment, size_t __size) __INTRODUCED_IN(16);
#endif /* __ANDROID_API__ >= 16 */

However, on some devices that were launched with pre-4.1 version of Android and later upgraded to 4.1, bionic seems to not have been updated.

This causes java.lang.UnsatisfiedLinkError: Cannot load library: reloc_library[1306]: 143 cannot locate 'posix_memalign'... in System.loadLibrary.

I have found related issue here.

As far as I can tell, there are no Android 4.2 devices with this problem.

[DanAlbert]

Do you have examples of devices like this? The linked bug report says the 4.1+ is fine.

[mdmt1]

Do you have examples of devices like this?

I have encountered it on Motorola RAZR i (x86), Android 4.1.

The linked bug report says the 4.1+ is fine.

I'm not sure how you came to this conclusion. It says that ZTE U5 (Android 4.1) also exhibits this issue. Later in the comments it also says:

Webperf team has also encountered this issue on Chrome for android on Android 4.1(X86). Upstream has known this issue.
posix_memalign was missing in the system library: libc.so.

After some searching in chromium repo, I have found this:

#define HAVE_POSIX_MEMALIGN 0 /* #define HAVE_POSIX_MEMALIGN 1 -- forced to 0. See https://crbug.com/604451 */

Linked bug report says:

We had at least one case of Android device "forgetting" to implement posix_memalign (despite the fact that is mandated by the NDK for the SDK level we target in chrome) and causing chrome to crash at startup.

Technically we have all the rights in Chrome to use posix_memalign. After the bump to JB (and the consequent drop of ICS) The SDK level we are targeting exposes that in the NDK.
I suppose that code in #1 predates the bump to the JB sdk, which was a fairly recent thing.
Sadly, however, some vendor forgot to alias posix_memalign in their libc violating the NDK. :-(

To learn more, I downloaded the Android 4.1 firmware for Motorola RAZR i and extracted libc.so.

objdump --dynamic-syms libc.so | rg memalign

00018860 g DF .text 0000002e memalign
000164d0 g DF .text 0000025f dlposix_memalign
000162b0 g DF .text 00000220 dlmemalign

For comparison, libc.so from system.img of Android 4.1 x86 virtual device.

objdump --dynamic-syms libc.so | rg memalign

000161b0 g DF .text 00000030 memalign
00016020 g DF .text 00000013 dlmemalign
00015e30 g DF .text 00000021 posix_memalign

I also searched for all new symbols in API 16 in the latest NDK (16.1.4479499) by running rg 'INTRODUCED_IN\(16\)' in sysroot directory.

Only posix_memalign is missing. All others (faccessat, tdelete, tdestroy, tfind, tsearch, readahead and all symbols from sys/xattr.h) are present.

[enh]

ah, x86-only? that sounds familiar.... https://issuetracker.google.com/28245055

[enh]

from that bug it looks like i should have bumped the API level for x86 posix_memalign to 17, but didn't. so i guess that's the fix here?

[mdmt1]

In Android 4.1 posix_memalign was defined like this:

int posix_memalign(void **memptr, size_t alignment, size_t size) {
  int ret = 0;

  *memptr = dlmemalign(alignment, size);

  if (*memptr == 0) {
    ret = ENOMEM;
  }

  return ret;
}

And memalign was aliased to dlmemalign.

Maybe posix_memalign can be declared like this?

#if __ANDROID_API__ >= 17
int posix_memalign(void** __memptr, size_t __alignment, size_t __size) __INTRODUCED_IN(17);
#else
int posix_memalign(void **memptr, size_t alignment, size_t size) {
  int ret = 0;

  *memptr = memalign(alignment, size);

  if (*memptr == 0) {
    ret = ENOMEM;
  }

  return ret;
}
#endif /* __ANDROID_API__ >= 17 */

[rprichard]

If we do bump the API level to 17, maybe we'd want to add something for API 16? We had an out-of-line version of the function in android_support until recently for the sake of API < 16:

https://android-review.googlesource.com/c/platform/ndk/+/610876

[DanAlbert]

Yeah, I think we may want to just put it back in libandroid_support. The alternative is that we add the inline directly to bionic until such time that we can drop API 16. @enh, thoughts? Neither is particularly difficult.

[enh]

either sgtm.

[mdmt1]

Accidentally pressed the "Close issue" button, disregard.

[DanAlbert]

This is "fixed" in r17 in that it's back in libandroid_support, but for completeness I need to get the headers/stub libs to stop pretending it was in android-16.