November 2024 - ghc-devs

openFile gives "file is locked" error on Linux when creating a non-existing file
by Harendra Kumar 07 Jul '25

07 Jul '25

Hi everyone, We have a long standing, elusive and intermittent test failure in streamly's file system event test suite. The code where the error emanates from looks like this: createFileWithParent :: FilePath -> FilePath -> IO () createFileWithParent file parent = do let filepath = parent </> file let dir = takeDirectory filepath putStrLn $ "createFileWithParent: file [" ++ file ++ "] dir [" ++ dir ++ "]" putStrLn $ "Ensuring dir: " ++ dir createDirectoryIfMissing True dir r <- doesDirectoryExist dir if r then do putStrLn $ "Ensured dir: " ++ dir when (not (null file)) $ do exists <- doesFileExist filepath if not exists then do putStrLn $ "Creating file: " ++ (parent </> file) openFile (parent </> file) WriteMode >>= hClose putStrLn $ "Created file: " ++ (parent </> file) else error $ "File exists: " ++ filepath else error $ "Could not create dir: " ++ dir The important thing in the code above is that we check that the file does not exist already, and we are creating it. Creating this new file intermittently fails with the following error messages, all of these are coming from prints in the above: createFileWithParent: file [file1] dir [/tmp/fsevent_dir-e1098325dc2b0880/watch-root] Ensuring dir: /tmp/fsevent_dir-e1098325dc2b0880/watch-root Ensured dir: /tmp/fsevent_dir-e1098325dc2b0880/watch-root Creating file: /tmp/fsevent_dir-e1098325dc2b0880/watch-root/file1 uncaught exception: IOException of type ResourceBusy /tmp/fsevent_dir-e1098325dc2b0880/watch-root/file1: openFile: resource busy (file is locked) How can a file that does not exist and being created be locked during creation? We see this only on Linux, the same tests always succeed on Windows and macOS. We are facing this in GHC 9.2.8, I am not sure if it is version specific because in the past I selectively disabled the tests for specific GHC versions and the error still surfaced in other GHC versions. Anything obvious that we may be missing here? Any pointers or more debug info to generate to debug this? I have not started looking into the openFile code yet, hoping someone else knowing it well might help here. Is this some other "resource busy" error which is being wrongly bucketed into "file is locked" error? Thanks, Harendra

4 20

Request for approval of account
by Mark Seemann 24 Jun '25

24 Jun '25

Hello I’d like to report a bug in GHC because an error message tells me to do so. In order to do that, I’m trying to follow the guidelines in https://gitlab.haskell.org/ghc/ghc/-/wikis/report-a-bug, so I’ve created an account. The next step, as I understand it, is to use this mailing list to request approval for he account. I’m hereby doing that. TIA Mark Seemann

2 1

Feedback on potential change in boot library
by Ben Gamari 17 Dec '24

17 Dec '24

tl;dr. We propose that GHC more aggressively bump its boot library dependencies. Hello all, Historically, GHC minor releases have been quite conservative in bumping boot library versions, generally defaulting to retaining the versions used in the GHC-x.y.1 release unless * a request is made by a boot library maintainer, or * we discover an issue which warrants a bump The motivation for this policy is both to * minimize the potential for regressions in correctness and performance, and * reduce the potential for end-user breakage due to interface changes as even minor releases can result in considerable impact (e.g. #25411, #22633) While this policy has served us well, its conservative nature demands the vigilence of both GHC and upstream maintainers to ensure that bumps that are truly necessary do not fall through the cracks. As the flaws of this process have been more apparent recently (e.g. #24597), we have done a bit of reflection on how we might improve the status quo. Concretely, I would like feedback on the adopting the following policy going forward: > Unless guidance is provided otherwise by a library maintainer, a GHC > x.y.z release will attempt to ship the newest minor version of each > boot libray in the same major series shipped with GHC x.y.1. I believe this policy would leave less room for human error and open opportunities for automated checking. On the other hand, the more aggressive bumping of submodules may mean that users are hit with more (usually minor) compatibility issues when moving between minor GHC releases. How do others feel about this? We are particularly interested to hear from boot library maintainers but feedback from packagers and users is also very much welcome. Cheers, - Ben

9 12

[ANNOUNCE] GHC 9.12.1-rc1 is now available
by Zubin Duggal 29 Nov '24

29 Nov '24

The GHC developers are very pleased to announce the availability of the release candidate for GHC 9.12.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][]. We hope to have this release available via ghcup shortly. GHC 9.12 will bring a number of new features and improvements, including: * The new language extension [OrPatterns] allowing you to combine multiple pattern clauses into one. * The [MultilineStrings] language extension to allow you to more easily write strings spanning multiple lines in your source code. * Improvements to the OverloadedRecordDot extension, allowing the built-in `HasField` class to be used for records with fields of non lifted representations. * The [NamedDefaults] language extension has been introduced allowing you to define defaults for typeclasses other than `Num`. * More deterministic object code output, controlled by the `-fobject-determinism` flag, which improves determinism of builds a lot (though does not fully do so) at the cost of some compiler performance (1-2%). See #12935 for the details * GHC now accepts type syntax in expressions as part of [GHC Proposal #281]. * The WASM backend now has support for TemplateHaskell. * ... and many more A full accounting of changes can be found in the [release notes][]. As always, GHC's release status, including planned future releases, can be found on the GHC Wiki [status][]. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. Cheers, Zubin [release notes]: https://downloads.haskell.org/ghc/9.12.1-rc1/docs/users_guide/9.12.1-notes.… [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [downloads.haskell.org] https://downloads.haskell.org/ghc/9.12.1-rc1 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [OrPatterns]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0522-o… [MultilineStrings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-m… [GHC Proposal #281]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-v… [NamedDefaults]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-e…

1 0

GHC 9.12.1 updates and rc1 status
by Zubin Duggal 27 Nov '24

27 Nov '24

Hi all, We had planned to release 9.12.1-rc1 today. Unfortunately, we discovered a few regressions and bugs which need to be fixed before we can publish a release candidate, including #25382, #25375 and !13633. I am currently waiting for some of these fixes to land in master before backporting them to the release branch. I will try to have the release candidate out on Monday the 25th. The final release is currently scheduled for December 6th. We will inform you if there are any changes to this schedule. Cheers, Zubin.

1 1

labeling MVar and STM data structures
by Kazu Yamamoto 21 Nov '24

21 Nov '24

Hello, I'm seeking of the source of the bug that my server based on Warp gets not-responding. "listThreads" shows that IOManager is blocked on a MVar permanently: 2 IOManager on cap 0: ThreadBlocked BlockedOnForeignCall 3 IOManager on cap 1: ThreadBlocked BlockedOnMVar 4 TimerManager: ThreadBlocked BlockedOnForeignCall IOManager should have the BlockedOnForeignCall reason since it's calling epoll_wait(). It's quit hard to debug this bug since I don't understand which MVar blocks IOManager of 3. Users can register MVar operations to IOManager while IOManager itself is using MVars internally. To make this kind of debugging easier, I would like ask GHC developers to extend MVar to hold its label and provide "labelMVar" like "labelThread". The same mechanism should be provided for STM as well. "BlockReason" should contain the target label. What do you think? Background: https://github.com/haskell/network/issues/590 --Kazu

3 3

[ANNOUNCE] GHC 9.12.1-alpha3 is now available
by Zubin Duggal 15 Nov '24

15 Nov '24

The GHC developers are very pleased to announce the availability of the third alpha release of GHC 9.12.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][]. We hope to have this release available via ghcup shortly. GHC 9.12 will bring a number of new features and improvements, including: * The new language extension [OrPatterns] allowing you to combine multiple pattern clauses into one. * The [MultilineStrings] language extension to allow you to more easily write strings spanning multiple lines in your source code. * Improvements to the OverloadedRecordDot extension, allowing the built-in `HasField` class to be used for records with fields of non lifted representations. * The [NamedDefaults] language extension has been introduced allowing you to define defaults for typeclasses other than `Num`. * More deterministic object code output, controlled by the `-fobject-determinism` flag, which improves determinism of builds a lot (though does not fully do so) at the cost of some compiler performance (1-2%). See #12935 for the details * GHC now accepts type syntax in expressions as part of [GHC Proposal #281]. * The WASM backend now has support for TemplateHaskell. * ... and many more A full accounting of changes can be found in the [release notes][]. As always, GHC's release status, including planned future releases, can be found on the GHC Wiki [status][]. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. [release notes]: https://downloads.haskell.org/ghc/9.12.1-alpha3/docs/users_guide/9.12.1-not… [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [downloads.haskell.org] https://downloads.haskell.org/ghc/9.12.1-alpha3 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [OrPatterns]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0522-o… [MultilineStrings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-m… [GHC Proposal #281]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-v… [NamedDefaults]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-e… Cheers, Zubin

1 0

Under which circumstances are the elements of a linked list laid next to each-other in memory?
by Hécate 13 Nov '24

13 Nov '24

Hi everyone, I was asked at work today why I went for Vector instead plain old List in order to store an API result that is quite small. While writing my reasons (pointer indirection, conversion to Aeson's internal representation of a JSON array using Vector), I remember that I heard that in some cases, GHC would be able to lay down in memory the elements of a linked list next to each other. I don't think this gets rid of the pointer-chasing, but I'm interested to know more about the circumstances in which linked lists are optimised. Does anyone know if there is a wiki page or something that I could read on the topic of linked list optimisation **other than fusion**? Cheers, Hécate -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

4 3

GHC CI
by Simon Peyton Jones 12 Nov '24

12 Nov '24

Dear GHC devs Is something stuck in CI? https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13553 has been stalled for 9 hrs. I have not seen that before. Thanks Simon

6 5

GHC 9.12 release schedule and submodule status
by Zubin Duggal 11 Nov '24

11 Nov '24

Hi all, (This is a resend of an email I sent a short while ago. I seem to have messed up some email headers that might trip up some filters so I'm resending it to be safe. You only need to read one of these if you recieved my previous email) I'm writing to your in your role as a maintainer of one of the GHC boot packages. This is an update on the 9.12 release schedule. We plan to have the release out by the end of the month (ideally on 29/11/24), with an alpha/rc every week from now until the release is finalised: | Date | Event | | ----------------- | -------- | | Nov 15 2024 | alpha 3 | | Nov 22 2024 | release candidate | | Nov 29 2024 | final | Additionally, this is the final call for any submodule bumps that may be desired. The current status of the submodules is described in this spreadsheet, under the GHC 9.12 tab: https://docs.google.com/spreadsheets/d/19WeWjXPh8Q64qoe3fjs8AswpTHk6uLBD8WG… If any version that is not listed in the spreadsheet is desired, please notify me and ensure that a release is tagged and uploaded to hackage as soon as possible. I would like to finalise the state of submodules by the first release candidate. This email is individually addressed to the maintainers of all the boot libraries, as best as we could collate such a list. If you are aware of any changes to the list of GHC boot packages maintainers, please let us know. We aim to have a more systematic process for such communications with library maintainers for releases in the future. Once we finalise such a process we will let you know. Thanks for all your work, Zubin.

1 0