Bug #90487 init_read_record not always followed by end_read_record on some error paths

• Submitted: 18 Apr 2018 6:45
• Modified: 18 Apr 2018 12:49
• Reporter: Laurynas Biveinis (OCA)
• Status: Verified
• Category: MySQL Server: DML
• Severity: S3 (Non-critical)
• Version: 5.7.21
• OS: Any
• CPU Architecture: Any

[18 Apr 2018 6:45] Laurynas Biveinis

Description:
init_read_record requires end_read_record to be called to free resources. This is not ensured in some cases.

1) mysql_update in sql_update.cc:

          error= init_read_record(&info, thd, NULL, &qep_tab, 0, 1, FALSE);
...
        if (open_cached_file(tempfile, mysql_tmpdir,TEMP_PREFIX,
                             DISK_BUFFER_SIZE, MYF(MY_WME)))
...
          goto exit_without_my_ok;
...
        while (!(error=info.read_record(&info))
        {
...
        }
...
        end_read_record(&info);
...
exit_without_my_ok:
...

Here, open_cached_file error after init_read_record will result in jump to exit_without_my_ok, skipping end_read_record.

2) Sql_cmd_delete::mysql_delete in sql_delete.cc:

      error= init_read_record(&info, thd, NULL, &qep_tab, 1, 1, FALSE);
...
    if (select_lex->has_ft_funcs() && init_ftfuncs(thd, select_lex))
      goto exit_without_my_ok;
...
   /* More processing here which might set thd->error? */
...
    if (thd->is_error())
      goto exit_without_my_ok;
...
    while (!(error=info.read_record(&info))
    {
...
    }
...
    end_read_record(&info);
...
exit_without_my_ok:
...

Same scenario.

How to repeat:
Code analysis

Suggested fix:
Ensure end_read_record being always called

[18 Apr 2018 12:49] MySQL Verification Team

Hi Laurynas,

I have inspected the source codes that you pointed to and I must agree with you.

Verified as reported.