More granular UBSAN Frame based filtering

[mariadb-RoelVandePaar]

Assume we have stack like this (obtained using export UBSAN_OPTIONS=print_stacktrace=1:report_error_type=1):

/test/10.6_dbg_san/mysys/mf_keycache.c:5950:11: runtime error: call to function init_simple_key_cache through pointer to incorrect function type 'int (*)(void *, unsigned int, unsigned long, unsigned int, unsigned int, unsigned int)'
/test/10.6_dbg_san/mysys/mf_keycache.c:480: note: init_simple_key_cache defined here
    #0 0x564b85abc73c in init_key_cache_internal /test/10.6_dbg_san/mysys/mf_keycache.c:5950:11
    #1 0x564b85abbc61 in init_key_cache /test/10.6_dbg_san/mysys/mf_keycache.c:6010:10
    #2 0x564b81e7a80c in ha_init_key_cache /test/10.6_dbg_san/sql/handler.cc:6135:5
    #3 0x564b7f07226f in process_key_caches(int (*)(char const*, st_key_cache*, void*), void*) /test/10.6_dbg_san/sql/keycaches.cc:180:12
    #4 0x564b7f0229f7 in init_server_components() /test/10.6_dbg_san/sql/mysqld.cc:5143:3
    #5 0x564b7f016ab0 in mysqld_main(int, char**) /test/10.6_dbg_san/sql/mysqld.cc:5806:7
    #6 0x564b7f001863 in main /test/10.6_dbg_san/sql/main.cc:34:10
    #7 0x14f7dde2a1c9 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    #8 0x14f7dde2a28a in __libc_start_main csu/../csu/libc-start.c:360:3
    #9 0x564b7ef26034 in _start (/test/UBASAN_MD271124-mariadb-10.6.21-linux-x86_64-dbg/bin/mariadbd+0x3eb8034) (BuildId: 3cd87cd3953ac9cf3a930328b34dbd55d44c8146)
 
SUMMARY: UndefinedBehaviorSanitizer: function-type-mismatch /test/10.6_dbg_san/mysys/mf_keycache.c:5950:11 

Then we can add a function:init_key_cache_internal UBSAN runtime supression in some text file like UBSAN.filter and use the same with export UBSAN_OPTIONS=suppressions=${HOME}/UBSAN.filter:print_stacktrace=1:report_error_type=1; etc.

However, this will filter all stacks which have any reference to init_key_cache_internal and as such the filter is significantly too wide.

Note also that the current suppressing/filtering is significantly self-limiting. Over time, functions which occur frequently in stack traces and which were previously suppressed can hide many (or all) issues, even when they are unrelated to the original bug in a more specific frame.

What would be significantly more helpful is something like:

function:init_key_cache_internal->init_key_cache->ha_init_key_cache

Or similar. However, there seems to be no way to currently do this. Is there a way to do this, and if not - can it be added please?

[vitalybuka]

Can you use compile time suppressions?
https://clang.llvm.org/docs/SanitizerSpecialCaseList.html

If possible to change the code, the attribute is ideal suppression https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#disabling-instrumentation-with-attribute-no-sanitize-undefined

[mariadb-RoelVandePaar]

Thank you @vitalybuka. I read the information.

For compile time supressions, it may not improve the current status quo over using runtime supressions?
https://github.com/mariadb-corporation/mariadb-qa/blob/master/UBSAN.filter

While in principle it is possible to change the source code, it is regrettably not practical to use a per-function __attribute__ given that we test many different versions with different code locations, and bugs get resolved over time (we place supressions to supress bugs until they are fixed).

Ideally stack-based UBSAN runtime filtering/supression would be added. Thank you for the input though.

[MaskRay]

Matching the call chain would require a lot of runtime code and it would not work with inlining.
Personally I don't think it is worth implementing in the runtime.

If you want to suppress issues when A calls B while other callers of B are fine, you can fork B to B', make A call B', and add a suppression for B' :)

[mariadb-RoelVandePaar]

@MaskRay Thank you for your thoughts.

We are working on debugging MariaDB server, and so are looking for a runtime-based and especially a scalable and feasible solution.

The requested functionality would seem quite normal when it comes to (stack based) filtering/supression. Furthermore, the current runtime supression functionality has a major shortcoming where an issue is supressed if any frame of the stack matches the supressed [function, code file], even if it is a completely different bug.

For example, consider a fictive bug in do_command() where do_command() is the final frame/actual function having a bug. Supressing/filtering this function would filter/supress as good as all future UBSAN bugs, as this core function appears in almost all stacks.

In other words, without the requested functionality - more granular UBSAN Frame based filtering - all UBSAN testing of complex software would quickly become self-limiting. Thank you

[mariadb-RoelVandePaar]

With the hope this will be implemented soon, and thanks.