| Bug #41441 | repair csv table crashes debug server | ||
|---|---|---|---|
| Submitted: | 12 Dec 2008 16:23 | Modified: | 15 Jan 2009 15:37 |
| Reporter: | Shane Bester (Platinum Quality Contributor) | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: CSV | Severity: | S1 (Critical) |
| Version: | 5.1.30 | OS: | Windows (XP64-bit) |
| Assigned to: | Sergei Glukhov | CPU Architecture: | Any |
[12 Dec 2008 16:23]
Shane Bester
[13 Dec 2008 11:14]
MySQL Verification Team
I used mysql-5.1.30-winx64 version...
[13 Dec 2008 11:18]
MySQL Verification Team
the exact assertion thrown by the runtime library:
Debug Assertion Failed!
File:close.c
Line:48
Expression: (osfile(fh) & FOPEN)
which is here in the runtime code:
int __cdecl _close (
int fh
)
{
int r; /* return value */
/* validate file handle */
_CHECK_FH_CLEAR_OSSERR_RETURN( fh, EBADF, -1 );
_VALIDATE_CLEAR_OSSERR_RETURN((fh >= 0 && (unsigned)fh < (unsigned)_nhandle), EBADF, -1);
_VALIDATE_CLEAR_OSSERR_RETURN((_osfile(fh) & FOPEN), EBADF, -1);
[13 Dec 2008 11:50]
MySQL Verification Team
actually this is a mysql bug, as we see in the following (shortened) debug trace:
my_create.c: 39: | >my_create
my_create.c: 41: | | my: Name: '.\test\t1.CSN' CreateFlags: 0 AccessFlags: 514 MyFlags: 16
my_open.c: 143: | | >my_register_filename
my_open.c: 167: | | | exit: fd: 28
my_open.c: 168: | | <my_register_filename
my_create.c: 78: | <my_create
my_seek.c: 49: | >my_seek
my_seek.c: 52: | | my: Fd: 26 Hpos: 0 Pos: 0 Whence: 0 MyFlags: 0
my_seek.c: 79: | <my_seek
my_read.c: 39: | >my_read
my_read.c: 41: | | my: Fd: 26 Buffer: 0x4ca42a8 Count: 4096 MyFlags: 0
my_read.c: 52: | | warning: Read only 3 bytes off 4096 from 26, errno: -1
my_read.c: 87: | <my_read
my_open.c: 93: | >my_close
my_open.c: 94: | | my: fd: 26 MyFlags: 0
my_open.c: 119: | <my_close
my_open.c: 93: | >my_close
my_open.c: 94: | | my: fd: 28 MyFlags: 0
my_open.c: 119: | <my_close
my_rename.c: 27: | >my_rename
my_rename.c: 28: | | my: from .\test\t1.CSN to .\test\t1.CSV MyFlags 0
my_rename.c: 78: | <my_rename
ha_tina.cc:1444: <ha_tina::repair
sql_table.cc:4379: admin: operator_func returned: -1
sql_table.cc: 792: info: Protocol_text::store field 0 (4): test.t1
sql_table.cc: 792: info: Protocol_text::store field 1 (4): repair
sql_table.cc:4408: info: result_code: -1
sql_table.cc: 792: info: Protocol_text::store field 2 (4): note
sql_table.cc: 792: info: Protocol_text::store field 3 (4): The storage engine for the table doesn't support repair
sql_base.cc:1205: >close_thread_tables
lock.cc: 387: | >mysql_unlock_tables
lock.cc: 393: | <mysql_unlock_tables
sql_base.cc:1340: | >close_thread_table
sql_base.cc:1344: | | tcache: table: 'test'.'t1' 0x4c7f6c8
hash.c: 456: | | >my_hash_delete
sql_base.cc: 788: | | | >free_cache_entry
sql_base.cc: 762: | | | | >intern_close_table
sql_base.cc: 766: | | | | | tcache: table: 'test'.'t1' 0x4c7f6c8
table.cc:1946: | | | | | >closefrm
table.cc:1947: | | | | | | enter: table: 0x4c7f6c8
ha_tina.cc: 856: | | | | | | >ha_tina::close
my_open.c: 93: | | | | | | | >my_close
my_open.c: 94: | | | | | | | | my: fd: 26 MyFlags: 0
notice how a file is created with fd=26, then read, and closed.
then it's closed again later. hence the assertion is valid.
btw, this assertion in the crt is introduced in VS2005 or later.
[13 Dec 2008 12:40]
MySQL Verification Team
Verified on Vista 64-bit: c:\dbs>c:\dbs\5.1\bin\mysqld --defaults-file=c:\dbs\5.1\my.ini --standalone --console 081213 9:31:44 InnoDB: Started; log sequence number 0 46409 081213 9:31:50 [Note] Event Scheduler: Loaded 0 events 081213 9:31:50 [Note] c:\dbs\5.1\bin\mysqld: ready for connections. Version: '5.1.31-nt-debug-log' socket: '' port: 3351 Source distribution 081213 9:33:40 - mysqld got exception 0x80000003 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=8388572 read_buffer_size=131072 max_used_connections=1 max_threads=151 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 338105 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd: 0x41e8158 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... 00000001407B4C2F mysqld.exe!_close()[close.c:48] 0000000140558E38 mysqld.exe!my_close()[my_open.c:99] 000000014065DF48 mysqld.exe!ha_tina::close()[ha_tina.cc:857] 0000000140426B00 mysqld.exe!closefrm()[table.cc:1950] 000000014029EA11 mysqld.exe!intern_close_table()[sql_base.cc:780] 000000014029EB07 mysqld.exe!free_cache_entry()[sql_base.cc:802] 0000000140567EEC mysqld.exe!my_hash_delete()[hash.c:531] 000000014029FECD mysqld.exe!close_thread_table()[sql_base.cc:1366] 000000014029FCA4 mysqld.exe!close_open_tables()[sql_base.cc:1174] 000000014029FA06 mysqld.exe!close_thread_tables()[sql_base.cc:1328] 00000001403EEE31 mysqld.exe!mysql_admin_table()[sql_table.cc:4604] 00000001403EFA20 mysqld.exe!mysql_repair_table()[sql_table.cc:4653] 0000000140323F0B mysqld.exe!mysql_execute_command()[sql_parse.cc:2880] 000000014032E56D mysqld.exe!mysql_parse()[sql_parse.cc:5793] 000000014031F8EA mysqld.exe!dispatch_command()[sql_parse.cc:1202] 000000014031ECDA mysqld.exe!do_command()[sql_parse.cc:857] 000000014047A746 mysqld.exe!handle_one_connection()[sql_connect.cc:1115] 000000014057EB25 mysqld.exe!pthread_start()[my_winthread.c:85] 000000014077A6C5 mysqld.exe!_callthreadstart()[thread.c:295] 000000014077A697 mysqld.exe!_threadstart()[thread.c:277] 000000007770CDCD kernel32.dll!BaseThreadInitThunk() 000000007792C6E1 ntdll.dll!RtlUserThreadStart() Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 00000000042508B8=repair table `t1` thd->thread_id=2 thd->killed=NOT_KILLED The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash. c:\dbs>
[13 Dec 2008 12:55]
MySQL Verification Team
Server binary compiled with VS2005, see prior Shane's comment.
[26 Dec 2008 11:37]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/62345 2754 Sergey Glukhov 2008-12-26 Bug#41441 repair csv table crashes debug server(for 5.1 only) The problem: data file can not be deleted on win because there is another opened instance of this file. Data file might be opened twice, on table opening stage and during write_row execution. We need to close both instances to satisfy Win. The fix is only for 5.1, In 6.0 we have naitive win set of functions, so the fix will be different there.
[26 Dec 2008 11:41]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/62346 2828 Sergey Glukhov 2008-12-26 Bug#41441 repair csv table crashes debug server(for 6.0) File renaming fails on Win because MoveFile() func can not get stat info of repaired file. The fix is to use my_redel() func instead of my_rename.
[29 Dec 2008 12:52]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/62411 2755 Sergey Glukhov 2008-12-29 Bug#41441 repair csv table crashes debug server(for 5.1 only) The problem: data file can not be deleted on win because there is another opened instance of this file. Data file might be opened twice, on table opening stage and during write_row execution. We need to close both instances to satisfy Win.
[29 Dec 2008 12:53]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/62412 2755 Sergey Glukhov 2008-12-29 Bug#41441 repair csv table crashes debug server The problem: data file can not be deleted on win because there is another opened instance of this file. Data file might be opened twice, on table opening stage and during write_row execution. We need to close both instances to satisfy Win.
[15 Jan 2009 6:35]
Bugs System
Pushed into 5.1.31 (revid:joro@sun.com-20090115053147-tx1oapthnzgvs1ro) (version source revid:azundris@mysql.com-20081230114838-cn52tu180wcrvh0h) (merge vers: 5.1.31) (pib:6)
[15 Jan 2009 15:37]
Tony Bedford
An entry was added to the 5.1.31 changelog: When a repair operation was carried out on a CSV table the debug server crashed.
[19 Jan 2009 11:33]
Bugs System
Pushed into 5.1.31-ndb-6.2.17 (revid:tomas.ulin@sun.com-20090119095303-uwwvxiibtr38djii) (version source revid:tomas.ulin@sun.com-20090115073240-1wanl85vlvw2she1) (merge vers: 5.1.31-ndb-6.2.17) (pib:6)
[19 Jan 2009 13:10]
Bugs System
Pushed into 5.1.31-ndb-6.3.21 (revid:tomas.ulin@sun.com-20090119104956-guxz190n2kh31fxl) (version source revid:tomas.ulin@sun.com-20090119104956-guxz190n2kh31fxl) (merge vers: 5.1.31-ndb-6.3.21) (pib:6)
[19 Jan 2009 16:15]
Bugs System
Pushed into 5.1.31-ndb-6.4.1 (revid:tomas.ulin@sun.com-20090119144033-4aylstx5czzz88i5) (version source revid:tomas.ulin@sun.com-20090119144033-4aylstx5czzz88i5) (merge vers: 5.1.31-ndb-6.4.1) (pib:6)
[20 Jan 2009 19:01]
Bugs System
Pushed into 6.0.10-alpha (revid:joro@sun.com-20090119171328-2hemf2ndc1dxl0et) (version source revid:azundris@mysql.com-20081230114916-c290n83z25wkt6e4) (merge vers: 6.0.9-alpha) (pib:6)
