Controlled reproduction attempts
================================

All tests were performed during a controlled maintenance window.

1. Sequential SHOW ENGINE INNODB STATUS
   Approx. 300 executions.
   Result: no crash.

2. Concurrent SHOW ENGINE INNODB STATUS
   5 workers x 300 = approx. 1,500 statements.
   Result: no crash.

3. Record lock wait test
   Locker transaction + 20 waiters.
   5 status workers x 500 = approx. 2,500 status statements.
   Result: no crash.

4. Transaction churn using direct MariaDB endpoint
   10 workers x 5,000 = approx. 50,000 transactions.
   5 workers x 10,000 = approx. 50,000
   SHOW ENGINE INNODB STATUS executions.
   Result: no crash.

5. MDEV-25315-inspired test
   Approx. 500 iterations.
   Result: no crash.

6. Lock/wait churn
   5 lockers, 15 waiters, 5 status workers.
   Result: no crash.

7. Aggressive secondary-index lifetime test
   5 locker workers
   10 waiter workers
   150 DROP/ADD secondary-index iterations
   5 status workers x 20,000 = approx. 100,000
   SHOW ENGINE INNODB STATUS executions.
   Result: no crash.

Conclusion:
The issue is not deterministically reproduced by SHOW ENGINE INNODB STATUS,
lock contention, transaction churn or secondary-index DDL alone.

Production evidence indicates that a rare InnoDB lock/page state is required
before SHOW ENGINE INNODB STATUS enters the observed crashing path.
