|
[Sponsors] |
April 2, 2008, 04:19 |
Hi it seems that both import u
|
#1 | ||
Senior Member
Dragos
Join Date: Mar 2009
Posts: 648
Rep Power: 20 |
Hi it seems that both import utilities fluentMeshToFoam/fluent3DMeshToFoam have a memory leak.
The error appears in both release 1.4.1 and development 1.4.1-dev distribution. Here is a small sample msh file that produces this error: fluentMeshToFoamError Here is the valgrind log for fluentMeshToFoam: Quote:
Quote:
|
|||
April 2, 2008, 04:36 |
Just ran it on the tutorials i
|
#2 |
Senior Member
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,419
Rep Power: 26 |
Just ran it on the tutorials icoFoam/elbow/elbow.msh file in 1.4.1 and no problem. Something special about your case? Can you attach it or send it to me?
valgrind fluentMeshToFoam $FOAM_RUN/icoFoam elbow $FOAM_TUTORIALS/icoFoam/elbow/elbow.msh .. End ==4387== ==4387== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 1) ==4387== malloc/free: in use at exit: 0 bytes in 0 blocks. ==4387== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==4387== For counts of detected errors, rerun with: -v ==4387== All heap blocks were freed -- no leaks are possible. |
|
April 2, 2008, 04:48 |
Hi Mattijs,
As I put it above
|
#3 |
Senior Member
Dragos
Join Date: Mar 2009
Posts: 648
Rep Power: 20 |
Hi Mattijs,
As I put it above, the sample msh file can be downloaded from: fluentMeshToFoamError, and represents just 2 cylinders one on top of another. The first is discretized using hexahedra, whereas the second is discretized using tetrahedra: Thank you for looking at it, Dragos |
|
April 2, 2008, 07:00 |
Hmm,
I've just tried it on th
|
#4 | |
Senior Member
Dragos
Join Date: Mar 2009
Posts: 648
Rep Power: 20 |
Hmm,
I've just tried it on the elbow mesh, and I get the same error: Quote:
What version of valgrind are you using? Dragos |
||
April 2, 2008, 10:32 |
valgrind 3.2.3 and 3.3.0 both
|
#5 |
Senior Member
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,419
Rep Power: 26 |
valgrind 3.2.3 and 3.3.0 both give 0 errors. Maybe there is a difference in the (f)lex versions and the bug is in the flex part. Feel free to debug it ;-)
|
|
April 2, 2008, 10:39 |
Ok, thanks for the support, I'
|
#6 |
Senior Member
Dragos
Join Date: Mar 2009
Posts: 648
Rep Power: 20 |
Ok, thanks for the support, I'll try.
Though the flex part should not play a role here since the realease version 1.4.1 is not compiled by me (I've donwloaded the binaries together with the sources). Dragos |
|
April 3, 2008, 09:13 |
Hello again,
I did some more
|
#7 | ||
Senior Member
Dragos
Join Date: Mar 2009
Posts: 648
Rep Power: 20 |
Hello again,
I did some more tests on different machines, both at the office and at home (all 64bit). On all of them, I get the same result from valgrind: Quote:
Quote:
- OpenFoam-1.4.1 on Suse 10.1 64 bit - OpenFoam-1.4.1-dev on Suse 10.1 64 bit - OpenFoam-1.4.1 on OpenSuse 10.3 64 bit - OpenFoam-1.4.1-dev on OpenSuse 10.3 64 bit - OpenFoam-1.4 on CentOS 4.6 (32 bit OS on 64 bit proc) They all show a memory leak in valgrind: valgrind fluentMeshToFoam ./ elbow elbow/elbow.msh Anyone out there can please confirm this? Just run the above command. Thanks, Dragos |
|||
April 3, 2008, 09:57 |
A new test on Linux evs-008 2.
|
#8 | |
Senior Member
Dragos
Join Date: Mar 2009
Posts: 648
Rep Power: 20 |
A new test on Linux evs-008 2.6.18-5-686 #1 SMP Wed Oct 3 00:12:50 UTC 2007 i686 GNU/Linux
Debian GNU/Linux 4.0 with the same command: valgrind fluentMeshToFoam ./ elbow elbow/elbow.msh gives the following: Quote:
|
||
May 15, 2008, 18:47 |
I to get this problem on Fedor
|
#9 |
New Member
adam mitchell
Join Date: Mar 2009
Posts: 1
Rep Power: 0 |
I to get this problem on Fedora Core release 6 (Zod)
valgrind fluentMeshToFoam ./ elbow elbow/elbow.msh ==22808== Invalid free() / delete / delete[] ==22808== at 0x4A0548E: free (vg_replace_malloc.c:233) ==22808== by 0x3594702DAA: free_mem (in /lib64/libc-2.5.so) ==22808== by 0x35947029C1: __libc_freeres (in /lib64/libc-2.5.so) ==22808== by 0x4802314: _vgnU_freeres (vg_preloaded.c:60) ==22808== by 0x3594632EA4: exit (in /lib64/libc-2.5.so) ==22808== by 0x359461DA4A: (below main) (in /lib64/libc-2.5.so) ==22808== Address 0x773EAC0 is not stack'd, malloc'd or (recently) free'd ==22808== ==22808== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 5 from 1) ==22808== malloc/free: in use at exit: 8 bytes in 1 blocks. ==22808== malloc/free: 111,669 allocs, 111,669 frees, 5,932,062 bytes allocated. ==22808== For counts of detected errors, rerun with: -v ==22808== searching for pointers to 1 not-freed blocks. ==22808== checked 599,960 bytes. ==22808== ==22808== LEAK SUMMARY: ==22808== definitely lost: 8 bytes in 1 blocks. ==22808== possibly lost: 0 bytes in 0 blocks. ==22808== still reachable: 0 bytes in 0 blocks. ==22808== suppressed: 0 bytes in 0 blocks. ==22808== Use --leak-check=full to see details of leaked memory. |
|
May 16, 2008, 03:17 |
Both 1.4.1 and 1.5beta give me
|
#10 |
Senior Member
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,419
Rep Power: 26 |
Both 1.4.1 and 1.5beta give me:
==27496== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 1) with --leak-check=full it reports that the two leaks are in - yyFlexLexer::yyensure_buffer_stack() and - getpwuid_r@@GLIBC_2.2.5 neither I think are anything to do with us. Running 4.2.1 & 4.2.2 gcc, OpenSuse 10.2, 64bit mode, double precision. |
|
May 19, 2008, 02:56 |
It seems that you're right Mat
|
#11 |
Senior Member
Dragos
Join Date: Mar 2009
Posts: 648
Rep Power: 20 |
It seems that you're right Mattijs, I found on the internet several posts related to this error (but on different topics: Memory leak in flex generated file). There are also some work around's, so as soon as I have time I will try one of them.
...but first I have to learn flex and its capability. Dragos |
|
|
|