RTS: mmap fails on RISC-V with Linux 6.8

[Heinrich Schuchardt]

Am 18. Juni 2025 16:34:09 MESZ schrieb Andreas Klebinger <klebinger.andreas at 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 at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs