April 2016 - ghc-tickets

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 26 Apr '16

26 Apr '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka <niteria@…>): In [changeset:"c9bcaf3165586ac214fa694e61c55eb45eb131ab/ghc" c9bcaf31/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c9bcaf3165586ac214fa694e61c55eb45eb131ab" Kill varSetElemsWellScoped in quantifyTyVars varSetElemsWellScoped introduces unnecessary non-determinism in inferred type signatures. Removing this instance required changing the representation of TcDepVars to use deterministic sets. This is the last occurence of varSetElemsWellScoped, allowing me to finally remove it. Test Plan: ./validate I will update the expected outputs when commiting, some reordering of type variables in types is expected. Reviewers: goldfire, simonpj, austin, bgamari Reviewed By: simonpj Subscribers: thomie, simonmar Differential Revision: https://phabricator.haskell.org/D2135 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:150> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9543: Testsuite driver: replace "extra_clean" by "git clean -X"
by GHC 26 Apr '16

26 Apr '16

#9543: Testsuite driver: replace "extra_clean" by "git clean -X" -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When adding a new test that creates extra files, one also has to do some bookkeeping: 1. Supply an `extra_clean` argument to the test function in `all.T`. 2. Add an entry in `testsuite/.gitignore` Step number 1 is often forgotten. Currently there are over 200 uncleaned files and directories left behind in the `testsuite`, after running `validate` and then `make clean` (checked with `git clean -X -d -n | wc -l`). I propose to replace the functionality that `extra_clean` provides, namely to remove these extra files when one calls `make clean`, by doing the equivalent of `git clean -X -d`: {{{ -X Remove only files ignored by Git. -d Remove untracked directories in addition to untracked files. ... }}} That is: use the information from the `.ignore` files to figure out which files to delete on `make clean`. The advantages of making this change are: 1. Less manual bookkeeping, less work, less code 2. A more thorough `make clean` Implementation detail: we can not just call `git clean` directly, since this should also work when we are not in a git directory (for example a build directory created with [wiki:Building/Using lndir]). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9543> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #4820: "Invalid object in isRetainer" when doing retainer profiling in GHC 7 branch
by GHC 26 Apr '16

26 Apr '16

#4820: "Invalid object in isRetainer" when doing retainer profiling in GHC 7 branch ----------------------------------+-------------------------------------- Reporter: dleuschner | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11978 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by carter): if i change the RTS options to set a larger retainer size, eg -R50 or even -R500, the shake test suite makes more progress before crashing. (in the context of the reproducing steps i describe in #11978) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4820#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11973: Simplifier ticks exhausted with complex list literal.
by GHC 26 Apr '16

26 Apr '16

#11973: Simplifier ticks exhausted with complex list literal. -------------------------------------+------------------------------------- Reporter: Lokathor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Windows Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- So I had a working version of a module that was too slow: https://github.com/Lokathor/ludolib/blob/6e69f87762c88d7909ca259ffe69141ea4… and then I tried to rearrange things so that the checking could short- circuit a bit and run faster. I came up with this: https://gist.github.com/Lokathor/d1e4a8cd6268835a2403423fb180a71d#file- automatagencrashesghc-hs-L172 Which loads and runs just fine in GHCi, but then when I go to compile it into a binary for benchmarking I got the following: {{{ ghc.exe: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-mingw32): Simplifier ticks exhausted When trying UnfoldingDone a_siVC To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 294802 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Setting the factor up to 1k caused it to crash out with the same problem. Setting the factor up to 10k caused GHC to just eat up nearly all of my RAM (11GB) and then stall out until I killed it a few minutes later. I tried not using -O2 during compilation, but it had the same problem anyway. With some IRC help, it was suggested to add the `-fsimple-list- literals` flag, which makes things compile and run just fine (and with the speed gain that I'd hoped for). So things work now, for some definition of "work", though I was advised to report this bad behavior anyway. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11973> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #4820: "Invalid object in isRetainer" when doing retainer profiling in GHC 7 branch
by GHC 25 Apr '16

25 Apr '16

#4820: "Invalid object in isRetainer" when doing retainer profiling in GHC 7 branch ----------------------------------+-------------------------------------- Reporter: dleuschner | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11978 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by carter): * priority: high => highest * version: 7.10.3 => 8.0.1 * related: => #11978 Comment: In working out how to reproduce this bug, I also found another bug, steps for reproducing can be found in #11978 marking as highest because its a reproducible crash -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4820#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9253: "internal error: evacuate(static): strange closure type 0" when running in QEMU
by GHC 25 Apr '16

25 Apr '16

#9253: "internal error: evacuate(static): strange closure type 0" when running in QEMU ------------------------------------+------------------------------------- Reporter: ocharles | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- We're trying to use NixOS to automatically run our acceptance tests in a VM on commit, in order to guarantee system stability. However, we're periodically seeing our web server component, compiled with GHC 7.8.2 is failing to start up. When it fails, the error message is always: {{{ internal error: evacuate(static): strange closure type 0 (GHC version 7.8.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Happy to do more debugging on this, but I'll need to be pointed in the right direction. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9253> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #4820: "Invalid object in isRetainer" when doing retainer profiling in GHC 7 branch
by GHC 24 Apr '16

24 Apr '16

#4820: "Invalid object in isRetainer" when doing retainer profiling in GHC 7 branch ----------------------------------+-------------------------------------- Reporter: dleuschner | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Profiling | Version: 7.10.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by carter): The code at work that trips this is open source, but I'm not sure how reproducible the crash is atm -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4820#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4820: "Invalid object in isRetainer" when doing retainer profiling in GHC 7 branch
by GHC 24 Apr '16

24 Apr '16

#4820: "Invalid object in isRetainer" when doing retainer profiling in GHC 7 branch ----------------------------------+-------------------------------------- Reporter: dleuschner | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Profiling | Version: 7.10.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by carter): * milestone: 7.0.2 => 8.0.2 Comment: Marking the milestone as 8.0.2 because it shouldn't be a release blocker , but is a real crash. And profiling shouldn't ;) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4820#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4820: "Invalid object in isRetainer" when doing retainer profiling in GHC 7 branch
by GHC 24 Apr '16

24 Apr '16

#4820: "Invalid object in isRetainer" when doing retainer profiling in GHC 7 branch ----------------------------------+-------------------------------------- Reporter: dleuschner | Owner: Type: bug | Status: new Priority: high | Milestone: 7.0.2 Component: Profiling | Version: 7.10.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by carter): * status: closed => new * resolution: invalid => * version: 7.0.1 => 7.10.3 * os: Linux => MacOS X Comment: On a highly concurrent application at work, we've seen this exact same sort of crash when doing retainer profiling. Don't have a repro yes, but this is a real crash. Not sure if I can replicate it on 8.0rc but I'll try to poke at it -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4820#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11972: Weak pointers can cause segfault
by GHC 23 Apr '16

23 Apr '16

#11972: Weak pointers can cause segfault -------------------------------------+------------------------------------- Reporter: ryantrinkle | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The attached program segfaults. It appears to be nondeterministic, but on my machine, it occurs at least 95% of the time. Some small changes, such as removing the bang pattern, cause the segfault to become much less likely. {{{ weakPointerSegfault: internal error: ASSERTION FAILED: file rts/sm/GCAux.c, line 44 (GHC version 8.0.0.20160411 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11972> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4