Windows installation provide the 32 and 64 bits atomic operations and compile
only the relevant part. For 64 bits there is a problem, but I already put a
big comment about it in the configure file ...
This commit was SVN r8480.
may call calloc(large number), which causes ptmalloc2 to call mmap, which
causes us to try to dlsym for mmap, which leads to looping badness.
This commit was SVN r8461.
the ptmalloc2 memory hooks component triggers callbacks for memory
allocation / deallocation. If enabled (the default) it is only when
memory is actually obtained from or released to the OS (so little
malloc calls only trigger callbacks if sbrk is called). If disabled,
callbacks are triggered every time malloc/free/etc. is called
* It turns out that syscall and mmap aren't good friends due to the return
type of mmap and some old legacy issues with syscall functions that
take more than 5 parameters. For now, default to either loading
the symbol from glibc using dlsym or using the __m{un,}map functions.
Thanks to George for finding this.
* Fix some dumb typos in the mmap / munmap catching code
This commit was SVN r8410.
both mmap and munmap), adjusting the configure script so that the
component will only be activated on systems that use ptmalloc2 in the
first place -- ie, Linux
* Remove the malloc_hooks component - it became an unworkable solution
once threads and such were considered.
* Remove malloc_interpose component - it never worked quite right and
was not going to be able to intercept malloc, so it wasn't going to
be useful for OMPI's purposes.
* Update tests a little bit to match recent memory hooks api
issues - still needs a bit of work.
This commit was SVN r8381.
* turns out (duh!) that there was a reason that the <projectdir>dir
variable was set in the AM conditional. If not, stupid directories
are created and not needed... duh.
This commit was SVN r8205.
component/base Makefile.am files, reducing the time configure spends
stamping out Makefiles at the end
* Install base_impl.h file when devel-headers are being installed
This commit was SVN r8200.
When compiling C++ code that includes something that looks for the C++
header file "memory" (stupid C++ headers not having .h extensions), it
goes through the header file search path, which includes $(topsrcdir)/opal,
so it finds the directory $(topsrcdir)/opal/memory/ and tries to load
that as the memory header file and all goes downhill.
This commit was SVN r8111.
test isn't really needed to make sure the malloc intercept code was working,
so just revert to not checking for now.
This should go to the 1.0 branch, as what is there now is causing issues.
This commit was SVN r8081.
this function, and the lock will still be held, so we'd have deadlock.
Instead, unlock, then release. We don't need the lock for calling the
release - we're not modifying any shared variables my that point.
This should probbaly go onto the 1.0 branch, although it would be nearly
impossible to trigger the deadlock with the way we use the free handlers
at present.
This commit was SVN r8057.
