* OCaml memory leak issue
@ 2010-11-24 3:54 Kecheng
2010-11-24 4:06 ` [Caml-list] " Edgar Friendly
2010-11-24 7:30 ` Török Edwin
0 siblings, 2 replies; 7+ messages in thread
From: Kecheng @ 2010-11-24 3:54 UTC (permalink / raw)
To: caml-list
[-- Attachment #1: Type: text/plain, Size: 2134 bytes --]
Hi,
I used valgrind to check the memory usage of my OCaml byte code, but I found that a memory leak. I'm very confused what the problem is. I tried a very simple code as following, and compileed it.
+++++++++++++++++++++++
let test =
let a = 1 in
let b = a + 5 in
printf "%d\n" b;
;;
test;;
+++++++++++++++++++++++
And I run valgrind to check:
valgrind --leak-check=yes ./obj/x86_LINUX/test5.byte.exe
I got the following report:
==21692== Memcheck, a memory error detector
==21692== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==21692== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==21692== Command: ./obj/x86_LINUX/test5.byte.exe
==21692==
6
==21692==
==21692== HEAP SUMMARY:
==21692== in use at exit: 430,488 bytes in 20 blocks
==21692== total heap usage: 68 allocs, 48 frees, 446,837 bytes allocated
==21692==
==21692== 120 bytes in 1 blocks are definitely lost in loss record 9 of 17
==21692== at 0x4A05E1C: malloc (vg_replace_malloc.c:195)
==21692== by 0x9AA510: caml_init_major_heap (in /home/kecheng/symbolic_simulation/cvc_test/cvc_1.5/obj/x86_LINUX/test5.byte.exe)
==21692== by 0x9A2A1A: caml_init_gc (in /home/kecheng/symbolic_simulation/cvc_test/cvc_1.5/obj/x86_LINUX/test5.byte.exe)
==21692== by 0x997E9D: caml_main (in /home/kecheng/symbolic_simulation/cvc_test/cvc_1.5/obj/x86_LINUX/test5.byte.exe)
==21692== by 0x9981CB: main (in /home/kecheng/symbolic_simulation/cvc_test/cvc_1.5/obj/x86_LINUX/test5.byte.exe)
==21692==
==21692== LEAK SUMMARY:
==21692== definitely lost: 120 bytes in 1 blocks
==21692== indirectly lost: 0 bytes in 0 blocks
==21692== possibly lost: 0 bytes in 0 blocks
==21692== still reachable: 430,368 bytes in 19 blocks
==21692== suppressed: 0 bytes in 0 blocks
==21692== Reachable blocks (those to which a pointer was found) are not shown.
==21692== To see them, rerun with: --leak-check=full --show-reachable=yes
==21692==
==21692== For counts of detected and suppressed errors, rerun with: -v
==21692== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
Kecheng
2010-11-23
[-- Attachment #2: Type: text/html, Size: 5103 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Caml-list] OCaml memory leak issue
2010-11-24 3:54 OCaml memory leak issue Kecheng
@ 2010-11-24 4:06 ` Edgar Friendly
2010-11-24 7:30 ` Török Edwin
1 sibling, 0 replies; 7+ messages in thread
From: Edgar Friendly @ 2010-11-24 4:06 UTC (permalink / raw)
To: caml-list
[-- Attachment #1: Type: text/plain, Size: 376 bytes --]
On 11/23/2010 07:54 PM, Kecheng wrote:
> let test =
> let a = 1 in
> let b = a + 5 in
> printf "%d\n" b;
> ;;
> test;;
This will finish with a bunch of allocated memory missing pointers to
it. But that's not a problem, because OCaml's GC is capable of freeing
this memory, as opposed to a C program, which would need a pointer to
the memory to free() it.
E.
[-- Attachment #2: Type: text/html, Size: 1085 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Caml-list] OCaml memory leak issue
2010-11-24 3:54 OCaml memory leak issue Kecheng
2010-11-24 4:06 ` [Caml-list] " Edgar Friendly
@ 2010-11-24 7:30 ` Török Edwin
2010-11-24 22:40 ` Goswin von Brederlow
1 sibling, 1 reply; 7+ messages in thread
From: Török Edwin @ 2010-11-24 7:30 UTC (permalink / raw)
To: Kecheng; +Cc: caml-list
On Tue, 23 Nov 2010 19:54:24 -0800
"Kecheng" <kecheng@cecs.pdx.edu> wrote:
> Hi,
>
> I used valgrind to check the memory usage of my OCaml byte code, but
> I found that a memory leak. I'm very confused what the problem is. I
> tried a very simple code as following, and compileed it.
>
> +++++++++++++++++++++++
> let test =
> let a = 1 in
> let b = a + 5 in
> printf "%d\n" b;
> ;;
> test;;
> +++++++++++++++++++++++
I think you need to call the GC on exit explicitly, its not done by
default.
Best regards,
--Edwin
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Caml-list] OCaml memory leak issue
2010-11-24 7:30 ` Török Edwin
@ 2010-11-24 22:40 ` Goswin von Brederlow
2010-11-24 23:41 ` DS
2010-11-25 7:42 ` Christophe TROESTLER
0 siblings, 2 replies; 7+ messages in thread
From: Goswin von Brederlow @ 2010-11-24 22:40 UTC (permalink / raw)
To: Edwin; +Cc: Kecheng, caml-list
Török Edwin <edwintorok@gmail.com> writes:
> On Tue, 23 Nov 2010 19:54:24 -0800
> "Kecheng" <kecheng@cecs.pdx.edu> wrote:
>
>> Hi,
>>
>> I used valgrind to check the memory usage of my OCaml byte code, but
>> I found that a memory leak. I'm very confused what the problem is. I
>> tried a very simple code as following, and compileed it.
>>
>> +++++++++++++++++++++++
>> let test =
>> let a = 1 in
>> let b = a + 5 in
>> printf "%d\n" b;
>> ;;
>> test;;
>> +++++++++++++++++++++++
>
> I think you need to call the GC on exit explicitly, its not done by
> default.
>
> Best regards,
> --Edwin
Correct. Ocaml assumes (or knows which OS does) the OS will free all
resource at exit anyway. No point wasting valuable time doing a GC
sweep.
In case of custom blocks and finalize function I believe this to be an
error. Managing resources that the OS does not free (IPC tokens,
tempfiles, ...) is made much harder due to this.
MfG
Goswin
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Caml-list] OCaml memory leak issue
2010-11-24 22:40 ` Goswin von Brederlow
@ 2010-11-24 23:41 ` DS
2010-11-25 13:27 ` Goswin von Brederlow
2010-11-25 7:42 ` Christophe TROESTLER
1 sibling, 1 reply; 7+ messages in thread
From: DS @ 2010-11-24 23:41 UTC (permalink / raw)
To: caml-list
On 24 Nov 2010, at 23:40, Goswin von Brederlow wrote:
> In case of custom blocks and finalize function I believe this to be an
> error. Managing resources that the OS does not free (IPC tokens,
> tempfiles, ...) is made much harder due to this.
But you can force a final GC run with Pervasives.at_exit Gc.full_major.
Regards.
-DS
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Caml-list] OCaml memory leak issue
2010-11-24 22:40 ` Goswin von Brederlow
2010-11-24 23:41 ` DS
@ 2010-11-25 7:42 ` Christophe TROESTLER
1 sibling, 0 replies; 7+ messages in thread
From: Christophe TROESTLER @ 2010-11-25 7:42 UTC (permalink / raw)
To: goswin-v-b; +Cc: edwintorok, caml-list, kecheng
On Wed, 24 Nov 2010 23:40:03 +0100, Goswin von Brederlow wrote:
>
> In case of custom blocks and finalize function I believe this to be an
> error. Managing resources that the OS does not free (IPC tokens,
> tempfiles, ...) is made much harder due to this.
You also have "at_exit" and weak pointers which can help you to do that.
Best,
C.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Caml-list] OCaml memory leak issue
2010-11-24 23:41 ` DS
@ 2010-11-25 13:27 ` Goswin von Brederlow
0 siblings, 0 replies; 7+ messages in thread
From: Goswin von Brederlow @ 2010-11-25 13:27 UTC (permalink / raw)
To: DS; +Cc: caml-list
DS <ds.caml@sol42.com> writes:
> On 24 Nov 2010, at 23:40, Goswin von Brederlow wrote:
>> In case of custom blocks and finalize function I believe this to be an
>> error. Managing resources that the OS does not free (IPC tokens,
>> tempfiles, ...) is made much harder due to this.
> But you can force a final GC run with Pervasives.at_exit Gc.full_major.
> Regards.
> -DS
But you can't force global variables to be freeed. Imho it would be nice
to have a GC setting where one could tell the runtime to free
everything, including global variables, before it exits.
MfG
Goswin
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-11-25 13:36 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-11-24 3:54 OCaml memory leak issue Kecheng
2010-11-24 4:06 ` [Caml-list] " Edgar Friendly
2010-11-24 7:30 ` Török Edwin
2010-11-24 22:40 ` Goswin von Brederlow
2010-11-24 23:41 ` DS
2010-11-25 13:27 ` Goswin von Brederlow
2010-11-25 7:42 ` Christophe TROESTLER
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).