Building with --enable-memory-sanitizer on FreeBSD errors with duplicate strlcpy and strlcat

[outtersg]

Description

./configure --with-pdo-pgsql=$HOME/local --enable-memory-sanitizer
make -j8

ld: error: duplicate symbol: strlcpy
>>> defined at msan_interceptors.cpp
>>>            msan_interceptors.o:(strlcpy) in archive /usr/lib/clang/19/lib/freebsd/libclang_rt.msan-x86_64.a
>>> defined at zend_string.c:507 (Zend/zend_string.c:507)
>>>            Zend/zend_string.o:(.text+0x5500)

And in fact the stock FreeBSD 14.3 clang, as well as my home-compiled ones, define the symbols, contrary to what is suggested in a comment:

/* strlcpy and strlcat are not intercepted by msan, so we need to do it ourselves. */
#if __has_feature(memory_sanitizer)
/* here strlcat and strlcpy are redefined with some msan */
#endif

while, as seen with nm -o:

/usr/lib/clang/19/lib/freebsd/libclang_rt.msan-x86_64.a:msan_interceptors.o:000000000000073f T strlcpy
/home/gui/local/clang+libcxx+omp+rt-20.1.4/lib/clang/20/lib/freebsd/libclang_rt.msan-x86_64.a:msan_interceptors.cpp.o:000000000000073f T strlcpy

The #if should probably be more subtle, from the commit comment it applied to Clang 17 but I can't say to what compiler and versions it should be limited: should it be detected in the configure?

PHP Version

master 2025-09-30

Operating System

No response

[outtersg]

I've seen a reference to clang 18.1.8 still missing them.

[iluuu1994]

Hi. Thanks for the report. Looking at the llvm source code:

https://github.com/llvm/llvm-project/blob/fe9fba8d24f4e7a0cca26fceb621cfa4276d793b/compiler-rt/lib/sanitizer_common/sanitizer_platform_interceptors.h#L568-L569

It seems like strlcpy() is only intercepted on some platforms, including FreeBSD. The same does not go for strlcat(), apparently. It's likely enough to guard the strlcpy() definition with #if !defined(__FreeBSD__) && !defined(__NetBSD__) && !defined(__APPLE__). Maybe you can test that and send a PR? I don't have a FreeBSD machine at hand.

[devnexen]

@iluuu1994 strlcat is also intercepted with the same guards as they go hand in hand in supported platforms anyway.

[iluuu1994]

Nice catch, I missed this. The GitHub search is not always great.

[outtersg]

@iluuu1994 wrote:

It's likely enough to guard the strlcpy() definition with #if !defined(__FreeBSD__) && !defined(__NetBSD__) && !defined(__APPLE__). Maybe you can test that and send a PR? I don't have a FreeBSD machine at hand.

Done (… and tested, of course) in #20032.

Note that this will require some maintenance, as it is hoped that MSAN + glibc will soon include them: then we'll have to add more and more cases where the functions are not to be defined.

At first I hoped to make it a clean configure.ac block (something like AS_VAR_IF([PHP_MEMORY_SANITIZER], [yes], [AC_CACHE_CHECK([if MSAN provides strlcpy], …, [AC_RUN_IFELSE([AC_LANG_SOURCE([ … right after the CFLAGS for MSAN), but I'm not familiar enough with MSAN to know how to test it for sure;
probably have a test program that knowingly does horrible things to memory while strlcpying, and make configure distinguish between a link failure (then not HAVE_STRL_MSAN) and an MSAN failure (then HAVE_STRL_MSAN, because we ensured it is present and errored as needed)?