-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
MDEV-37510: crash when tracing with max_sel_arg_weight equal to 1 #4505
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: 11.4
Are you sure you want to change the base?
MDEV-37510: crash when tracing with max_sel_arg_weight equal to 1 #4505
Conversation
When the optimizer_max_sel_arg_weight is set to 1, a nested query crashed while tracing. SEL_ARG object has a field named 'field', that is not set when the type is other than KEY_RANGE. But, the field was accessed to store its name, and weight to the trace. This resulted in a crash due to NULL pointer. Added a check to access field if the type is KEY_RANGE, and if not, just trace the type.
426c6e5 to
6fd75f1
Compare
| ) | ||
| ) | ||
| WHERE t1.c1 NOT IN (5, 6, 7); | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't believe this is the minimal testcase.
Please try to reduce it as much as possible.
Tables need to have two records to avoid the "1-row table is const table" code path.
when one sees
CREATE TABLE t2 (c1 INT, c2 VARCHAR(10), c3 VARCHAR(10) DEFAULT NULL);
one wonders what is DEFAULT NULL there for? It's not needed in any case, please remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure
| { | ||
| obj.add("key1_field", key1->field->field_name); | ||
| obj.add("key1_weight", (longlong) key1->weight); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please print key1_weight and key2_weight in any case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok
| obj.add("key2_weight", (longlong) key2->weight); | ||
| } | ||
| else | ||
| obj.add("key2_type", (uint) key2->type); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is non-intuitive which condition the SEL_ARG with key2_type=X was made of...
But I see that SEL_ARG::part might not be set either. Ok, let's not bother and just print 'key2_type'.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am thinking to print type and weight for both key1, and key2. Additionally if key1 type is RANGE then also print the field name. What do you think?
| add("key1_weight", (longlong)key1->weight). | ||
| add("key2_weight", (longlong)key2->weight); | ||
|
|
||
| if (key1->type == SEL_ARG::KEY_RANGE && key1->field) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIU we rely that key1->field is available for type=KEY_RANGE, so please leave just the KEY_RANGE check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok
When the optimizer_max_sel_arg_weight is set to 1, a nested query crashed while tracing.
SEL_ARG object has a field named 'field', that is not set when the type is other than KEY_RANGE. But, the field was accessed to store its name, and weight to the trace. This resulted in a crash due to NULL pointer.
Added a check to access field if the type is KEY_RANGE, and if not, just trace the type.