upcxx's library exposes dlmalloc symbols

Issue #429 resolved
Max Grossman created an issue

dlmalloc is a commonly used dynamic memory allocator, usually used to add efficient dynamic memory allocation routines on top of some pool of memory. Examples of just a few libraries that use dlmalloc include UPC++, OSSS OpenSHMEM, and nvshmem. There are probably many others I don’t know about.

Because UPC++ uses dlmalloc and makes the dlmalloc APIs externally visible (e.g. mspace_malloc, mspace_realloc), those functions clash with any other libraries that also use dlmalloc and make its APIs externally visible. This causes linker errors like the ones below when trying to link a single app with both UPC++ libraries and some other library using dlmalloc:

/gpfs/alpine/world-shared/csc296/summit/upcxx/gcc-8.1.1/2020.10.0/upcxx.debug.gasnet_seq.ibv/lib/libupcxx.a(dl_malloc.o): In function `mspace_malloc':
/tmp/upcxx-nightly-summit-gcc/bld/upcxx_install/upcxx-2020.10.0/src/./dl_malloc.c:5506: multiple definition of `mspace_malloc'
../nvshmem-install/lib/libnvshmem.a(dlmalloc.o):dlmalloc.cpp:(.text+0xe40): first defined here

A simple solution could be to simply rename dlmalloc APIs in UPC++ to something custom (e.g. upcxx_mspace_malloc).

Comments (3)

  1. Dan Bonachea

    dlmalloc has some compile-time defines that affect its operation (where we use at least two of these), so it would be inappropriate for us to share the same object with other libraries that happen to use dlmalloc.

    So I strongly agree we should really name-shift the routines we use.

    I think the right way to do this is add some clearly-commented #defines to the upcxx-specific section at the top of src/dlmalloc.[ch] that shift the mspace_ routines into upcxx_mspace_ (and similarly for any other public symbols that leak out in our build of dlmalloc). We should avoid changes to the body of dlmalloc.[ch] unless absolutely necessary.

  2. Log in to comment