SUMMARY
A number of us have been working on getting valgrind 3.13 working well on FreeBSD.  Commit 64aa729bfae7 changed some logic which is interacting badly with FreeBSD's dynamic linker.  Our linker, when loading a shared library, mmap()s the first page of the file to read its ELF header; the header is unmapped once the task of loading the object is finished.  The problem is that the header is mapped at a non-fixed address which may be reused during a subsequent load of a different file.  When the reuse occurs and the new file is activated, valgrind believes that the new file overlaps with the old one and erroneously discards symbols for the old file.

STEPS TO REPRODUCE
1. Check out commit 1c7e497629539f73c5bc364b3e13dea8358fd76c from github.com/freebsdfoundation/valgrind and build valgrind on FreeBSD-CURRENT.
2. Run memcheck on any application which uses malloc().

OBSERVED RESULT
memcheck reports zero heap usage because the bug described above breaks redirection of malloc().

ADDITIONAL INFORMATION
I attempted my own fix: https://github.com/FreeBSDFoundation/valgrind/commit/2c57a7b44a52d5e944dcc5686d6733bf2b917f32

The idea is to track whether a given segment was mapped with MAP_FIXED, and ignore mappings of ELF objections if the mapping is read-only and not fixed.  It seems to work, but since we currently have quite a few failing regression tests on FreeBSD it's hard to determine whether it introduces new problems.