Bug #36704 multi-table update with derived tables cause crash
Submitted: 14 May 2008 0:24 Modified: 29 Jun 2010 6:58
Reporter: Shane Bester (Platinum Quality Contributor) Email Updates:
Status: Can't repeat Impact on me:
None 
Category:MySQL Server: DML Severity:S1 (Critical)
Version:5.1.24, 5.1.26, 5.1.30 OS:Any
Assigned to: CPU Architecture:Any

[14 May 2008 0:24] Shane Bester 
Description:
while testing more stored procedures containing various statements running in 12 threads, this crash happened:

mysqld.exe!create_tmp_field_from_field
mysqld.exe!create_tmp_field
mysqld.exe!create_tmp_table
mysqld.exe!select_union::create_result_table
mysqld.exe!mysql_derived_prepare
mysqld.exe!mysql_handle_derived
mysqld.exe!mysql_multi_update_prepare
mysqld.exe!mysql_execute_command
mysqld.exe!sp_instr_stmt::exec_core
mysqld.exe!sp_lex_keeper::reset_lex_and_exec_core
mysqld.exe!sp_instr_stmt::execute
mysqld.exe!sp_head::execute
mysqld.exe!sp_head::execute_procedure
mysqld.exe!mysql_execute_command
mysqld.exe!mysql_parse
mysqld.exe!dispatch_command
mysqld.exe!do_command
mysqld.exe!handle_one_connection
mysqld.exe!pthread_start
mysqld.exe!_threadstart

How to repeat:
don't know yet.
[25 Jun 2008 18:20] MySQL Verification Team 
this still crashed in 5.1.26.

I have studied the crash which happened in function create_tmp_field_from_field() in sql_select.cc line 9185.

new_field= org_field->new_field(thd->mem_root, table,
               table == org_field->table); 

the cause was the pointers in/to the virtual function table seems to have been changed by another thread and thus the address to new_field couldn't be looked up.  Here's the corresponding assembler (and my commentary):

00582498 mov ebx,dword ptr [esp+30h] get table from stack....
0058249C cmp ebx,dword ptr [edi+10h] compare table to org_field->table
0058249F mov ecx,dword ptr [esp+24h] get thd from stack 
005824A3 mov edx,dword ptr [edi] put address of__vfptr (0x007e8734) in edx
005824A5 mov edx,dword ptr [edx+0C4h] <--crash 

[edx+0xc4] should (and does in the core) point to 49th function address which is new_field().  But at the time of this crash, the values at 0x007e8734 must have momentarily been garbage.

The error was: Access violation reading location 0xfeeeffb2
[1 Jan 2009 14:51] MySQL Verification Team 
still got this crash on 5.1.30.  i might be the same as bug #41816
[1 Jan 2009 14:58] MySQL Verification Team 
valgrind errors+crash from 5.1.30

Attachment: bug36704_valgrind_errors_and_crash.txt (text/plain), 50.22 KiB.
[2 Jan 2009 8:37] MySQL Verification Team 
probably a duplicate of bug #41802
[23 Mar 2009 15:57] Susanne Ebrecht 
Please provide a test case.
[23 Apr 2009 23:00] Bugs System 
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[26 Jun 2010 18:36] Valeriy Kravchuk 
We need some definite decision on this bug: duplicate or not.
[29 Jun 2010 6:58] MySQL Verification Team 
not sure if it was a duplicate, but it's not repeatable anymore, so will just leave "cant repeat" for the status.