Hi all, Ludovic Courtès <l...@gnu.org> writes:
> Hello, > > Maxime Devos <maximede...@telenet.be> skribis: > >> Ludovic Courtès schreef op zo 11-07-2021 om 00:19 [+0200]: >>> Hi, >>> >>> Maxime Devos <maximede...@telenet.be> skribis: >>> >>> > FAIL: stackoverflow1 >>> > ==================== >>> > >>> > qemu: uncaught target signal 11 (Segmentation fault) - core dumped >>> > FAIL stackoverflow1 (exit status: 139) >>> > >>> > FAIL: stackoverflow2 >>> > ==================== >>> > >>> > Starting recursion pass 1. >>> > Stack overflow 1 missed. >>> > FAIL stackoverflow2 (exit status: 1) >>> >>> For now I worked around it by offloading this to a “real” machine >>> (overdrive1), where it builds fine. I wonder if there’s much we can do >>> regarding QEMU’s behavior here. >> >> Maybe detect if QEMU is used, and if so, don't run the test suite? >> Not really a ‘clean’ solution though, w.r.t. reproducibility, >> and I wouldn't know how to detect this. > > Yeah, I’d rather avoid that. > >> If this is a bug in QEMU, then ideally that would be fixed in QEMU, >> but I wouldn't know where to look. > > It could be that someone else on the intertubes stumbled upon that > issue, that’d be great. It could be that libsigsegv plays tricks that > don’t fare well with QEMU’s expectations, as in > <https://bugzilla.redhat.com/show_bug.cgi?id=1493304#c5>. We should ask > on bug-libsigs...@gnu.org. > > Thanks, > Ludo’. (I just realized I never actually replied to this!) Configuring with "--disable-stackvma" seems to fix this. Doing this makes libsigsegv use a different heuristic for determining if a SIGSEGV was a stack overflow. I don't think it should impact functionality. Perhaps just apply that to aarch64 until there's a proper fix? This is probably a QEMU bug... I will try to report this to upstream QEMU when I can, as I can't find my notes on this right now. -- Sarah
