• Quick test on real hardware requested to test qemu

    From John Paul Adrian Glaubitz@21:1/5 to All on Tue Sep 22 15:10:01 2020
    Hi!

    Could someone install the "debfoster" command please on real hardware and test whether
    it crashes like it does on qemu?

    root@pacman:~# debfoster
    debfoster: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: AO_load: Assertion `((size_t)addr & (sizeof(*addr) - 1)) == 0' failed.
    Aborted
    root@pacman:~#

    Thanks,
    Adrian

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to John Paul Adrian Glaubitz on Tue Sep 22 15:30:01 2020
    On 9/22/20 3:24 PM, John Paul Adrian Glaubitz wrote:
    On 9/22/20 3:22 PM, Andreas Schwab wrote:
    On Sep 22 2020, John Paul Adrian Glaubitz wrote:

    root@pacman:~# debfoster
    debfoster: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: AO_load: Assertion `((size_t)addr & (sizeof(*addr) - 1)) == 0' failed.

    That a typical bad alignment check. It should use __alignof__, not
    sizeof.

    Aha, I was assuming something like that already but I wasn't sure since libatomic-ops wasn't
    updated for a while in Debian [1].

    What would be the correct check then in [1]?

    Adrian

    [1] https://github.com/ivmai/libatomic_ops/blob/master/src/atomic_ops/sysdeps/loadstore/atomic_load.h#L31

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to Andreas Schwab on Tue Sep 22 15:30:01 2020
    On 9/22/20 3:22 PM, Andreas Schwab wrote:
    On Sep 22 2020, John Paul Adrian Glaubitz wrote:

    root@pacman:~# debfoster
    debfoster: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: AO_load: Assertion `((size_t)addr & (sizeof(*addr) - 1)) == 0' failed.

    That a typical bad alignment check. It should use __alignof__, not
    sizeof.

    Aha, I was assuming something like that already but I wasn't sure since libatomic-ops wasn't
    updated for a while in Debian [1].

    Adrian

    [1] https://packages.qa.debian.org/liba/libatomic-ops.html

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Schwab@21:1/5 to John Paul Adrian Glaubitz on Tue Sep 22 16:00:01 2020
    On Sep 22 2020, John Paul Adrian Glaubitz wrote:

    root@pacman:~# debfoster
    debfoster: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: AO_load: Assertion `((size_t)addr & (sizeof(*addr) - 1)) == 0' failed.

    That a typical bad alignment check. It should use __alignof__, not
    sizeof.

    Andreas.

    --
    Andreas Schwab, schwab@linux-m68k.org
    GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
    "And now for something completely different."

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to John Paul Adrian Glaubitz on Tue Sep 22 18:10:01 2020
    On 9/22/20 5:23 PM, John Paul Adrian Glaubitz wrote:> On 9/22/20 3:27 PM, John Paul Adrian Glaubitz wrote:
    That a typical bad alignment check. It should use __alignof__, not
    sizeof.

    Aha, I was assuming something like that already but I wasn't sure since libatomic-ops wasn't
    updated for a while in Debian [1].

    What would be the correct check then in [1]?

    I was just re-reading the code and realized I'm dumb. Never mind.

    s/sizeof/__alignof__/ should help.

    Hmm, now it fails with __alignof__():

    (sid-m68k-sbuild)root@epyc:/# debfoster -f
    debfoster: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: AO_load: Assertion `((size_t)addr & (__alignof__(*addr) - 1)) == 0' failed.
    qemu: uncaught target signal 6 (Aborted) - core dumped
    Aborted
    (sid-m68k-sbuild)root@epyc:/#

    Adrian

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to John Paul Adrian Glaubitz on Tue Sep 22 17:30:01 2020
    On 9/22/20 3:27 PM, John Paul Adrian Glaubitz wrote:
    That a typical bad alignment check. It should use __alignof__, not
    sizeof.

    Aha, I was assuming something like that already but I wasn't sure since libatomic-ops wasn't
    updated for a while in Debian [1].

    What would be the correct check then in [1]?
    I was just re-reading the code and realized I'm dumb. Never mind.

    s/sizeof/__alignof__/ should help.

    Adrian

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Geert Uytterhoeven@21:1/5 to glaubitz@physik.fu-berlin.de on Tue Sep 22 19:30:01 2020
    Hi Adrian,

    On Tue, Sep 22, 2020 at 5:23 PM John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
    On 9/22/20 3:27 PM, John Paul Adrian Glaubitz wrote:
    That a typical bad alignment check. It should use __alignof__, not
    sizeof.

    Aha, I was assuming something like that already but I wasn't sure since libatomic-ops wasn't
    updated for a while in Debian [1].

    What would be the correct check then in [1]?
    I was just re-reading the code and realized I'm dumb. Never mind.

    s/sizeof/__alignof__/ should help.

    Are 32-bit accesses to an address of the form 4 * n + 2 atomic?

    Gr{oetje,eeting}s,

    Geert

    --
    Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

    In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
    -- Linus Torvalds

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stan Johnson@21:1/5 to John Paul Adrian Glaubitz on Tue Sep 22 22:00:02 2020
    On 9/22/20 10:06 AM, John Paul Adrian Glaubitz wrote:
    On 9/22/20 5:23 PM, John Paul Adrian Glaubitz wrote:> On 9/22/20 3:27 PM, John Paul Adrian Glaubitz wrote:
    That a typical bad alignment check. It should use __alignof__, not
    sizeof.

    Aha, I was assuming something like that already but I wasn't sure since libatomic-ops wasn't
    updated for a while in Debian [1].

    What would be the correct check then in [1]?

    I was just re-reading the code and realized I'm dumb. Never mind.

    s/sizeof/__alignof__/ should help.

    Hmm, now it fails with __alignof__():

    (sid-m68k-sbuild)root@epyc:/# debfoster -f
    debfoster: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: AO_load: Assertion `((size_t)addr & (__alignof__(*addr) - 1)) == 0' failed.
    qemu: uncaught target signal 6 (Aborted) - core dumped
    Aborted
    (sid-m68k-sbuild)root@epyc:/#

    Adrian


    On a Centris 650:

    # apt-get install debfoster
    Reading package lists... Done
    Building dependency tree
    Reading state information... Done
    The following additional packages will be installed:
    gcc-10-base libgc1 libgcc-s2
    The following NEW packages will be installed:
    debfoster gcc-10-base libgc1 libgcc-s2
    0 upgraded, 4 newly installed, 0 to remove and 108 not upgraded.
    Need to get 494 kB of archives.
    After this operation, 903 kB of additional disk space will be used.
    Do you want to continue? [Y/n]
    Get:1 http://ftp.ports.debian.org/debian-ports sid/main m68k gcc-10-base
    m68k 10.2.0-9 [199 kB]
    Get:2 http://ftp.ports.debian.org/debian-ports sid/main m68k libgcc-s2
    m68k 10.2.0-9 [25.6 kB]
    Get:3 http://ftp.ports.debian.org/debian-ports sid/main m68k libgc1 m68k 1:8.0.4-2 [235 kB]
    Get:4 http://ftp.ports.debian.org/debian-ports sid/main m68k debfoster
    m68k 2.7-2.1+b1 [33.8 kB]
    ...
    Installing debfoster had the following error:
    Unpacking libgcc-s2:m68k (10.2.0-9) ...
    dpkg: error processing archive /var/cache/apt/archives/libgcc-s2_10.2.0-9_m68k.deb (--unpack):
    trying to overwrite '/lib/m68k-linux-gnu/libgcc_s.so.2', which is also
    in package libgcc2:m68k 1:9.2.1-19
    ...

    And the executable failed:

    # debfoster
    debfoster: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31:
    AO_load: Assertion `((size_t)addr & (sizeof(*addr) - 1)) == 0' failed.
    Aborted

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to John Paul Adrian Glaubitz on Wed Sep 23 00:30:01 2020
    On 9/22/20 6:06 PM, John Paul Adrian Glaubitz wrote:
    Hmm, now it fails with __alignof__():

    (sid-m68k-sbuild)root@epyc:/# debfoster -f
    debfoster: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: AO_load: Assertion `((size_t)addr & (__alignof__(*addr) - 1)) == 0' failed.
    qemu: uncaught target signal 6 (Aborted) - core dumped
    Aborted
    (sid-m68k-sbuild)root@epyc:/#

    It's actually a bug in libgc and was fixed here [1].

    Adrian

    [1] https://github.com/ivmai/bdwgc/commit/b55459ad47d9aaa75c9a4b0f99a3b867592ab8e0

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)