Enable tests on Android bot

[sanxiyn]

Android port is pretty stable now. It is stable enough to compile working Servo, for example. Let's enable tests on Android bot and start to block pull requests on it. We can reconsider if it is causing problems.

[sanxiyn]

When the pull request is merged, make check-stage2-T-arm-linux-androideabi-H-x86_64-unknown-linux-gnu-rpass will pass. It takes about 5 minutes running on a hardware Android device.

[alexcrichton]

Doesn't this involve having hardware with an arm processor on it? Right now I don't think that build artifacts are transferred between builders which is what it seems like this would have to do.

This would be awesome to be able to run tests on arm though, especially if it wasn't a huge slowdown on cycle time.

[sanxiyn]

There is already an (admittedly hacky) necessary automation in place to transfer build artifacts to (and results from) an Android device using adb. It can be used with either a hardware Android device, or an Android emulator.

[sanxiyn]

Pinging @brson.

[brson]

We can't get this done before 0.8. Let's try afterward.

[sanxiyn]

Unfortunately, this regressed, and currently all binaries result in segmentation fault on ARM. I bisected the problem down to #9301. Any idea what might be causing this?

[alexcrichton]

That commit had to do with changing how the global crate map is passed around. It was no longer passed explicitly to main, but rather exposed as a weak symbol through various platform-defined methods. It perhaps means that the symbol/linker on arm does something a tad bit unusual, but it would probably warrant more investigation.

If the symbol returned NULL, then that'd kill all programs because one of the first things the runtime does is to set up logging.

[huonw]

@fhahn's work in #9593 will probably fix the segfault (but disabling logging), assuming that he implements @luqmana's suggestion to detect the crate map being null.

[luqmana]

I tried a quick test by running a simple hello world (with some caveats as documented at #9632) with the android emulator and I can't reproduce a segfault.

[luqmana]

Logging seems to work fine too. @sanxiyn Could you get a stacktrace?

[sanxiyn]

I can reproduce the segfault with the Android emulator. I am not sure what's going on... Also, does anyone know how can one get a stack trace on Android?

[sanxiyn]

My current hypothesis is that Android dynamic linker does something different for weak symbols. See this comment for example. I also confirmed that Android dynamic linker behaves differently from Linux dynamic linker with respect to weak symbols using a simple C code.

So 1. is this plausible, and 2. is it possible to avoid use of weak symbols? Thanks.

[alexcrichton]

Does that mean that weak symbols don't work at all on android, or does that means that weak symbols just work differently on android?

If they don't work at all, we may have to re-think how we do this, but if they do work in some situations, then we can certainly have android-specific behavior.

[luqmana]

@sanxiyn It's werid that you're seeing a segfault but I'm not. I just confirmed again with rustc -v:

rustc 0.9-pre (fe4e747 2013-10-01 15:06:25 -0700)
host: x86_64-unknown-linux-gnu

-> % cat > hello.rs
fn main() {
    info!("info");
    debug!("debug");
    println!("Hello World!");
}

-> % rustc --target=arm-linux-androideabi --android-cross-path=$ANDROID_STANDALONE hello.rs --cfg debug

-> % android create avd --force -n test -t android-18 --abi armeabi-v7a
Android 4.3 is a basic Android platform.
Do you wish to create a custom hardware profile [no]
Created AVD 'test' based on Android 4.3, ARM (armeabi-v7a) processor,
with the following hardware config:
hw.lcd.density=240
vm.heapSize=48
hw.ramSize=512

-> % emulator -avd test -no-skin -no-audio -no-window &
[1] 6621

-> % adb remount
remount succeeded

-> % adb push $ANDROID_STANDALONE/arm-linux-androideabi/lib/libgnustl_shared.so /data/tmp/
1015 KB/s (1211344 bytes in 1.165s)

-> % adb push hello /data/tmp/hello
136 KB/s (8000 bytes in 0.057s)

-> % adb push /usr/local/lib/rustc/arm-linux-androideabi/lib/libstd-6c65cf4b443341b1-0.9-pre.so /data/tmp/
905 KB/s (6223580 bytes in 6.715s)

-> % adb push /usr/local/lib/rustc/arm-linux-androideabi/lib/librustrt.so /data/tmp/
1001 KB/s (3947716 bytes in 3.849s)

-> % adb shell
root@generic:/ # cd /data/tmp
root@generic:/data/tmp # ls
hello
libgnustl_shared.so
librustrt.so
libstd-6c65cf4b443341b1-0.9-pre.so
root@generic:/data/tmp # LD_LIBRARY_PATH=. ./hello
Hello World!
root@generic:/data/tmp # LD_LIBRARY_PATH=. RUST_LOG=::help ./hello

Crate log map:

 hello
 std::io
 std::condition
 std::ptr
 std::os
1|root@generic:/data/tmp # LD_LIBRARY_PATH=. RUST_LOG=hello ./hello
"info"
"debug"
Hello World!
root@generic:/data/tmp # LD_LIBRARY_PATH=. RUST_LOG=hello=info ./hello
"info"
Hello World!
root@generic:/data/tmp # LD_LIBRARY_PATH=. RUST_LOG=hello=debug ./hello
"info"
"debug"
Hello World!

[yichoi]

@luqman if you make your avd device with API level 17 not 18, you can see segfault.

android create avd --force -n test -t android-17 --abi armeabi-v7a

[sanxiyn]

I also confirm that android-18 emulator does not segfault, and android-17 emulator does, and hardware devices we have (whose API level is below 18) segfault.

For the current issue "enabling tests on Android bot", I think we can proceed with android-18 emulator. If we setup it sooner, it will prevent further regressions. I still want to understand what is going on with API level <18 and fix the issue, if only for hardware devices.

[klutzy]

I tested @sanxiyn's executable on my Galaxy Nexus (4.3, android-18); it didn't segfault.

[sanxiyn]

This regressed again, now failing 62 tests. Bisected to #9695. Probably related to changes to runtime reseeding random number generator, but haven't figured it out yet. Any suspect?

[huonw]

That PR changes std::rand to read from /dev/urandom using std::rt::io when possible, and the scheduler start-up to use libc::{open, close, read} with /dev/urandom to seed the scheduler's RNG.

What're the failures?

[sanxiyn]

I posted the list of tests failed to Gist: https://gist.github.com/sanxiyn/7007168

[sanxiyn]

This has been enabled. Closing.

https://mail.mozilla.org/pipermail/rust-dev/2014-January/008223.html