This is because we don't have strong requirements about symbol naming.
If every symbol in a FSAL had a unique prefix, or something, then we
could turn that off.  But there are symbols in FSALs that are
duplicate elsewhere, and we need those to resolve to the ones in the
FSALs.

If your FSAL is safe, you can maybe turn that off; some FSALs work
with it, since it's disable when we use ASAN.  However, you really
should be building your FSAL with the same toolchain and flags as
Ganesha is built, or you may get odd results.  I would expect using a
different allocator to cause problems, for example.

Daniel

On Wed, Mar 11, 2020 at 12:51 PM Olivier Garaud
<olivier.garaud@scality.com> wrote:
>
> Hi,
>
> I'm wondering about the way Ganesha loads the FSAL
>
> in load_fsal we have
>>
>> #if defined(LINUX) && !defined(SANITIZE_ADDRESS)
>> dl = dlopen(path, RTLD_NOW | RTLD_LOCAL | RTLD_DEEPBIND);
>> #elif defined(FREEBSD) || defined(SANITIZE_ADDRESS)
>> dl = dlopen(path, RTLD_NOW | RTLD_LOCAL);
>> #endif
>
>
> On my system Ganesha is built with jemalloc but my FSAL is not (it's not using the same build chain)
>
> My FSAL is using malloc_usable_size.
> Ganesha does not use this symbol so it is resolved during dlopen.
> Because the RTLD_DEEPBIND flag is used, the libc version of malloc_usable_size is instead of the jemalloc one which ultimately leads to a crash.
>
> I could make sure both are built with the same allocator but this also happens when I try to dynamically change the memory allocator (LD_PRELOAD tcmalloc).
>
> Looking to the history (back in 2012) the RTLD_DEEPBIND flags has been introduced / removed and finally kept.
>
> Can somebody remember the reason why it is needed ?
> Did someone else had this kind of issue with LD_PRELOAD ?
>
> Thanks for your help,
> Regards,
>
> Olivier
> _______________________________________________
> Devel mailing list -- devel@lists.nfs-ganesha.org
> To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org