Thanks for the reply. I have updated the Gambit-C to v4.5.1, changed the vectors to homogeneous s8vectors hopefully to reduce the memory usage, but the same problem arises. I am using gsc, but I am compiling a number of scm files as .o files and load them dynamically into the REPL, is it possible that this is causing the problem?
I will check my program more closely to see if there are any parts that is holding too much memory.
As for the possibility of memory leaks, this puzzles me. In a language with garbage collection, what does it mean to have memory leaks?
Regards, Peter
----- 郵件原件 ---- 寄件人﹕ Marc Feeley feeley@iro.umontreal.ca 收件人 peter lo peter19852001@yahoo.com.hk 副本(CC) gambit-list@iro.umontreal.ca 傳送日期﹕ 2009 年 9月 9 日 星期三 上午 12:03:25 主題: Re: [gambit-list] Regarding garbage collection in Windows XP
On 6-Sep-09, at 11:54 PM, peter lo wrote:
Dear all, I have been using Gambit to write programs for my research, but recently I encounter a problem. When I run some programs, I get this error:
*** ERROR IN ##rest-param-check-heap -- Heap overflow 1> ,b 0 ##rest-param-check-heap 1 trace-back-path 2 find-seq 3 find-seq 4 find-motif-in-occ-list 5 find-motif-in-occ-list 6 find-motif-in-occ-list 7 find-motif-in-fasta-pruned 8 find-motif-in-fasta-pruned 9 find-motif-in-fasta-pruned ... 12 with-output-to-file 13 for-each 14 for-each 15 (interaction) (stdin)@69:1 (for-each (lambda (errL) ... 1> ,t
A ,be would have been more informative, to see the variables in each frame (to have an idea of the type of data you are manipulating).
I am using Gambit-C v4.4.4 on Windows XP with 1.95 GB ram. I have tried rebooting and run again, and have added a call to (##gc) for each run like this:
(for errL '(0.2 0.3) (for s (append game-data-sets tompa-data-sets) (##gc) (with-output-to-file (string-append "motif_finder_res/game_tompa/" s "_g_e_" (number->string errL) "_res.txt") (f0 (find-motif-in-fasta (codify-fasta (read-fasta s) DNA-code) 5 20 (k-best-keeper 50 better-motif) errL)))))
Calling (##gc) explicitly will not help. One way to get more information on what is happening is to add the -:d2 option when you start gsi . This will give you a trace of the GCs that occur, and the size of the heap, size of the live objects, etc.
But the same problem arises, and Windows XP says virtual memory low. Is this a problem of Gambit or Windows XP? Is the garbage collector a mark and sweep one and fragmentation occurrs?
Don't worry about the GC algorithm. Most objects are allocated in an area that is compacted.
My guess is that your program has a memory leak. It may be due to the definition of the "for" macro above. Have you tried compiling your program (I advise using v4.5.1 which has a -exe option to create standalone executables).
Marc
Yahoo!香港提供網上安全攻略,教你如何防範黑客! 請前往 http://hk.promo.yahoo.com/security/ 了解更多!