Missing system calls when running tests under qemu-arm at TravisCI

help
1

I have been setting up continuous integration for various targets based on rust-everywhere. And I've hit a block at the arm-unknown-linux-gnu:

My build failed with:

qemu: Unsupported syscall: 384
running 8 tests
/build/buildd/qemu-linaro-1.0.50-2012.03/tcg/tcg.c:1360: tcg fatal error
/build/buildd/qemu-linaro-1.0.50-2012.03/tcg/tcg.c:1360: tcg fatal error
No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself.

Now it seems pretty obvious why it works on my box, but fails on TravisCI: I have Debian Testing with qemu 2.5 and Travis has Ubuntu Precise Pangolin with ancient qemu 1.0.50.

However, what I am totally failing to find is what is actually causing triggering the problem.

By searching on LXR I found that on Arm, system call 384 should be [getrandom](http://lxr.free-electrons.com/source/arch/arm/include/
uapi/asm/unistd.h#L413). So I wanted to debug the test locally and see what triggers it. However:

  • I can't find number of that system call on x86_64 either by searching LXR or local /usr/include.
  • To a catch syscall getrandom gdb replies Unknown syscall name 'getrandom'.
  • Including linux/random.h does not define function getrandom, neither in gcc nor in arm-linux-gnueabihf-gcc.

So I am at loss how to find what is triggering the problem? Does anybody have an idea how to find it?

2

This might not make any difference but Travis has had has Ubuntu Trusty for a while: Redirecting…

3

Yes, I know. And I am trying to cast various hexes at it to make it work; problem is, that documentation of the configuration format, especially how the matrix interacts with things, is pretty bad. And the travis lint is not helping; it says the addons key does nothing when it clearly works...

Anyway, I am really curious about what the missing system call actually is and what is calling it. Independent of any attempts to get TravisCI use working versions of the relevant packages.

4

It fails on trusty too (the build succeeded only because the script does not report the segfault well).

However, for some strange reason, it succeeded in this attempt even though according to the install log it installed the same version of qemu as before (I told it to add the debian sid repository, but apt still said it installed qemu 1.0.50 from precise-updates/universe just like the other builds.

At least I tested that the sudo: required and dist: trusty keys can be set for specific builds in the matrix.include and take effect as desired despite travis lint saying they are unexpected.