2014-10-23 22:49 GMT+02:00 Luite Stegeman <stegeman@gmail.com>:

If stability/segfaults are a major factor in choosing to communicate with the GHCi program, rather than using GHC as a library, then this really should be addressed directly. Has anyone done investigation of the situations that make ghc-mod/ghc-server, but not GHCi, crash?

The crashes tend to be related to linker problems (like duplicate symbols, often also in combination with TH) IME.

I think the problem that projects like ghc-mod, hdevtools etc encounter is that the GHC API is quite lowlevel. For example, just look at the code for `:load`: https://github.com/ghc/ghc/blob/5bb73d79a83bca57dc431421ca1e022f34b8dec9/ghc/InteractiveUI.hs#L1343 .

- First, I have no idea what abandonAll is doing here (and hdevtools isn't using it). I guess it is related to GHCi debugger, so that might not be a problem.

- We then unload the active program and call doLoad. doLoad just resets some debugging related things (note that it calls discardActiveBreakPoints again, even though loadModule' already did that) and then calls GHC.load. After that, it calls `afterLoad`, which uses a foreign function calling into the RTS (!) to reset CAFs. As this function is only foreign import'ed in GHCi itself, I'm sure neither ghc-mod nor hdevtools call it.

Needing to call a RTS function just to safely load a new module, replacing the old program, doesn't feel right to me. The problem here is that this `loadModule` function is only inside GHCi, and not exported through the GHC API.

This was just one example, I'm sure there are more. There is just no highlevel GHC API function for most of GHCi's commands.

Another reason for the crashes might be that ghc-mod and hdevtools tend to do many, many more reloads than GHCi, because they reload on every file save (or even after 0.5s idle time). Crashes that only appear very infrequent are thus much more likely to occur in ghc-mod.

--

Benno