The attached test case runs GHC in a separate thread (with a single call to runGhc when the thread is started), waiting for compile requests on one channel and outputting "done" on another. Requests consist of a list of filenames to compile. These file names are added as targets and then load LoadAddTargets is called.

On every request we also call setSessionDynFlags with a different log_action. On the first request the log_action is set to dispatcher 0 (defined in forkGhc), on the second request the log_action is set to dispatcher 1, and so on. This dispatcher just outputs the messages it receives from GHC, along with this integer; hence, all messages from the first request should include the integer 0, all messages from the second request should include the integer 1, and so on. However, when the program is run (in a directory containing all the specified source files), the output is

----- 0 ------
(0,"[1 of 2] Compiling B                ( B.hs, B.o )")
(0,"[2 of 2] Compiling Main             ( A.hs, A.o )")
----- 1 ------
(0,"[2 of 2] Compiling Main             ( A.hs, A.o )")
----- 2 ------
(2,"[1 of 1] Compiling Main             ( C.hs, C.o )")
(2,"Linking A ...")

On the first request we ask Ghc to compile A.hs and B.hs; A.hs here depends on B.hs, which is compiled first, but A.hs contains an error and cannot be compiled. Then on the second request we ask GHC to compile A.hs and B.hs again; since B.hs is already compiled it only tries to compile A.hs, but this still fails. On the third request we ask Ghc to compile C.hs, an independent source file.

Note that the integer listed for the second request is 0, not 1. For some reason the setSessionDynFlags does not seem to affect the recompilation of A.hs, even though when we compile C.hs in the third request, the output is 2, as expected.

(This bug also occurs in GHC 7.4, but the API is slightly different so some minor modifications to to the code need to be made.)