[GHC] #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later

[GHC]

#14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs
on Ubuntu 16.04 or later
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  alpmestan
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.4.1
       Component:  GHC API           |              Version:  8.4.1-alpha1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Runtime crash     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #14603            |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by bgamari):

 > I ended up chasing down the problem with gdb a little bit but didn't
 really know where to break and stepping through everything was just not
 conceivable so I ended up going about it the good old way, by printing a
 bunch of things along the code path that leads to the error.

 Great work so far! Indeed this is often the case; `gdb` can only get you
 so far. I should mention that [[http://rr-project.org/|rr]] is an
 extremely helpful tool in cases like this since it gives you multiple
 changes to trace through a given run of the program.

 I also have a `breakpoint`
 [[https://github.com/bgamari/breakpoint|package]] which makes it easy to
 insert debugger breakpoints into a Haskell program. While using the
 package in GHC may be more work than it's worth, stealing the idea should
 be straightforward. You also may want to try using my
 [[https://github.com/bgamari/ghc-utils/tree/master/gdb|gdb plugin]]. It
 makes inspecting the STG stack and heap significantly easier.

 Out of curiosity, is the issue still reproducible when GHC is built with
 profiling enabled? If so, it might be nice to continue debugging  under
 this way as the profiled way includes a significant amount of information
 about the structure of heap objects that can be useful while debugging
 (e.g. type names).

 At this point I would do the following:
  1. Insert a breakpoint right before the `unsafeCoerce#`
  2. Look at the assembler that results and try to work out which register
 `annotation_wrapper` ends up in
  3. Reproduce the issue in the debugging, look at this register, and look
 at its info table
  4. Verify that the info table corresponds to either a thunk or a
 constructor of the expected type

 After that the decision tree will branch.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14675#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler