Foundation crashes on Android

Geordie_J · December 18, 2017, 5:13pm

Hello,

I’m trying to get the latest version of Foundation working on Android. Just looking to see if anyone has seen similar issues on other (esp. 32bit) platforms or on Android itself.

I made some minor changes:
– CoreFoundation/Base.subproj/CFSortFunctions.c to get e.g. __checkint_int32_mul working – the 32bit versions of those macros seem to be undefined (or incorrectly), so I renamed e.g. __check_int32_mul to __checkint_int32_mul etc.
– Added an #if !defined(__ANDROID__) check around the import of #include <unicode/unumsys.h>.
– Added #if defined(__ANDROID__) typedef unsigned short __swift_mode_t; to LibcShims.h in the Swift repo. This is the change I’m least sure about – I have no idea why this is suddenly necessary, or even whether I’m defining the type correctly.

Other than that everything seems to build fine.

The issue is I’m getting a signal 11 (SIGSEGV), code 1 (SEGV_MAPERR) in memmove/memcpy if I try something simple like this:

let nsDate = NSDate()
print(nsDate)

/system/lib/libc.so (memcpy+140)
.../swift-corelibs-foundation/CoreFoundation/Collections.subproj/CFData.c:653
.../swift-corelibs-foundation/CoreFoundation/Collections.subproj/CFData.c:442
.../swift-corelibs-foundation/CoreFoundation/Collections.subproj/CFData.c:449
.../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:1301
.../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:1326
.../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:816
.../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:824
.../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:860
.../swift-corelibs-foundation/CoreFoundation/Locale.subproj/CFDateFormatter.c:878
.../swift-corelibs-foundation/CoreFoundation/Locale.subproj/CFDateFormatter.c:1052
.../swift-corelibs-foundation/Foundation/NSDate.swift:116

Apparently it crashes on a memmove trying to run CFDateFormatterCreate. Has anyone else seen this? Is it possible that memmove isn’t being linked correctly? I’d be grateful for any tips along these lines.

libDispatch seems broken too, but this is probably another issue. Running CFRunLoopRun() produces a __HALT trap with no further stack trace. This one is a signal 4 (SIGILL), code 1 (ILL_ILLOPC), which is normally an overflow or unwrapping a nil value. I guess I’ll try to compile a debug version of libdispatch to track this one further.

I’d be grateful for any further info or tips! Thanks :)
– Geordie

Philippe_Hausler · December 18, 2017, 5:44pm

Hello,

I’m trying to get the latest version of Foundation working on Android. Just looking to see if anyone has seen similar issues on other (esp. 32bit) platforms or on Android itself.

I made some minor changes:
– CoreFoundation/Base.subproj/CFSortFunctions.c to get e.g. __checkint_int32_mul working – the 32bit versions of those macros seem to be undefined (or incorrectly), so I renamed e.g. __check_int32_mul to __checkint_int32_mul etc.
– Added an if !defined(__ANDROID__) check around the import of #include <unicode/unumsys.h>.
– Added if defined(__ANDROID__) typedef unsigned short __swift_mode_t; to LibcShims.h in the Swift repo. This is the change I’m least sure about – I have no idea why this is suddenly necessary, or even whether I’m defining the type correctly.

Other than that everything seems to build fine.

The issue is I’m getting a signal 11 (SIGSEGV), code 1 (SEGV_MAPERR) in memmove/memcpy if I try something simple like this:

let nsDate = NSDate()
print(nsDate)

/system/lib/libc.so (memcpy+140)
.../swift-corelibs-foundation/CoreFoundation/Collections.subproj/CFData.c:653
.../swift-corelibs-foundation/CoreFoundation/Collections.subproj/CFData.c:442
.../swift-corelibs-foundation/CoreFoundation/Collections.subproj/CFData.c:449
.../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:1301
.../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:1326
.../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:816
.../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:824
.../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:860
.../swift-corelibs-foundation/CoreFoundation/Locale.subproj/CFDateFormatter.c:878
.../swift-corelibs-foundation/CoreFoundation/Locale.subproj/CFDateFormatter.c:1052
.../swift-corelibs-foundation/Foundation/NSDate.swift:116

Apparently it crashes on a memmove trying to run CFDateFormatterCreate. Has anyone else seen this? Is it possible that memmove isn’t being linked correctly? I’d be grateful for any tips along these lines.

My guess is that the memcpy is getting passed NULL or a bad pointer, can you attach gdb to the process? (One trick I have used in the past is to add a small C function called as the very first thing after loading the library that hot loops until a global is set and then once gdb is attached set the global to the value that will let the loop exit).

libDispatch seems broken too, but this is probably another issue. Running CFRunLoopRun() produces a __HALT trap with no further stack trace. This one is a signal 4 (SIGILL), code 1 (ILL_ILLOPC), which is normally an overflow or unwrapping a nil value. I guess I’ll try to compile a debug version of libdispatch to track this one further.

Again getting gdb in the mix here would be really helpful to understand what is going on.

···

On Dec 18, 2017, at 9:13 AM, Geordie J via swift-dev <swift-dev@swift.org> wrote:

I’d be grateful for any further info or tips! Thanks :)
– Geordie

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Geordie_J · December 18, 2017, 6:02pm

Hello,

I’m trying to get the latest version of Foundation working on Android.
Just looking to see if anyone has seen similar issues on other (esp. 32bit)
platforms or on Android itself.

I made some minor changes:
– CoreFoundation/Base.subproj/CFSortFunctions.c to get e.g.
__checkint_int32_mul working – the 32bit versions of those macros seem to
be undefined (or incorrectly), so I renamed e.g. *__check_int32_mul* to
*__checkint_int32_mul* etc.
– Added an *if !defined(__ANDROID__)* check around the import of *#include
<unicode/unumsys.h>*.
– Added *if defined(__ANDROID__) typedef unsigned short __swift_mode_t;* to
LibcShims.h in the Swift repo. This is the change I’m least sure about – I
have no idea why this is suddenly necessary, or even whether I’m defining
the type correctly.

Other than that everything seems to build fine.

The issue is I’m getting a signal 11 (SIGSEGV), code 1 (SEGV_MAPERR) in
memmove/memcpy if I try something simple like this:

*let nsDate = NSDate()*
*print(nsDate)*

/system/lib/libc.so (memcpy+140)

.../swift-corelibs-foundation/CoreFoundation/Collections.subproj/CFData.c:653

.../swift-corelibs-foundation/CoreFoundation/Collections.subproj/CFData.c:442

.../swift-corelibs-foundation/CoreFoundation/Collections.subproj/CFData.c:449

.../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:1301

.../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:1326

.../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:816

.../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:824

.../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:860

.../swift-corelibs-foundation/CoreFoundation/Locale.subproj/CFDateFormatter.c:878

.../swift-corelibs-foundation/CoreFoundation/Locale.subproj/CFDateFormatter.c:1052
.../swift-corelibs-foundation/Foundation/NSDate.swift:116

Apparently it crashes on a memmove trying to run CFDateFormatterCreate.
Has anyone else seen this? Is it possible that memmove isn’t being linked
correctly? I’d be grateful for any tips along these lines.

My guess is that the memcpy is getting passed NULL or a bad pointer, can
you attach gdb to the process? (One trick I have used in the past is to add
a small C function called as the very first thing after loading the library
that hot loops until a global is set and then once gdb is attached set the
global to the value that will let the loop exit).

Ok good tip about the null pointer. CFData.c:653 does do some pointer
arithmetic just before the crash. It’s all quite deep in the internals of
CF though so I’m surprised that this issue hasn’t come up elsewhere.

Annoyingly I don’t have a rooted device to run gdb (Android studio has an
lldb debugging option but I couldn’t get it working with Swift binaries
last I tried).

I think my best bet will be to run gdb in the Android emulator’s shell
environment but I haven’t had luck with that in the past either. I’ll have
another look at this option tomorrow.

Thanks for the tip about the C function! It may well come in handy.

libDispatch seems broken too, but this is probably another issue. Running
CFRunLoopRun() produces a *__HALT* trap with no further stack trace. This
one is a signal 4 (SIGILL), code 1 (ILL_ILLOPC), which is normally an
overflow or unwrapping a nil value. I guess I’ll try to compile a debug
version of libdispatch to track this one further.

Again getting gdb in the mix here would be really helpful to understand
what is going on.

My guess is I’d need a debug build of libdispatch to get anything useful
out of gdb too. So that’ll be my first step, then I’ll try to get gdb (or
lldb?) running.

Thanks for the pointers so far ;)

Cheers,
- Geordie

···

Philippe Hausler <phausler@apple.com> schrieb am Mo. 18. Dez. 2017 um 18:44: > > On Dec 18, 2017, at 9:13 AM, Geordie J via swift-dev <swift-dev@swift.org> > wrote:

I’d be grateful for any further info or tips! Thanks :)
– Geordie

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev