GNU bug report logs - #45214
guile segfaults on 32-bit big-endian targets

Previous Next

Package: guile;

Reported by: John Paul Adrian Glaubitz <glaubitz <at> physik.fu-berlin.de>

Date: Sat, 12 Dec 2020 21:27:01 UTC

Severity: normal

Full log


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

From: John David Anglin <dave.anglin <at> bell.net>
To: John Paul Adrian Glaubitz <glaubitz <at> physik.fu-berlin.de>, bug-guile <at> gnu.org
Subject: Re: guile segfaults on 32-bit big-endian targets
Date: Mon, 8 Feb 2021 18:24:58 -0500
On 2020-12-12 5:21 p.m., John David Anglin wrote:
> On 2020-12-12 4:26 p.m., John Paul Adrian Glaubitz wrote:
>> I assume the crash has got something to do how values are packed and unpacked
>> into the SCM object type. I have not been able to find the problem yet myself,
>> unfortunately which is why I am reporting this issue here.
> I see this in scm.h:
>
> /* The 0?: constructions makes sure that the code is never executed, and
>    that there is no performance hit.  However, the alternative is
>    compiled, and does generate a warning when used with the wrong
>    pointer type.  We use a volatile pointer type to avoid warnings from
>    clang.
>
>    The Tru64 and ia64-hp-hpux11.23 compilers fail on `case (0?0=0:x)'
>    statements, so for them type-checking is disabled.  */
> # if defined __DECC || defined __HP_cc
> #  define SCM_UNPACK(x) ((scm_t_bits) (x))
> # else
> #  define SCM_UNPACK(x) ((scm_t_bits) (0? (*(volatile SCM *)0=(x)): x))
> # endif
I don't believe this is a problem.

We need to investigate why scm_sum is passed "x=x <at> entry=0x0".   SCM_BIGP (x) will fault on it.   Maybe SP_REF is broken.

Regards,
Dave

-- 
John David Anglin  dave.anglin <at> bell.net






This bug report was last modified 3 years and 255 days ago.

Previous Next


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