MySQL Bugs: #12470: MySQL server crashes when attached view is SELECT'ed upon.

Bug #12470	MySQL server crashes when attached view is SELECT'ed upon.
Submitted:	9 Aug 2005 17:46	Modified:	12 Aug 2005 20:01
Reporter:	Bobby Beckmann	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Optimizer	Severity:	S1 (Critical)
Version:	5.0.10-beta-debug	OS:	Linux (Linux 2.6.12 and Windows XP)
Assigned to:	Igor Babaev	CPU Architecture:	Any

Description:
Attached view crashes MySQL during free resource routines.

How to repeat:
In attached file, source runme.sql. This will create a database, create some empty tables, create a view on these tables and do a select on the view. Then boom.

Suggested fix:
Don't free what you haven't malloc'd!

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.mysql.com/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to 'Open'.

Thank you for your interest in MySQL.

Additional info:

Tested against 5.0 from bk tree:
ChangeSet@1.1964.1.1, 2005-08-09 14:48:43-05:00, reggie@monster.

Reproduced with 5.0.12-20050809

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x080c7ecf in Query_arena::free_items (this=0x860f63c) at item.h:679
#2  0x080c4d85 in THD::cleanup_after_query (this=0x860f630) at sql_class.cc:545
#3  0x080f43f6 in mysql_parse (thd=0x860f630, inBuf=0x8624790 "select * from v_bug", length=140572272) at sql_parse.cc:5411
#4  0x080e9f51 in dispatch_command (command=COM_QUERY, thd=0x860f630, packet=0x8611509 "", packet_length=20) at sql_parse.cc:1657
#5  0x080e9809 in do_command (thd=0x860f630) at sql_parse.cc:1460
#6  0x080e8995 in handle_one_connection (arg=0x8642a38) at sql_parse.cc:1113
#7  0x080d7326 in create_new_thread (thd=0x860f630) at mysqld.cc:3642
#8  0x080d79eb in handle_connections_sockets (arg=0x0) at mysqld.cc:3914
#9  0x080d6dad in main (argc=140782136, argv=0xbffff274) at mysqld.cc:3313

The problem can be demonstrated with the following simple example:
mysql> CREATE TABLE t1 (pk int PRIMARY KEY, b int);
Query OK, 0 rows affected (0.00 sec)

mysql> CREATE TABLE t2 (pk int PRIMARY KEY, fk int, INDEX idx(fk));
Query OK, 0 rows affected (0.32 sec)

mysql> CREATE TABLE t3 (pk int PRIMARY KEY, fk int, INDEX idx(fk));
Query OK, 0 rows affected (0.05 sec)

mysql> CREATE TABLE t4 (pk int PRIMARY KEY, fk int, INDEX idx(fk));
Query OK, 0 rows affected (0.04 sec)

mysql> CREATE TABLE t5 (pk int PRIMARY KEY, fk int, INDEX idx(fk));
Query OK, 0 rows affected (0.05 sec)

mysql> CREATE VIEW v1 AS
    ->   SELECT t1.pk as a FROM t1,t2,t3,t4,t5
    ->     WHERE t1.b IS NULL AND
    ->           t1.pk=t2.fk AND t2.pk=t3.fk AND t3.pk=t4.fk AND t4.pk=t5.fk;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT a FROM v1;
Empty set (0.00 sec)

For the last query the server crashes due to a memory corruption.

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/28211

ChangeSet
  1.1983 05/08/12 01:27:04 igor@rurik.mysql.com +3 -0
  sql_base.cc:
    Fixed bug #12470.
    A misplaced initialization of the cond_count counter
    resulted in a wrong calculation of it. This caused a memory
    corruption since this counter was used as a parameter of
    some memory allocation.
  view.test:
    Added a test case for bug #12470

The fix will appear in 5.0.12.

Noted in 5.0.12 changelog.