MDEV-36345: Add Leak Sanitizer suppression for _dl_catch_exception

[grooverdan]

• The Jira issue number for this PR is: MDEV-36345 and MDEV-35772.

Description

Targeting same branches that the new ASAN builder builds for - MariaDB/buildbot#815

This showed up when executing under ASAN(includes LSAN) the tests in the following order:

• plugins.show_all_plugins
• plugins.simple_password_check
• plugins.sql_error_log
• plugins.two_password_validations
• roles.acl_load_mutex-5170

Or an "INSTALL PLUGIN" (existing or not), followed by "SHUTDOWN" as exhibited in MDEV-35772.

Given the common depth of stack the internal glibc symbol was chosen based on its exception naming and the
msan libunwind bug llvm/llvm-project#84348 that maybe is going into ASAN resolving too.

Release Notes

nothing

How can this PR be tested?

mtr sequence per commit message

Basing the PR against the correct MariaDB version

• This is a new feature or a refactoring, and the PR is based against the main branch.
• This is a bug fix, and the PR is based against the earliest maintained branch in which the bug can be reproduced.

PR quality check

• I checked the CODING_STANDARDS.md file and my PR conforms to this where appropriate.
• For any trivial modifications to the PR, I am ok with the reviewer making the changes themselves.

[vuvova]

This looks way too broad to me. Is there any way to make it more specific?

[grooverdan]

This looks way too broad to me. Is there any way to make it more specific?

Doesn't appear to be. Unlike valgrind suppressions leak sanitizer is a single pattern against a symbol.

https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer#suppressions

I can't explain the existing libtasn1 or libgnutls patterns in this file.

The _dl_catch_exception was chosen as the common point at which dl_open seems to leak. While something else could use the same symbol name it might quickly find itself in conflict.

[grooverdan]

This is the last correction get the 10.11 amd64-ubasan-clang-20 builder green. Is the above acceptable @vuvova

Apparently if the debug-syms of the library isn't there it resolved the supression:

==259662==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 232 byte(s) in 1 object(s) allocated from:
    #0 0x55de9e7c003d in operator new(unsigned long) (/home/buildbot/bld/sql/mariadbd+0x1e1903d) (BuildId: 62a140bff1cc187f265224597f9e12933e64e81b)
    #1 0x7bf8c705a278  (<unknown module>)
    #2 0x7bf8c6d42bb2  (<unknown module>)
    #3 0x7bf8c69ef1d7  (<unknown module>)
    #4 0x7bf8c616ea65  (<unknown module>)
    #5 0x7ff8de0919cd  (/lib64/ld-linux-x86-64.so.2+0x49cd) (BuildId: 3cbc62ba7dc05b522c3e7be640288b1197a92ae3)

Direct leak of 216 byte(s) in 1 object(s) allocated from:
    #0 0x55de9e7c003d in operator new(unsigned long) (/home/buildbot/bld/sql/mariadbd+0x1e1903d) (BuildId: 62a140bff1cc187f265224597f9e12933e64e81b)
    #1 0x7bf8c6d431df  (<unknown module>)
    #2 0x7bf8c6d42be5  (<unknown module>)
    #3 0x7bf8c69ef1d7  (<unknown module>)
    #4 0x7bf8c616ea65  (<unknown module>)
    #5 0x7ff8de0919cd  (/lib64/ld-linux-x86-64.so.2+0x49cd) (BuildId: 3cbc62ba7dc05b522c3e7be640288b1197a92ae3)

SUMMARY: AddressSanitizer: 448 byte(s) leaked in 2 allocation(s).

[vuvova]

Do you know when _dl_catch_exception is called? dl_open leaks can be legitimate bugs — on load it invokes __attribute__((constructor)) functions and C++ object static constructors, and we don't want them to leak memory.

[grooverdan]

Do you know when _dl_catch_exception is called? dl_open leaks can be legitimate bugs — on load it invokes __attribute__((constructor)) functions and C++ object static constructors, and we don't want them to leak memory.

Yes. this is looking more like a legitimate leak in of the plugins. Closing and relooking.