This segfaults on arm64 and ppc64le, both on xenial and bionic, both with gcc and clang. amd64, both linux and osx, and s390x are unaffected. FWIW, read(0, ...) doesn’t segfault, but it doesn’t read what it was supposed to, either.
It seems that libc6-dev version: 2.27-3ubuntu1 is used for each Ubuntu case. The upstream latest version is 2.30.
I think you can report to glibc project or Ubuntu libc6 to specify the issue: Is the issue Travis specific or Ubuntu specific or not depending on Linux distributions?
FWIW (probably not much), it works fine on a small Raspberry Pi,
though that’s armv6l, not arm64.
I think you can report to glibc project or Ubuntu libc6 to specify the issue: Is the issue Travis specific or Ubuntu specific or not depending on Linux distributions?
No way. It’s an issue in a alpha feature, involving virtualization
infrastructure that I know absolutely nothing about. So it’s up to
Travis CI folks to investigate further, and narrow down whether the
issue is rooted on their in the first place.
I am interested in seeing a resolution to this issue. At least one upstream project will not implement multi-arch ci support because of the perception that Travis multi arch support is not stable calling out this and other issues.
I am unable to reproduce the segfault on ppc64le outside of the travis environment. I have attempted to match the environment as close as possible with no luck. I made an attempt to troubleshoot the issue inside travis but found that I could not create core file on travis multi-arch, so I am stuck.
Reporting the problem upstream with out the ability to reproduce is useless.
If anyone has ideas or a status please post here.
Another possible way to run ppc64le case is to try to use os: linux-ppc64le without specifying arch: foo It is a legacy ppc64le environment in Traivs.
It had been running experimentally before arch: foo syntax was introduced. And now the os: linux-ppc64le is not recommended by Travis. But I think it’s worth to try it for now.
Here is the example.
Another possible way to run arm64 case is to use Drone CI’s arm64 case.
One more idea is to use QEMU on Travis x86_64 (amd64) environment.
Here is the example running aarch64 with the aarch64 cross compiler on x86_64.
Here is the tool I sometimes maintains as one of the maintainers, to run a specific CPU architecture container on x86_64.
But note QEMU emulation environment is very slow and this is emulation.
So, though in my opinion, the native architecture is much better than QEMU environment. But I would introduce the QEMU way as one of the possible ways to run aarch64 and ppc64le cases.
@szeder@junaruga
Much appreciated - report and possible verification ways!
@UlkaAsati - thanks for interlinking, related topic was narrowed down to a suspicious instance for now, verifying if it was indeed the case. Here I lean to agree with @junaruga that there’s maybe a cross-platform issue with tools.