#5186: GHC Heap Issue
---------------------------------+------------------------------------------
Reporter: JDGallag | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.0.3 | Keywords:
Testcase: | Blockedby:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
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?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5186>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
