GNU bug report logs - #49509
libsigsegv fails to build on emulated aarch64 [core-updates]

Previous Next

To reply to this bug, email your comments to 49509 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: bug-guix <at> gnu.org
Subject: libsigsegv fails to build on emulated aarch64 [core-updates]
Date: Sat, 10 Jul 2021 20:07:27 +0200

[Message part 1 (text/plain, inline)]

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.

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 49509 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: 49509 <at> debbugs.gnu.org
Subject: Re: bug#49509: libsigsegv fails to build on emulated aarch64
 [core-updates]
Date: Sun, 11 Jul 2021 00:19:00 +0200

Hi,

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

Message #11 received at 49509 <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 49509 <at> debbugs.gnu.org
Subject: Re: bug#49509: libsigsegv fails to build on emulated aarch64
 [core-updates]
Date: Sun, 11 Jul 2021 16:11:38 +0200

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, inline)]

Message #14 received at 49509 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: 49509 <at> debbugs.gnu.org
Subject: Re: bug#49509: libsigsegv fails to build on emulated aarch64
 [core-updates]
Date: Sun, 11 Jul 2021 18:13:54 +0200

Hello,

Maxime Devos <maximedevos <at> telenet.be> skribis:

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

Thanks,
Ludo’.

Message #17 received at 49509 <at> debbugs.gnu.org (full text, mbox):

From: Sarah Morgensen <iskarian <at> mgsn.dev>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 49509 <at> debbugs.gnu.org, Maxime Devos <maximedevos <at> telenet.be>
Subject: Re: bug#49509: libsigsegv fails to build on emulated aarch64
 [core-updates]
Date: Wed, 29 Sep 2021 19:40:20 -0700

Hi all,

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

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

Message #20 received at 49509 <at> debbugs.gnu.org (full text, mbox):

From: Efraim Flashner <efraim <at> flashner.co.il>
To: Sarah Morgensen <iskarian <at> mgsn.dev>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 49509 <at> debbugs.gnu.org
Subject: Re: bug#49509: libsigsegv fails to build on emulated aarch64
 [core-updates]
Date: Thu, 30 Sep 2021 11:37:36 +0300

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, inline)]

Message #23 received at 49509 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Sarah Morgensen <iskarian <at> mgsn.dev>
Cc: 49509 <at> debbugs.gnu.org, Maxime Devos <maximedevos <at> telenet.be>
Subject: Re: bug#49509: libsigsegv fails to build on emulated aarch64
 [core-updates]
Date: Thu, 30 Sep 2021 22:20:19 +0200

Hi!

Sarah Morgensen <iskarian <at> 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’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.