The issue described here affects testing regularly. It leads to some wasted work as existing bugs/asserts are incorrectly identified as new issues given the different stack they sporadically produce (ref below).
What happens is this: for various bugs/testcases (have captured different ones below), the original assert will be produced (correct assert + SIGABRT), but the stack will always be in the frames Diagnostics_area::set_error_status from THD::raise_condition from THD::raise_condition from my_message_sql.
An example of such observed asserts (uniqueID's):
At some point I thought there to be a connection to these bugs, but I no longer believe this. Instead, it seems that (during the server crash/testcase replay), quite sporadically, the Diagnostics_area::set_error_status codepath is followed and the assertion (likely "any assertion", though maybe only for sporadic bugs/testcases) is presented with the Diagnostics_area::set_error_status as crashing frame.
It would seem to make little sense to connect the stacks of these assertions with the bugs in question, though let me know if you think otherwise.
It may be that this expression of the issue is 10.6 only (TBD). I have set it to 10.6 for the time being. The issue seems to have become much more prevalent lately.
It may also be specifically connected with issues which produce many different asserts across different versions like
MDEV-25317 and MDEV-22660.
I have seen this Diagnostics_area::set_error_status sporadic issue in 10.5 before too, but the result was different in that the assert was not displayed. The assert now showing could be a result of the small code patch which we do before building as previously discussed with Daniel Black. https://github.com/mariadb-corporation/mariadb-qa/blob/master/build_mdpsms_dbg.sh#L267-L270
The issue seems sporadic and not readily repeatable.