Details
-
Task
-
Status: Open (View Workflow)
-
Trivial
-
Resolution: Unresolved
-
None
-
None
Description
We often get failures where the EXPLAIN output is different somewhere in the middle of a test file:
main.statistics_json [ fail ]
|
Test ended at 2026-04-26 19:40:36
|
 |
CURRENT_TEST: main.statistics_json
|
--- /optane/dev-git2/13.0-context-replay/mysql-test/main/statistics_json.result 2026-04-24 13:53:12.213385977 +0300
|
+++ /optane/dev-git2/13.0-context-replay/mysql-test/main/statistics_json.reject 2026-04-26 19:40:36.430342374 +0300
|
@@ -4504,7 +4504,7 @@
|
00000000000000000000711C711C711C711C711CE338E338E338E338E33855555555555555555555C671C671C671C671C671388E388E388E388E388EAAAAAAAAAAAAAAAAAAAA1BC71BC71BC71BC71BC78DE38DE38DE38DE38DE3FFFFFFFFFFFFFFFFFFFF
|
explain extended select * from t1_bin where a between 'a-3a' and 'zzzzzzzzz';
|
id select_type table type possible_keys key key_len ref rows filtered Extra
|
-1 SIMPLE t1_bin ALL NULL NULL NULL NULL 10 58.82 Using where
|
+1 SIMPLE t1_bin ALL NULL NULL NULL NULL 10 10.00 Using where
|
Warnings:
|
Note 1003 select `test`.`t1_bin`.`a` AS `a` from `test`.`t1_bin` where `test`.`t1_bin`.`a` between 'a-3a' and 'zzzzzzzzz'
|
analyze select * from t1_bin where a between 'a-3a' and 'zzzzzzzzz';
|
One can debug those in two ways:
A. Extract the testcase from the file and run it.
This is easy to do when
- the testcase doesn't include a lot of context (server variables set, tables filled etc)
- the testcase is ran in normal mode.
B. Run the testcase with --gdb or --manual-gdb.
Then, it's a challenge to have execution stop exactly at the breaking query.
How to fix this
Server source code: mtr_breakpoint()
Add to the server a debug-only dummy function:
#ifndef DBUG_OFF
|
void mtr_breakpoint() { return; } |
#endif |
Make sure the server calls it whenever one runs:
set @debug_break_now=1; |
(Note that @debug_break_now is a user variable, not system variable).
(TODO: alternatively could create an SQL-level function, SELECT debug_break_now()?)
mysql-test-run part
One can look at the test failure example above
@@ -4504,7 +4504,7 @@
|
000000000000000000...
|
explain extended select * from t1_bin where a between 'a-3a' and 'zzzzzzzzz'; |
and observe that the failing EXPLAIN is on line 4505.
So, one could run
./mysql-test-run --manual-gdb --result-breakpoint=4505 test_case
|
When mtr sees that it is about to run a query which will be written into .reject file into line
4505, it runs set @debug_break_now=1; against the server.
That hits the breakpoint.
Set the breakpoint in gdbinit
mysql-test-run creates mysql-test/var/tmp/gdbinit.mysqld.1 file.
when --result-breakpoint=... argument is present, the gdbinit file should include "break mtr_breakpoint" to
set the breakpoint.