GHC Heap Issue

[JDGallag]

Greetings,

It appears that programs compiled with ghc --make, directly to machine code may violate the running memory of other programs. This bug begins with trying to debug a text editor written in Haskell that was interfering with other applications in unexpected and undesirable ways.

The most obvious sign that GHC may be producing code that affects the memory of other running programs can be seen in the following.

import Control.DeepSeq

strictString xs = (deepseq xs) xs

main = do
    -- The really big file is just A...A (100 times) printed for a few thousand lines
    t <- readFile really_Big_File
    strictString t

Compiling and running the above program caused crashes on most applications I ran it at the same time with. Most noticeably, with the music players, Amarok, VLC, and Enna. With any of the music players running and playing a song, I could run the above program for about seconds. This was just long enough to get a result, but not long enough that I ran out of memory; in fact, 2 seconds was chosen because it left 1GB of memory in RAM (on average). The program was killed and the RAM use went back down by another 1GB. Then, after everything was closed, the music players began producing strange noises. The track was still running, but the music had been changed to an odd beeping popping sequence that seemed almost regular. Pausing and resuming the music did not change anything the weird noise continued. However, when a new song was loaded the song played as normal. I performed other tests, and they all seemed to suggest that GHC programs are capable of overwriting the memory of other programs.

This example may seem contrived, and it is, but it gets at the heart of the matter. When sending text to a display buffer in gtk, the text must be strictly evaluated, and loading the really large file causes exactly the same errors as the above example. It should be possible to provide sanity checks at run time, and make sure the data you are working with is safe. However, I still have the question: why is(or is) GHC overwriting the memory of running programs?

[dons]

Operating systems don't work like that: they do not have access to other processes' memory (or address space).

What you're observing is the kernel struggling to keep memory available for all the programs you are running, and possible, the effect of swapping memory from ram to disk. In particular, real time programs, like music decoders, will stutter and fail to keep it together when there's a lot of contention for memory.

In summary: don't try to allocate really big files while running music players, unless you expect interference from the operating system as it juggles all the work you're giving it.