Finding Memory Leaks
I have a rather complex Haskell program that performs an engineering simulation using a lot of large complex valued matrices. The imperative components of the simulation are written in C and interfaced into Haskell which handles the higher level logic. This has served me fairly well, and I've been pleased with both the development style and the performance of my code. However I've run into a fairly major issue with an unresolvable memory leak in the Haskell code. The memory leak is apparent since both private allocated bytes and page file bytes associated with the process increase linearly over time while the process is running. Eventually it causes the process to crash. I believe it's in the Haskell code because I have replaced malloc, free, realloc etc. in the C code with a memory leak detector and the C code appears to free all allocated resources. I also know that the memory leak is due to unmatched free's from a call to malloc from one of the windows XP system libraries. Unfortunately GHC's heap profiler does not reveal the memory leak. All my code is compiled using the -prof -auto flag and then run using +RTS -hc -RTS. The resulting plots do not show a linear increase in heap usage, although the Windows XP operating system does report such an increase. This leaves me in a difficult position in terms of finding the offending code. I am currently resorting to commenting out code line by line, but it's very tedious since I have to preserve the state functionality of the code to get it to run. Is there a way to compile Haskell into C using GHC and then forcing the C code to hook up to the memory leak detecting versions of malloc? I know that GHC can produce intermediary C code, but I have no idea how to access it and how to setup all the run time libraries etc, so that I can compile the C code separately. Any advice for me in this situation would be appreciated.
SevenThunders wrote:
All my code is compiled using the -prof -auto flag and then run using +RTS -hc -RTS. The resulting plots do not show a linear increase in heap usage, although the Windows XP operating system does report such an increase.
This is either a bug in GHC or a bug in the profiler or both unless I am
mistaken.
The bug seems to arise when using FFI and using the wrapper mode for a
Haskell callback.
A pointer to the Haskell wrapper is created on the fly and then supposedly
released by freeHaskellFunPtr.
Unfortunately, at least under Windows XP 64 on my amd x2 3800 box, memory
grows without bound. Even worse, however is the fact that profiling this
function does not reveal the leak at all. It shows a constant memory
profile.
Here is the Haskell program. The actual c program containing cfunc is not
really used in this snippet. (and I can't quite get that to work in this
case for some reason.)
On 11/2/06, SevenThunders
SevenThunders wrote:
All my code is compiled using the -prof -auto flag and then run using +RTS -hc -RTS. The resulting plots do not show a linear increase in heap usage, although the Windows XP operating system does report such an increase.
This is either a bug in GHC or a bug in the profiler or both unless I am mistaken. The bug seems to arise when using FFI and using the wrapper mode for a Haskell callback. A pointer to the Haskell wrapper is created on the fly and then supposedly released by freeHaskellFunPtr.
Unfortunately, at least under Windows XP 64 on my amd x2 3800 box, memory grows without bound. Even worse, however is the fact that profiling this function does not reveal the leak at all. It shows a constant memory profile.
Do any memory leaks show up if you compile with -caf-all when you profile? Jason
Jason Dagit-2 wrote:
Do any memory leaks show up if you compile with -caf-all when you profile?
Jason _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
It doesn't seem to make any difference, although I do not know what this flag does. I compiled the code using ghc -fglasgow-exts -fffi -prof -auto -caf-all -I. --make leaky.hs cleaky.o and did not see the steady ramp up in memory that one sees with the windows xp performance tool. -- View this message in context: http://www.nabble.com/Finding-Memory-Leaks-tf2563630.html#a7151020 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
mattcbro:
Jason Dagit-2 wrote:
Do any memory leaks show up if you compile with -caf-all when you profile?
Jason _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
It doesn't seem to make any difference, although I do not know what this flag does. I compiled the code using ghc -fglasgow-exts -fffi -prof -auto -caf-all -I. --make leaky.hs cleaky.o
and did not see the steady ramp up in memory that one sees with the windows xp performance tool.
Hmm, are you missing a -O ? Does that help at all? -- Don
Donald Bruce Stewart wrote:
Hmm, are you missing a -O ? Does that help at all?
-- Don
Adding the -O does not stop the memory leak problem. As for the profiler, it does make the CAF:main function show more erratic memory spikes, however no memory ramping is revealed even though the operating system performance monitors in windows XP show this ramping effect quite dramatically. By the way I have verified that the memory leaks occur both in windows XP 64 and in ordinary 32 bit windows XP. -- View this message in context: http://www.nabble.com/Finding-Memory-Leaks-tf2563630.html#a7163358 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
participants (4)
-
dons＠cse.unsw.edu.au -
Jason Dagit -
Matthew Bromberg -
SevenThunders