MDBF-1185 msan/ubsan/asan with clang 22#912
Conversation
a8aae3f to
fc7bff6
Compare
|
Hi, @grooverdan ! My suggestion is to use This is the estimated load of this patch: https://github.com/MariaDB/buildbot/actions/runs/22293877010?pr=912
|
063a9c2 to
2531155
Compare
Arch: amd64
note llvm/clang 22 release hasn't happened. I think we'll container rebuild when that happens for a better dev test. |
Thanks, @grooverdan . I am asking this because merging to DEV it is also a commitment to "soon will be released in buildbot production" and if this is not happening anytime soon it might get reverted if I want to do a release. |
|
Released - hence #916
I've done the local #916 build and its passed its non-debug builds, server 10.11 on MSAN and ASAN/UBSAN. I'm not expecting massive failure. Sure - lets take a non-merged test on DEV If you've got time to trigger a 10.11, main, and if resources 11.4 (as a middle), I'll go through the results and report back here. |
2531155 to
ff553bf
Compare
912ac74 to
5d07cfb
Compare
|
Guys, sorry, missed that one, let me know if still relevant! |
|
@fauust This is to configure the @grooverdan Since clang-22 builders are resource demanding, the plan would be:
|
done |
|
Hi, @grooverdan ! Here's the patch status on all branches, from the HEAD commits at the time of triggering.
|
|
Thanks. Yikes. 10.6 was only intended to gain clang-22-msan per constants. Bugs lodged and linked to MDBF-1185. view/cursor bugs waiting on merge up. ubasasn-debug - normal failures - waiting on mroonga merge up (10.11 only still) and connector ODBC update or code error supressions.
|
Here we phase in clang 22 as a msan and ubasan builder. New builders get sg_bbw1 as a worker. If all goes well, we'll remove clang-20 out.
With the new clang 22 msan, ubasan builders there is the opportunity to test new suites/options. As new versions generally allow a little time to experiment with different options, added an experimental option to helpers. The spider suite is enabled in Debug but not RelWithDeb info Debug is proved stable, so check if the non-debug is also. This proved quick and stable locally. On testing cursor and view protocols on msan and ubasan in both debug and non-debug, the ubasan non-debug was showing the same few trivial tests to correct as elsewhere and ran significantly faster. msan view showed a test failure that occurred without MSAN. This was fast enough in a non-debug mode.
asan_ubsan - mtr + reporter after view/cursor tests
|
Looks good but now the capacity of the target worker is only: So we can only host 2 builders given we scale them down to parallel=10, |
|
So I've a small preference for option1 freeing more resources and requiring less consequential changes. Edit: ODBC mem leaks need https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1141600 as a stable backport (preferably) otherwise we pull a testing/unstable into the Deb 13 msan image. Option 1: Drop
|
@grooverdan Option 1 seems like a good plan. The way I look at it: For a future protected branches we should use Hetzner, preferably 3 workers. hz-bbw6 (27/96):
^ OK, enough capacity. hz-bbw8 and hz-bbw9 (105/110):
^ not ok, there's an extra + 8. What can we sacrifice? MSAN-20 DEBUG? sg-bbw1 (0/20):
^ enough capacity, I don't want to use this worker for protected builders hence adding it as a backup worker for UBASAN CLANG 22 DEBUG. |

Here we phase in clang 22 as a msan and ubasan builder.
If all goes well, we'll remove clang-20 out.
Add New Build template
Checklist