
I've been getting a segfault whenever I try to run my program with +RTS -hc (having compiled with profiling enabled). Any idea what might cause this, or how I might track it down? I am using ghc 6.0.1, and see this problem on both linux (debian testing) and macos X. On macos X the crash log looks like it's crashing in heapCensusChain. My program uses ForeignPtrs quite a bit, so my only (rather weak) theory is that perhaps the profiler is trying to look at the contents of my ForeignPtrs? In a sort of related question, is there any way I can make the heap size decrease? In my test case, the memory usage peaks pretty early, and then it keeps running for another few hours. It would be nice if it could shrink the heap again to release swap. And actually, even though according to +RTS -Sstderr my live memory usage drops, the heap size (as seen by top) keeps going up (a megabyte every second or so) until the process gets killed because it's eaten up all the swap and memory. :( I suspect the problem may be in the allocation I'm doing via ForeignPtrs, but I'm not sure how to track anything down without profiling working. Any suggestions would be appreciated. -- David Roundy http://www.abridgegame.org

Just one more data point. Running under valgrind I get the following errors: ==8773== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==8773== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==8773== Using valgrind-20030725, a program supervision framework for x86-linux. ==8773== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==8773== Estimated CPU clock rate is 697 MHz ==8773== For more details, rerun with: -v ==8773== ==8773== Source and destination overlap in strcpy(0x8311830, 0x8311833) ==8773== at 0x400216BF: strcpy (mac_replace_strmem.c:87) ==8773== by 0x82A2B45: time_str (in /home/droundy/darcs/darcs) ==8773== by 0x40330E3D: __libc_start_main (in /lib/libc-2.3.2.so) ==8773== by 0x8049F50: (within /home/droundy/darcs/darcs) ==8773== ==8773== Invalid read of size 2 ==8773== at 0x829E3E6: heapCensusChain (in /home/droundy/darcs/darcs) ==8773== Address 0xFFFFFFFC is not stack'd, malloc'd or free'd Segmentation fault I don't know if the overlapping source and destinations in strcpy are the problem or not. The address 0xFFFFFFFC is also being accessed when I run on MacOS X. -- David Roundy http://www.abridgegame.org
participants (1)
-
David Roundy