Am 18. Juni 2025 16:34:09 MESZ schrieb Andreas Klebinger <klebinger.andr...@gmx.at>: >There have been changes to upstream that likely fixes this. > >See https://gitlab.haskell.org/ghc/ghc/-/issues/25492 > >If you can reproduce this issue using a ghc build base of a recent ghc master >version please let us know! > >Cheers
The loop in <https://gitlab.haskell.org/ghc/ghc/-/blob/master/rts/posix/OSMem.c?ref_type=heads#L589> is still the same as what failed when I reported the issue. The loop has not changed within the last 4 years. If mmap() consistently returns an address below 8GiB, the code loops forever. Best regards Heinrich > >On 27/05/2025 20:35, Heinrich Schuchardt via ghc-devs wrote: > >> The following bug related to the Haskell runtime was reported in Launchpad: >> >> Haskell's default behaviour of using large-address-space is causing pandoc >> to stuck in an infinite loop on QEMU 10 Edit >> https://bugs.launchpad.net/ubuntu/+source/ghc/+bug/2111581 >> >> The problem seems to relate to the following loop in osReserveHeapMemory(): >> >> https://gitlab.haskell.org/ghc/ghc/-/blob/master/rts/posix/OSMem.c?ref_type=heads#L589 >> >> >> According to the mmap() manpage the address passed to the kernel in only a >> hint there is no guarantee that the same address will be used for allocation. >> >> As shown in the strace logs attached in Launchpad this code can lead to an >> endless loop when the kernel decides always to return an address below 8 GiB. >> >> It might make sense to round up the address to 8 GiB if the returned address >> is below 8 GiB and reduce *len accordingly instead of retrying. >> >> Best regards >> >> Heinrich >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
