ma_page.c:430: _ma_new: Assertion `key_del_current != share->state.key_del && (key_del_current != 0) && ((key_del_current == (~ (my_off_t) 0)) || (key_del_current <= (share->state.state.key_file_length - block_size)))' failed.

[Philip Stoev]

When running a DML workload involving large varchar fields and multibyte character sets, (m)aria 5.2 asserted as follows:

ma_page.c:430: _ma_new: Assertion `key_del_current != share->state.key_del && (key_del_current != 0) && ((key_del_current == (~ (my_off_t) 0)) || (key_del_current <= (share->state.state.key_file_length - block_size)))' failed.

#8 0x00897de8 in __assert_fail () from /lib/libc.so.6
#9 0x08537ea1 in _ma_new (info=0xb5936a50, level=6, page_link=0xb6050a1c) at ma_page.c:426
#10 0x08564258 in _ma_split_page (info=0xb5936a50, key=0xb6056a70, split_page=0xb605644c, org_split_length=8188, inserted_key_pos=0x0, changed_length=0,
    move_length=0,
    key_buff=0xb6053549 "\377\002\066luhfqodhgjrwuygklwoywxuabeopuumwmmdsgxuudptslxmzjuvrwrloufjrkmtcfsgfmyzfmdypssnkucufrcdkprrpzvppzihqrakaovwdkwtsysglgiznfstkwatfduwqeezitadqmetkrfunjdhcffrxzmerimotlgsyqfbokragwjgxgjptjzbhlcsybxgia"..., insert_last_key=0 '\000') at ma_write.c:998
#11 0x08569c78 in d_search (info=0xb5936a50, key=0xb6056a70, comp_flag=4, anc_page=0xb605644c) at ma_delete.c:484
#12 0x08569136 in _ma_ck_real_delete (info=0xb5936a50, key=0xb6056a70, root=0xb60569c0) at ma_delete.c:228
#13 0x08568f0e in _ma_ck_delete (info=0xb5936a50, key=0xb6056a70) at ma_delete.c:183
#14 0x085611d2 in maria_update (info=0xb5936a50,
    oldrec=0xb5f4cf70 "\360\204\001qevzmhnzeddxugniycrumrafofagrdyszwpxleusmzebcvudykgugzpauneibvoddqrhtsobmlsqnbnopmsslwfidcvsnecefsrcwkkfuvlpcxbiywiwwrcdzdsdsmpeechldjvnfitirjnvrlyvaipogfjsmdvgidcjsmalslrxjmogsjxtarehsglynvvdqszrs"..., newrec=0xb5f48b58 "\360\001") at ma_update.c:131
#15 0x08521e43 in ha_maria::update_row (this=0xb5927940,
    old_data=0xb5f4cf70 "\360\204\001qevzmhnzeddxugniycrumrafofagrdyszwpxleusmzebcvudykgugzpauneibvoddqrhtsobmlsqnbnopmsslwfidcvsnecefsrcwkkfuvlpcxbiywiwwrcdzdsdsmpeechldjvnfitirjnvrlyvaipogfjsmdvgidcjsmalslrxjmogsjxtarehsglynvvdqszrs"..., new_data=0xb5f48b58 "\360\001") at ha_maria.cc:2089
#16 0x083a652f in handler::ha_update_row (this=0xb5927940,
    old_data=0xb5f4cf70 "\360\204\001qevzmhnzeddxugniycrumrafofagrdyszwpxleusmzebcvudykgugzpauneibvoddqrhtsobmlsqnbnopmsslwfidcvsnecefsrcwkkfuvlpcxbiywiwwrcdzdsdsmpeechldjvnfitirjnvrlyvaipogfjsmdvgidcjsmalslrxjmogsjxtarehsglynvvdqszrs"..., new_data=0xb5f48b58 "\360\001") at handler.cc:4863
#17 0x083ae57f in ha_partition::update_row (this=0xb5927518,
    old_data=0xb5f4cf70 "\360\204\001qevzmhnzeddxugniycrumrafofagrdyszwpxleusmzebcvudykgugzpauneibvoddqrhtsobmlsqnbnopmsslwfidcvsnecefsrcwkkfuvlpcxbiywiwwrcdzdsdsmpeechldjvnfitirjnvrlyvaipogfjsmdvgidcjsmalslrxjmogsjxtarehsglynvvdqszrs"..., new_data=0xb5f48b58 "\360\001") at ha_partition.cc:3149
#18 0x083a652f in handler::ha_update_row (this=0xb5927518,
    old_data=0xb5f4cf70 "\360\204\001qevzmhnzeddxugniycrumrafofagrdyszwpxleusmzebcvudykgugzpauneibvoddqrhtsobmlsqnbnopmsslwfidcvsnecefsrcwkkfuvlpcxbiywiwwrcdzdsdsmpeechldjvnfitirjnvrlyvaipogfjsmdvgidcjsmalslrxjmogsjxtarehsglynvvdqszrs"..., new_data=0xb5f48b58 "\360\001") at handler.cc:4863
#19 0x0832abd4 in mysql_update (thd=0xb255b10, table_list=0xb5d0ce08, fields=..., values=..., conds=0xb5c3d030, order_num=0, order=0x0,
    limit=18446744073709550263, handle_duplicates=DUP_ERROR, ignore=false) at sql_update.cc:649
#20 0x08280b02 in mysql_execute_command (thd=0xb255b10) at sql_parse.cc:3093
#21 0x08289aa4 in mysql_parse (thd=0xb255b10,
    inBuf=0xb5c3cf18 "UPDATE `table10000_maria_key_pk_parts_2_varchar_1024_not_null` SET `col_varchar_1024_latin1_not_null_key` = 4 WHERE `col_varchar_1024_utf8_not_null` < 'vkjpkfdupstijqsnxydgydevniwvxvihfgrdqmm'", length=192, found_semicolon=0xb6058230) at sql_parse.cc:6024
#22 0x0827bd9a in dispatch_command (command=COM_QUERY, thd=0xb255b10,
    packet=0xb257af1 "UPDATE `table10000_maria_key_pk_parts_2_varchar_1024_not_null` SET `col_varchar_1024_latin1_not_null_key` = 4 WHERE `col_varchar_1024_utf8_not_null` < 'vkjpkfdupstijqsnxydgydevniwvxvihfgrdqmm' ", packet_length=193) at sql_parse.cc:1183
#23 0x0827b288 in do_command (thd=0xb255b10) at sql_parse.cc:890
#24 0x08278420 in handle_one_connection (arg=0xb255b10) at sql_connect.cc:1153
#25 0x00a08919 in start_thread () from /lib/libpthread.so.0
#26 0x00951e5e in clone () from /lib/libc.so.6

The core and binary will be uploaded shortly.

[Philip Stoev (pstoev-askmonty)]

Datadir, core, binary:

http://pstoev-askmonty.s3.amazonaws.com/var-bug613423.zip

bzr version-info:

revision-id: <email address hidden>
date: 2010-08-04 12:43:51 +0300
build-date: 2010-08-04 15:27:53 +0300
revno: 2836
branch-nick: maria-5.2

[Philip Stoev (pstoev-askmonty)]

RQG command line that has been observed to cause this assertion:

/home/buildbot/randgen/runall.pl \
--basedir=. \
--grammar=conf/engines/varchar.yy \
--gendata=conf/engines/varchar.zz \
--reporter=Backtrace,ErrorLog,Recovery,Shutdown \
--duration=240 \
--queries=1M \
--engine=Maria \
--mysqld=--maria-checkpoint-interval=0 \
--mysqld=--log-output=file \
--seed=1282841249 \
--mysqld=--loose-skip-innodb \
--mysqld=--loose-pbxt=OFF

[Michael Widenius (monty)]

I have tested for this issue for 1 hour with the query:

while runall.pl --basedir=/my/maria-5.2 --vardir=/my/vardir --mysqld=--safe-mode --mysqld=--loose-debug-assert-if-crashed-table --mysqld=--sync-sys=0 --grammar=conf/engines/varchar.yy --gendata=conf/engines/varchar.zz --reporter=Backtrace,ErrorLog,Recovery,Shutdown --duration=240 --queries=1M --engine=Maria --mysqld=--maria-checkpoint-interval=0 --mysqld=--log-output=file --seed=1282841249 --mysqld=--loose-skip-innodb --mysqld=--loose-pbxt=OFF ; do echo "ok" ; done

Without any issues.

So I have to assume this issue is fixed now.
(There has been a lot of fixes in Aria since this bug was reported).