InnoDB: Parallel DDL threads race in debug_sync on the shared THD

[inikep]

What does this change do?

Serializes the four DEBUG_SYNC calls in storage/innobase/ddl/ddl0builder.cc
with a per-ddl::Context mutex, so the parallel DDL threads that share the
connection's THD cannot execute one debug sync action at the same time.

Why is it needed?

The tasks driving ddl::Builder are pulled off a shared queue by whichever DDL
thread is free (ddl::Loader::Task_queue::mt_execute()), so an online ALTER
building several indexes runs setup_sort() / btree_build() / finalize()
concurrently, and every one of those threads passes the same THD -
ddl::Context::thd() - to DEBUG_SYNC. debug_sync() does no locking; it
assumes a sync point is only ever hit by the thread owning the THD.

On a 9.7.2 debug build an ALTER that adds four indexes with
innodb_ddl_threads = 4, with row_log_apply_before armed, kills the server:

mysqld: sql/debug_sync.cc:946: void debug_sync_remove_action(
st_debug_sync_control*, st_debug_sync_action*):
Assertion `dsp_idx < ds_control->ds_active' failed.
 #10 debug_sync_remove_action        sql/debug_sync.cc:946
 #11 debug_sync                      sql/debug_sync.cc:1951
 #12 ddl::Builder::finalize          storage/innobase/ddl/ddl0builder.cc:1994
 #13 ddl::Builder::finish            storage/innobase/ddl/ddl0builder.cc:2086
 #14 ddl::Loader::Task::operator()   storage/innobase/ddl/ddl0builder.cc:2180
 #15 ddl::Loader::Task_queue::mt_execute  storage/innobase/ddl/ddl0loader.cc:178

Every step of debug_sync() races when two threads share the THD, and each has
its own symptom:

• both threads pass the action->activation_count test, then the first consumes
  the last activation while the second is entering debug_sync_execute() -
  Assertion 'action->activation_count' failed;
• both then find activation_count == 0 on the way out and both call
  debug_sync_remove_action() on the same action - the assertion in the stack
  above;
• WAIT_FOR clears the signal it woke up on unless NO_CLEAR_EVENT is given,
  so with two threads waiting on one action the first one out clears the event
  and the second waits for a signal that no longer exists - the ALTER hangs.

The commit message contains a DBUG trace
(--debug=d,debug_sync,debug_sync_exec,debug_sync_point:i:o) showing two DDL
threads inside the one sync point on the one THD, with the second never
resuming.

The mutex is deliberately per context, i.e. per DDL statement and hence per THD.
A single file-static mutex instead hangs innodb.innodb-index-online-purge,
which parks one DDL inside row_log_apply_before and only releases it after a
second, independent DDL has reached the same sync point. It is taken only when
debug sync is armed, mirroring the DEBUG_SYNC macro's own
opt_debug_sync_timeout fast path, and the whole construct compiles away
without ENABLED_DEBUG_SYNC, so release builds are unaffected.

How was it tested?

• Added/updated MTR tests under mysql-test/
• scripts/ci/mtr.sh passes locally
• Ran the relevant full suite (name it): every existing test using these
  sync points - innodb.innodb-alter-varchar-debug,
  innodb.innodb-index-online, innodb.innodb-index-online-purge,
  innodb.virtual_debug, innodb.bulk_create_index_online,
  innodb.ddl_kill, innodb.index-create-dml-rollback,
  gcol.gcol_rollback, plus innodb.innodb-alter-debug and
  innodb.innodb-alter-nullable

New test innodb.ddl_debug_sync_race, in three parts: a reproducer that arms
the sync point with two activations so two builders of one ALTER meet in it, a
stress with a single activation (the shape that hits the
action->activation_count assertion in the field), and a check that the
serialization does not span connections.

Measured on a 9.7.2 debug build (gcc 15, CMAKE_BUILD_TYPE=Debug): unpatched,
the new test crashed the server with the assertion above 5 times in a
--repeat=24 --parallel=8 run and hung in others; patched, the same run passes
24/24.

Re-verified on trunk (06a5c1c) after the rebase, same build configuration:
the same --repeat=24 --parallel=8 run passes 24/24 with the patch, and all
ten existing tests listed above pass. The four sync points and the surrounding
builder code are identical to 9.7.2 there, so the unpatched failure modes apply
unchanged; the crash counts quoted above were measured on the 9.7.2 build.

Contributor checklist

• I have signed the OCA with the email on these commits
• Code is formatted (scripts/ci/format.sh)
• Commits are focused with descriptive messages

AI assistance

• I did not use AI assistance for this contribution
• I used AI assistance for this contribution

Claude Code was used to reproduce the failure, analyse the debug_sync control
block races, write the MTR test and draft this description. The diagnosis was
confirmed against a DBUG trace of the running server, and every claim about
pass/fail behaviour above comes from actual patched and unpatched builds of
9.7.2 rather than from inspection.

Areas touched

innodb (DDL), mysql-test

[oracle-contributor-agreement]

Thank you for your pull request and welcome to our community! To contribute, please sign the Oracle Contributor Agreement (OCA).
The following contributors of this PR have not signed the OCA:

• PR author: inikep

To sign the OCA, please create an Oracle account and sign the OCA in Oracle's Contributor Agreement Application.

When signing the OCA, please provide your GitHub username. After signing the OCA and getting an OCA approval from Oracle, this PR will be automatically updated.

If you are an Oracle employee, please make sure that you are a member of the main Oracle GitHub organization, and your membership in this organization is public.

[inikep]

I confirm the code being submitted is offered under the terms of the OCA, and that I am authorized to contribute it