[MDEV-29117] Error on close of 'C:\xampp\mysql\data\aria_log_control' (Errcode: 9 "Bad file descriptor") (large import) Created: 2022-07-18  Updated: 2023-09-19

Status: Open
Project: MariaDB Server
Component/s: Platform Windows, Storage Engine - Aria
Affects Version/s: 10.4.24
Fix Version/s: 10.3

Type: Bug Priority: Major
Reporter: Daniel Black Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Environment:

Windows, XAMPP



 Description   

from stackoverflow question:

I noticed the 2nd time now that MySQL crashes/corrupts itself a while after doing a (big) database import from an SQL file which was created by exporting the database from the server in PHPMyAdmin

2022-07-18  0:17:24 0 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2022-07-18  0:17:24 0 [Note] InnoDB: Uses event mutexes
2022-07-18  0:17:24 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-07-18  0:17:24 0 [Note] InnoDB: Number of pools: 1
2022-07-18  0:17:24 0 [Note] InnoDB: Using SSE2 crc32 instructions
2022-07-18  0:17:24 0 [Note] InnoDB: Initializing buffer pool, total size = 16M, instances = 1, chunk size = 16M
2022-07-18  0:17:24 0 [Note] InnoDB: Completed initialization of buffer pool
2022-07-18  0:17:24 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2022-07-18  0:17:24 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2022-07-18  0:17:24 0 [Note] InnoDB: Setting file 'C:\xampp\mysql\data\ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2022-07-18  0:17:24 0 [Note] InnoDB: File 'C:\xampp\mysql\data\ibtmp1' size is now 12 MB.
2022-07-18  0:17:24 0 [Note] InnoDB: Waiting for purge to start
2022-07-18  0:17:24 0 [Note] InnoDB: 10.4.24 started; log sequence number 56544792; transaction id 997
2022-07-18  0:17:24 0 [Note] InnoDB: Loading buffer pool(s) from C:\xampp\mysql\data\ib_buffer_pool
2022-07-18  0:17:24 0 [Note] Plugin 'FEEDBACK' is disabled.
2022-07-18  0:17:24 0 [Note] InnoDB: Buffer pool(s) load completed at 220718  0:17:24
2022-07-18  0:17:24 0 [Note] Server socket created on IP: '::'.

Event log

The description for Event ID 100 from source MariaDB cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
 
If the event originated on another computer, the display information had to be saved with the event.
 
The following information was included with the event: 
 
mysqld.exe: Error on close of 'C:\xampp\mysql\data\aria_log_control' (Errcode: 9 "Bad file descriptor")
 
The system cannot find the file specified



 Comments   
Comment by Daniel Black [ 2022-07-18 ]

The management of control_file_fd in storage/maria/ma_control_file.c appears sound.

There appears to be a case in my_win_sopen where if my_open_osfhandle exceeds my_file_limit a file will be closed but still returned as opened by:

diff --git a/mysys/my_winfile.c b/mysys/my_winfile.c
index 0c76eb25560..350b4d142e4 100644
--- a/mysys/my_winfile.c
+++ b/mysys/my_winfile.c
@@ -263,6 +263,7 @@ File my_win_sopen(const char *path, int oflag, int shflag, int pmode)
     oflag & (_O_APPEND | _O_RDONLY | _O_TEXT))) == -1)
   {
     CloseHandle(osfh);
+    DBUG_RETURN(-1);
   }
 
   DBUG_RETURN(fh);                   /* return handle */

This would prevent the return of a closed file handle. The one server use of ma_control_file_open in ha_maria_init might cope with this correctly.

Comment by Vladislav Vaintroub [ 2022-07-18 ]

danblack, nope, not really. That code is fine.

The code you're quoting goes like this. Note the fh and osfh variables, those mean 2 different things.

  if ((fh= my_open_osfhandle(osfh, 
    oflag & (_O_APPEND | _O_RDONLY | _O_TEXT))) == -1)
  {
    CloseHandle(osfh);
  }
 
  DBUG_RETURN(fh);                   /* return handle */

There is no need to insert DBUG_RETURN(-1) after CloseHandle in case of error, it will be done anyway, after the "if" block

slightly simplified, the current logic is this

fh = my_open_osfhandle(osfh...);
if(fh == -1)
  CloseHandle(osfh);
return fh;

There is no need to change it.

Comment by Daniel Black [ 2022-07-18 ]

Quite right thanks. I'm at a bit of a loss to the the cause of a double close now.

Comment by Bully WiiPlaza [ 2022-07-20 ]

Hello, I'm the guy who reported the bug on StackOverflow. Since this is a major issue I would very much appreciate to learn about a potential workaround or what the actual issue now is so that I can diagnose it properly and peacefully continue working on my project. How exactly is something like this even happening on such an old and reliable DB engine? It's really odd to me. My usage of MySQL is quite straight-forward and nothing out of the ordinary. It may sound ignorant but using more modern C++ may be clever for modernizing and improving file system related code using e.g. the excellent C+17 filesystem instead of this messy low-level C stuff where issues are more opaque than e.g. when a C+ exception is thrown. Either way, thanks for the effort and I hope to hear back soon.

Comment by Daniel Black [ 2022-07-20 ]

From SO:

For reference, about how many tables are in your SQL file. Are these Aria, InnoDB or a mix?

A procmon recording that is limited to the actions on aria_log_control might be useful (or at least excluding the large writes of a database import).

Comment by Bully WiiPlaza [ 2022-07-26 ]

@Daniel: What about me sending you the database schema and database dump so that you can load both yourself and see about this bug? I'm willing to send you the files privately since they are not too confidential. Is your e-mail address on Jira fine?

Comment by Daniel Black [ 2022-07-27 ]

Sure.

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