| Bug #12517 | MySQL Server crashes when closing connexion | ||
|---|---|---|---|
| Submitted: | 11 Aug 2005 10:07 | Modified: | 14 Sep 2005 1:03 |
| Reporter: | Emmanuel KARTMANN | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Replication | Severity: | S1 (Critical) |
| Version: | 4.1.13a | OS: | Any (any) |
| Assigned to: | Sergey Vlasenko | CPU Architecture: | Any |
[11 Aug 2005 10:08]
Emmanuel KARTMANN
Prepare the crash - this script create a database and a SQL table (empty)
Attachment: mysql_crash_prepare.sql (text/plain), 443 bytes.
[11 Aug 2005 10:09]
Emmanuel KARTMANN
This script crashes MySQL when connexion is closed
Attachment: mysql_crash.sql (text/plain), 481 bytes.
[11 Aug 2005 20:52]
MySQL Verification Team
Verified with 4.1.14-debug-log (I was able to repeat it on Linux too)
[12 Aug 2005 14:23]
Andrey Hristov
0xa5a5a5a5 means that the memory was never initialized. In debug builds A5 is the magic number used for initializing malloced memory.
[24 Aug 2005 15: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/internals/28759
[26 Aug 2005 13:49]
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/internals/28895
[30 Aug 2005 13:22]
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/internals/29028
[8 Sep 2005 8:09]
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/internals/29480
[12 Sep 2005 15:18]
Sergey Vlasenko
Patch is available in 4.1.15 & 5.0.13
[14 Sep 2005 1:03]
Paul DuBois
Noted in 4.1.15, 5.0.13 changelogs.
[21 Oct 2005 7:06]
Emmanuel KARTMANN
Bug seems to be fixed in 4.1.15 (yeah!). Cheers, E.
Description: After execution of a specific SQL script ("killer queries"), MySQL crashes while trying to close the connexion (a normal close/cleanup). The error occurs ONLY if the BINARY LOG is active. The call stack is as follows: > mysqld-debug.exe!MYSQL_LOG::write(Log_event * event_info=0x0bd5fe94) Line 1383 + 0x30 C++ mysqld-debug.exe!close_temporary_tables(THD * thd=0x0b863eb8) Line 543 C++ mysqld-debug.exe!THD::cleanup() Line 356 + 0x9 C++ mysqld-debug.exe!end_thread(THD * thd=0x0b863eb8, int put_in_cache=1) Line 1480 C++ mysqld-debug.exe!handle_one_connection(void * arg=0x0b8760f0) Line 1076 + 0xb C++ mysqld-debug.exe!pthread_start(void * param=0x00dea030) Line 63 + 0x7 C mysqld-debug.exe!_threadstart(void * ptd=0x00deddb0) Line 173 + 0xd C kernel32.dll!7c80b50b() Source code at this point is: User_var_log_event e(thd, user_var_event->user_var_event->name.str, user_var_event->user_var_event->name.length, user_var_event->value, user_var_event->length, user_var_event->type, user_var_event->charset_number); Pointer user_var_event is OK, but user_var_event->user_var_event is NOT - error is "Unhandled exception at 0x00477d70 in mysqld-debug.exe: 0xC0000005: Access violation reading location 0xa5a5a5a9."... How to repeat: Start MySQL in debug/console mode with binary log enabled: "C:\Program Files\MySQL\MySQL Server 4.1\bin\mysqld-debug.exe" --console --data="C:\Program Files\MySQL\MySQL Server 4.1\data" --log-bin ... C:\Program Files\MySQL\MySQL Server 4.1\bin\mysqld-debug.exe: ready for connecti ons. Version: '4.1.13-debug-log' socket: '' port: 3306 Official MySQL binary In another window, start mySQL client to prepare the crash (just create a specific database/table): C:\> "C:\Program Files\MySQL\MySQL Server 4.1\bin\mysql.exe" -u root -p < mysql_crash_prepare.sql Enter password: **** Then execute the client to cause the crash on the server (you can repeat the crash by re-executing this command only): C:\> "C:\Program Files\MySQL\MySQL Server 4.1\bin\mysql.exe" -u root -p < mysql_crash.sql Enter password: **** MySQL crashes - and in debug mode you get a dialog box "DBUG" with text "Test signal"; click on OK and MySQL crashes - you get the Windows dialog box saying "mysqld-debug.exe has encountered a problem and needs to close. We are sorry for the inconvenience.". If you have JIT debugging enabled, you can click on the debug button in this dialog box... Please note that the release version of MySQL seems to trap the signals SIGSEGV (segment violation) and does not crash everytime; but it still does crash from time to time... The "killer queries" are attached to this bug report; they are very simple: create a temporary file, initialize a user variable and then use this variable in a DELETE query (which should be logged into the binary log): CREATE TEMPORARY TABLE mysql_crash.my_temporary_table(id INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY); SET @id := 1; DELETE FROM mysql_crash.my_table WHERE id LIKE @id; Suggested fix: I guess this is a pointer copy issue - copying pointer value instead of allocating memory for pointer's sub-fields. When copying variables entries to be logged into binary log (I guess it's done in sql\item_func.cpp on line 2913) you should allocate memory for user_var_event->user_var_event: user_var_event->user_var_event= new user_var_entry(var_entry); And then implement a copy constructor for user_var_entry class (allocating memory). But this is just a guess...