From ben at smart-cactus.org  Wed Jun  4 01:27:19 2025
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 03 Jun 2025 21:27:19 -0400
Subject: Features for GHC 9.14?
Message-ID: <87zfeo8few.fsf@smart-cactus.org>

Hi all,

I am currently putting together the GHC status talk for this year's HIW.
Do let me know if you anticipate merging any features for the coming
9.14 release which you haven't yet put on GitLab.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250603/f6f9b2eb/attachment.sig>

From matthewtpickering at gmail.com  Wed Jun  4 08:15:54 2025
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Wed, 4 Jun 2025 09:15:54 +0100
Subject: Features for GHC 9.14?
In-Reply-To: <87zfeo8few.fsf@smart-cactus.org>
References: <87zfeo8few.fsf@smart-cactus.org>
Message-ID: <CALuQ0m-B5BJCewtCMyHSF5euBeXs1XHZn2p=d04C94EvKzqBcQ@mail.gmail.com>

Hi Ben,

Can you clarify what date in July the release is scheduled for?

I think we have managed to merge the significant features which were
targeted for this release.

* Explicit Level Imports (Matt)
* Debugger Improvements (Rodrigo)
* MHU GHCi Support (Hannes)
* Improved Prinop Performance in the Interpreter (Andreas)

Cheers,

Matt

On Wed, Jun 4, 2025 at 2:27 AM Ben Gamari via ghc-devs <ghc-devs at haskell.org>
wrote:

> Hi all,
>
> I am currently putting together the GHC status talk for this year's HIW.
> Do let me know if you anticipate merging any features for the coming
> 9.14 release which you haven't yet put on GitLab.
>
> Cheers,
>
> - Ben
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250604/8160b221/attachment.html>

From george.colpitts at gmail.com  Wed Jun  4 11:16:42 2025
From: george.colpitts at gmail.com (George Colpitts)
Date: Wed, 4 Jun 2025 08:16:42 -0300
Subject: Features for GHC 9.14?
In-Reply-To: <CALuQ0m-B5BJCewtCMyHSF5euBeXs1XHZn2p=d04C94EvKzqBcQ@mail.gmail.com>
References: <87zfeo8few.fsf@smart-cactus.org>
 <CALuQ0m-B5BJCewtCMyHSF5euBeXs1XHZn2p=d04C94EvKzqBcQ@mail.gmail.com>
Message-ID: <CAB-d4A6jfLtZai4Du4c-qcDd+n-7XJ6ensALq-_pmP8-KpvMVQ@mail.gmail.com>

According to https://gitlab.haskell.org/ghc/ghc/-/milestones/400#tab-issues
the final release is scheduled for September.

Will we be supporting llvm 20?

On Wed, Jun 4, 2025 at 5:16 AM Matthew Pickering <
matthewtpickering at gmail.com> wrote:

> Hi Ben,
>
> Can you clarify what date in July the release is scheduled for?
>
> I think we have managed to merge the significant features which were
> targeted for this release.
>
> * Explicit Level Imports (Matt)
> * Debugger Improvements (Rodrigo)
> * MHU GHCi Support (Hannes)
> * Improved Prinop Performance in the Interpreter (Andreas)
>
> Cheers,
>
> Matt
>
> On Wed, Jun 4, 2025 at 2:27 AM Ben Gamari via ghc-devs <
> ghc-devs at haskell.org> wrote:
>
>> Hi all,
>>
>> I am currently putting together the GHC status talk for this year's HIW.
>> Do let me know if you anticipate merging any features for the coming
>> 9.14 release which you haven't yet put on GitLab.
>>
>> Cheers,
>>
>> - Ben
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250604/e74da222/attachment.html>

From ben at smart-cactus.org  Wed Jun  4 16:17:33 2025
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 04 Jun 2025 12:17:33 -0400
Subject: Features for GHC 9.14?
In-Reply-To: <CAB-d4A6jfLtZai4Du4c-qcDd+n-7XJ6ensALq-_pmP8-KpvMVQ@mail.gmail.com>
References: <87zfeo8few.fsf@smart-cactus.org>
 <CALuQ0m-B5BJCewtCMyHSF5euBeXs1XHZn2p=d04C94EvKzqBcQ@mail.gmail.com>
 <CAB-d4A6jfLtZai4Du4c-qcDd+n-7XJ6ensALq-_pmP8-KpvMVQ@mail.gmail.com>
Message-ID: <87wm9r8orp.fsf@smart-cactus.org>

George Colpitts <george.colpitts at gmail.com> writes:

> According to https://gitlab.haskell.org/ghc/ghc/-/milestones/400#tab-issues
> the final release is scheduled for September.
>
> Will we be supporting llvm 20?
>
Yes, we will likely enable LLVM 20 support.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250604/d212f5bb/attachment.sig>

From ben at smart-cactus.org  Wed Jun  4 16:18:55 2025
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 04 Jun 2025 12:18:55 -0400
Subject: Features for GHC 9.14?
In-Reply-To: <CALuQ0m-B5BJCewtCMyHSF5euBeXs1XHZn2p=d04C94EvKzqBcQ@mail.gmail.com>
References: <87zfeo8few.fsf@smart-cactus.org>
 <CALuQ0m-B5BJCewtCMyHSF5euBeXs1XHZn2p=d04C94EvKzqBcQ@mail.gmail.com>
Message-ID: <87tt4v8opc.fsf@smart-cactus.org>

Matthew Pickering <matthewtpickering at gmail.com> writes:

> Hi Ben,
>
> Can you clarify what date in July the release is scheduled for?
>
Indeed the preliminary schedule previously given in the milestone is not
realistic at this point. I have updated the schedule to a more realistic
September date as I hope to fork soon after we return from Zurihac.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250604/61957c5a/attachment.sig>

From ben at well-typed.com  Thu Jun 12 22:53:37 2025
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 12 Jun 2025 18:53:37 -0400
Subject: GHC 9.14 fork status
Message-ID: <877c1g8tch.fsf@smart-cactus.org>

Hi all,

As those of you at Zurihac may know, we are currently in the process of
preparing for the GHC 9.14 fork. This week I have been working through
the various necessary core library version bumps and submodule changes.
My hope is that we can land this work early next week and declare the
fork at some point in the days that follow.

I am aware of a few things that we want to land prior to forking:

 * @int-index's !14136 (Visible forall in GADTs)
 * testing and enabling of LLVM 20 support
 * an update of win32-tarballs
 * Cheng's libffi update (!14392)

If you have any further work that you would like to see in 9.14 please
do let me know by next Wednesday.

If all goes well, my hope is that we can have our first alpha out by the
end of this month, with an eye towards a final release in early
September.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250612/79c14de7/attachment.sig>

From ben at well-typed.com  Thu Jun 12 22:42:41 2025
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 12 Jun 2025 18:42:41 -0400
Subject: GHC 9.14 boot library status
Message-ID: <878qlw8tuq.fsf@smart-cactus.org>

Hi all,

This week I have been pushing through submodule updates and bounds
bumps in preparation for the fork of the GHC 9.14 release. Today I have
opened merge requests against those boot libraries which will require
changes to integrate into 9.14; thankfully, it appears that these
changes are all limited to bounds bumps this cycle.

In keeping with our release management policy [1], I have updated GHC's
submodules to reflect the current releases present on Hackage. I have
also updated the submodule tracking spreadsheet [2] to reflect the
expected boot library versions on release. Please have a look over the
spreadsheet and if you would like to see anything changed here, update
it accordingly at some point in the next few weeks.

As always, thanks for your efforts!

Cheers,

- Ben


[1] https://gitlab.haskell.org/ghc/ghc-hq/-/blob/main/release-management.mkd?ref_type=heads
[2] https://docs.google.com/spreadsheets/d/19WeWjXPh8Q64qoe3fjs8AswpTHk6uLBD8WG-7R97a1U/edit?gid=343507833#gid=343507833
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250612/86a3d942/attachment.sig>

From a.pelenitsyn at gmail.com  Thu Jun 12 23:16:26 2025
From: a.pelenitsyn at gmail.com (Artem Pelenitsyn)
Date: Thu, 12 Jun 2025 19:16:26 -0400
Subject: GHC 9.14 boot library status
In-Reply-To: <878qlw8tuq.fsf@smart-cactus.org>
References: <878qlw8tuq.fsf@smart-cactus.org>
Message-ID: <CAPKAvQWr5aUOMQv_yS_7K4PPeHEFTNE7iPKSob+EV5qV==s1=g@mail.gmail.com>

Hi Ben,

In the spreadsheet, Cabal says desired version 3.15.0.0, while it should be
3.16.0.0 I believe: Cabal reserves odd numbers for development versions.

Thanks for all your hard work!

--
Best, Artem

On Thu, Jun 12, 2025, 7:00 PM Ben Gamari <ben at well-typed.com> wrote:

> Hi all,
>
> This week I have been pushing through submodule updates and bounds
> bumps in preparation for the fork of the GHC 9.14 release. Today I have
> opened merge requests against those boot libraries which will require
> changes to integrate into 9.14; thankfully, it appears that these
> changes are all limited to bounds bumps this cycle.
>
> In keeping with our release management policy [1], I have updated GHC's
> submodules to reflect the current releases present on Hackage. I have
> also updated the submodule tracking spreadsheet [2] to reflect the
> expected boot library versions on release. Please have a look over the
> spreadsheet and if you would like to see anything changed here, update
> it accordingly at some point in the next few weeks.
>
> As always, thanks for your efforts!
>
> Cheers,
>
> - Ben
>
>
> [1]
> https://gitlab.haskell.org/ghc/ghc-hq/-/blob/main/release-management.mkd?ref_type=heads
> [2]
> https://docs.google.com/spreadsheets/d/19WeWjXPh8Q64qoe3fjs8AswpTHk6uLBD8WG-7R97a1U/edit?gid=343507833#gid=343507833
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250612/5ddae4ef/attachment.html>

From ben at well-typed.com  Thu Jun 12 23:48:11 2025
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 12 Jun 2025 19:48:11 -0400
Subject: GHC 9.14 boot library status
In-Reply-To: <CAPKAvQWr5aUOMQv_yS_7K4PPeHEFTNE7iPKSob+EV5qV==s1=g@mail.gmail.com>
References: <878qlw8tuq.fsf@smart-cactus.org>
 <CAPKAvQWr5aUOMQv_yS_7K4PPeHEFTNE7iPKSob+EV5qV==s1=g@mail.gmail.com>
Message-ID: <871pro8qtk.fsf@smart-cactus.org>

Artem Pelenitsyn <a.pelenitsyn at gmail.com> writes:

> Hi Ben,
>
> In the spreadsheet, Cabal says desired version 3.15.0.0, while it should be
> 3.16.0.0 I believe: Cabal reserves odd numbers for development versions.
>
Sigh, yes, quite right. Thanks for noticing!

Fixed.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250612/f78dccbe/attachment.sig>

From matthewtpickering at gmail.com  Fri Jun 13 09:01:53 2025
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Fri, 13 Jun 2025 10:01:53 +0100
Subject: GHC 9.14 fork status
In-Reply-To: <877c1g8tch.fsf@smart-cactus.org>
References: <877c1g8tch.fsf@smart-cactus.org>
Message-ID: <CALuQ0m9bVtCdzSjBYFhb024VCjLzV6txRffpi8d9S5Bz3LiE2w@mail.gmail.com>

Hi Ben,

Can we land the following patches:

* https://gitlab.haskell.org/ghc/ghc/-/merge_requests/14183
* https://gitlab.haskell.org/ghc/ghc/-/merge_requests/14321
* https://gitlab.haskell.org/ghc/ghc/-/merge_requests/14377

If someone could help landing #14183, that would be good.

Matt

On Thu, Jun 12, 2025 at 11:53 PM Ben Gamari <ben at well-typed.com> wrote:

> Hi all,
>
> As those of you at Zurihac may know, we are currently in the process of
> preparing for the GHC 9.14 fork. This week I have been working through
> the various necessary core library version bumps and submodule changes.
> My hope is that we can land this work early next week and declare the
> fork at some point in the days that follow.
>
> I am aware of a few things that we want to land prior to forking:
>
>  * @int-index's !14136 (Visible forall in GADTs)
>  * testing and enabling of LLVM 20 support
>  * an update of win32-tarballs
>  * Cheng's libffi update (!14392)
>
> If you have any further work that you would like to see in 9.14 please
> do let me know by next Wednesday.
>
> If all goes well, my hope is that we can have our first alpha out by the
> end of this month, with an eye towards a final release in early
> September.
>
> Cheers,
>
> - Ben
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250613/cde79c61/attachment.html>

From ben at well-typed.com  Mon Jun 16 21:04:00 2025
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 16 Jun 2025 17:04:00 -0400
Subject: Placing GitLab behind Anubis
Message-ID: <87frfz760y.fsf@smart-cactus.org>

Hi all,

As you may know, for the last few years we have used a variety of
strategies for dealing with the problem of abuse and spam on
gitlab.haskell.org. The currently-employed and seemingly most effective
technique has been to require manual approval of new account requests.

This has always been an uneasy compromise. Not only does this approval
process add considerable friction to the contribution process, the
increasing prevalence of ill-behaved web crawlers has rendered the
approach less and less effective at prevent that form of abuse.

For this reason we now exploring alternative approaches. One promising
strategy employed by other FOSS GitLab deployments (e.g.
gitlab.freedesktop.org) is the Anubis proof-of-work system. Anubis works
by forcing the client to perform a small (but non-negligible) amount of
work before requests are serviced. This will mean that GitLab users'
clients will periodically be asked to perform small amounts of work.
While Anubis primarily targets crawlers, it may be that the slight
increase in per-request cost might also allow us to lift our manual
account approval requirement.

Ultimately, the only way to find out is to try. If there are no
objections, I will place Anubis in front of GitLab starting next week.
During this process we will assess the effectiveness of Anubis at
prevent both spam and over-zealous crawlers. This may require a bit of
iterative parameter tuning but I am hopeful that the end result might be
a more accessible and faster GitLab instance for us all.

Let me know what you think.

Cheers,

- Ben


[1] https://github.com/TecharoHQ/anubis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250616/93bc3917/attachment.sig>

From mark at ploeh.dk  Tue Jun 17 05:27:41 2025
From: mark at ploeh.dk (Mark Seemann)
Date: Tue, 17 Jun 2025 05:27:41 +0000
Subject: Placing GitLab behind Anubis
In-Reply-To: <87frfz760y.fsf@smart-cactus.org>
References: <87frfz760y.fsf@smart-cactus.org>
Message-ID: <DBBPR04MB79647219026FACA0B2C4E78DB073A@DBBPR04MB7964.eurprd04.prod.outlook.com>

Hi

I'm currently just a lurker here, so my opinion may not count as much as those who actually contribute, but perhaps other readers have the same questions as I do.

- What does 'small' mean? Are we talking about a second of work, minutes, hours?
- Do clients need to install custom software to interact, or is that work done via existing protocols?

TIA

Mark Seemann

-----Original Message-----
From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Ben Gamari
Sent: 16. juni 2025 23:04
To: GHC developers <ghc-devs at haskell.org>
Subject: Placing GitLab behind Anubis

Hi all,

As you may know, for the last few years we have used a variety of strategies for dealing with the problem of abuse and spam on gitlab.haskell.org. The currently-employed and seemingly most effective technique has been to require manual approval of new account requests.

This has always been an uneasy compromise. Not only does this approval process add considerable friction to the contribution process, the increasing prevalence of ill-behaved web crawlers has rendered the approach less and less effective at prevent that form of abuse.

For this reason we now exploring alternative approaches. One promising strategy employed by other FOSS GitLab deployments (e.g.
gitlab.freedesktop.org) is the Anubis proof-of-work system. Anubis works by forcing the client to perform a small (but non-negligible) amount of work before requests are serviced. This will mean that GitLab users'
clients will periodically be asked to perform small amounts of work.
While Anubis primarily targets crawlers, it may be that the slight increase in per-request cost might also allow us to lift our manual account approval requirement.

Ultimately, the only way to find out is to try. If there are no objections, I will place Anubis in front of GitLab starting next week.
During this process we will assess the effectiveness of Anubis at prevent both spam and over-zealous crawlers. This may require a bit of iterative parameter tuning but I am hopeful that the end result might be a more accessible and faster GitLab instance for us all.

Let me know what you think.

Cheers,

- Ben


[1] https://github.com/TecharoHQ/anubis

From hecate at glitchbra.in  Tue Jun 17 05:50:53 2025
From: hecate at glitchbra.in (=?ISO-8859-1?Q?H=E9cate?=)
Date: Tue, 17 Jun 2025 07:50:53 +0200
Subject: Placing GitLab behind Anubis
In-Reply-To: <DBBPR04MB79647219026FACA0B2C4E78DB073A@DBBPR04MB7964.eurprd04.prod.outlook.com>
References: <87frfz760y.fsf@smart-cactus.org>
 <DBBPR04MB79647219026FACA0B2C4E78DB073A@DBBPR04MB7964.eurprd04.prod.outlook.com>
Message-ID: <0455998C-2CDC-4C88-BC81-B8413AB656D7@glitchbra.in>

From experience it takes a couple of seconds and it's just client JS.

Le 17 juin 2025 07:27:41 GMT+02:00, Mark Seemann <mark at ploeh.dk> a écrit :
>Hi
>
>I'm currently just a lurker here, so my opinion may not count as much as those who actually contribute, but perhaps other readers have the same questions as I do.
>
>- What does 'small' mean? Are we talking about a second of work, minutes, hours?
>- Do clients need to install custom software to interact, or is that work done via existing protocols?
>
>TIA
>
>Mark Seemann
>
>-----Original Message-----
>From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Ben Gamari
>Sent: 16. juni 2025 23:04
>To: GHC developers <ghc-devs at haskell.org>
>Subject: Placing GitLab behind Anubis
>
>Hi all,
>
>As you may know, for the last few years we have used a variety of strategies for dealing with the problem of abuse and spam on gitlab.haskell.org. The currently-employed and seemingly most effective technique has been to require manual approval of new account requests.
>
>This has always been an uneasy compromise. Not only does this approval process add considerable friction to the contribution process, the increasing prevalence of ill-behaved web crawlers has rendered the approach less and less effective at prevent that form of abuse.
>
>For this reason we now exploring alternative approaches. One promising strategy employed by other FOSS GitLab deployments (e.g.
>gitlab.freedesktop.org) is the Anubis proof-of-work system. Anubis works by forcing the client to perform a small (but non-negligible) amount of work before requests are serviced. This will mean that GitLab users'
>clients will periodically be asked to perform small amounts of work.
>While Anubis primarily targets crawlers, it may be that the slight increase in per-request cost might also allow us to lift our manual account approval requirement.
>
>Ultimately, the only way to find out is to try. If there are no objections, I will place Anubis in front of GitLab starting next week.
>During this process we will assess the effectiveness of Anubis at prevent both spam and over-zealous crawlers. This may require a bit of iterative parameter tuning but I am hopeful that the end result might be a more accessible and faster GitLab instance for us all.
>
>Let me know what you think.
>
>Cheers,
>
>- Ben
>
>
>[1] https://github.com/TecharoHQ/anubis
>_______________________________________________
>ghc-devs mailing list
>ghc-devs at haskell.org
>http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250617/d23ce386/attachment.html>

From ben at smart-cactus.org  Tue Jun 17 12:51:58 2025
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 17 Jun 2025 08:51:58 -0400
Subject: Placing GitLab behind Anubis
In-Reply-To: <0455998C-2CDC-4C88-BC81-B8413AB656D7@glitchbra.in>
References: <87frfz760y.fsf@smart-cactus.org>
 <DBBPR04MB79647219026FACA0B2C4E78DB073A@DBBPR04MB7964.eurprd04.prod.outlook.com>
 <0455998C-2CDC-4C88-BC81-B8413AB656D7@glitchbra.in>
Message-ID: <87bjqm7cph.fsf@smart-cactus.org>

Hécate via ghc-devs <ghc-devs at haskell.org> writes:

> From experience it takes a couple of seconds and it's just client JS.
>

Right, I believe the amount of work is configurable. This is a knob that
we will may need to twiddle. freedesktop.org's challenge takes less than
a second on my laptop.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250617/7f7d236e/attachment.sig>

From klebinger.andreas at gmx.at  Wed Jun 18 14:34:09 2025
From: klebinger.andreas at gmx.at (Andreas Klebinger)
Date: Wed, 18 Jun 2025 16:34:09 +0200
Subject: RTS: mmap fails on RISC-V with Linux 6.8
In-Reply-To: <3595c1c3-8509-41de-936e-00843acdb645@gmx.de>
References: <3595c1c3-8509-41de-936e-00843acdb645@gmx.de>
Message-ID: <683eb016-1da0-4865-b9f8-6ce63380c288@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

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

From xypron.glpk at gmx.de  Fri Jun 20 05:11:00 2025
From: xypron.glpk at gmx.de (Heinrich Schuchardt)
Date: Fri, 20 Jun 2025 07:11:00 +0200
Subject: RTS: mmap fails on RISC-V with Linux 6.8
In-Reply-To: <683eb016-1da0-4865-b9f8-6ce63380c288@gmx.at>
References: <3595c1c3-8509-41de-936e-00843acdb645@gmx.de>
 <683eb016-1da0-4865-b9f8-6ce63380c288@gmx.at>
Message-ID: <2FDA0A34-40A8-4287-9975-8887B74E4992@gmx.de>

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