Description of problem:

    mysqld segfaults when attempting to show the CREATE TABLE statement that
    defines a view with a missing table

Version-Release number of selected component (if applicable):

    mysql-5.0.77-3.el5.x86_64

How reproducible:

    100%

Steps to Reproduce:

    # service mysqld start
    # mysql
    mysql> create database test_db;
    Query OK, 1 row affected (0.00 sec)

    mysql> use test_db;
    Database changed
    mysql> create table one (string varchar(20), num int);
    Query OK, 0 rows affected (0.00 sec)

    mysql> create table two (string varchar(20), num int);
    Query OK, 0 rows affected (0.00 sec)

    mysql> create view v1 as select one.string as string1, \
    two.string as string2, count(one.num) as num_count \
    from one left join two on one.num = two.num;
    Query OK, 0 rows affected (0.00 sec)

    mysql> drop table two;
    Query OK, 0 rows affected (0.00 sec)

    mysql> show create table v1;
    ERROR 2013 (HY000): Lost connection to MySQL server during query
  
Actual results:

    The the mysqld thread handling the SHOW CREATE TABLE query
    segfaults.  The following entry is created in /var/log/mysqld.log:

        091202 14:52:06 - mysqld got signal 11 ;
        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=8384512
        read_buffer_size=131072
        max_used_connections=1
        max_connections=100
        threads_connected=1
        It is possible that mysqld could use up to 
        key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections
	 = 225787 K
        bytes of memory
        Hope that's ok; if not, decrease some variables in the equation.
        
        thd=0x1fe3fee0
        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...
        Cannot determine thread, fp=0x45a19fb0, backtrace may not be correct.
        Stack range sanity check OK, backtrace follows:
        (nil)
        New value of fp=0x1fe3fee0 failed sanity check, terminating stack trace!
        Please read
        http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and
        follow instructions on how to resolve the stack
        trace. Resolved stack trace is much more helpful in diagnosing
        the problem, so please do resolve it
        Trying to get some variables.
        Some pointers may be invalid and cause the dump to abort...
        thd->query at 0x1fe7e050 = show create table v1
        thd->thread_id=1
        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.
        
        Number of processes running now: 0

Expected results:

    mysqld should not segfault
        
Additional info:

    The backtrace for the segfault (from running mysqld under gdb) is:

    (gdb) bt
    #0 0x00000000004f089d in Item_sum::print (this=0x1e917c08,
       str=0x45a823e0) at item_sum.cc:449
    #1  0x00000000004d6a02 in Item::print_item_w_name (this=0x0,
        str=0x45a823e0) at item.cc:443
    #2  0x00000000005c05f0 in st_select_lex::print (this=0x1e916ae8,
        thd=0x1e8d80a0, str=0x45a823e0) at sql_select.cc:15839
    #3  0x00000000004d13e4 in st_select_lex_unit::print
        (this=0x1e916740, str=0x45a823e0) at sql_lex.cc:1624
    #4  0x000000000064d574 in mysqld_show_create (thd=0x1e8d80a0,
        table_list=0x1e9161f0) at sql_show.cc:1272
    #5  0x0000000000578974 in mysql_execute_command (thd=0x1e8d80a0) at
        sql_parse.cc:3532
    #6  0x000000000057c051 in mysql_parse (thd=0x1e8d80a0,
        inBuf=0x1e916110 "show create table event_stats", length=29,
        found_semicolon=0x45a83b98) at sql_parse.cc:6321
    #7  0x000000000057d26a in dispatch_command (command=COM_QUERY,
        thd=0x1e8d80a0, packet=<value optimized out>, packet_length=30)
        at sql_parse.cc:1961
    #8  0x000000000057e2bf in handle_one_connection (arg=<value
        optimized out>) at sql_parse.cc:1642
    #9  0x00000033384064a7 in start_thread (arg=<value optimized out>)
        at pthread_create.c:297 10 0x00000033378d3c2d in clone () from
        /lib64/libc.so.6

    The segfault occurs because *pargs is null in the following code in
    item_sum.cc:

    441 void Item_sum::print(String *str)
    442 {
    443   Item **pargs= orig_args;
    444   str->append(func_name());
    445   for (uint i=0 ; i < arg_count ; i++)
    446   {
    447     if (i)
    448       str->append(',');
    449     pargs[i]->print(str);
    450   }
    451   str->append(')');
    452 }

    Since pargs is set from the value of orig_args, the problem is
    that orig_args is null and that case is not handled properly.

    The problem appears to be resolved with the upstream patch of
    item_sum.cc at:

    http://bazaar.launchpad.net/~mysql/mysql-server/mysql-5.0/revision/2710.60.8

    The upstream patch was added to resolve MySQL Bug 43354
    (http://bugs.mysql.com/bug.php?id=43354).  Although the bug describes
    a different series of steps to reproduce the problem, the backtraces of 
    the two problems are very similar.