<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Issue</th>
<td>
<a href=https://github.com/llvm/llvm-project/issues/135943>135943</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>
UBSAN is very slow when using print_stacktrace=1
</td>
</tr>
<tr>
<th>Labels</th>
<td>
new issue
</td>
</tr>
<tr>
<th>Assignees</th>
<td>
</td>
</tr>
<tr>
<th>Reporter</th>
<td>
mariadb-RoelVandePaar
</td>
</tr>
</table>
<pre>
We are seeing on average a 100x slowdown in SQL queries-per-second when using UBSAN's `print_stacktrace=1` on UB+ASAN MariaDB builds.
For example, when using this SQL in the `mariadb` CLI on MariaDB server 10.5 or 10.6
```
INSTALL SONAME 'ha_rocksdb';
CREATE TABLE T8 (C1 char(5),INDEX(C1)) DEFAULT CHARSET = utf8 ENGINE=RocksDB COMMENT='abcde';
```
The second query will take about 90 seconds with `print_stacktrace=1` in `UBSAN_OPTIONS` and about 4-5 seconds without.
On generic testruns we measure how many queries are executed within a given timeframe, for example 30 seconds, and we are seeing that with `print_stacktrace=1` the number of queries executed is about 1/100th of the amount of queries without `print_stacktrace=1` while using a wide variety of queries.
The overhead of `print_stacktrace=1` thus seems to be about 100x slowdown, at least when it comes to MariaDB testing.
Compiler: Clang 18.1.3 (1), LLVM 18. Build: ASAN+UBSAN
Settings made:
```
export UBSAN_OPTIONS=suppressions=/home/roel/mariadb-qa/UBSAN.filter:print_stacktrace=1:report_error_type=1
export ASAN_OPTIONS=suppressions=${HOME}/mariadb-qa/ASAN.filter:quarantine_size_mb=512:atexit=0:detect_invalid_pointer_pairs=3:dump_instruction_bytes=1:abort_on_error=1:allocator_may_return_null=1
```
ulimits (if relevant):
```
$ ulimit -a
real-time non-blocking time (microseconds, -R) unlimited
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1048576
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) unlimited
real-time priority (-r) 0
stack size (kbytes, -s) 400000
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
```
Please let me know if there is any fix / solution or workaround, as full stacks are required.
</pre>
<img width="1" height="1" alt="" src="http://email.email.llvm.org/o/eJyEVltz4joS_jXipQvKlrk-8GBue1KVkNmQOXveKNlusDay5OgCYX_9VhtIgGEyrqliIunr_rq_brWEc3KrEcesN2G9WUsEXxo7roSVosjaLwbV30IX-EMI28pMcRj_B0FYBIco9RaMBrFDK7YIAuIo-gCnzL4wew1Sw-rfj_Ae0Ep07Rpt22FudAH7EjUER_ifk1W6ZHzggPWj2krt186L_M1bkSNLZjHrR-Tk54TxSbpKl_BE1GYTyIJUheuwKGVRujAW8ENUtULGp5cOfCldw0Nq8CWSm1NwZHn6-EDWzzYd2h1aiKNOD0zz2z_aZ_3o9C9KH5ar1_TxEVbPy_RpDowPSrG2Jn9zRcb4gCUTFqXTl3n6OofXdPI4BzZfsMmUTbqn_4yGwPjw9EeanFdjyEthGR_2GB8xPn1Yzub_3D3Y7I9gNl-kPx9fYfpX-rKavwJLZhD8Zgjz5b8elnOWzF6I1mwC0-enp_nylSUzxgciywv8ZHoZGovS15K0bWQi5Q6wl0qBF28IIjPBwyg67TvYS19-p5vUtNtIvH7-8frwvFzRstDFyVa33bsyZoLvwJHHs4YtarQyB4_O26Ad7BEqFC5YhNLsoRL6cC6vpibxA_PgsWhsSQ0CtnKHGryscGNF1dTG5qtUIPmMhXaI1_6qun0p_B-jpKrSocrQgtl88vnkIt0p2JjxRRxFvqRjBBKVCdpfgk45-M7bvpQKT7UtYC8LhJ2wEv3hwlDnS0uzQ1uiKGj32yCCo6grB95Adhb7qqObHHlQKJw_tpj0kJsKG8y5h0gtqbcnClNT1VKhZUkKUyX0FuJhJ-4k1ADHMp7C4-PfT7QME2ppOpk2l8LkeDk0dlboyaqDShTIktuexI_aWA_XpZbMXKhri85Jo11T-4vSUBUsrEHF-OJ8zb0LxhcNuLORyjd072YqSS2SpzVaa-zaH-rj-ieD9A8Eumww-ev5ac4Gs1v_6ZX79yCs0F5qXDv5P1xXGUtmvZizJBUeP6RnySxiSVqgx9yvpd4JJYt1baT2aNe1kJY8JnQkVPVaamqi3Euj19nBozvFIzIKx-hjROdFpUwuvLHrShzWFn2weq2DUqdgb-6MoGQlvSNN5QYsKtwJ7UndX4RivAvH49AWLEotCtWm_gRtdDtTJn9rGo9WyF4lc2suerT9Qhdf0I0JLFiU5sYibKgpKE9w9TE-bEweofkttBBegMPtHSRB3455ImhxC3V5iUVQxLW20ljpD3D7MT5sIwEp8N8wvENzc-urRl2QI5rUQrk7Bo6-5C2wEh9AdrGACitjD7-NT92DnjC_kL6GVrdQU6NuBLnP9JOuJmAcdYe9AU3ZWtb3E0QDMebw5bEm4JBF6Y_n1cM_UKFz9P54DxgufFJSPyHvtyS_6u638jUk7Vm_5iL4jYDXCXEE6Ub0UXnW4VTN92CXle3vaRAcWqitydG5ewkljuEWuJPWB6F-Ff0XrrtbaFOmTS1-L97HLfDmSvhBUwJBoYcK4U2bPchm6llsJqI-wEZ-AOMLcEYFupboxbU39k1YE3TRDBsHm6AUNLk_jniL70FaLDqtYpwUo2QkWjiOB93uYNTrxVGrHA-TYVTkfDSK-4OoF3XjUT7IeNSP41EciWTYkmMecdroRyPei6MOJoNhPsoRccM3vX6fdSOshFQdpXZVx9htSzoXcBwnvVE3aSmRoXLNg5lzjXtodhnn9H62YwK1s7B1rBsp6bz7MuOlVzhu5gwlYUfPKxqul-_Ve2OnFawal97Xji5UvmB8sZW-DFknNxXjC3Jw-mnX1vwXc8_4oqHl6NFx5L0b8_8HAAD__whWqn0">