1. Forum
  2. Usenet
  3. LINUX.DEBIAN.MAINT.EMACSE

  • Emacs 30.1 fails to build on 32-bit archs, "Pure Lisp storage overflow"

    From Sean Whitton@21:1/5 to All on Mon Feb 24 12:50:01 2025
    Hello,

    The new Emacs 30.1 fails to build on all of Debian's 32-bit release architectures, Intel and Arm.

    The failures look a little different in each case but in all three the
    string "Pure Lisp storage overflow" appears near the end of the log:

    armel: https://buildd.debian.org/status/fetch.php?pkg=emacs&arch=armel&ver=1%3A30.1%2B1-1&stamp=1740392779&raw=0
    armhf: https://buildd.debian.org/status/fetch.php?pkg=emacs&arch=armhf&ver=1%3A30.1%2B1-1&stamp=1740392697&raw=0
    i386: https://buildd.debian.org/status/fetch.php?pkg=emacs&arch=armhf&ver=1%3A30.1%2B1-1&stamp=1740392697&raw=0

    Any ideas?

    Thanks.

    --
    Sean Whitton

    --=-=-Content-Type: application/pgp-signature; name="signature.asc"

    -----BEGIN PGP SIGNATURE-----

    iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAme8WyQZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQB/ND/4wvxvX8U/a8UAhi0tyFBbc QqNcFTH46k8cU/Mi4lFtZRNNCJd/JPd9yJDXpkrmB7F3Im7+yLIPLbw4mKgibW6Y 4YzduUsv1rEJBEcpkb1IENHuzcYzONa7Xbjfd7LaHDZ1+nsb7lFgw+m75e00zjWX XKBIpe5vT+GOnoFfPXWu5L56nNcx5h5acsa1hnTredaz1Vb2E2OhEVUbVECEMd5L adP5o8U1CiR2Qxmf8p3jqnmde1NrRLws3iWcIR021Hici0rffZJ6cHCB0998TQBm amZs3dT/kCze5b6mwigBax0EEf/ScNTROKVxHYbRQpXDsYtOWRGnrEZNJPU8h2pm 3vNVP7IKhzwtXfnJpaYoD7XrbySh+Y4ol8Ytvx+kUyGJta37VcNJ5WpgfEoYFqk8 iWi284pc1/7y/vD8ZfI0mywI40XvEKiqmFMoXfC/cX9626vEHTo/xPQJqya8LhgF KoiaIXEjdd85JXN6qxCR8eUUEYtD9oklK/8Enpv2xTPa0bEWXq0kBl7EfKONGyCD 6LnfQxDYmLIVRCl3zoU0riUmApAHIwwIaCiDMTqxGwsEEusfMCd/GteHQ8e+uKE9 wrQLkjNQgrmlMwFASj4t/y4cBrHvFgqfn7zqZzXy0r/A3D+iVzrJh3IezU6Nw5NO G6yCLyvd/PhIWzdNYpACAg==8MiZ
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Us
  • From Sean Whitton@21:1/5 to Sean Whitton on Mon Feb 24 13:10:01 2025
    Hello,

    On Mon 24 Feb 2025 at 07:42pm +08, Sean Whitton wrote:

    The new Emacs 30.1 fails to build on all of Debian's 32-bit release architectures, Intel and Arm.

    The failures look a little different in each case but in all three the
    string "Pure Lisp storage overflow" appears near the end of the log:

    armel: https://buildd.debian.org/status/fetch.php?pkg=emacs&arch=armel&ver=1%3A30.1%2B1-1&stamp=1740392779&raw=0
    armhf: https://buildd.debian.org/status/fetch.php?pkg=emacs&arch=armhf&ver=1%3A30.1%2B1-1&stamp=1740392697&raw=0
    i386: https://buildd.debian.org/status/fetch.php?pkg=emacs&arch=armhf&ver=1%3A30.1%2B1-1&stamp=1740392697&raw=0

    Xiyue pointed me to #75907 -- thank you.

    I can boost the BASE_PURESIZE just on Debian's builds but does it make
    sense that we're hitting it sooner on 32-bit archs?

    --
    Sean Whitton

    --=-=-Content-Type: application/pgp-signature; name="signature.asc"

    -----BEGIN PGP SIGNATURE-----

    iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAme8X/IZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQAfMEACoLl2xEBclR/vJKxTezzw9 VxkrtJImQkrHUbH5TAhWVxHY+qa7tbWHiMkTQ3ozAnI1BgWjxkzB2zs4VgawlIH7 DzdAe0ADcTMAstcadz0zgrZeHj3zupIXrHBixZhABpbxrM1ggNdcPjya0xCWrmvL GNeFsMGa0m9ekWbHW/QtAVjMe9Bocy6xsgHQ8BxVPJFtLZYNpVslLRV2wv7FcFEc ICtvYsU+H8gj2435XXEesa4gOzpOSKWkfUdiv2UnFs5vRgKlwimPbi0MDN3NeQFy sQFAvtYZiISQAC294+3UHHGO/O5kMkQXrw7hoJZX4obuxWHCaqh/WTXHXhHqwfZe xrNh6+3BWdRF8GAgVAH6a657bNlVRh5CsSIoIAAe9zrQpol2PjiDdt8N+PVkX4W3 0s6PdTlxTR3L/ZwzP9Ww1nGuCfETu4xeRkLkvBusdGH5cTqadp76bf/UYb5F1nym fOQ3KUJD70lM2A1JPdq9SOW9U5H70UT6yI/cxdM3MbZkkjHl3WK5wXtzGUqXYD7c +JOznwyuznvEzLkmwk65+446FvwsrOU9R30xds+a5yjdC3AZz1fIY6D4UKeZc3Ag 7LLioc7/aEVYRARugscBtXBNaXwoNb604SsvW4Dc4vgMg8aTXC44GAHr8YP7R0Lx r6QaRiMDiF8tXnTUUgU5sw==SrlY
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Us
  • From Eli Zaretskii@21:1/5 to All on Mon Feb 24 15:10:01 2025
    From: Sean Whitton <spwhitton@spwhitton.name>
    Cc: debian-emacsen@lists.debian.org
    Date: Mon, 24 Feb 2025 20:02:58 +0800


    On Mon 24 Feb 2025 at 07:42pm +08, Sean Whitton wrote:

    The new Emacs 30.1 fails to build on all of Debian's 32-bit release architectures, Intel and Arm.

    The failures look a little different in each case but in all three the string "Pure Lisp storage overflow" appears near the end of the log:

    armel: https://buildd.debian.org/status/fetch.php?pkg=emacs&arch=armel&ver=1%3A30.1%2B1-1&stamp=1740392779&raw=0
    armhf: https://buildd.debian.org/status/fetch.php?pkg=emacs&arch=armhf&ver=1%3A30.1%2B1-1&stamp=1740392697&raw=0
    i386: https://buildd.debian.org/status/fetch.php?pkg=emacs&arch=armhf&ver=1%3A30.1%2B1-1&stamp=1740392697&raw=0

    Xiyue pointed me to #75907 -- thank you.

    I can boost the BASE_PURESIZE just on Debian's builds but does it make
    sense that we're hitting it sooner on 32-bit archs?

    The actual use of pure space depends on the length of the file names
    involved in the build, so if you build in a deeper directory, it could overflow.

    Also, are you building the original release tarballs, and only with
    "configure && make -jN", or are you building using some different
    procedure? That could also explain the overflow.

    By how much do you need to enlarge to make the builds succeed?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sean Whitton@21:1/5 to Eli Zaretskii on Tue Feb 25 02:20:01 2025
    Hello,

    On Mon 24 Feb 2025 at 03:47pm +02, Eli Zaretskii wrote:

    The actual use of pure space depends on the length of the file names
    involved in the build, so if you build in a deeper directory, it could overflow.

    We do use deeper directories, but no deeper on 32-bit than 64-bit.

    Also, are you building the original release tarballs,

    We use the emacs-30.1 git tag, not tarballs, if that's relevant.

    and only with "configure && make -jN", or are you building using some different procedure? That could also explain the overflow.

    Pretty much just that, yes. (We do autotools reconf first.)

    By how much do you need to enlarge to make the builds succeed?

    3400000->4500000 seems to do the trick, based on the error messages
    asking for roughly 4.3MB.

    --
    Sean Whitton

    --=-=-Content-Type: application/pgp-signature; name="signature.asc"

    -----BEGIN PGP SIGNATURE-----

    iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAme9GjEZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQLtbEACYCLoV/VoqZAy3Xo5Wk4ps c9of/MPIypSlI1Fffw1YHLl0CPR8QmvJMCJCVyJj2whM8pCeAaJGBjYFzLMYLFa1 HNOkJybET0GzvB/suvsGjT+XfMSTN7SY6X1dyqONnz8scJr5BOlv3NaKQziS/gFm 8r04AnwxZXZLbxyaPyrmCZIc2UU0aAizNjlN6zno6wn1QU39DYruGQxbt5WyijdK KFPKA3ecDpdMrVXGfrOS/UcyuLNWd4U4iZ09IPJSHoqbjF+CfFQHVsBwD+MoUqXj W8OZikd/nVA+1h+c+AhH5dklCy9Z1qvnejpqjVrVoPviXq0rkBOgP35prcXxaYU+ 0zEjcKv6uJACNIUh5S7mIZzxypgZL99i739AMnPzDa0cUiguxhq4I0ra7yPVkVa4 iMMiMXXXkL2aF6M/Kxf8xYINt82NfuYXlLiDS4WlYzldIybLeXaQ3fiis2tIj4Bz 6UkamLabekZtGjsHD0kD8dziFwEphnJLG7fX3UoW3Hpm4UvBnRB00rIN889PJMOk Ec0knmkl5wUSCH6JNJ1EGFhABljxya/PiHDVLxgjL/ZRF35XrjKQGbyrTC2GPjEK ZEgMgNer7yZJpjSuvUosbbVSlAKDo9q9fl8wJ49yDIr/nMwUD0oE5kdgM6S4WsKN laevOnXXROem5NGpd+ossA==DiZQ
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Us
  • From Peter Oliver@21:1/5 to Sean Whitton on Tue Feb 25 12:20:01 2025
    This message is in MIME format. The first part should be readable text,
    while the remaining parts are likely unreadable without MIME-aware tools.

    On Mon, 24 Feb 2025, Sean Whitton wrote:

    The new Emacs 30.1 fails to build on all of Debian's 32-bit release architectures, Intel and Arm.

    IĒm not sure if this helps, but we donĒt see this issue on Fedora, so we must be doing something differently.

    https://koji.fedoraproject.org/koji/taskinfo?taskID=129594050

    --
    Peter Oliver

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eli Zaretskii@21:1/5 to All on Tue Feb 25 17:20:01 2025
    From: Xiyue Deng <manphiz@gmail.com>
    Cc: emacs-devel@gnu.org, debian-emacsen@lists.debian.org
    Date: Mon, 24 Feb 2025 16:37:53 -0800

    By how much do you need to enlarge to make the builds succeed?


    FTR in the log of Debian armhf buildd[1] there is a line says:

    ,----
    | emacs:0:Pure Lisp storage overflow (approx. 4546239 bytes needed)
    `----

    I tested that increasing the base value to 4500000 worked on i386 (patch attached). Also tested that 4M was not large enough. Sean is also
    testing 45 * 1024 * 1024 on 32-bit arm* buildds.

    Is this the smallest number that works? E.g., does 4000000 also work
    or does it fail?

    Though 4.5M is probably sufficient for now, I wonder whether it's
    acceptable to further increase this to 5000000 to be more future proof?

    We didn't yet have enough complaints about puresize to justify that.

    On the other hand, I see there are threads on emacs-devel talking about removing pure space. Is that referring to this pure lisp storage?

    Yes, we recently removed pure space on master.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sean Whitton@21:1/5 to Eli Zaretskii on Wed Feb 26 12:10:01 2025
    Hello,

    On Tue 25 Feb 2025 at 05:58pm +02, Eli Zaretskii wrote:

    From: Sean Whitton <spwhitton@spwhitton.name>
    Cc: emacs-devel@gnu.org, debian-emacsen@lists.debian.org
    Date: Tue, 25 Feb 2025 09:17:37 +0800

    Also, are you building the original release tarballs,

    We use the emacs-30.1 git tag, not tarballs, if that's relevant.

    It might be relevant, yes. Does building the release tarball work
    without increasing the puresize on the same architecture?

    Doing a pure 'cd emacs-30.1 && make' does not reproduce the problem.

    I could try to attach our build scripts to the tarball rather than to
    git, but given how pure space is going away, and Fedora don't see this
    problem, I'm not sure it's worth the time.

    3400000->4500000 seems to do the trick, based on the error messages
    asking for roughly 4.3MB.

    The number it is asking for is not directly usable as BASE_PURESIZE,
    because Emacs then performs all kinds of juggling with that before it determines the size of the array. See puresize.h.

    True.

    --
    Sean Whitton

    --=-=-Content-Type: application/pgp-signature; name="signature.asc"

    -----BEGIN PGP SIGNATURE-----

    iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAme+9P0ZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQJ3aEACdc24FgRwnszpEeVt15DJS s8AdIOaH3OQD0ISUuIan3UDN0EofwH6Ejk2qfvhx8w709wr7wWN3f9hMHz6WmVpx tqlMk5L2yHGgUAQdiHwk0DpwltKM6M/41F6RUNHbqQVx0r9rxiTZr2KZOtyynGXn o4wffpmUXzeYLoe70kISFeZd48RZCQiNzptCODEaKhxPpO/a9D+QybpCro4HfO+e e3kx7+z1dGtwNz63891E/xAKDBY58uNaHIvMywxe/vmXKW+Tu3SG9ZuOMrWzT50H r1mF8eIPIkbOTVE/Nt4tpOUvcJ9btIiTDca3LIq4yb7RBtAJODV9RyuXvnhOW39G H7Mlm9Z+Kv+gS5C72rRByeKtRzJiXB+WZ+HkC4Oc/4l2XWroC3rcc0m7+lj66Dml uyPCqG3HnTG06wFWJcwgpW1sfLhB4liBQLxrqrlU/qicuQphCiL4G/Rgx4ZEGLH6 aR8b0eukSDckenAx4uZB2MMBHxQCJZNaIyef4bQttKMKG0QeEl/ZLjYy94KnWnHi YxPddySZ+1h3Lk3pUWIOqy46GErGdLwTwON07lbK3QKDhIDl3DNMN7e3yVoOemqI 8Il3outTthArioWlNgcW6AOOv2L1MQdeImJmvP4LcU73M/ccAvVN3K0O267JbQI4 MfxjqrIdt1wKh2q48WW1mA==0vwb
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Us
  • From Eli Zaretskii@21:1/5 to All on Wed Feb 26 15:30:02 2025
    From: Sean Whitton <spwhitton@spwhitton.name>
    Cc: emacs-devel@gnu.org, debian-emacsen@lists.debian.org
    Date: Wed, 26 Feb 2025 19:03:25 +0800

    Also, are you building the original release tarballs,

    We use the emacs-30.1 git tag, not tarballs, if that's relevant.

    It might be relevant, yes. Does building the release tarball work
    without increasing the puresize on the same architecture?

    Doing a pure 'cd emacs-30.1 && make' does not reproduce the problem.

    Yes, I thought it might.

    I could try to attach our build scripts to the tarball rather than to
    git, but given how pure space is going away, and Fedora don't see this problem, I'm not sure it's worth the time.

    It isn't.

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