MySQL Bugs: #48760: assert in __cxa_pure_virtual called by Item_field::result

Bug #48760	assert in __cxa_pure_virtual called by Item_field::result_type
Submitted:	13 Nov 2009 13:36	Modified:	19 Jan 2010 9:22
Reporter:	Matthias Leich	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Server: Stored Routines	Severity:	S3 (Non-critical)
Version:	5.1	OS:	Any
Assigned to:	Georgi Kodinov	CPU Architecture:	Any

Description:
The assert is in my_new.cc:51 :
   assert(! "Aborted: pure virtual method called.");

When running RQG tests on
   mysql-5.1-bugteam revno: 3198 2009-11-12
I get the following assertion with very low
likelihood:
-------------------------------------------
Thread 1 (process 6030):
#0  0x00007f94b8b37ce6 in pthread_kill () from /lib64/libpthread.so.0
#1  0x0000000000b16093 in my_write_core (sig=6) at stacktrace.c:310
#2  0x00000000006baca7 in handle_segfault (sig=6) at mysqld.cc:2570
#3  <signal handler called>
#4  0x00007f94b7d405c5 in raise () from /lib64/libc.so.6
#5  0x00007f94b7d41bb3 in abort () from /lib64/libc.so.6
#6  0x00007f94b7d391e9 in __assert_fail () from /lib64/libc.so.6
#7  0x0000000000afa781 in __cxa_pure_virtual () at my_new.cc:51
#8  0x00000000005f38ca in Item_field::result_type (this=0x7f94ac011dd0) at item.h:1463
#9  0x0000000000633023 in Item_bool_func2::fix_length_and_dec (this=0x7f94ac04aff0) at item_cmpfunc.cc:481
#10 0x0000000000618895 in Item_func::fix_fields (this=0x7f94ac04aff0, thd=0x1942200, ref=0x7f94ac048a20) at item_func.cc:198
#11 0x000000000062d9db in Item_cond::fix_fields (this=0x7f94ac016930, thd=0x1942200, ref=0x7f94ac00ac50) at item_cmpfunc.cc:4005
#12 0x0000000000713c0c in setup_conds (thd=0x1942200, tables=0x7f94ac007620, leaves=0x7f94ac007620, conds=0x7f94ac04a1b0) at sql_base.cc:8030
#13 0x00000000007645b4 in setup_without_group (thd=0x1942200, ref_pointer_array=0x7f94ac04a320, tables=0x7f94ac007620, leaves=0x7f94ac007620, fields=@0x40b2de00, all_fields=@0x7f94ac04a088, conds=0x7f94ac04a1b0, order=0x0, group=0x0,
    hidden_group_fields=0x7f94ac04a067) at sql_select.cc:413
#14 0x000000000075bb11 in JOIN::prepare (this=0x7f94ac048a80, rref_pointer_array=0x7f94ac006cd0, tables_init=0x7f94ac007620, 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=0x7f94ac006ad8, unit_arg=0x7f94ac0066a0) at sql_select.cc:495
#15 0x000000000075cb81 in mysql_select (thd=0x1942200, rref_pointer_array=0x7f94ac006cd0, tables=0x7f94ac007620, wild_num=0, fields=@0x40b2de00, conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=1342177408,
    result=0x7f94ac03c220, unit=0x7f94ac0066a0, select_lex=0x7f94ac006ad8) at sql_select.cc:2423
#16 0x000000000077eea2 in mysql_multi_update (thd=0x1942200, table_list=0x7f94ac007620, fields=0x7f94ac006be8, values=0x7f94ac007030, conds=0x0, options=0, handle_duplicates=DUP_ERROR, ignore=false, unit=0x7f94ac0066a0, select_lex=0x7f94ac006ad8)
    at sql_update.cc:1229
#17 0x00000000006cf74d in mysql_execute_command (thd=0x1942200) at sql_parse.cc:3130
#18 0x000000000089e771 in sp_instr_stmt::exec_core (this=0x7f94ac00af90, thd=0x1942200, nextp=0x40b2f188) at sp_head.cc:2912
#19 0x000000000089e9b3 in sp_lex_keeper::reset_lex_and_exec_core (this=0x7f94ac00afd8, thd=0x1942200, nextp=0x40b2f188, open_tables=false, instr=0x7f94ac00af90) at sp_head.cc:2740
#20 0x00000000008a4f90 in sp_instr_stmt::execute (this=0x7f94ac00af90, thd=0x1942200, nextp=0x40b2f188) at sp_head.cc:2855
#21 0x00000000008a0ed2 in sp_head::execute (this=0x1a4b2b0, thd=0x1942200) at sp_head.cc:1255
#22 0x00000000008a1c9f in sp_head::execute_procedure (this=0x1a4b2b0, thd=0x1942200, args=0x1944600) at sp_head.cc:1988
#23 0x00000000006d3a4d in mysql_execute_command (thd=0x1942200) at sql_parse.cc:4392
#24 0x00000000006d5ba6 in mysql_parse (thd=0x1942200, inBuf=0x1ac4d90 "CALL testdb_S . p1", length=18, found_semicolon=0x40b30ef0) at sql_parse.cc:5970
#25 0x00000000006d69ea in dispatch_command (command=COM_QUERY, thd=0x1942200, packet=0x19f28c1 "CALL testdb_S . p1", packet_length=18) at sql_parse.cc:1231
#26 0x00000000006d7ddc in do_command (thd=0x1942200) at sql_parse.cc:872
#27 0x00000000006c4269 in handle_one_connection (arg=0x1942200) at sql_connect.cc:1127
#28 0x00007f94b8b33040 in start_thread () from /lib64/libpthread.so.0
#29 0x00007f94b7de108d in clone () from /lib64/libc.so.6
#30 0x0000000000000000 in ?? ()

I have not seen this assertion when running the same
test on mysq1-5.0-bugteam or mysql-6.0-codebase-bugfixing.
But because of the "randomness" of RQG tests with 30 "worker"
threads this could not be called a proof that these two
MySQL versions are free of this bug.

How to repeat:
nice -20 perl runall.pl --basedir=........ \
--threads=30 --queries=3000 --grammar=conf/bug48157.yy \
--vardir=.... --seed=1 \
--mysqld=--log-output=file \
--reporter=Deadlock,Backtrace,Shutdown \
--gendata=conf/empty.zz
--duration=60 --mysqld=--table-lock-wait-timeout=1 \
--mysqld=--innodb-lock-wait-timeout=1

I will upload the grammar files.

Grammar for stress testing

Attachment: bug48157.yy (application/octet-stream, text), 597 bytes.

Grammar for creation of objects

Attachment: empty.zz (application/octet-stream, text), 211 bytes.

To me, it looks like setup_fields() has not been called for one particular field.

Fixed by the fix for bug #47649

Closed as a duplicate of bug #48157.