Memory leaks

[destructor64]

When we ran the ipic3d pilot code yesterday, the runtime died with "double free or corruption" errors.

We wanted to investigate this and used valgrind, which reports quite a few errors.

To evaluate whether the problem lies in the runtime/HPX or our compiler, we compiled an empty main with our compiler. The result is the same.

To report the problem here we tried with the latest version of the master branch and also there we get error reports.

Since in the default compiler configuration there are no tests I tried with the provided examples.
Some of these examples crash immediately (stencil_1d_pfor and stencil_2d_pfor). Others run for ages (pfor/*) and the ones which run in "reasonable" time in valgrind report errors (fibonacci and uts/uts).

These problems should be investigated and fixed

[sithhell]

On 10/12/2017 12:44 PM, peterz-dps wrote: When we ran the ipic3d pilot code yesterday, the runtime died with "double free or corruption" errors. We wanted to investigate this and used valgrind, which reports quite a few errors. To evaluate whether the problem lies in the runtime/HPX or our compiler, we compiled an empty main with our compiler. The result is the same. To report the problem here we tried with the latest version of the master branch and also there we get error reports. Since in the default compiler configuration there are no tests I tried with the provided examples. Some of these examples crash immediately (stencil_1d_pfor and stencil_2d_pfor). Others run for ages (pfor/*) and the ones which run in "reasonable" time in valgrind report errors (fibonacci and uts/uts). These problems should be investigated and fixed

I strongly recommend not to use valgrind. In order to get reasonable results in a timely fashion, you should use the address sanitizer coming with clang. To use them, you have to configure HPX with: -DHPX_WITH_SANITIZERS=On and also adapt your CMAKE_CXX_FLAGS to contain: -fsanitize=address -fno-omit-frame-pointer Please note that you should also have boost built with the same flags, otherwise you will get false positives.

[destructor64]

That is another option, but doesn't change the problem. The runtime or HPX seem to have problems there...

To quote from the valgrind report:

Conditional jump or move depends on uninitialised value(s)
[...]
// the above repeated multiple times...
[...]
Invalid read of size 8
[...]
==19277== LEAK SUMMARY:
==19277==    definitely lost: 754,552 bytes in 3,938 blocks
==19277==    indirectly lost: 418,870 bytes in 2,185 blocks
==19277==      possibly lost: 0 bytes in 0 blocks
==19277==    still reachable: 628,085 bytes in 7,155 blocks
==19277==         suppressed: 0 bytes in 0 blocks

[sithhell]

On 10/12/2017 01:03 PM, peterz-dps wrote: That is another option, but doesn't change the problem. The runtime or HPX seem to have problems there...

valgrind is known to have quite a few false positives. Especially the uninitialised values reports are mostly very misleading and might be the result of some optimizations. The leaked memory might be due to statics and/or thread local variables. TBH, I stopped caring about valgrind since it is too slow and requires a maintained suppression file to eliminate the false positives. Nevertheless, if you intend to run HPX programs under the valgrind memchecker, you need to add HPX_WITH_VALGRIND=On to the CMake cache and rebuild. This avoids some false positives due to the user level context switching. A very outdated memcheck suppression file, can be found here: https://github.com/STEllAR-GROUP/hpx/blob/master/tools/valgrind/memcheck.supp

…

To quote from the valgrind report: |Conditional jump or move depends on uninitialised value(s) [...] // the above repeated multiple times... [...] Invalid read of size 8 [...] ==19277== LEAK SUMMARY: ==19277== definitely lost: 754,552 bytes in 3,938 blocks ==19277== indirectly lost: 418,870 bytes in 2,185 blocks ==19277== possibly lost: 0 bytes in 0 blocks ==19277== still reachable: 628,085 bytes in 7,155 blocks ==19277== suppressed: 0 bytes in 0 blocks | — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#17 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADRl1Rbukb-b8Euk6ZSigXUppjDtT9Pks5srfHsgaJpZM4P20IE>.

[sithhell]

Did you rerun with my suggestions or even tried address sanitizer?