November 2014 - ghc-tickets

Re: [GHC] #3589: Recompilation checker doesn't take into account CPP headers
by GHC 21 Nov '14

21 Nov '14

#3589: Recompilation checker doesn't take into account CPP headers -------------------------------------+--------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.4.1 Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | -------------------------------------+--------------------------------- Comment (by Austin Seipp <austin@…>): In [changeset:"803fc5db31f084b73713342cdceaed5a9c664267/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="803fc5db31f084b73713342cdceaed5a9c664267" Add API Annotations Summary: The final design and discussion is captured at https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations This is a proof of concept implementation of a completely separate annotation structure, populated in the parser,and tied to the AST by means of a virtual "node-key" comprising the surrounding SrcSpan and a value derived from the specific constructor used for the node. The key parts of the design are the following. == The Annotations == In `hsSyn/ApiAnnotation.hs` ```lang=haskell type ApiAnns = (Map.Map ApiAnnKey SrcSpan, Map.Map SrcSpan [Located Token]) type ApiAnnKey = (SrcSpan,AnnKeywordId) -- --------------------------------------------------------------------- -- | Retrieve an annotation based on the @SrcSpan@ of the annotated AST -- element, and the known type of the annotation. getAnnotation :: ApiAnns -> SrcSpan -> AnnKeywordId -> Maybe SrcSpan getAnnotation (anns,_) span ann = Map.lookup (span,ann) anns -- |Retrieve the comments allocated to the current @SrcSpan@ getAnnotationComments :: ApiAnns -> SrcSpan -> [Located Token] getAnnotationComments (_,anns) span = case Map.lookup span anns of Just cs -> cs Nothing -> [] -- | Note: in general the names of these are taken from the -- corresponding token, unless otherwise noted data AnnKeywordId = AnnAs | AnnBang | AnnClass | AnnClose -- ^ } or ] or ) or #) etc | AnnComma | AnnDarrow | AnnData | AnnDcolon .... ``` == Capturing in the lexer/parser == The annotations are captured in the lexer / parser by extending PState to include a field In `parser/Lexer.x` ```lang=haskell data PState = PState { .... annotations :: [(ApiAnnKey,SrcSpan)] -- Annotations giving the locations of 'noise' tokens in the -- source, so that users of the GHC API can do source to -- source conversions. } ``` The lexer exposes a helper function to add an annotation ```lang=haskell addAnnotation :: SrcSpan -> Ann -> SrcSpan -> P () addAnnotation l a v = P $ \s -> POk s { annotations = ((AK l a), v) : annotations s } () ``` The parser also has some helper functions of the form ```lang=haskell type MaybeAnn = Maybe (SrcSpan -> P ()) gl = getLoc gj x = Just (gl x) ams :: Located a -> [MaybeAnn] -> P (Located a) ams a@(L l _) bs = (mapM_ (\a -> a l) $ catMaybes bs) >> return a ``` This allows annotations to be captured in the parser by means of ``` ctypedoc :: { LHsType RdrName } : 'forall' tv_bndrs '.' ctypedoc {% hintExplicitForall (getLoc $1) >> ams (LL $ mkExplicitHsForAllTy $2 (noLoc []) $4) [mj AnnForall $1,mj AnnDot $3] } | context '=>' ctypedoc {% ams (LL $ mkQualifiedHsForAllTy $1 $3) [mj AnnDarrow $2] } | ipvar '::' type {% ams (LL (HsIParamTy (unLoc $1) $3)) [mj AnnDcolon $2] } | typedoc { $1 } ``` == Parse result == ```lang-haskell data HsParsedModule = HsParsedModule { hpm_module :: Located (HsModule RdrName), hpm_src_files :: [FilePath], -- ^ extra source files (e.g. from #includes). The lexer collects -- these from '# <file> <line>' pragmas, which the C preprocessor -- leaves behind. These files and their timestamps are stored in -- the .hi file, so that we can force recompilation if any of -- them change (#3589) hpm_annotations :: ApiAnns } -- | The result of successful parsing. data ParsedModule = ParsedModule { pm_mod_summary :: ModSummary , pm_parsed_source :: ParsedSource , pm_extra_src_files :: [FilePath] , pm_annotations :: ApiAnns } ``` This diff depends on D426 Test Plan: sh ./validate Reviewers: austin, simonpj, Mikolaj Reviewed By: simonpj, Mikolaj Subscribers: Mikolaj, goldfire, thomie, carter Differential Revision: https://phabricator.haskell.org/D438 GHC Trac Issues: #9628 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3589#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8568: internal error: allocation of ... bytes too large
by GHC 21 Nov '14

21 Nov '14

#8568: internal error: allocation of ... bytes too large ------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Running the following GHCi session: {{{ import GHC.DataSize import qualified Data.HashTable.IO as HT import Control.Monad t <- HT.new :: IO (HT.BasicHashTable Int Char) forM_ [0..100000] $ \i -> HT.insert t i 'a' recursiveSize t }}} results in the following error: {{{ <interactive>: internal error: allocation of 1208480 bytes too large (GHC should have complained at compile-time) (GHC version 7.6.3 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap: 6 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8568> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9647: allocation of 10790760 bytes too large
by GHC 21 Nov '14

21 Nov '14

#9647: allocation of 10790760 bytes too large -------------------------------------+------------------------------------- Reporter: mirko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: run time | Operating System: Windows insufficient memory | Type of failure: Incorrect Architecture: x86_64 (amd64) | warning at compile-time Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- I got an error message and invitation to submit a bug report. So here is the error message first, followed by my description of what happened. C:\Users\Owner\Documents\hs>ghc -o void void.hs -rtsopts [1 of 1] Compiling Main ( void.hs, void.o ) Linking void.exe ... C:\Users\Owner\Documents\hs>void +RTS -K400M -RTS > void.txt void: internal error: allocation of 10790760 bytes too large (GHC should have complained at compile-time) (GHC version 7.8.3 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug C:\Users\Owner\Documents\hs>void +RTS -K40000M -RTS > void.txt void: internal error: allocation of 10790760 bytes too large (GHC should have complained at compile-time) (GHC version 7.8.3 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Description of what happened. I gave my program really large numbers. It contains the following line: rr = (of40)*(r250^3041) In the above of40 is (if I remember correctly) the product of the first 40000 odd primes. I computed it with reduce (a computer algebra system) which saved the result (as an explicitly written out number in decimal notation), which I copied and inserted in my hs file, initializing of40 with its value. In the file it takes 2457 rows, 1024 cols, so it appears to be about 2 515 968 (that is two million+) decimal digits. As seen it is multiplied by r250^3041, here r250 is a 250-digit number so r250^3041 is about 760 250 (seven hundred sixty thousand+) decimal digits, so the product rr = (of40)*(r250^3041) seems to be more than 3 000 000 (three million+) decimal digits. I tried to compile it yesterday, I did get an error message from the compiler: I do not remember exactly what it was, I may try to reproduce it later and include it, but it was something along the lines of insufficient amount of memory. I run a Hewlett-Packard HPE 500y, upgraded to 16 Gb RAM (the max it would take), Windows 7, AMD Phenom(tm) II X6 1045T Processor 2.70 GHz (6 core). So yesterday after I got the first error message I increased the paging file size from automatic to 32768 Mb initial, and 65536 Mb max. Then tried to compile again, the compiler gradually took more and more memory (I was watching the performance using the Task Manager) so it gradually went up to using all 16 Gb of RAM, and stayed there for I think at least 40 min, could have been more than an hour (or even 2 hours, sorry can't quite remember). At some point it seemed the computer froze, the task manager stopped showing any activity, but I did not attempt to immediately restart it, the mouse would not respond anyway, and in a few minutes it fixed itself, it seemed to continue compiling, after which it eventually gave up and complained about insufficient amount of memory again. So this morning I increased the paging file to initial size 49152 Mb, max size 196608 Mb (I don't know if such big numbers make sense but I tried). I tried to compile again starting around 9am, left my apt at around 4pm and the compiler had not yet finished, and came back after midnight, the compiler had finished. It had produced a big exe file (I see now, around 9 pm, so it must have kept compiling for around 12 hours): 09/27/2014 09:38 PM 20,602,960 void.exe AVG (antivirus) claimed that this file was a threat and refused to let me run it, so I had to disable AVG, after which I got the error messages as already enclosed at the beginning of this description. The Paging file reports as: Recommended 24574 Mb, Currently allocated: 163765 Mb. Note I gave the options -rtsopts to the compiler, I do not remember anymore what they mean, and whether they are valid (or perhaps not used anymore), I got them from a webpage perhaps a couple of years ago and at that time they made sense, so I just kept using them. I also gave the option +RTS -K400M -RTS when I tried to execute the compiled program, and then +RTS -K40000M -RTS, both versions generated the error messages shown above. I tend to believe that giving Haskell such large numbers inside the .hs file explains all of the above problems, it might even be a bit surprising it went so far before it finally gave up. But I do not really know, so let me just report it. So I changed the paging file back to automatic, and I am compiling the same file (after renaming it) to try to reproduce the error message that I got yesterday (or rather the other day, now being after midnight). It has been compiling for about 4 min so far, nothing really visible, memory usage stays at 1.28 Gb (where it was before I started compiling). I don't quite remember what happened the first time when I tried to compile, I think I got the error message (about insufficient amount of memory) immediately, or almost immediately. This does not happen now, I wonder if the computer took into account that I changed the paging file back to automatic, I may need to restart to make sure. Well, ok, 13 min after it started compiling, the memory usage started going up gradually. It goes from e.g. 13.9 to 14 Gb in about a second or two. So in about 2 min it went from 1.28 to 15.9 Gb, and now stays there (I do not know how to interpret all that Task Manager shows me). I may not be able to reproduce the first error message: At that time I was running 5 copies of reduce, each busy multiplying numbers for some hours. Right now I am only running the GHC by itself, so no other load. It is running for about 23 min now, the last 6 of which the memory usage stays at 15.9 Gb. My computer may have learned to increase the paging file on its own. The computer refuses to give up this time, but I can't wait, going to bed is long overdue, if it generates an error message I'll copy it in the morning. Well, memory usage decreased a bit to 15.1, this happened after it stayed at 15.9 for about 15 min. It I remember correctly what had happened the other day, it will increase again, and then give an error message. It's at 15.3 Gb for about 3 min now. On the other hand the processor is doing almost nothing, going between 0% and 1%. Memory 15.4, 15.8, processor went up to 16% to 17% (which is = 1 out of 6 cores), memory 15.9, this is about 40 min after it started compiling and about 23 min after it went up to 15.9 Gb (15.8 presently). I should perhaps be patient and wait for the compiler to give up and give me an error message that I could copy, but I do not have the patience to do that: Again the original error message was something to the effect that the compiler refused to work because of insufficient amount of memory. I kept trying to compile, so apparently the compiler tried to be nice to me, and eventually compiled my program in 9 hours, after which when I tried to execute it, I was invited to write this report. It keeps compiling right now, at 16% (1 of 6 cores) processor, and 15.9 Gb memory usage, for about 47 min (30 min at 15.9). P.S. Thanks for Richard Eisenberg and Herbert Valerio Riedel for replying to my email. I initially had problems, trying to register and submit a new bug report, the BotScout stopped me, and it was too late at night to try to figure it, so I just emailed Richard in my frustration. Now, BotScout may not be the culprit: I did not read carefully what it asked me to do, and it was something like Evaluate `(!!6) ...' My knowledge of Haskell is rather superficial (I use it since it compiles and is relatively fast, and does not need an extra library to work with large numbers), so I have to often consult the tutorial for simple constructs. I have had some previous experience with Common Lisp (or Scheme, a course taken 12 years ago) and in Lisp there is a command "evaluate", and also single quotation marks are used within the language occasionally. So, I just copied the entire line Evaluate `(!!6) (whatever it was)' and pasted it in the interpreter which gave me some nonsense which I sent back to BotScout. BotScout then gave me a second chance, and I do not quite remember if I tried to be more careful, perhaps not, so BotScout wouldn't even let me try anymore after that (even if I started from scratch ... perhaps it remembered me). After that happened I copied only the (!!6), etc, and the my GHC interpreter did evaluate something meaningful (a single number, no error message). I just didn't want to spend the time to think that late at night, and at first it seemed to me that the word Evaluate might have been part of a Haskell expression. I question if the above (perhaps too lengthy) report is of any use, but again, I follow the instruction, if in doubt, submit it. Thank you again! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9647> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #4505: Segmentation fault on long input (list of pairs)
by GHC 21 Nov '14

21 Nov '14

#4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation Operating System: Linux | fault, segfault, long input Type of failure: Runtime | Architecture: x86_64 (amd64) crash | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by Yuras): * priority: low => normal * difficulty: => Unknown Comment: The compile time check (introduced in a278f3f02d09bc32b0a75d4a04d710090cde250f) was removed when replacing the old code generator. So now it crashes at runtime again. It was report a number of times, see #9647 and #8568. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4505#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5462: Deriving clause for arbitrary classes
by GHC 21 Nov '14

21 Nov '14

#5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dreixel Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Generics Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7346 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D476 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5462#comment:48> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1476: Template Haskell: splicing types and patterns
by GHC 21 Nov '14

21 Nov '14

#1476: Template Haskell: splicing types and patterns -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: patch Priority: low | Milestone: 7.10.1 Component: Template | Version: 6.6.1 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D433 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg <eir@…>): In [changeset:"cfa574cea30b411080de5d641309bdf135ed9be5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="cfa574cea30b411080de5d641309bdf135ed9be5" Update manual for pattern splices (#1476) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1476#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7484: Template Haskell allows building invalid record fields/names
by GHC 21 Nov '14

21 Nov '14

#7484: Template Haskell allows building invalid record fields/names -------------------------------------+------------------------------------- Reporter: iustin | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.6.1 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8750 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D431 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg <eir@…>): In [changeset:"dbf360a5264d5d6597e046dcd9b4f49effa91eee/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="dbf360a5264d5d6597e046dcd9b4f49effa91eee" Test #7484 in th/T7484 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7484#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7484: Template Haskell allows building invalid record fields/names
by GHC 21 Nov '14

21 Nov '14

#7484: Template Haskell allows building invalid record fields/names -------------------------------------+------------------------------------- Reporter: iustin | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.6.1 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8750 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D431 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg <eir@…>): In [changeset:"da2fca9e2be8c61c91c034d8c2302d8b1d1e7b41/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="da2fca9e2be8c61c91c034d8c2302d8b1d1e7b41" Fix #7484, checking for good binder names in Convert. This commit also refactors a bunch of lexeme-oriented code into a new module Lexeme, and includes a submodule update for haddock. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7484#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1476: Template Haskell: splicing types and patterns
by GHC 21 Nov '14

21 Nov '14

#1476: Template Haskell: splicing types and patterns -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: patch Priority: low | Milestone: 7.10.1 Component: Template | Version: 6.6.1 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D433 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg <eir@…>): In [changeset:"adb20a0aec89047af397ef8c3fcde78217e6e5f6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="adb20a0aec89047af397ef8c3fcde78217e6e5f6" Test #1476 in th/T1476 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1476#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1476: Template Haskell: splicing types and patterns
by GHC 21 Nov '14

21 Nov '14

#1476: Template Haskell: splicing types and patterns -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: patch Priority: low | Milestone: 7.10.1 Component: Template | Version: 6.6.1 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D433 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg <eir@…>): In [changeset:"d627c5cf81fcce05ec160edc5be907297ff05c33/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d627c5cf81fcce05ec160edc5be907297ff05c33" Test that nested pattern splices don't scope (#1476). Test case: th/T1476b. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1476#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0