bug#49509: libsigsegv fails to build on emulated aarch64 [core-updates]

bug#49509: libsigsegv fails to build on emulated aarch64 [core-updates]

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 3792 bytes --]

Hi guix

I noticed a new build failure on ci.guix.gnu.org:
<https://ci.guix.gnu.org/build/660357/log/raw>.

Relevant log output:

make[2]: Leaving directory '/tmp/guix-build-libsigsegv-2.13.drv-0/libsigsegv-2.13'
make[1]: Leaving directory '/tmp/guix-build-libsigsegv-2.13.drv-0/libsigsegv-2.13'
phase `build' succeeded after 44.7 seconds
starting phase `check'
yes
checking for working strerror function... Making check in src
make[1]: Entering directory '/tmp/guix-build-libsigsegv-2.13.drv-0/libsigsegv-2.13/src'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/tmp/guix-build-libsigsegv-2.13.drv-0/libsigsegv-2.13/src'
Making check in tests
make[1]: Entering directory '/tmp/guix-build-libsigsegv-2.13.drv-0/libsigsegv-2.13/tests'
make  check-TESTS
make[2]: Entering directory '/tmp/guix-build-libsigsegv-2.13.drv-0/libsigsegv-2.13/tests'
time.h
checking for struct tm.tm_zone... yes
checking for fake locale system (OpenBSD)... make[3]: Entering directory '/tmp/guix-build-libsigsegv-2.13.drv-0/libsigsegv-2.13/tests'
yes
checking for struct tm.tm_gmtoff... FAIL: stackoverflow2
PASS: sigsegv2
../build-aux/test-driver: line 109:  6663 Segmentation fault      "$@" > $log_file 2>&1
PASS: sigsegv3
PASS: sigsegv1
FAIL: stackoverflow1
yes
checking for nlink_t... (cached) yes
checking whether unlink honors trailing slashes... yes
checking for O_CLOEXEC... no
checking for Solaris 11.4 locale system... no
checking for getlocalename_l... ============================================================================
Testsuite summary for libsigsegv 2.13
============================================================================
# TOTAL: 5
# PASS:  3
# SKIP:  0
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0
============================================================================
See tests/test-suite.log
============================================================================
make[3]: *** [Makefile:729: test-suite.log] Error 1
make[3]: Leaving directory '/tmp/guix-build-libsigsegv-2.13.drv-0/libsigsegv-2.13/tests'
make[2]: *** [Makefile:837: check-TESTS] Error 2
make[2]: Leaving directory '/tmp/guix-build-libsigsegv-2.13.drv-0/libsigsegv-2.13/tests'
make[1]: *** [Makefile:966: check-am] Error 2
make[1]: Leaving directory '/tmp/guix-build-libsigsegv-2.13.drv-0/libsigsegv-2.13/tests'
make: *** [Makefile:432: check-recursive] Error 1

Test suite failed, dumping logs.

--- ./tests/test-suite.log --------------------------------------------------

===========================================
   libsigsegv 2.13: tests/test-suite.log
===========================================

# TOTAL: 5
# PASS:  3
# SKIP:  0
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

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)


error: in phase 'check': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("check" "-j" "16") exit-status: 2 term-signal: #f stop-signal: #f> 
phase `check' failed after 3.5 seconds
command "make" "check" "-j" "16" failed with status 2
builder for `/gnu/store/ww5bf6xz13wxjs1sjvjc2kmwq5mrjdj5-libsigsegv-2.13.drv' failed with exit code 1
@ build-failed /gnu/store/ww5bf6xz13wxjs1sjvjc2kmwq5mrjdj5-libsigsegv-2.13.drv - 1 builder for `/gnu/store/ww5bf6xz13wxjs1sjvjc2kmwq5mrjdj5-libsigsegv-2.13.drv' failed with exit code 1
cannot build derivation `/gnu/store/5pfnq2666wp2gg1h6yl0c92din8n24wc-gawk-5.1.0.drv': 1 dependencies couldn't be built

Greetings,
Maxime.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

bug#49509: libsigsegv fails to build on emulated aarch64 [core-updates]

[Ludovic Courtès]

Hi,

Maxime Devos <maximedevos@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.

Ludo’.

bug#49509: libsigsegv fails to build on emulated aarch64 [core-updates]

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 967 bytes --]

Ludovic Courtès schreef op zo 11-07-2021 om 00:19 [+0200]:
> Hi,
> 
> Maxime Devos <maximedevos@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.

If this is a bug in QEMU, then ideally that would be fixed in QEMU,
but I wouldn't know where to look.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

bug#49509: libsigsegv fails to build on emulated aarch64 [core-updates]

[Ludovic Courtès]

Hello,

Maxime Devos <maximedevos@telenet.be> skribis:

> Ludovic Courtès schreef op zo 11-07-2021 om 00:19 [+0200]:
>> Hi,
>> 
>> Maxime Devos <maximedevos@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-libsigsegv@gnu.org.

Thanks,
Ludo’.

bug#49509: libsigsegv fails to build on emulated aarch64 [core-updates]

[Sarah Morgensen]

Hi all,

Ludovic Courtès <ludo@gnu.org> writes:

> Hello,
>
> Maxime Devos <maximedevos@telenet.be> skribis:
>
>> Ludovic Courtès schreef op zo 11-07-2021 om 00:19 [+0200]:
>>> Hi,
>>> 
>>> Maxime Devos <maximedevos@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-libsigsegv@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

bug#49509: libsigsegv fails to build on emulated aarch64 [core-updates]

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 2650 bytes --]

On Wed, Sep 29, 2021 at 07:40:20PM -0700, Sarah Morgensen wrote:
> Hi all,
> 
> Ludovic Courtès <ludo@gnu.org> writes:
> 
> > Hello,
> >
> > Maxime Devos <maximedevos@telenet.be> skribis:
> >
> >> Ludovic Courtès schreef op zo 11-07-2021 om 00:19 [+0200]:
> >>> Hi,
> >>> 
> >>> Maxime Devos <maximedevos@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-libsigsegv@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.
> 

I came across this on x86_64 when using our qemu-binfmt service when
building for powerpc-linux too, and I'm pretty sure powerpc64le-linux
and armhf-linux also. I haven't tried going the other direction, from
aarch64-linux and emulating x86_64/i686 to see if it happens there too.

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#49509: libsigsegv fails to build on emulated aarch64 [core-updates]

[Ludovic Courtès]

Hi!

Sarah Morgensen <iskarian@mgsn.dev> skribis:

> 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?

Sounds like a good interim measure, for aarch64 and powerpc at least as
Efraim writes.

If you can come up with a patch, we could apply it in the upcoming
rebuild.

Thanks,
Ludo’.