- ghc-devs - Haskell.org

testing ... ping
by Compl Yue 03 Feb '20

03 Feb '20

Sorry if this bothered you, I have problem sending email to the list, sending this for bgamari to further diagnostic the situation.

1 0

Random crashes with memory corruption symptoms
by Harendra Kumar 03 Feb '20

03 Feb '20

Hi, While running a test-suite for the streaming library streamly I am encountering a crash which seems to happen at random places at different times. The common messages are: * Segmentation fault: 11 * internal error: scavenge_mark_stack: unimplemented/strange closure type 24792696 @ 0x4200a623e0 * internal error: update_fwd: unknown/strange object 223743520 and several other such messages. Prima facie this looks like the memory is getting corrupted/scribbled somehow. My first suspicion was that this could be a problem in the streamly library code. But I have stripped down the code to bare minimum and there is no C FFI code or no poking to memory pointers. My next suspicion was the hspec/quickcheck testing code that is being used in this test. I checked the hspec code to ensure that there is no C code/pointer poking in any of the code involved. But no luck there as well, still looking to further strip down that code. My suspicion now is moving more towards the GHC RTS. This issue only shows when the following conditions are met: * hspec "parallel" combinator is used to run tests in parallel * streamly concurrent code is being tested which can create many threads * The GHC heap size is restricted to a small size ~32MB using "-M32M" rts option. * It is consistently seen with GHC 8.6.5 as well as GHC 8.8.1 It never occurs when the heap size is not restricted. I have seen random crashes before as well with a "IO manager die" message, when using concurrent networking IO with streamly. Though earlier it was not easily reproducible, I stopped chasing it. But now it looks like that issue might also be a manifestation of the same underlying problem. My guess is it could be something in the RTS concurrency/threading related code. Let me know if the symptoms ring a bell or if you can point to something specific based on the symptoms. Also, what are the usual tools/methods/debugging aids/flags to debug such issues in GHC? If not a GHC issue what are the possible ways in which such problem can be induced by application code? Meanwhile, I am also trying to simplify the reproducing code further to remove other factors as much as possible. The current code is at https://github.com/composewell/streamly on the ghc-segfault branch. Run "$ while true; do cabal run properties || break; done" in the shell and if you are lucky it may crash soon. The test code is in "test/Prop.hs" - here https://github.com/composewell/streamly/blob/ghc-segfault/test/Prop.hs . -harendra

3 6

RE: Simplifying subsumption
by Simon Peyton Jones 03 Feb '20

03 Feb '20

Jurriaan, It would be good to dig out the patches that affect packages without which GHC cannot build. (E.g. haskeline.) Would that take long? You have them already... It doesn't have to be perfect or git-tracked; just send a patch file in an email. I'm just trying to avoid re-inventing the wheel. A more systematic set of patches, for all the hackage packages you looked at, could certainly wait a week or three. Thanks Simon | -----Original Message----- | From: Jurriaan Hage <J.Hage(a)uu.nl> | Sent: 02 February 2020 19:00 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Cc: Jurriaan Hage <jur(a)cs.uu.nl>; Ben Gamari <ben(a)well-typed.com>; ghc- | devs <ghc-devs(a)haskell.org> | Subject: Re: Simplifying subsumption | | Hi Simon, | | Fine by me. | What kind of timeline are we looking at? I have to grade exams the coming | week, since I was ill last week, | and the week afterwards I am in Poland (but maybe I do have time for this | kind of thing then). | | Jur | | > On 2Feb, 2020, at 19:38, Simon Peyton Jones <simonpj(a)microsoft.com> | wrote: | > | > Jurriaan, Ben | > | > I have a MR up for #17775, which implements the now-accepted GHC | proposal to simplify subsumption. | > | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h | askell.org%2Fghc%2Fghc%2Fmerge_requests%2F2600&data=02%7C01%7Csimonpj% | 40microsoft.com%7C3d05874428304c245e9d08d7a8121882%7C72f988bf86f141af91ab2 | d7cd011db47%7C1%7C0%7C637162667999082070&sdata=Y7s3L%2F1xrCSxdF0EfRNik | YJnOU2Y6RtVlR92irMg7cU%3D&reserved=0 | > | > However, it requires some eta expansions in haskeline, and maybe other | packages. I don’t know how to do that. Could you, or another member of | the GHC support team, help do this? We want a MR we can validate on its | own before committing, of course. | > | > Jurriaan has all the necessary library patches. | > | > We should not commit to HEAD until there has been some code review, | though. | > | > Moreover as we know, when committed, it’ll break a number of packages, | so we need to broadcast a warning, along with the patches Jurriaan has to | fix them. I’m not sure when and how to do that. | > | > Thanks! | > | > Simon | >

1 0

Simplifying subsumption
by Simon Peyton Jones 02 Feb '20

02 Feb '20

Jurriaan, Ben I have a MR up for #17775, which implements the now-accepted GHC proposal to simplify subsumption. https://gitlab.haskell.org/ghc/ghc/merge_requests/2600 However, it requires some eta expansions in haskeline, and maybe other packages. I don't know how to do that. Could you, or another member of the GHC support team, help do this? We want a MR we can validate on its own before committing, of course. Jurriaan has all the necessary library patches. We should not commit to HEAD until there has been some code review, though. Moreover as we know, when committed, it'll break a number of packages, so we need to broadcast a warning, along with the patches Jurriaan has to fix them. I'm not sure when and how to do that. Thanks! Simon

1 0

How to run the testsuite with an out of tree compiler?
by Matthew Pickering 01 Feb '20

01 Feb '20

I am trying to run `ghcide` on GHC's tests. The documentation says that I should pass `--test-compiler=..` to hadrian in order to do this. When I do this however it starts trying to configure a bunch of packages and starting to build stuff. I don't want hadrian to build anything, I just want it to use my patched version of GHC when running certain tests! How can I achieve this? Cheers, Matt

1 1

[ANNOUNCE] Glasgow Haskell Compiler 8.10.1-rc1 released
by Ben Gamari 30 Jan '20

30 Jan '20

Hello all, The GHC team is happy to announce the availability of the first release candidate of GHC 8.10.1. Source and binary distributions are available at the usual place: https://downloads.haskell.org/ghc/8.10.1-rc1/ GHC 8.10.1 will bring a number of new features including: * The new UnliftedNewtypes extension allowing newtypes around unlifted types. * The new StandaloneKindSignatures extension allows users to give top-level kind signatures to type, type family, and class declarations. * A new warning, -Wderiving-defaults, to draw attention to ambiguous deriving clauses * A number of improvements in code generation, including changes * A new GHCi command, :instances, for listing the class instances available for a type. * An upgraded Windows toolchain lifting the MAX_PATH limitation * A new, low-latency garbage collector. * Improved support profiling, including support for sending profiler samples to the eventlog, allowing correlation between the profile and other program events This is the first and likely final release candidate. For a variety of reasons, it comes a few weeks later than the original schedule of release late December. However, besides a few core libraries book-keeping issues this candidate is believed to be in good condition for the final release. As such, the final 8.10.1 release will likely come in two weeks. Note that at the moment we still require that macOS Catalina users exempt the binary distribution from the notarization requirement by running `xattr -cr .` on the unpacked tree before running `make install`. In addition, we are still looking for any Alpine Linux to help diagnose the correctness issues in the Alpine binary distribution [1]. If you use Alpine any you can offer here would be greatly appreciated. Please do test this release and let us know if you encounter any other issues. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/issues/17508 [2] https://gitlab.haskell.org/ghc/ghc/issues/17418

5 4

more submodule questions
by Richard Eisenberg 30 Jan '20

30 Jan '20

Hi devs, I recently found this text at the end of https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/git/submodules <https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/git/submodules> : --- The CI pipeline of ghc/ghc> <applewebdata://9E3625B8-2065-48C6-A8FA-16817EA6E642/ghc/ghc> includes a linting step to ensure that all submodules refer only to "persistent" commits of the upstream repositories (e.g. not wip/ branches, which may disappear in the future). Specifically, the linter checks that any submodules refer to commits that are reachable by at least one branch that doesn't begin with the prefix wip/. Consequently, you must ensure that any submodule changes introduced in a ghc/ghc> <applewebdata://9E3625B8-2065-48C6-A8FA-16817EA6E642/ghc/ghc> merge request are merged upstream before the merge request is added to the merge queue. --- I don't understand what this means. - By citing "ghc/ghc>", does this mean that the linter only checks for this on branches of the ghc/ghc repo? If I have a fork (e.g. rae/ghc), are these checks disabled? - Does this linter stop CI from progressing to, say, running the testsuite? If so, then how can we run the testsuite via CI if we have any submodule changes? We want to run the testsuite while the work is still in progress. - By "you must ensure ... before the merge request is added to the merge queue": this makes me wonder whether the linter is just a warning or an error. That is, if I must ensure it, then it suggests that CI is not ensuring it. Sorry to be dense here! Thanks, Richard

2 3

stage2 build fails
by Simon Peyton Jones 28 Jan '20

28 Jan '20

I'm getting this with "sh validate -legacy" compiler/main/DynFlags.hs:1344:15: error: [-Woverlapping-patterns, -Werror=overlapping-patterns] Pattern match is redundant In an equation for 'settings': settings s | otherwise = ... | 1344 | | otherwise = panic $ "Invalid cfg parameters." ++ exampleString | ^^^^^^^^^ This is when compiling the stage-2 compiler. There's an ifdef in DynFlags thus #if __GLASGOW_HASKELL__ <= 810 | otherwise = panic $ "Invalid cfg parameters." ++ exampleString #endif but somehow it's not triggering for the stage2 compiler. Any ideas? It's blocking a full build. This #ifdef was added in 8038cbd96f4, when GHC became better at reporting redundant code. Simon

4 12

Intree gmp builds using Hadrian use system gmp headers
by Carter Schonwald 27 Jan '20

27 Jan '20

Hey all, For those using Hadrian for platforms where intree gmp config is important, some sleuthing I’ve done over the past half seems to indicate that currently it’s not correct via Hadrian, but only via make. https://gitlab.haskell.org/ghc/ghc/issues/17756 I’m able to reproduce this on multiple OS X machines (though it took me a while to read apart that is Hadrian specific.) Punchline : at the moment, Hadrian intree gmp builds succeed because gmp headers in default include search paths of gcc/clang get picked up. In a properly isolated environment / one without the offending header leakage, I’m able at least on OS X to get Hadrian with intree gmp to consistently fail.

1 1

gaining access to the `ghc` group
by Richard Eisenberg 27 Jan '20

27 Jan '20

Hi devs, I'm onboarding a new contributor (Gert-Jan Bottu), whose patch (!2465) makes commensurate changes in Haddock. In order to use CI, then, he needs to be able to push a wip/ branch to our fork of Haddock. In order to do that, he needs to be in the `ghc` group. (I'm assuming -- but have not checked -- that just forking Haddock on the gitlab.haskell.org <http://gitlab.haskell.org/> instance is not enough. The wiki page on submodules (https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/git/submodules <https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/git/submodules>) suggests it is not.) That same wiki page says the one needs merely ask to join the `ghc` group. Good. So I follow the "ask" link to get to https://gitlab.haskell.org/ghc/ghc/wikis/mailing-lists-and-irc#mailing-list… <https://gitlab.haskell.org/ghc/ghc/wikis/mailing-lists-and-irc#mailing-list…> . That page helpfully describes where we can be reached, but it's not all that helpful for someone who wants to join the `ghc` group. According to that page, newcomers have to post publicly in either ghc-devs (I have never seen such a request there) or in #ghc. If I'm new in town, I wouldn't feel all that happy doing so, likely wanting to wait until I actually had a patch accepted before requesting rights.... but of course I need access to CI in order to get a patch accepted. Instead, would it be possible to have some sort of ghc-admin list, perhaps? While (I think) I know the individuals to contact for a request like this, an official mailing list would make this more transparent and, in my opinion, easier to onboard new contributors. I understand if folks don't want yet another mailing list, but then is here some other approach here that doesn't require posting in public? Thanks! Richard

2 2