Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,262
    • Issues 4,262
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 405
    • Merge Requests 405
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #17236

Closed
Open
Opened Sep 23, 2019 by sheaf@trac-sheafDeveloper

Plugins non-deterministically segfault on Windows

Plugins seem to be broken on Windows (in my case Windows 10, x64), nondeterministically causing hangs and segmentation faults. The problem seems to have worsened with GHC 8.8.1.

I've attached a simple repro PluginCrash.zip which makes use of the ghc-typelits-knownnat plugin (a pure plugin). Running cabal repl either hangs or causes a segmentation fault; error messages reproduced below.

Show/hide error messages.

Access violation in generated code when reading 0x6d9f4

 Attempting to reconstruct a stack trace...

   Frame        Code address
 * 0x45fdab0    0x14369014 C:\Haskell\GHC\ghc-8.8.1\lib\ghc-8.8.1\libHSghc-8.8.1.a(PrimOp.o)+0xe94
                 (ghc_PrimOp_primOpTag_info+0xbd9c)



Access violation in generated code when reading 0x0

 Attempting to reconstruct a stack trace...

   Frame        Code address
 * 0x45fdab0    0x10e9d993 C:\Haskell\GHC\ghc-8.8.1\lib\ghc-8.8.1\libHSghc-8.8.1.a(NameCache.o)+0x4c3
                 (ghc_NameCache_lookupOrigNameCache_info+0x9c5)



Access violation in generated code when reading 0x7c58

 Attempting to reconstruct a stack trace...

   Frame        Code address
 * 0x45fdab0    0x14c57b8f C:\Haskell\GHC\ghc-8.8.1\lib\ghc-8.8.1\libHSghc-8.8.1.a(TysWiredIn.o)+0x1a52f
                 (ghc_TysWiredIn_isBuiltInOcczumaybe_info+0x1651)



ghc.exe: internal error: evacuate(static): strange closure type 0
    (GHC version 8.8.1 for x86_64_unknown_mingw32)

ghc.exe: internal error: evacuate(static): strange closure type 51339
    (GHC version 8.8.1 for x86_64_unknown_mingw32)

ghc.exe: internal error: evacuate(static): strange closure type 2949221
    (GHC version 8.8.1 for x86_64_unknown_mingw32)



Access violation in generated code when executing data at 0xa00

 Attempting to reconstruct a stack trace...

   Frame        Code address
 * 0x45fdab0    0xa00



Access violation in generated code when executing data at 0x1b98

 Attempting to reconstruct a stack trace...

   Frame        Code address
 * 0x45fdab0    0x1b98

The same error messages seem to reoccur (e.g. mentioning TysWiredIn.o or PrimOp.o).

Reproducing should consist only of running cabal repl, with an up-to-date package db for the plugin dependency. It might also be possible to replace the external plugin by a stub plugin. Edit: This is indeed the case, see this comment for how to reproduce the crash with a stub plugin.

Note that running cabal build seems to work OK in this repro case (not in my original code). However, subsequently loading it with cabal repl seems to cause GHCi to hang when attempting to quit. On the other hand, in the original code, about 1 in 10 times cabal repl/cabal build goes through OK and everything works as expected. With this small repro, cabal repl hasn't succeeded even after over 100 attempts.

The problem seems to occur significantly less frequently with previous versions of GHC, but the nondeterministic nature of the issue can make it hard to tell.

Edited Oct 04, 2019 by sheaf
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#17236