Date: Sat, 14 Jan 2017 22:53:14 -0800 From: Mark Millard <markmi@dsl-only.net> To: freebsd-arm <freebsd-arm@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org> Subject: qemu-arm-static appears to have problems with signal delivery during (at least) poudrirer-devel based cross builds of some ports with ALLOW_MAKE_JOBS=yes Message-ID: <BF74B3CA-9BD6-4F97-B472-FF918FCE737A@dsl-only.net>
next in thread | raw e-mail | index | archive | help
[Context: head (12) -r312009 and ports head -r431413.] I've been experimenting on amd64 with poudriere-devel with -x for -a arm.armv6 and I ran into: > TCG temporary leak before 00021826 > qemu: uncaught target signal 4 (Illegal instruction) - core dumped in 3 of the 31 ports for the build, but 4 skipped so 3 of 27 attempted. The 00021826 is the same number in all the examples so far (whatever its base). These seem to be the only TCG messages and each failure starts with one and then reports the qemu message. (Also true for the below.) As far as I can tell the TCG notice is the report of an internal qemu problem that is then translated into an Illegal instruction. This was with ALLOW_MAKE_JOBS=yes but -J 1 for poudriere. For 2 of the problem ports retries worked, still using ALLOW_MAKE_JOBS=yes and -J 1 . But the 3rd port failed each time tried with ALLOW_MAKE_JOBS=yes --but in a different step each time. In all failure cases it was gmake that got the "illegal instruction". But disabling ALLOW_MAKE_JOBS=yes appears (so far) to avoid the issue. For example, that 3rd failing port built fine. (I've been doing more ports since, with ALLOW_MAKE_JOBS=yes repeatedly failing and lack of it working.) My guess is SIGCHLD delivery sometimes touches something (or a timing) that is not handled well in qemu-arm-static. I've had not problems on an rpi2 or bpim3 in the past. (I have seen some analogous "soemtimes" issues on powerpc under and version of lang that mishandled the stack part of the ABI FreeBSD uses, SIGCHLD sometimes getting on the stack at a bad-time for the messed up code generation, leading to stack corruption. Code not getting signals had no problems.) Note: The amd64 context is FreeBSD under VirtualBox under macOS and it has had no problem for native builds of world, kernel, or ports. === Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BF74B3CA-9BD6-4F97-B472-FF918FCE737A>