# Arm64/ppc64le segfaults
**URL:** https://travis-ci.community/t/arm64-ppc64le-segfaults/6158
**Category:** Multi CPU Architecture
**Tags:** bug
**Created:** [November 27, 2019, 2:59am UTC](https://travis-ci.community/t/arm64-ppc64le-segfaults/6158 "2019-11-27T02:59:24Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@szeder](https://travis-ci.community/u/szeder)
#### Post date: [November 27, 2019, 2:59am UTC](https://travis-ci.community/t/arm64-ppc64le-segfaults/6158/1 "2019-11-27T02:59:24Z")
I get reproducible segfaults in `getc(stdin)` when stdin is a fifo accessed like this:
```auto
mkfifo fifo
exec 8<>fifo
echo asdf >fifo
rm fifo
./a-program-calling-getc <&8
```
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.
Fairly minimal example:
[https://travis-ci.org/szeder/git/builds/617513593](https://travis-ci.org/szeder/git/builds/617513593)
[https://travis-ci.org/szeder/git/builds/617513614](https://travis-ci.org/szeder/git/builds/617513614)
---
### Author:  [@UlkaAsati](https://travis-ci.community/u/UlkaAsati)
#### Post date: [December 13, 2019, 9:49am UTC](https://travis-ci.community/t/arm64-ppc64le-segfaults/6158/2 "2019-12-13T09:49:03Z")
@Michal For Binoic and xenial distribution, receiving segfault for ppc64le and arm64 jobs Whereas it passes for AMD64.
all the passed and failing jobs can be seen here:
[https://travis-ci.com/ghatwala/git/builds/140921043](https://travis-ci.com/ghatwala/git/builds/140921043)
I saw similar issue here [Segfaults in arm64 environment](https://travis-ci.community/t/segfaults-in-arm64-environment/5617)
Looking for your inputs.Thanks in advance
---
### Author:  [@noloader](https://travis-ci.community/u/noloader)
#### Post date: [December 13, 2019, 12:02pm UTC](https://travis-ci.community/t/arm64-ppc64le-segfaults/6158/3 "2019-12-13T12:02:31Z")
I _think_ your program has undefined behavior:
```auto
int main(int argc, char *argv[])
{
int c = 'z';
c = getc(stdin);
if (c == EOF)
printf("EOF!\n");
else
printf("got '%c' (0x%x)\n", c, c);
return 0;
}
```
The first `c` should probably use `%d`, not `%c`, since `c` is an `int`. Maybe something like:
```auto
printf("got '%d' (0x%x)\n", c, c);
```
Use `g++ -Wall` or a Sanitizer to vet the code at compile time.
---
### Author:  [@szeder](https://travis-ci.community/u/szeder)
#### Post date: [December 13, 2019, 2:54pm UTC](https://travis-ci.community/t/arm64-ppc64le-segfaults/6158/4 "2019-12-13T14:54:52Z")
It doesn’t matter,
```auto
int main(...)
{
getc(stdin);
return 0;
}
```
segfaults all the same.
[https://travis-ci.org/szeder/git/builds/624647282](https://travis-ci.org/szeder/git/builds/624647282)
[https://travis-ci.org/szeder/git/builds/624647400](https://travis-ci.org/szeder/git/builds/624647400)
---
### Author:  [@junaruga](https://travis-ci.community/u/junaruga)
#### Post date: [December 13, 2019, 6:12pm UTC](https://travis-ci.community/t/arm64-ppc64le-segfaults/6158/5 "2019-12-13T18:12:17Z")
I checked the issued on the repository [https://github.com/junaruga/git/tree/arm64-libc-fifo-segfault-jaruga](https://github.com/junaruga/git/tree/arm64-libc-fifo-segfault-jaruga) forked from your repository: [https://github.com/szeder/git/tree/arm64-libc-fifo-segfault](https://github.com/szeder/git/tree/arm64-libc-fifo-segfault) .
I checked it with strace.
```auto
sudo apt-get -yq install strace
strace -f ci/arm64-segfault-demo.sh
```
The result is here.
[https://travis-ci.org/junaruga/git/builds/624724660](https://travis-ci.org/junaruga/git/builds/624724660)
For s390x + gcc (ok) case
```auto
[pid 2769] fstat(0, {st_mode=000, st_size=0, ...}) = 0
```
For arm64 + gcc (error) case
```auto
[pid 2834] fstat(0, ) = ?
```
I also checked the used glibc version too.
```auto
dpkg -S /usr/include/stdio.h
apt-cache show libc6-dev
```
See [https://travis-ci.org/junaruga/git/jobs/624724663#L61](https://travis-ci.org/junaruga/git/jobs/624724663#L61)
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?
- glibc project: [https://www.gnu.org/software/libc/](https://www.gnu.org/software/libc/) - Report a bug
- Ubuntu libc6-dev: [https://packages.ubuntu.com/bionic/libc6-dev](https://packages.ubuntu.com/bionic/libc6-dev) - Bug Reports
---
### Author:  [@szeder](https://travis-ci.community/u/szeder)
#### Post date: [December 14, 2019, 10:00am UTC](https://travis-ci.community/t/arm64-ppc64le-segfaults/6158/6 "2019-12-14T10:00:37Z")
> For arm64 + gcc (error) case
>
> ```auto
> [pid 2834] fstat(0, ) = ?
>
> ```
Indeed, a simple
```auto
struct stat st;
fstat(0, &st);
```
segfaults, too.
> **[Travis CI - Test and Deploy with Confidence](https://app.travis-ci.com/szeder/git/jobs/624872760)**
>
> Travis CI enables your team to test and ship your apps with confidence. Easily sync your projects with Travis CI and you'll be testing your code in minutes.
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.
---
### Author:  [@djlwilder](https://travis-ci.community/u/djlwilder)
#### Post date: [January 8, 2020, 8:15pm UTC](https://travis-ci.community/t/arm64-ppc64le-segfaults/6158/7 "2020-01-08T20:15:45Z")
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.
---
### Author:  [@junaruga](https://travis-ci.community/u/junaruga)
#### Post date: [January 8, 2020, 9:54pm UTC](https://travis-ci.community/t/arm64-ppc64le-segfaults/6158/8 "2020-01-08T21:54:17Z")
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](https://drone.io/)’s arm64 case.
Here is the example.
>
---
### Author:  [@junaruga](https://travis-ci.community/u/junaruga)
#### Post date: [January 8, 2020, 10:08pm UTC](https://travis-ci.community/t/arm64-ppc64le-segfaults/6158/9 "2020-01-08T22:08:26Z")
> If anyone has ideas or a status please post here.
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.
> **[GitHub - multiarch/qemu-user-static: :earth\_africa: \`/usr/bin/qemu-\*-static\`](https://github.com/multiarch/qemu-user-static)**
>
> :earth\_africa: \`/usr/bin/qemu-\*-static\`. Contribute to multiarch/qemu-user-static development by creating an account on GitHub.
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.
---
### Author:  [@Michal](https://travis-ci.community/u/Michal)
#### Post date: [January 10, 2020, 1:53pm UTC](https://travis-ci.community/t/arm64-ppc64le-segfaults/6158/10 "2020-01-10T13:53:47Z")
@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.
We need to double check that.
cc @djlwilder
---
### Author:  [@Michal](https://travis-ci.community/u/Michal)
#### Post date: [January 16, 2020, 12:31pm UTC](https://travis-ci.community/t/arm64-ppc64le-segfaults/6158/11 "2020-01-16T12:31:27Z")
Please standby.
It seems there’s a kernel fix to be done, we’re waiting for that to be available.
---
### Author:  [@noloader](https://travis-ci.community/u/noloader)
#### Post date: [March 6, 2020, 5:15pm UTC](https://travis-ci.community/t/arm64-ppc64le-segfaults/6158/12 "2020-03-06T17:15:36Z")
@szeder,
Sorry for the late reply.
> It’s an issue in a alpha feature, involving virtualization
> infrastructure
I found I could side-step a lot of the issues by using Bionic; and avoiding down-level platforms like Xenial.
I still have a few failures but I am pretty sure they are due to compiler bugs.