Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,867
    • Issues 4,867
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 457
    • Merge requests 457
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #16791
Closed
Open
Created Jun 10, 2019 by Simon Jakobi@sjakobiDeveloper

Turning Language.Haskell.TH.PprLib.PprM into a newtype triggers TH failures with ext-interp on LLVM and Windows

This is the problematic change:

--- a/libraries/template-haskell/Language/Haskell/TH/PprLib.hs
+++ b/libraries/template-haskell/Language/Haskell/TH/PprLib.hs
@@ -118,7 +118,7 @@ punctuate :: Doc -> [Doc] -> [Doc]
 -- The "implementation"
 
 type State = (Map Name Name, Uniq)
-data PprM a = PprM { runPprM :: State -> (a, State) }
+newtype PprM a = PprM { runPprM :: State -> (a, State) }
 
 pprName :: Name -> Doc
 pprName = pprName' Alone

I stumbled upon this issue in !1133 (closed) and made !1143 (closed) to confirm.

In the validate-x86_64-linux-deb9-llvm job I consistently saw

    Unexpected failures:
       th/T10891.run                        T10891 [exit code non-0] (ext-interp)
       th/T11341.run                        T11341 [exit code non-0] (ext-interp)
       th/T11345.run                        T11345 [exit code non-0] (ext-interp)
       th/T11463.run                        T11463 [exit code non-0] (ext-interp)
       th/T12403.run                        T12403 [exit code non-0] (ext-interp)
       th/T2700.run                         T2700 [exit code non-0] (ext-interp)
       th/T5358.run                         T5358 [stderr mismatch] (ext-interp)
       th/T9064.run                         T9064 [exit code non-0] (ext-interp)
       th/TH_foreignCallingConventions.run  TH_foreignCallingConventions [exit code non-0] (ext-interp)
       th/TH_reifyDecl2.run                 TH_reifyDecl2 [exit code non-0] (ext-interp)

All of them were a version of

    Exception when trying to run compile-time code:
      {handle: <file descriptor: 11>}: GHCi.Message.remoteCall: end of file

Full error messages


The validate-x86_64-windows jobs also had additional test failures. In !1143 (closed) the following appeared (usual suspects elided)

Unexpected failures:
   dependent/should_compile/Rae31.run                 Rae31 [exit code non-0] (normal)
   th/T10796a.run                                     T10796a [exit code non-0] (normal)
   th/T10811.run                                      T10811 [exit code non-0] (normal)
   th/T15365.run                                      T15365 [exit code non-0] (ext-interp)
   th/T8954.run                                       T8954 [exit code non-0] (ext-interp)
   th/TH_rebindableAdo.run                            TH_rebindableAdo [exit code non-0] (ext-interp)

In an earlier job from !1133 (closed) T12407(ext-interp) had failed too.

The error messages all appear to to be

Access violation in generated code when reading 

or

Access violation in generated code when executing data

Selected error messages including stack traces

Edited Jun 10, 2019 by Simon Jakobi
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking