[swift-dev] Foundation crashes on Android

[Geordie Jay]

Philippe Hausler <phausler at 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 at swift.org>
> wrote:
>
> 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


>
>
> I’d be grateful for any further info or tips! Thanks :)
> – Geordie
>
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20171218/ee5ca7cf/attachment.html>