Bug #7276 Test failure: 'timezone2' (using '--ps-protocol': 'unable to prepare ...'+core)
Submitted: 14 Dec 2004 16:40 Modified: 22 Dec 2004 20:29
Reporter: Joerg Bruehe Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server Severity:S1 (Critical)
Version:5.0.3-pre OS:Linux (Linux / Athlon)
Assigned to: Assigned Account CPU Architecture:Any

[14 Dec 2004 16:40] Joerg Bruehe
Description:
Test 'timezone2' fails for me in current 5.0, when I run the test suite with '--ps-protocol'.
In a standard run, this test passes.

This is a non-debug build: 'compile-pentium-max'.

Failure report:
=== cut ===
timezone2                      [ fail ]

Errors are (from /M50/push-5.0/mysql-test/var/log/mysqltest-time) :
/M50/push-5.0/client/.libs/mysqltest: At line 155: unable to prepare statement 'select convert_tz(now(),'UTC', 'Universal') = now()': Lost connection to MySQL server during query (mysql_stmt_errno=2013 returned=1)
(the last lines may be the most important ones)

Ending Tests
Shutting-down MySQL daemon

master not cooperating with mysqladmin, will try manual kill
./mysql-test-run: line 1289: kill: (32174) - Kein passender Prozess gefunden
master refused to die. Sending SIGKILL
./mysql-test-run: line 1293: kill: (32174) - Kein passender Prozess gefunden
Master shutdown finished
Slave shutdown finished
=== cut ===

This should be the backtrace:
(gdb) where
#0  0x4022d691 in kill () from /lib/libc.so.6
#1  0x40153511 in pthread_kill () from /lib/libpthread.so.0
#2  0x08295dcb in write_core (sig=32180) at stacktrace.c:220
#3  0x0819ab58 in handle_segfault (sig=32180) at mysqld.cc:1904
#4  0x40156895 in __pthread_sighandler () from /lib/libpthread.so.0
#5  <signal handler called>
#6  tz_load_from_open_tables (tz_name=0x8c06b54, tz_tables=0x8beb2a0) at sql_string.h:87
#7  0x08bf23c8 in ?? ()
#8  0x082a1361 in my_tz_find (name=0x8beb2a0, tz_tables=0x0) at tztime.cc:2206
#9  0x0815c319 in Item_func_convert_tz::fix_fields(THD*, st_table_list*, Item**) (this=0x8beb2a0, thd_arg=0x7db4, tables_arg=0x0, ref=0x0)
    at item_timefunc.cc:1676
#10 0x0812d969 in Item_func::fix_fields(THD*, st_table_list*, Item**) (this=0x8c06d30, thd=0x8beb2a0, tables=0x0, ref=0x8c06df4) at item_func.cc:311
#11 0x081d82d6 in setup_fields (thd=0x8beb2a0, ref_pointer_array=0x8c06e90, tables=0x0, fields=@0x40158bd0, sum_func_list=0x8be1e64) at sql_list.h:323
#12 0x081df710 in JOIN::prepare(Item***, st_table_list*, unsigned, Item*, unsigned, st_order*, st_order*, Item*, st_order*, st_select_lex*, st_select_lex_unit*) (this=0x8be1148, rref_pointer_array=0x8bffbc4, tables_init=0x0, wild_num=0, conds_init=0x0, og_num=0, order_init=0x0, group_init=0x0, having_init=0x0,
    proc_param_init=0x0, select_lex_arg=0xb, unit_arg=0x8bff904) at sql_select.cc:470
#13 0x08290133 in st_select_lex_unit::prepare(THD*, select_result*, unsigned long) (this=0x8bff904, thd_arg=0x8beb2a0, sel_result=0x8bffbc4,
    additional_options=0) at sql_union.cc:224
#14 0x082041b3 in mysql_test_select (stmt=0x8bff8c8, tables=0x0, text_protocol=false) at sql_prepare.cc:1102
#15 0x08203619 in check_prepared_statement (stmt=0x8bff8c8, text_protocol=false) at sql_prepare.cc:1483
#16 0x08201a49 in mysql_stmt_prepare (thd=0x0, packet=0x8bf78a9 "select convert_tz(now(),'UTC', 'Universal') = now()", packet_length=0, name=0x0)
    at sql_prepare.cc:1680
#17 0x081b0984 in dispatch_command (command=COM_PREPARE, thd=0x8beb2a0, packet=0x8bf78a9 "select convert_tz(now(),'UTC', 'Universal') = now()",
    packet_length=52) at sql_parse.cc:1493
#18 0x081b0496 in do_command (thd=0x16) at sql_parse.cc:1320
#19 0x081af94c in handle_one_connection (arg=0x34) at sql_parse.cc:1052
#20 0x40150c60 in pthread_start_thread () from /lib/libpthread.so.0
(gdb)

Latest changeset on my PC:
ChangeSet@1.1738, 2004-12-14 13:41:32+03:00, gluh@gluh.mysql.r18.ru
  Fix for bug #7223: information_schema: error in "views"

The error is older, as I got it already yesterday but did not yet report.

How to repeat:
Run the test suite with '--ps-protocol'.
[15 Dec 2004 14:23] Dmitry Lenev
It seems that this is yet another manifestation of bug #6849. So I am marking this bug
as duplicate.
[22 Dec 2004 20:29] Joerg Bruehe
The error did not re-appear in a test run on Dec 22, fresh pull, re-built, so I assume Dmitri's patch for bug#6849 (closed on Dec 21) also helped for this one.