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=... 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
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 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=...
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
Am 18. Juni 2025 16:34:09 MESZ schrieb Andreas Klebinger
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=... 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=...
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
participants (2)
-
Andreas Klebinger -
Heinrich Schuchardt