<div dir="ltr">Yikes, sounds like a nasty bug. Thanks for investigating, Eric!<div><br></div><div>I'm all for a fix. You may have already considered this, but perhaps the Android-specific workaround could be put into swift-corelibs-foundation? I wonder which the core team would prefer?</div><div><br></div><div>- Brian Gesiak<br><div><div><div><br></div><div><br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 6, 2016 at 6:58 PM, Eric Wing via swift-users <span dir="ltr"><<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 10/31/16, Eric Wing <<a href="mailto:ewmailing@gmail.com">ewmailing@gmail.com</a>> wrote:<br>
> Hello, I've been trying to get Swift 3 working on Android. (I<br>
> previously had Swift 2.x working.)<br>
><br>
> I have the baseline components built following the standard<br>
> Android/Swift instructions.<br>
><br>
> But when I go to make a trivial, but real Android<br>
> app (i.e. start in Java Activity and use JNI/LoadLibrary to get to<br>
> Swift), the Swift code seems to hang (freeze?) whenever my Swift code<br>
> calls print("foo").<br>
><br>
> Removing all print calls, allows my trivial code to run correctly. But in<br>
> slightly more complicated test programs (which call into other C<br>
> libraries), I'm getting program crashes. It looks like libc triggers<br>
> some kind of abort call in these cases. I know these C libraries work<br>
> in non-Swift cases.<br>
><br>
> My best guess right now is since Swift print() is also broken, I think<br>
> there might be some problem related to libc++ (and maybe its<br>
> interaction with libc) which is used in the build process. (The<br>
> Android NDK docs warn about std::cout buffering breaking if you have<br>
> multiple static linked libc++, but I'm not statically linking it.)<br>
><br>
> I'm currently using libc++_shared.<br>
> I updated my repo a few days ago which includes a fix for NDK r13<br>
> which I am using.<br>
><br>
><br>
> Does this problem ring a bell for anybody?<br>
> Or can somebody help me figure out how to start debugging this? I've<br>
> been trying a lot of different things behind the scenes, but I'm<br>
> starting to run out of ideas.<br>
><br>
> Thanks,<br>
> Eric<br>
><br>
<br>
</div></div>I discovered there is a serious deadlock bug in Android 5.0. flockfile<br>
on stdout/stderr causes a deadlock. Swift print() ultimately calls<br>
flockfile, which in turn causes a deadlock. I verified this by first<br>
commenting out the lock functions in the print function, and then<br>
later by commenting out the flockfile/funlockfile implementations in<br>
the Stubs.cpp.<br>
<br>
<br>
One of the comments here mentions this bug:<br>
<a href="https://chengyihe.wordpress.com/2015/10/31/android-child-process-hits-mutex-deadlock-in-printf-after-fork/" rel="noreferrer" target="_blank">https://chengyihe.wordpress.<wbr>com/2015/10/31/android-child-<wbr>process-hits-mutex-deadlock-<wbr>in-printf-after-fork/</a><br>
<br>
The workaround seems to be either to remove the call to flockfile() or<br>
update to Android 5.1. I upgraded my device to 5.1 and the problem<br>
disappeared.<br>
<br>
But thanks to Android fragmentation, going to 5.1 this means we lose<br>
another 13.1% of devices, leaving us only 40.6% of devices.<br>
<br>
<br>
This does bring up another issue though, at least for print() and<br>
anything stdout/stderr related on Android. On Android, sending<br>
anything to stdout/stderr via the NDK is effectively useless because<br>
they are effectively sent to /dev/null. (The ‘adb shell setprop<br>
log.redirect-stdio true’ trick doesn’t work for the NDK. There is one<br>
convoluted trick to redirect using pipes in your codebase, but that is<br>
a different can of worms.)<br>
<br>
In general, print() statements need to go through<br>
__android_log_write() and __android_log_print() on Android for anybody<br>
to see anything. Is this something we should implement in Swift?<br>
<div class="HOEnZb"><div class="h5"><br>
Thanks,<br>
Eric<br>
______________________________<wbr>_________________<br>
swift-users mailing list<br>
<a href="mailto:swift-users@swift.org">swift-users@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-users" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-users</a><br>
</div></div></blockquote></div><br></div>