Bug #44319 Assertion failure in file ha_innodb.cc line 4018
Submitted: 16 Apr 2009 12:27 Modified: 25 Oct 2009 18:40
Reporter: Victor Kirkebo Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S3 (Non-critical)
Version:5.1.34 OS:Solaris
Assigned to: Assigned Account CPU Architecture:Any
Tags: core dump, coredump, ha_innodb.cc, prebuilt, ROW_MYSQL_WHOLE_ROW, template_type, update_row

[16 Apr 2009 12:27] Victor Kirkebo
Description:
The sys_rpl_combo test suite caused mysqld to core dump after a failed assertion.
Assertion failed: prebuilt->template_type == ROW_MYSQL_WHOLE_ROW, file handler/ha_innodb.cc, line 4018

From the test logs it seems that the particular test causing the core dump was tb1_eng1_upd6.test.
However, there is no log available with the exact statement with parameters.

Stack trace:

[xxxxx@xxxxx]/tmp/sysrplcomboMBR/var/master-data: dbx ~/mysql/mysql-advanced-5.1.34-solaris10-x86_64/bin/mysqld core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc
Reading mysqld
core file header read successfully
Reading ld.so.1
Reading libmtmalloc.so.1
Reading libpthread.so.1
Reading libthread.so.1
Reading libdl.so.1
Reading librt.so.1
Reading libresolv.so.2
Reading libsocket.so.1
Reading libnsl.so.1
Reading libm.so.2
Reading libCstd.so.1
Reading libCrun.so.1
Reading libc.so.1
Reading libaio.so.1
Reading libmd.so.1
t@29019 (l@29019) terminated by signal ABRT (Abort)
0xfffffd7ffed7abaa: __lwp_kill+0x000a:  jae      __lwp_kill+0x18        [ 0xfffffd7ffed7abb8, .+0xe ]
Current function is my_write_core (optimized)
dbx: warning: can't find file "/export/home/my/tmp-200903301116-5.1.34-13393/solaris10-x86_64/mysqlcom-5.1.34/mysys/stacktrace.c"
dbx: warning: see `help finding-files'
(dbx) thread t@29019
t@29019 (l@29019) stopped in __lwp_kill at 0xfffffd7ffed7abaa
0xfffffd7ffed7abaa: __lwp_kill+0x000a:  jae      __lwp_kill+0x18        [ 0xfffffd7ffed7abb8, .+0xe ]
(dbx) where
current thread: t@29019
 [1] __lwp_kill(0x715b, 0x6, 0xffffffff918d4740, 0x0, 0x0, 0x0), at 0xfffffd7ffed7abaa
 [2] _thr_kill(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffed73483
=>[3] my_write_core(sig = ???) (optimized), at 0xa2eb29 (line ~311) in "stacktrace.c"
 [4] handle_segfault(sig = ???) (optimized), at 0x7a04b8 (line ~2537) in "mysqld.cc"
 [5] __sighndlr(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffed75386
 [6] call_user_handler(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffed69c82
 [7] sigacthandler(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffed69e9e
 ---- called from signal handler with signal 6 (SIGABRT) ------
 [8] __lwp_kill(0x715b, 0x6, 0xffffffff918d4740, 0x5, 0xffffffffffffffff, 0x0), at 0xfffffd7ffed7abaa
 [9] _thr_kill(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffed73483
 [10] raise(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffed21349
 [11] abort(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffed0089e
 [12] __assert(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffed00b5e
 [13] ha_innobase::update_row(this = ???, old_row = ???, new_row = ???) (optimized), at 0x917703 (line ~4018) in "ha_innodb.cc"
 [14] handler::ha_update_row(this = ???, old_data = ???, new_data = ???) (optimized), at 0x87ed44 (line ~4603) in "handler.cc"
 [15] ha_partition::update_row(this = ???, old_data = ???, new_data = ???) (optimized), at 0x884401 (line ~3063) in "ha_partition.cc"
 [16] handler::ha_update_row(this = ???, old_data = ???, new_data = ???) (optimized), at 0x87ed44 (line ~4603) in "handler.cc"
 [17] mysql_update(thd = ???, table_list = ???, fields = CLASS, values = CLASS, conds = ???, order_num = ???, order = ???, limit = ???, handle_duplic
ates = ???, ignore = ???) (optimized), at 0x82ce54 (line ~640) in "sql_update.cc"
 [18] mysql_execute_command(thd = ???) (optimized), at 0x7b0bd5 (line ~3012) in "sql_parse.cc"
 [19] mysql_parse(thd = ???, inBuf = ???, length = ???, found_semicolon = ???) (optimized), at 0x7b4fea (line ~5903) in "sql_parse.cc"
 [20] dispatch_command(command = ???, thd = ???, packet = ???, packet_length = ???) (optimized), at 0x7abd42 (line ~1217) in "sql_parse.cc"
 [21] do_command(thd = ???) (optimized), at 0x7ab3c3 (line ~858) in "sql_parse.cc"
 [22] handle_one_connection(arg = ???) (optimized), at 0x7aa181 (line ~1116) in "sql_connect.cc"
 [23] _thr_setup(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffed7504b
 [24] _lwp_start(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffed75280
(dbx) 

How to repeat:
How to repeat:
This error has happened only once when running a 12 hour test as decsribed below. The core dump happened 4 hours into the test.

bzr branch bzr+ssh://username@bk-internal.mysql.com/bzrroot/server/mysql-test-extra-5.1
cd mysql-test-extra-5.1/mysql-test/qa-suite/sys_rpl_combo/
ulimit -n 32768
perl ./run_systest_rpl.pl --config=MBR.env --monitors=replication --rpl_sys_mode=MBR --duration=43200 &>MBR5.1.34.out &

MBR.env settings:
MYSQL_BASEDIR="~/mysql/mysql-advanced-5.1.34-solaris10-x86_64"
STRESS_TEST_WORKDIR="/tmp/sysrplcomboMBR"
PERL_PROG="/opt/csw/bin/perl"              # Solaris-specific value
[24 Sep 2009 9:48] Susanne Ebrecht
Set to verified according to comments above
[25 Sep 2009 18:40] Jimmy Yang
Hi, a few items to help us debug this issue:

1. Could we get access to the core file/log file?

2. If not, could you please help check if you can get the actual value "prebuilt->template_type" at the time of assertion failure?

3. Could "tb1_eng1_upd6.test" be run seperately, so that reduce the time to reproduce the problem? And can this be reproduced each time ?

4. Can this issue be reproduced on linux platforms?

Thanks
Jimmy
[26 Oct 2009 0:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".