1. Big memory leak in division operator example !
The program bellow can be used to see the memory leak,
after the first loop the memory comsumption remain the same,
but after the second it raises to more than 20MB.
Linux XUbuntu 7.04 and Euphoria 3.1
--------
include machine.e
include get.e
integer N
atom x, y, z
object Void
constant RAND_MAX = 1073741823
N = 100000
puts (1, "starting multiply...\n")
Void = wait_key ()
for i = 0 to N -1 do
x = 50.0 * 5
y = 50.0 * 9
z = 50.0 * 976
end for
puts (1, "No memory leak till now !!!\nstarting division...\n")
Void = wait_key ()
for i = 0 to N -1 do
x = 50.0 - (100.0*rand(RAND_MAX)/(RAND_MAX+1.0))
y = 50.0 - (100.0*rand(RAND_MAX)/(RAND_MAX+1.0))
z = 50.0 - (100.0*rand(RAND_MAX)/(RAND_MAX+1.0))
end for
puts (1, "Look at the memory leak now !!!!\nfinished...\n")
Void = wait_key ()
2. Re: Big memory leak in division operator example !
Domingo Alvarez Duarte wrote:
> The program bellow can be used to see the memory leak,
> after the first loop the memory comsumption remain the same,
> but after the second it raises to more than 20MB.
>
> Linux XUbuntu 7.04 and Euphoria 3.1
>
> --------
>
> include machine.e
> include get.e
>
> integer N
> atom x, y, z
> object Void
>
> constant RAND_MAX = 1073741823
>
> N = 100000
>
> puts (1, "starting multiply...\n")
> Void = wait_key ()
>
> for i = 0 to N -1 do
> x = 50.0 * 5
> y = 50.0 * 9
> z = 50.0 * 976
> end for
>
> puts (1, "No memory leak till now !!!\nstarting division...\n")
> Void = wait_key ()
>
> for i = 0 to N -1 do
> x = 50.0 - (100.0*rand(RAND_MAX)/(RAND_MAX+1.0))
> y = 50.0 - (100.0*rand(RAND_MAX)/(RAND_MAX+1.0))
> z = 50.0 - (100.0*rand(RAND_MAX)/(RAND_MAX+1.0))
> end for
>
> puts (1, "Look at the memory leak now !!!!\nfinished...\n")
> Void = wait_key ()
I raised the iterations to N = 10000000, and took out the
wait_key() calls, and couldn't see any memory leak using
ex, exw, or exwc (with Windows Task Manager).
Which Linux command did you use to measure the amount of
memory being used, and does the memory usage
keep rising with more iterations, or does it stop at 20 Mb?
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Big memory leak in division operator example !
Hi Rob
I did copy your setup with the high N and during the divisions Top reported
up to 90 % memory use, in my case 90 % of 1Gb. I'm using Kubuntu 7.04.
Regards
John
4. Re: Big memory leak in division operator example !
- Posted by Domingo Alvarez Duarte <domingo at dad-it.com>
Jun 20, 2007
-
Last edited Jun 21, 2007
I use "top" and watch the memory usage by the proccess at each stop point
I did with more loops and it leaks more memory with more looks.
I'm compiling euphoria with debug enabled to exec it through "valgrind"
because the original euphoria shows several leaks with "valgrind".
I'll show my resuts as soon as I get it !
5. Re: Big memory leak in division operator example !
- Posted by Domingo Alvarez Duarte <domingo at dad-it.com>
Jun 20, 2007
-
Last edited Jun 21, 2007
First valgrind report for program:
----------
include machine.e
include get.e
integer N
atom x, y, z
object Void
constant RAND_MAX = 1073741823
N = 10
puts (1, "No memory leak till now !!!\nstarting division...\n")
Void = wait_key ()
for i = 0 to N -1 do
x = 50.0 - (100.0*rand(RAND_MAX)/(RAND_MAX+1.0))
y = 50.0 - (100.0*rand(RAND_MAX)/(RAND_MAX+1.0))
z = 50.0 - (100.0*rand(RAND_MAX)/(RAND_MAX+1.0))
end for
puts (1, "Look at the memory leak now !!!!\nfinished...\n")
Void = wait_key ()
-------------
The above is a simplified program to don't wait too much for valgrind
analyse it, I called it test-memory-check2.exu.
command used with euphoria compiled with "-g" flag added:
valgrind --leak-check=yes exu test-memory-check2.exu
-----------
$ valgrind --leak-check=yes exu test-memory-leak2.exu
==13416== Memcheck, a memory error detector.
==13416== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==13416== Using LibVEX rev 1658, a library for dynamic binary translation.
==13416== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==13416== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation
framework.
==13416== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==13416== For more details, rerun with: -v
==13416==
No memory leak till now !!!
starting division...
Look at the memory leak now !!!!
finished...
==13416==
==13416== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 1)
==13416== malloc/free: in use at exit: 119,365 bytes in 2,719 blocks.
==13416== malloc/free: 10,156 allocs, 7,437 frees, 543,167 bytes allocated.
==13416== For counts of detected errors, rerun with: -v
==13416== searching for pointers to 2,719 not-freed blocks.
==13416== checked 338,024 bytes.
==13416==
==13416== 8 bytes in 1 blocks are definitely lost in loss record 2 of 19
==13416== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13416== by 0x8085025: eu_startup (be_runtime.c:3624)
==13416== by 0x8049050: (within /home/mingo/euphoria/bin/exu)
==13416==
==13416==
==13416== 48 bytes in 4 blocks are definitely lost in loss record 5 of 19
==13416== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13416== by 0x808C07E: Dminus (be_inline.c:46)
==13416==
==13416==
==13416== 100 bytes in 1 blocks are definitely lost in loss record 8 of 19
==13416== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13416== by 0x808F44E: InitTask (be_task.c:242)
==13416== by 0x8049050: (within /home/mingo/euphoria/bin/exu)
==13416==
==13416==
==13416== 168 bytes in 14 blocks are definitely lost in loss record 10 of 19
==13416== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13416== by 0x808BFC6: NewDouble (be_inline.c:46)
==13416== by 0x8049050: (within /home/mingo/euphoria/bin/exu)
==13416==
==13416==
==13416== 1,932 bytes in 6 blocks are definitely lost in loss record 14 of 19
==13416== at 0x402071B: realloc (vg_replace_malloc.c:306)
==13416== by 0x8085F3D: Append (be_runtime.c:689)
==13416==
==13416==
==13416== 7,800 bytes in 49 blocks are possibly lost in loss record 15 of 19
==13416== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13416== by 0x808D99B: machine (be_machine.c:2523)
==13416==
==13416==
==13416== 47,776 bytes in 537 blocks are definitely lost in loss record 19 of 19
==13416== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13416== by 0x8089CFA: NewS1 (be_alloc.c:752)
==13416== by 0x8049050: (within /home/mingo/euphoria/bin/exu)
==13416==
==13416== LEAK SUMMARY:
==13416== definitely lost: 50,032 bytes in 563 blocks.
==13416== possibly lost: 7,800 bytes in 49 blocks.
==13416== still reachable: 61,533 bytes in 2,107 blocks.
==13416== suppressed: 0 bytes in 0 blocks.
==13416== Reachable blocks (those to which a pointer was found) are not shown.
==13416== To see them, rerun with: --show-reachable=yes
6. Re: Big memory leak in division operator example !
- Posted by Domingo Alvarez Duarte <domingo at dad-it.com>
Jun 20, 2007
-
Last edited Jun 21, 2007
now with this command line:
$ valgrind --show-reachable=yes --leak-check=yes exu test-memory-leak2.exu
==13748== Memcheck, a memory error detector.
==13748== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==13748== Using LibVEX rev 1658, a library for dynamic binary translation.
==13748== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==13748== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation
framework.
==13748== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==13748== For more details, rerun with: -v
==13748==
No memory leak till now !!!
starting division...
Look at the memory leak now !!!!
finished...
==13748==
==13748== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 1)
==13748== malloc/free: in use at exit: 119,365 bytes in 2,719 blocks.
==13748== malloc/free: 10,156 allocs, 7,437 frees, 543,167 bytes allocated.
==13748== For counts of detected errors, rerun with: -v
==13748== searching for pointers to 2,719 not-freed blocks.
==13748== checked 338,024 bytes.
==13748==
==13748== 8 bytes in 1 blocks are still reachable in loss record 1 of 19
==13748== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13748== by 0x8089B9A: be_init (be_main.c:175)
==13748==
==13748==
==13748== 8 bytes in 1 blocks are definitely lost in loss record 2 of 19
==13748== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13748== by 0x8085025: eu_startup (be_runtime.c:3624)
==13748== by 0x8049050: (within /home/mingo/euphoria/bin/exu)
==13748==
==13748==
==13748== 12 bytes in 1 blocks are still reachable in loss record 3 of 19
==13748== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13748== by 0x8083C1F: shift_args (be_runtime.c:4272)
==13748== by 0x8049050: (within /home/mingo/euphoria/bin/exu)
==13748==
==13748==
==13748== 23 bytes in 1 blocks are still reachable in loss record 4 of 19
==13748== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13748== by 0x8089C52: be_init (be_main.c:187)
==13748==
==13748==
==13748== 48 bytes in 4 blocks are definitely lost in loss record 5 of 19
==13748== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13748== by 0x808C07E: Dminus (be_inline.c:46)
==13748==
==13748==
==13748== 100 bytes in 1 blocks are still reachable in loss record 6 of 19
==13748== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13748== by 0x808B2F4: InitTraceWindow (be_rterror.c:222)
==13748==
==13748==
==13748== 100 bytes in 1 blocks are still reachable in loss record 7 of 19
==13748== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13748== by 0x808F44E: InitTask (be_task.c:242)
==13748==
==13748==
==13748== 100 bytes in 1 blocks are definitely lost in loss record 8 of 19
==13748== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13748== by 0x808F44E: InitTask (be_task.c:242)
==13748== by 0x8049050: (within /home/mingo/euphoria/bin/exu)
==13748==
==13748==
==13748== 120 bytes in 10 blocks are still reachable in loss record 9 of 19
==13748== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13748== by 0x8089DEE: tmp_alloc (be_alloc.c:155)
==13748== by 0x8049050: (within /home/mingo/euphoria/bin/exu)
==13748==
==13748==
==13748== 168 bytes in 14 blocks are definitely lost in loss record 10 of 19
==13748== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13748== by 0x808BFC6: NewDouble (be_inline.c:46)
==13748== by 0x8049050: (within /home/mingo/euphoria/bin/exu)
==13748==
==13748==
==13748== 228 bytes in 5 blocks are still reachable in loss record 11 of 19
==13748== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13748== by 0x8089CFA: NewS1 (be_alloc.c:752)
==13748== by 0x8049050: (within /home/mingo/euphoria/bin/exu)
==13748==
==13748==
==13748== 372 bytes in 31 blocks are still reachable in loss record 12 of 19
==13748== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13748== by 0x808C07E: Dminus (be_inline.c:46)
==13748==
==13748==
==13748== 800 bytes in 1 blocks are still reachable in loss record 13 of 19
==13748== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13748== by 0x807D736: InitStack (be_execute.c:693)
==13748==
==13748==
==13748== 1,932 bytes in 6 blocks are definitely lost in loss record 14 of 19
==13748== at 0x402071B: realloc (vg_replace_malloc.c:306)
==13748== by 0x8085F3D: Append (be_runtime.c:689)
==13748==
==13748==
==13748== 7,800 bytes in 49 blocks are possibly lost in loss record 15 of 19
==13748== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13748== by 0x808D99B: machine (be_machine.c:2523)
==13748==
==13748==
==13748== 10,704 bytes in 892 blocks are still reachable in loss record 16 of 19
==13748== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13748== by 0x808BFFE: Dadd (be_inline.c:46)
==13748==
==13748==
==13748== 13,236 bytes in 1,103 blocks are still reachable in loss record 17 of
19
==13748== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13748== by 0x808BFC6: NewDouble (be_inline.c:46)
==13748== by 0x8049050: (within /home/mingo/euphoria/bin/exu)
==13748==
==13748==
==13748== 35,830 bytes in 60 blocks are still reachable in loss record 18 of 19
==13748== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13748== by 0x808D99B: machine (be_machine.c:2523)
==13748== by 0x8049050: (within /home/mingo/euphoria/bin/exu)
==13748==
==13748==
==13748== 47,776 bytes in 537 blocks are definitely lost in loss record 19 of 19
==13748== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13748== by 0x8089CFA: NewS1 (be_alloc.c:752)
==13748== by 0x8049050: (within /home/mingo/euphoria/bin/exu)
==13748==
==13748== LEAK SUMMARY:
==13748== definitely lost: 50,032 bytes in 563 blocks.
==13748== possibly lost: 7,800 bytes in 49 blocks.
==13748== still reachable: 61,533 bytes in 2,107 blocks.
==13748== suppressed: 0 bytes in 0 blocks.
7. Re: Big memory leak in division operator example !
- Posted by Domingo Alvarez Duarte <domingo at dad-it.com>
Jun 20, 2007
-
Last edited Jun 21, 2007
And here is the converte to C program with "-g" flag and under valgrind:
$ valgrind --show-reachable=yes --leak-check=yes ./test-memory-leak2
==13912== Memcheck, a memory error detector.
==13912== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==13912== Using LibVEX rev 1658, a library for dynamic binary translation.
==13912== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==13912== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation
framework.
==13912== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==13912== For more details, rerun with: -v
==13912==
==13912== Invalid write of size 4
==13912== at 0x80536BE: InitTask (be_task.c:273)
==13912== by 0x8048FF0: (within
/home/mingo/downloads/euphoria/euSQLite3/test-memory-leak2)
==13912== Address 0xBE986714 is not stack'd, malloc'd or (recently) free'd
==13912==
==13912== Invalid write of size 4
==13912== at 0x80536C7: InitTask (be_task.c:279)
==13912== by 0x8048FF0: (within
/home/mingo/downloads/euphoria/euSQLite3/test-memory-leak2)
==13912== Address 0xBE9A5714 is not stack'd, malloc'd or (recently) free'd
No memory leak till now !!!
starting division...
Look at the memory leak now !!!!
finished...
==13912==
==13912== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 15 from 1)
==13912== malloc/free: in use at exit: 2,980 bytes in 152 blocks.
==13912== malloc/free: 160 allocs, 8 frees, 4,314 bytes allocated.
==13912== For counts of detected errors, rerun with: -v
==13912== searching for pointers to 152 not-freed blocks.
==13912== checked 261,940 bytes.
==13912==
==13912==
==13912== 4 bytes in 1 blocks are still reachable in loss record 1 of 8
==13912== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13912== by 0x804AD6E: machine (be_machine.c:2523)
==13912== by 0x8048FF0: (within
/home/mingo/downloads/euphoria/euSQLite3/test-memory-leak2)
==13912==
==13912==
==13912== 8 bytes in 1 blocks are still reachable in loss record 2 of 8
==13912== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13912== by 0x804D2FF: shift_args (be_runtime.c:4272)
==13912== by 0x8048FF0: (within
/home/mingo/downloads/euphoria/euSQLite3/test-memory-leak2)
==13912==
==13912==
==13912== 8 bytes in 1 blocks are still reachable in loss record 3 of 8
==13912== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13912== by 0x804E615: eu_startup (be_runtime.c:3624)
==13912== by 0x8048FF0: (within
/home/mingo/downloads/euphoria/euSQLite3/test-memory-leak2)
==13912==
==13912==
==13912== 100 bytes in 1 blocks are still reachable in loss record 4 of 8
==13912== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13912== by 0x8053620: InitTask (be_task.c:242)
==13912== by 0x8048FF0: (within
/home/mingo/downloads/euphoria/euSQLite3/test-memory-leak2)
==13912==
==13912==
==13912== 108 bytes in 9 blocks are definitely lost in loss record 5 of 8
==13912== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13912== by 0x804BC86: NewDouble (be_inline.c:46)
==13912== by 0x8048FF0: (within
/home/mingo/downloads/euphoria/euSQLite3/test-memory-leak2)
==13912==
==13912==
==13912== 120 bytes in 10 blocks are still reachable in loss record 6 of 8
==13912== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13912== by 0x804C71E: tmp_alloc (be_alloc.c:155)
==13912== by 0x8048FF0: (within
/home/mingo/downloads/euphoria/euSQLite3/test-memory-leak2)
==13912==
==13912==
==13912== 1,240 bytes in 13 blocks are definitely lost in loss record 7 of 8
==13912== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13912== by 0x804C62A: NewS1 (be_alloc.c:752)
==13912== by 0x8048FF0: (within
/home/mingo/downloads/euphoria/euSQLite3/test-memory-leak2)
==13912==
==13912==
==13912== 1,392 bytes in 116 blocks are still reachable in loss record 8 of 8
==13912== at 0x4020620: malloc (vg_replace_malloc.c:149)
==13912== by 0x804BC86: NewDouble (be_inline.c:46)
==13912== by 0x8048FF0: (within
/home/mingo/downloads/euphoria/euSQLite3/test-memory-leak2)
==13912==
==13912== LEAK SUMMARY:
==13912== definitely lost: 1,348 bytes in 22 blocks.
==13912== possibly lost: 0 bytes in 0 blocks.
==13912== still reachable: 1,632 bytes in 130 blocks.
==13912== suppressed: 0 bytes in 0 blocks.
8. Re: Big memory leak in division operator example !
- Posted by Domingo Alvarez Duarte <domingo at dad-it.com>
Jun 20, 2007
-
Last edited Jun 21, 2007
This one was done without "-fomit-frame-pointer" and "-g" compiled euphoria
and gives a lot more details:
$ valgrind --show-reachable=yes --leak-check=yes exu test-memory-leak2.exu
==15474== Memcheck, a memory error detector.
==15474== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==15474== Using LibVEX rev 1658, a library for dynamic binary translation.
==15474== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==15474== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation
framework.
==15474== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==15474== For more details, rerun with: -v
==15474==
No memory leak till now !!!
starting division...
Look at the memory leak now !!!!
finished...
==15474==
==15474== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 1)
==15474== malloc/free: in use at exit: 119,365 bytes in 2,719 blocks.
==15474== malloc/free: 10,156 allocs, 7,437 frees, 543,167 bytes allocated.
==15474== For counts of detected errors, rerun with: -v
==15474== searching for pointers to 2,719 not-freed blocks.
==15474== checked 338,092 bytes.
==15474==
==15474== 8 bytes in 1 blocks are still reachable in loss record 1 of 19
==15474== at 0x4020620: malloc (vg_replace_malloc.c:149)
==15474== by 0x8088EDD: be_init (be_main.c:175)
==15474== by 0x808B7FB: start_backend (be_machine.c:4549)
==15474== by 0x808D54E: machine (be_machine.c:4893)
==15474== by 0x807864E: _17BackEnd (backend.c:2032)
==15474== by 0x807A711: _18main (main.c:663)
==15474== by 0x804E004: main0 (main-0.c:416)
==15474== by 0x804D9CF: main (main-.c:2383)
==15474==
==15474==
==15474== 8 bytes in 1 blocks are definitely lost in loss record 2 of 19
==15474== at 0x4020620: malloc (vg_replace_malloc.c:149)
==15474== by 0x8084385: eu_startup (be_runtime.c:3624)
==15474== by 0x8049143: main (main-.c:126)
==15474==
==15474==
==15474== 12 bytes in 1 blocks are still reachable in loss record 3 of 19
==15474== at 0x4020620: malloc (vg_replace_malloc.c:149)
==15474== by 0x8082F80: shift_args (be_runtime.c:4272)
==15474== by 0x8049154: main (main-.c:129)
==15474==
==15474==
==15474== 23 bytes in 1 blocks are still reachable in loss record 4 of 19
==15474== at 0x4020620: malloc (vg_replace_malloc.c:149)
==15474== by 0x8088F96: be_init (be_main.c:187)
==15474== by 0x808B7FB: start_backend (be_machine.c:4549)
==15474== by 0x808D54E: machine (be_machine.c:4893)
==15474== by 0x807864E: _17BackEnd (backend.c:2032)
==15474== by 0x807A711: _18main (main.c:663)
==15474== by 0x804E004: main0 (main-0.c:416)
==15474== by 0x804D9CF: main (main-.c:2383)
==15474==
==15474==
==15474== 48 bytes in 4 blocks are definitely lost in loss record 5 of 19
==15474== at 0x4020620: malloc (vg_replace_malloc.c:149)
==15474== by 0x808B45E: Dminus (be_inline.c:46)
==15474== by 0x807D34F: do_exec (be_execute.c:2379)
==15474== by 0x8082180: Execute (be_execute.c:1396)
==15474== by 0x808B80B: start_backend (be_machine.c:4551)
==15474== by 0x808D54E: machine (be_machine.c:4893)
==15474== by 0x807864E: _17BackEnd (backend.c:2032)
==15474== by 0x807A711: _18main (main.c:663)
==15474== by 0x804E004: main0 (main-0.c:416)
==15474== by 0x804D9CF: main (main-.c:2383)
==15474==
==15474==
==15474== 100 bytes in 1 blocks are still reachable in loss record 6 of 19
==15474== at 0x4020620: malloc (vg_replace_malloc.c:149)
==15474== by 0x808A6A8: InitTraceWindow (be_rterror.c:222)
==15474== by 0x808B7FB: start_backend (be_machine.c:4549)
==15474== by 0x808D54E: machine (be_machine.c:4893)
==15474== by 0x807864E: _17BackEnd (backend.c:2032)
==15474== by 0x807A711: _18main (main.c:663)
==15474== by 0x804E004: main0 (main-0.c:416)
==15474== by 0x804D9CF: main (main-.c:2383)
==15474==
==15474==
==15474== 100 bytes in 1 blocks are still reachable in loss record 7 of 19
==15474== at 0x4020620: malloc (vg_replace_malloc.c:149)
==15474== by 0x808E741: InitTask (be_task.c:242)
==15474== by 0x80823B8: InitExecute (be_execute.c:725)
==15474== by 0x8088F5F: be_init (be_main.c:212)
==15474== by 0x808B7FB: start_backend (be_machine.c:4549)
==15474== by 0x808D54E: machine (be_machine.c:4893)
==15474== by 0x807864E: _17BackEnd (backend.c:2032)
==15474== by 0x807A711: _18main (main.c:663)
==15474== by 0x804E004: main0 (main-0.c:416)
==15474== by 0x804D9CF: main (main-.c:2383)
==15474==
==15474==
==15474== 100 bytes in 1 blocks are definitely lost in loss record 8 of 19
==15474== at 0x4020620: malloc (vg_replace_malloc.c:149)
==15474== by 0x808E741: InitTask (be_task.c:242)
==15474== by 0x8049143: main (main-.c:126)
==15474==
==15474==
==15474== 120 bytes in 10 blocks are still reachable in loss record 9 of 19
==15474== at 0x4020620: malloc (vg_replace_malloc.c:149)
==15474== by 0x8089151: tmp_alloc (be_alloc.c:155)
==15474== by 0x8089174: InitEMalloc (be_alloc.c:185)
==15474== by 0x808436E: eu_startup (be_runtime.c:3621)
==15474== by 0x8049143: main (main-.c:126)
==15474==
==15474==
==15474== 168 bytes in 14 blocks are definitely lost in loss record 10 of 19
==15474== at 0x4020620: malloc (vg_replace_malloc.c:149)
==15474== by 0x808B3A7: NewDouble (be_inline.c:46)
==15474== by 0x804ECFF: init_literal (init-.c:729)
==15474== by 0x8049148: main (main-.c:128)
==15474==
==15474==
==15474== 228 bytes in 5 blocks are still reachable in loss record 11 of 19
==15474== at 0x4020620: malloc (vg_replace_malloc.c:149)
==15474== by 0x808904C: NewS1 (be_alloc.c:752)
==15474== by 0x808910C: NewString (be_alloc.c:771)
==15474== by 0x804E1BE: init_literal (init-.c:559)
==15474== by 0x8049148: main (main-.c:128)
==15474==
==15474==
==15474== 372 bytes in 31 blocks are still reachable in loss record 12 of 19
==15474== at 0x4020620: malloc (vg_replace_malloc.c:149)
==15474== by 0x808B45E: Dminus (be_inline.c:46)
==15474== by 0x8086668: binary_op (be_runtime.c:1881)
==15474== by 0x8073C27: _16compress (compress.c:301)
==15474== by 0x807715C: _17BackEnd (backend.c:851)
==15474== by 0x807A711: _18main (main.c:663)
==15474== by 0x804E004: main0 (main-0.c:416)
==15474== by 0x804D9CF: main (main-.c:2383)
==15474==
==15474==
==15474== 800 bytes in 1 blocks are still reachable in loss record 13 of 19
==15474== at 0x4020620: malloc (vg_replace_malloc.c:149)
==15474== by 0x807C1E8: InitStack (be_execute.c:693)
==15474== by 0x80823B3: InitExecute (be_execute.c:722)
==15474== by 0x8088F5F: be_init (be_main.c:212)
==15474== by 0x808B7FB: start_backend (be_machine.c:4549)
==15474== by 0x808D54E: machine (be_machine.c:4893)
==15474== by 0x807864E: _17BackEnd (backend.c:2032)
==15474== by 0x807A711: _18main (main.c:663)
==15474== by 0x804E004: main0 (main-0.c:416)
==15474== by 0x804D9CF: main (main-.c:2383)
==15474==
==15474==
==15474== 1,932 bytes in 6 blocks are definitely lost in loss record 14 of 19
==15474== at 0x402071B: realloc (vg_replace_malloc.c:306)
==15474== by 0x8085273: Append (be_runtime.c:689)
==15474== by 0x804C2E2: main (main-.c:1710)
==15474==
==15474==
==15474== 7,800 bytes in 49 blocks are possibly lost in loss record 15 of 19
==15474== at 0x4020620: malloc (vg_replace_malloc.c:149)
==15474== by 0x808CD1E: machine (be_machine.c:2523)
==15474== by 0x805098A: _7allocate (machine.c:17)
==15474== by 0x8074B30: _17BackEnd (backend.c:456)
==15474== by 0x807A711: _18main (main.c:663)
==15474== by 0x804E004: main0 (main-0.c:416)
==15474== by 0x804D9CF: main (main-.c:2383)
==15474==
==15474==
==15474== 10,704 bytes in 892 blocks are still reachable in loss record 16 of 19
==15474== at 0x4020620: malloc (vg_replace_malloc.c:149)
==15474== by 0x808B3DE: Dadd (be_inline.c:46)
==15474== by 0x8086668: binary_op (be_runtime.c:1881)
==15474== by 0x8054AEF: _10hashfn (symtab.c:107)
==15474== by 0x8055D99: _10InitSymTab (symtab.c:1280)
==15474== by 0x807A6DE: _18main (main.c:636)
==15474== by 0x804E004: main0 (main-0.c:416)
==15474== by 0x804D9CF: main (main-.c:2383)
==15474==
==15474==
==15474== 13,236 bytes in 1,103 blocks are still reachable in loss record 17 of
19
==15474== at 0x4020620: malloc (vg_replace_malloc.c:149)
==15474== by 0x808B3A7: NewDouble (be_inline.c:46)
==15474== by 0x80493C9: main (main-.c:274)
==15474==
==15474==
==15474== 35,830 bytes in 60 blocks are still reachable in loss record 18 of 19
==15474== at 0x4020620: malloc (vg_replace_malloc.c:149)
==15474== by 0x808CD1E: machine (be_machine.c:2523)
==15474== by 0x805098A: _7allocate (machine.c:17)
==15474== by 0x804941A: main (main-.c:288)
==15474==
==15474==
==15474== 47,776 bytes in 537 blocks are definitely lost in loss record 19 of 19
==15474== at 0x4020620: malloc (vg_replace_malloc.c:149)
==15474== by 0x808904C: NewS1 (be_alloc.c:752)
==15474== by 0x808910C: NewString (be_alloc.c:771)
==15474== by 0x804E0E1: init_literal (init-.c:546)
==15474== by 0x8049148: main (main-.c:128)
==15474==
==15474== LEAK SUMMARY:
==15474== definitely lost: 50,032 bytes in 563 blocks.
==15474== possibly lost: 7,800 bytes in 49 blocks.
==15474== still reachable: 61,533 bytes in 2,107 blocks.
==15474== suppressed: 0 bytes in 0 blocks.
9. Re: Big memory leak in division operator example !
- Posted by Robert Craig <rds at RapidEuphoria.com>
Jun 20, 2007
-
Last edited Jun 21, 2007
On OpenEuphoria.org's Linux machine I see your reported leak
when I run exu for 3.1, but not when I run exu for 3.0.0
Perhaps someone can test some pre-3.1 versions of Euphoria for Linux.
I don't see a leak on Windows or DOS, so I don't think
this is a case of incorrect reference counting, which
would be a cross-platform issue.
I'm not sure that you can trust all the details reported
by valgrind, since Euphoria stores pointers to
f.p. numbers and sequences by shifting the address to
the right by 3 bits, since it "knows" that all allocated blocks
will be on 8-byte (000) boundaries. valgind can't possibly know
that Euphoria is doing this, or take it into account.
I'm guessing something changed recently that may have upset
the "dirty" knowledge that Euphoria for Linux uses regarding
malloc(). e.g. it assumes that the length of a malloc'd block
is stored just before the block.
I don't have time to look at this any further right now.
Matt - did you change something regarding the use of malloc
on Linux? Or was it just for your version of FreeBSD?
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
10. Re: Big memory leak in division operator example !
I downloaded euphoria 3.0 and did the tests mentioned before
and there is no memory leak in respecto to division operator in loops.
It's something that was changed in 3.1 thanks for point that I'll look at
the differences an see if I can find where the problem is.
Thanks for your help till now, I hope that my point can be used
to improve euphoria !
11. Re: Big memory leak in division operator example !
I tested the code but didn't find a memory leak. My CodeSort program
(The old one) had a terrible memory leak. It used over 512MB of RAM plus my
PageFile!! I found out that it had been trying to find a number that did not
exist.
12. Re: Big memory leak in division operator example !
Robert wrote:
>
> Matt - did you change something regarding the use of malloc
> on Linux? Or was it just for your version of FreeBSD?
I don't recall changing anything that should have affected linux, though
it's certainly possible that I did. I'll take a look, although I can't
say how soon. I'm still recovering from moving...
Matt
13. Re: Big memory leak in division operator example !
Matt wrote:
>
> Robert wrote:
> >
> > Matt - did you change something regarding the use of malloc
> > on Linux? Or was it just for your version of FreeBSD?
>
> I don't recall changing anything that should have affected linux, though
> it's certainly possible that I did. I'll take a look, although I can't
> say how soon. I'm still recovering from moving...
>
OK, took a look at svn, and it looks like I switched the memory management
to straight malloc/realloc/free, without any of the custom allocation and
block management.
Matt
14. Re: Big memory leak in division operator example !
Matt Lewis wrote:
> OK, took a look at svn, and it looks like I switched the memory management
> to straight malloc/realloc/free, without any of the custom allocation and
> block management.
I tested on FreeBSD just now, and found that exu for 3.1
can't handle the leak example, but exu for 3.0.2 is OK.
The storage allocation system is very complicated.
I wish I could make it simple and portable,
but I think we would lose too much performance.
Also, it fixes at least one WATCOM bug, and does some other
things.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
