#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 alpmestan): When work resumes after going back to the scheduler, we load the stack and jump to its top (`stg_enter_info`). This then leads us to execute a whoooooooole bunch of code. I saw many kinds of closure types along the way, among which a `Data.Data` related one (expected: we embed a `Data` dictionary in `AnnotationWrapper`), a ghci `BreakArray` related one, partial applications, `FUN_STATIC`, etc. The somewhat uninformative context in which the crash finally happens can be seen [https://gist.github.com/alpmestan/a029e46c9cb7beb6839c6ac6058a95f9#file- foo-asm-L1017 here], interleaved with my attempts to find out a bit of information about the addresses/closures/etc randomly in `rbx`, `rax`, printing the top of the stack, etc. I was honestly hoping that the context would be a little more informative. However, all hope is not lost. I'm going to use `rr` as suggested by Ben to record the run, and then I'll be able to go to the crash, look at the address we're trying to jump to, and use `reverse-cont` to see who wrote that address there. This however requires me to set up something else than VirtualBox as `rr` needs hardware performance counters that VirtualBox does not support. I got started with this today. In parallel, I might keep doing a few experiments in `gdb` in my existing (VirtualBox) VM. For instance, when looking at the `TcSplice` code yesterday, I saw a few `do` blocks with some important code (as far as annotation handling is concerned) that I haven't looked closely at yet. In particular, I'm not sure whether the code that produces `zonked_wrapped_expr'` could be the problem. I have a reason or two to believe that it's an interesting place to look at, like the fact that I did see some `Data.Data` related symbol _after_ `interpretBCO`, and these few lines of code are where we produce the `Data.Data` dictionary apparently. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14675#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler