#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