| Bug #105380 | result of GROUP_CONCAT is inconsistent when group_concat_max_len becomes larger | ||
|---|---|---|---|
| Submitted: | 29 Oct 2021 9:35 | Modified: | 19 Nov 2021 20:49 |
| Reporter: | Hope Lee (OCA) | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: DML | Severity: | S3 (Non-critical) |
| Version: | 8.0.27 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | Contribution | ||
[29 Oct 2021 9:38]
MySQL Verification Team
Hello Lee, Thank you for the report and test case. regards, Umesh
[2 Nov 2021 10:33]
Hope Lee
Bugfix Arithmetic overflow when group_concat_max_len is set to a large value (*) I confirm the code being submitted is offered under the terms of the OCA, and that I am authorized to contribute it.
Contribution: 0001-Bugfix-Arithmetic-overflow-when-group_concat_max_len.patch (application/octet-stream, text), 2.76 KiB.
[2 Nov 2021 12:19]
MySQL Verification Team
Thank you for the contribution. regards, Umesh
[10 Nov 2021 14:15]
Erlend Dahl
Posted by developer: Actually if you force the string in the group concat to be utf8mb4, the problem reproduces on 5.7. If you force it to be latin1 on 8.0 (default on 5.7), the problem goes away.
[19 Nov 2021 20:49]
Christine Cole
Posted by developer: Fixed as of the upcoming MySQL 8.0.28 release, and here's the proposed changelog entry from the documentation team: The result length of the GROUP_CONCAT() function was wrong when the value of group_concat_max_len was increased. With a small group_concat_max_len value, the result was correct. This issue was caused by arithmetic overflow. Our thanks to Hope Lee for the contribution. Thank you for the bug report.
Description: The result length of function GROUP_CONCAT is wrong even when group_concat_max_len increase. With a small group_concat_max_len, the result is correct. How to repeat: root@localhost:(none) 8.0.27> SET SESSION group_concat_max_len=1024; Query OK, 0 rows affected (0.00 sec) root@localhost:(none) 8.0.27> SELECT LENGTH(t.value) FROM ( SELECT GROUP_CONCAT('32689,34068,34370,34930,37034,37638,38478,38643,38925,39889,40497,41729,43085,43115,43500,44781,46344,46411,47173,47228,47623,48576,50293,50653,51794,54177,55347,55398,59492,59598,59804,59969,60612,62024,62754,62796,64647,68679,68974,69482,69625,70162,71100000') AS value ) t; +-----------------+ | LENGTH(t.value) | +-----------------+ | 260 | +-----------------+ 1 row in set (0.00 sec) root@localhost:(none) 8.0.27> SET SESSION group_concat_max_len=1073741832; Query OK, 0 rows affected (0.00 sec) root@localhost:(none) 8.0.27> SELECT LENGTH(t.value) FROM ( SELECT GROUP_CONCAT('32689,34068,34370,34930,37034,37638,38478,38643,38925,39889,40497,41729,43085,43115,43500,44781,46344,46411,47173,47228,47623,48576,50293,50653,51794,54177,55347,55398,59492,59598,59804,59969,60612,62024,62754,62796,64647,68679,68974,69482,69625,70162,71100000') AS value ) t; +-----------------+ | LENGTH(t.value) | +-----------------+ | 255 | +-----------------+ 1 row in set (0.00 sec) The result of the second execution is obviously wrong. Suggested fix: The root cause of this issue is arithmetic overflow in function `Item_func_group_concat::make_string_field()`, which use the product of `max_characters` (uint32) and `collation.collation->mbmaxlen` (uint) as parameter `len_arg` (uint32) in constructor `Field_blob::Field_blob()`.