[andrewryan]

Dear Foamers

Checking the memory management of my own application I ran into an invalid free, which I could not find anywhere in my code. Turns out that valgrind complains about invalid free in solvers like icoFoam, here is the complete output:

==4973== Invalid free() / delete / delete[]
==4973==    at 0x4C27D71: free (vg_replace_malloc.c:366)
==4973==    by 0x7408A0A: free_mem (in /lib/libc-2.12.1.so)
==4973==    by 0x74085A1: __libc_freeres (in /lib/libc-2.12.1.so)
==4973==    by 0x4A2366B: _vgnU_freeres (vg_preloaded.c:62)
==4973==    by 0x730F4A4: exit (exit.c:93)
==4973==    by 0x72F4D94: (below main) (libc-start.c:258)
==4973==  Address 0x404dc50 is not stack'd, malloc'd or (recently) free'd
==4973== 
==4973== 
==4973== HEAP SUMMARY:
==4973==     in use at exit: 300 bytes in 11 blocks
==4973==   total heap usage: 202,813 allocs, 202,803 frees, 99,653,936 bytes allocated
==4973== 
==4973== LEAK SUMMARY:
==4973==    definitely lost: 60 bytes in 1 blocks
==4973==    indirectly lost: 240 bytes in 10 blocks
==4973==      possibly lost: 0 bytes in 0 blocks
==4973==    still reachable: 0 bytes in 0 blocks
==4973==         suppressed: 0 bytes in 0 blocks
==4973== Rerun with --leak-check=full to see details of leaked memory
==4973== 
==4973== For counts of detected and suppressed errors, rerun with: -v
==4973== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)

Steps to reproduce: Install valgrind and run valgrind icoFoam in the cavity case in $FOAM_TUTORIALS/incompressible/icoFoam

The same also seems to happen with other solver such as potentialFoam. This looks like a bug to me.

[l_r_mcglashan]

I don't get this error, although I remember getting some like it before and it's something to do with glibc, maybe update that?

Looks identical to this: http://sourceware.org/bugzilla/show_bug.cgi?id=10610

[hjasak]

This is all in POSIX.C with functions like

Foam::userName() (POSIX.C:123)
getpwuid_r (in /lib/libc-2.9.so)
getpwuid (in /lib/libc-2.9.so)

and it is inconsequential. I have recently cleaned up bugs in HashTables as well, but it looks like this is at the level of OS interface and I cannot be bothered to chase it.

If you clean up POSIX.C to do the deletes as needed I will pick up the code, merge it and buy you a beer!

Deal?

Hrv

[l_r_mcglashan]

Is the invalid free not a separate error from the memory leak?

I also don't see how Foam::userName() (POSIX.C:123) is at fault, there's no dynamic memory allocation in there.