How to identify a potential memory leak in guile programs?

How to identify a potential memory leak in guile programs?

[Hengqing Hu]

Dear list,

I wrote a small program in scheme interpreted by guile.
It is used to find identical code blocks in a file or directory.
The problem I have is, when the contents of directory is large,
the memory used by the program keeps increasing and finally
when memory is used up, I get the following error:
ERROR: In procedure primitive-fork:
ERROR: Cannot allocate memory

Can somebody help to look into the code and tell me what's wrong?
The guile version used is guile-1.8.8-5.fc18.2.x86_64 on fedora 18.

You can find the program here:
https://github.com/hudayou/fib

-- 
Best Regards, Hengqing Hu

Re: How to identify a potential memory leak in guile programs?

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 939 bytes --]

() Hengqing Hu <hengqing.hu@gmail.com>
() Tue, 22 Jan 2013 16:51:04 +0800

   Can somebody help to look into the code and tell me what's wrong?

I don't know if this is the only problem, but certainly it contributes.
The proc ‘enumerate-interval’ consumes stack unnnecessarily.

 guile> (enumerate-interval 3 500)
 ERROR: Stack overflow
 ABORT: (stack-overflow)

Here is another implementation that doesn't have that problem.

 (define (enumerate-interval low high)
   (map (lambda (i)
          (+ i low))
        (iota (- high low -1))))

-- 
Thien-Thi Nguyen ..................................... GPG key: 4C807502
.                  NB: ttn at glug dot org is not me                   .
.                 (and has not been since 2007 or so)                  .
.                        ACCEPT NO SUBSTITUTES                         .
........... please send technical questions to mailing lists ...........

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: How to identify a potential memory leak in guile programs?

[Hengqing Hu]

After make it iterative, the fault disappears.
Many thanks to the help!

 (define (enumerate-interval low high)
-  (if (> low high)
-    nil
-    (cons low (enumerate-interval (+ low 1) high))))
+  (let loop ((i high)
+             (interval nil))
+    (if (< i low)
+      interval
+      (loop (- i 1) (cons i interval)))))


On Tue, Jan 22, 2013 at 7:14 PM, Thien-Thi Nguyen <ttn@gnuvola.org> wrote:
> () Hengqing Hu <hengqing.hu@gmail.com>
> () Tue, 22 Jan 2013 16:51:04 +0800
>
>    Can somebody help to look into the code and tell me what's wrong?
>
> I don't know if this is the only problem, but certainly it contributes.
> The proc ‘enumerate-interval’ consumes stack unnnecessarily.
>
>  guile> (enumerate-interval 3 500)
>  ERROR: Stack overflow
>  ABORT: (stack-overflow)
>
> Here is another implementation that doesn't have that problem.
>
>  (define (enumerate-interval low high)
>    (map (lambda (i)
>           (+ i low))
>         (iota (- high low -1))))
>
> --
> Thien-Thi Nguyen ..................................... GPG key: 4C807502
> .                  NB: ttn at glug dot org is not me                   .
> .                 (and has not been since 2007 or so)                  .
> .                        ACCEPT NO SUBSTITUTES                         .
> ........... please send technical questions to mailing lists ...........



-- 
Best Regards, Hengqing Hu

Re: How to identify a potential memory leak in guile programs?

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]

() Hengqing Hu <hengqing.hu@gmail.com>
() Tue, 22 Jan 2013 23:09:00 +0800

   After make it iterative, the fault disappears.
   Many thanks to the help!

    (define (enumerate-interval low high)
   -  (if (> low high)
   -    nil
   -    (cons low (enumerate-interval (+ low 1) high))))
   +  (let loop ((i high)
   +             (interval nil))
   +    (if (< i low)
   +      interval
   +      (loop (- i 1) (cons i interval)))))

Cool.  I see that the new implementation is not only iterative, but also
non-destructive (like the old) and tail-recursive (unlike the old).

-- 
Thien-Thi Nguyen ..................................... GPG key: 4C807502
.                  NB: ttn at glug dot org is not me                   .
.                 (and has not been since 2007 or so)                  .
.                        ACCEPT NO SUBSTITUTES                         .
........... please send technical questions to mailing lists ...........

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]