January 2025 - ghc-devs

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

06 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

GHC memory usage when typechecking from source vs. loading ModIfaces
by Gergő Érdi 03 Apr '25

03 Apr '25

Hi, I’m using the GHC API to typecheck 35,000 modules that form a complicated dependency graph (with multiple top-level modules, i.e. there’s no single “god module” that would transitively depend on everything else), and I noticed that peak memory usage is wildly different when everything is done from scratch vs. when everything is loaded from files containing ModIfaces: 17G vs. 8G. This ratio replicates for smaller samples as well, e.g. 80M vs 33M for 407 modules. I’m aware of https://gitlab.haskell.org/ghc/ghc/-/issues/13586 and so when I finish typechecking a module, I take the resulting ModIface and create the ModDetails that ends up in the HomeUnitGraph from that. My understanding of Matt’s original GHC fix in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5478 is that it does the same, i.e. it only makes a fresh ModDetails only once per module, after the ModIface is ready. But of course that still means that ModDetails can only keep growing as more and more parts of it are used for typechecking more and more dependants. Could that be the cause? I tried a crude experiment of “putting the toothpaste back in the tube” by replacing all ModDetails with a fresh one in the HUG after each finished typechecking , but that’s a complete disaster for memory usage: even for the small 407 module example, the memory usage shoots up to 1.5G. I can imagine it’s because imported Ids are probably not shared anymore between different importer modules. Any ideas on how I could improve memory usage in the from-scratch case, so that it's more similar to the from-ModIface case? Thanks, Gergo

5 30

Google Summer of Code Project Ideas
by Aaron Allen 27 Jan '25

27 Jan '25

Haskell will be applying for the Google Summer of Code 2025 program and it would be great to have some project ideas involving GHC. If anything comes to mind, please submit an idea proposal using the instructions found here: https://summer.haskell.org/ideas.html. Thanks, Aaron

2 2

CLC Elections January 2025
by Andrew Lelechenko 26 Jan '25

26 Jan '25

Core Libraries Committee seeks nominations for three expiring seats (including my own). I’m specifically sending this email to ghc-devs, because im my opinion CLC can benefit from representatives of GHC team. # What is CLC? CLC is a volunteer body, primarily tasked with management of API of `base` package, but also owning so-called Core Libraries and responsible for PVP. You can find out more at https://github.com/haskell/core-libraries-committee/ # Who should apply? Anyone who meets the following criteria should apply: * Candidates should have enough bandwidth to review merge requests to `base` on a semi-frequent basis (~3-4 per month), and sustain this for their 3 years term in a healthy manner. * Candidates should be able to contribute opinions and analysis to issues raised by the community as a part of the CLC proposal process on a semi-frequent basis (~7 per month). * Candidates should be good communicators, and at least be able to articulate to the CLC team when they will be available vs. unavailable. * Candidates should be productive, and be able to follow through on merge requests and conversations to their completion in a diligent and timely manner. We encourage any and all who satisfy these requirements to apply. Please note that we are not looking for the biggest galaxy brain in the room -- quite the opposite. We are looking for productive, motivated individuals who want to help support the ecosystem that we love. As such, we hope to build a broad sample of the community. # How can I apply? To apply for one of these positions, send an email to clc.nominations.2025(a)gmail.com that consists of the following data: * The subject “CLC Election September 2025 - {your name}”. * Why you think you’re a good fit given the above criteria. * If applicable, please point us to some code you’ve written. Please apply before Feb 2. Best regards, Andrew

1 1

History of DH contributions
by Vladislav Zavialov 20 Jan '25

20 Jan '25

Dear GHC devs, I’ll be soon publishing a task breakdown for DH (as I see it). In addition to the planned changes, I decided to include the recent history of related work (2018–2024) in the form of links to specific proposals, issues, and commits. Here’s an example of what a single section is going to look like: https://discourse.haskell.org/uploads/default/optimized/2X/4/4954f5fac0a03e… and there will be about 50 of such sections. However, as the volume of GHC commits and issues is too high for me to go through all of them, I had to limit the scope and focus on my own work. If you have any DH-related contributions that you want represented, please let me know and I’ll try to find a place to include a reference. Vlad

1 0

[PSA]: Correctness issue in GHC-9.12
by Andreas Klebinger 17 Jan '25

17 Jan '25

A bug in 9.12.1 was reported and confirmed (ghc bug https://gitlab.haskell.org/ghc/ghc/-/issues/25653) which can lead to incorrect runtime results in compiled programs. In particular this seems to happen for sub-word divisions with a known divisor when optimizations are enabled and affects at least the x86 backend, although it’s likely that other backends are also affected. We plan to release a bug fix release 9.12.2 in the near future to address this issue and recommend people do not upgrade until then.

1 0

gitlab.haskell.org maintenance 2025-01-10
by Bryan Richter 10 Jan '25

10 Jan '25

Hi folks, In about 24 hours, I will perform some maintenance on gitlab.haskell.org. I will be addressing the frequent disk outages by improving how partitions are used. This will only require a system restart, so you can expect some short downtime.

2 5

Approving gitlab account for creating an issue
by Liisi Kerik 04 Jan '25

04 Jan '25

Hi, Could you please approve my gitlab account (@LiisiKerik)? I recently ran into a performance problem (ghc plugins make builds very slow on Windows) and would like to create an issue about this. Best regards, Liisi Kerik

2 1