[MDEV-29264] JSON function overflow error based on LONGTEXT field Created: 2022-08-06  Updated: 2022-08-16  Resolved: 2022-08-15

Status: Closed
Project: MariaDB Server
Component/s: JSON, Storage Engine - ColumnStore
Affects Version/s: 10.6.7, 10.7.3, 10.8.2, 10.8.3, 10.9.1
Fix Version/s: 10.6.9, 10.7.5, 10.8.4, 10.9.2, 10.10.1

Type: Bug Priority: Major
Reporter: ziyitan Assignee: Rucha Deodhar
Resolution: Fixed Votes: 0
Labels: gsoc22
Environment:

Rockylinux 8 arm64



 Description   

Hi, I'm GSoC 2022 contributor, I'm working on the MCOL-785.
Now I have a problem: The JSON Function result is truncated when the function is called based on LONGTEXT field.

Take the JSON_ARRAY as an example:

MariaDB root@(none):test> create table t1(t TEXT, l LONGTEXT) engine=columnstore;
Query OK, 0 rows affected
Time: 0.147s
MariaDB root@(none):test> insert into t1 values('key1', 'key1');
Query OK, 1 row affected
Time: 0.179s
MariaDB root@(none):test> select json_array(t), json_array(l) from t1;
+---------------+---------------+
| json_array(t) | json_array(l) |
+---------------+---------------+
| ["key1"]      | ["key         |
+---------------+---------------+
1 row in set
Time: 0.097s
MariaDB root@(none):test>

After debugging, I found that such difference is caused by overflow error.

bool Item_func_json_array::fix_length_and_dec(THD *thd)
{
  ulonglong char_length= 2;
...
  for (n_arg=0 ; n_arg < arg_count ; n_arg++)
    char_length+= args[n_arg]->max_char_length() + 4;
...
}

First, the return type of args[n_arg]- >max_char_length() is uint32, the max value of uint32 is 4,294,967,295.
When called based on LONGTEXT, the result of args[n_arg]- >max_char_length() is 4,294,967,295(Maximum value of LONGTEXT). So args[n_arg]->max_char_length()+4 will be 3 due to overflow. And there is no overflow when calling based on TEXT.

I will make a patch to this issue. I would be very grateful if you can handle it soon.

same issues exist in JSON_OBJECT, JSON_ARRAY_APPEND(INSERT), JSON_INSERT(REPLACE|SET)


Generated at Thu Feb 08 10:07:09 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.