Bug #14287 RBR: create_select_tmp test segfaults the master
Submitted: 25 Oct 2005 9:48 Modified: 1 Feb 2006 13:47
Reporter: Guilhem Bichot Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version:5.0-wl1012 OS:Linux (linux)
Assigned to: Mats Kindahl CPU Architecture:Any

[25 Oct 2005 9:48] Guilhem Bichot
Description:
Running ./mysql-test-run create_select_tmp
causes mysqld (the master) to segfault :
==19391== Invalid read of size 4
==19391==    at 0x81D576E: THD::is_table_mapped(st_table*) const (sql_class.cc:2085)
==19391==    by 0x81D2C26: THD::binlog_flush_and_set_pending_rows_event(Rows_log_event*) (sql_class.cc:2195)
==19391==    by 0x81D4674: Rows_log_event* THD::binlog_prepare_pending_rows_event<Write_rows_log_event>(st_table*, unsigned,
 st_bitmap const*, unsigned, unsigned, bool) (sql_class.cc:2154)
==19391==    by 0x81D312E: THD::binlog_write_row(st_table*, bool, st_bitmap const*, unsigned, char const*) (sql_class.cc:235
1)
==19391==    by 0x82C1F76: Write_rows_log_event::binlog_row_logging_function(THD*, st_table*, bool, st_bitmap*, unsigned, ch
ar const*, char const*) (log_event.h:1968)
==19391==    by 0x82C1668: int binlog_log_row<Write_rows_log_event>(st_table*, char const*, char const*) (handler.cc:2547)
==19391==    by 0x82C13D3: handler::ha_write_row(char*) (handler.cc:2577)
==19391==    by 0x825B185: write_record(THD*, st_table*, st_copy_info*) (sql_insert.cc:1150)
==19391==    by 0x825E62F: select_insert::send_data(List<Item>&) (sql_insert.cc:2380)
==19391==    by 0x824D675: end_send(JOIN*, st_join_table*, bool) (sql_select.cc:10013)
==19391==    by 0x824BE47: evaluate_join_record(JOIN*, st_join_table*, int, char*) (sql_select.cc:9338)
==19391==    by 0x824BBB9: sub_select(JOIN*, st_join_table*, bool) (sql_select.cc:9223)
==19391==    by 0x824B717: do_select(JOIN*, List<Item>*, st_table*, Procedure*) (sql_select.cc:8986)
==19391==    by 0x8239FFE: JOIN::exec() (sql_select.cc:1669)
==19391==    by 0x823A57E: _Z12mysql_selectP3THDPPP4ItemP13st_table_listjR4ListIS1_ES2_jP8st_orderSB_S2_SB_mP13select_result
P18st_select_lex_unitP13st_select_lex (sql_select.cc:1833)
==19391==    by 0x8235322: handle_select(THD*, st_lex*, select_result*, unsigned long) (sql_select.cc:234)
==19391==  Address 0x1F5B7850 is 0 bytes inside a block of size 1652 free'd
==19391==    at 0x1B9047A9: free (vg_replace_malloc.c:152)
==19391==    by 0x85ADCE7: my_no_flags_free (my_malloc.c:60)
==19391==    by 0x8222CE4: free_cache_entry(st_table*) (sql_base.cc:241)
==19391==    by 0x85B7DDD: hash_delete (hash.c:509)
==19391==    by 0x825F378: select_create::abort() (sql_insert.cc:2621)
==19391==    by 0x82353BE: handle_select(THD*, st_lex*, select_result*, unsigned long) (sql_select.cc:255)
==19391==    by 0x81FAB0F: mysql_execute_command(THD*) (sql_parse.cc:2862)
==19391==    by 0x82027DE: mysql_parse(THD*, char*, unsigned) (sql_parse.cc:5514)
==19391==    by 0x81F7E2C: dispatch_command(enum_server_command, THD*, char*, unsigned) (sql_parse.cc:1697)
==19391==    by 0x81F7671: do_command(THD*) (sql_parse.cc:1498)
==19391==    by 0x81F66FE: handle_one_connection (sql_parse.cc:1143)

So it *looks* like a TABLE object which is used (by is_table_mapped)
while it has been closed (freed) earlier.
It is much like a bunch of errors we had in RBR, except that this time
there is not the infamous

Table_map
Query
Write_rows

pattern in the master's binlog, and it's a crash in master, not in
slave.
The statement which crashes is
CREATE TABLE t2 ( PRIMARY KEY (a) ) ENGINE=MYISAM SELECT a FROM t1;
And as we know RBR doesn't yet support CREATE SELECT, so this is not
really surprising.

How to repeat:
run the test
[1 Feb 2006 13:47] Mats Kindahl
Thank you for taking the time to report a problem.  Unfortunately
you are not using a current version of the product your reported a
problem with -- the problem might already be fixed. Please download
a new version from http://www.mysql.com/downloads/

If you are able to reproduce the bug with one of the latest versions,
please change the version on this bug report to the version you
tested and change the status back to "Open".  Again, thank you for
your continued support of MySQL.

Additional info:

CREATE-SELECT for row-based replication is implemented in 5.1.6-alpha, so I close the bug.