qemu-arm-static crashes "segmentation fault" when running "svn checkout"

Bug #1869782 reported by Manuel Reimer on 2020-03-30
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
QEMU
Undecided
Unassigned

Bug Description

I'm not actually sure how far I can help as I so far failed to reproduce the issue on my local VM but I get it on Travis CI every time. I even went through the hassle of hacking a Debian repository into their Ubuntu Bionic VM to get qemu 4.2 as I hoped a new version could fix this.

This build runs in an armv6h chroot. I don't get the segfault if I do the same on an armv7h chroot for some reason.

Here is where the error occured: https://travis-ci.com/github/VDR4Arch/vdr4arch/jobs/309106220#L5420

Maybe now I'll just try to remove all uses of svn in my build scripts...

Is it actually a viable solution to cross-build with qemu? I'm starting to doubt it...

Would it help if I manage to get this core dump out of Travis somehow (maybe make Travis push it to some GIT or upload it to my webserver)?

description: updated
Peter Maydell (pmaydell) wrote :

Is there a way that you can confirm that the QEMU being used to execute the binaries in the chroot really really is the new one you think it is? In this kind of setup where there's a chroot and somebody else's CI system and so on it can be quite easy for eg the new qemu binary not to get copied into the chroot so it's using the old version still, or whatever. So being able to rule that kind of possibility out would be helpful.

Manuel Reimer (manuel-reimer) wrote :

I could run an "qemu... --version" in the chroot to get it into log.

But I'm close to 100% sure it is version 4.2 as the VM is set up from scratch for every build and the chroot is also set up from scratch.

Manuel Reimer (manuel-reimer) wrote :

This is a "Ubuntu Bionic" thing.

I've tried again on a VM with up-to-date Ubuntu Bionic and get the same segfault.

For comparison I've placed the Debian build of qemu-user-static version 4.2 to my Arch Linux VM and have no crash there.

So either the kernel version or some kernel configuration. Now I'm trying to get a coredump on my VM.

Manuel Reimer (manuel-reimer) wrote :

Managed to get a coredump. Coredumps usually tell me nothing but maybe someone here can find something useful in there...

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers