| Bug #54401 | assert in Diagnostics_area::set_eof_status , HANDLER | ||
|---|---|---|---|
| Submitted: | 10 Jun 2010 15:02 | Modified: | 12 Aug 2010 19:54 |
| Reporter: | Matthias Leich | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server | Severity: | S3 (Non-critical) |
| Version: | mysql-trunk-runtime | OS: | Any |
| Assigned to: | Jon Olav Hauglid | CPU Architecture: | Any |
| Tags: | assert, handler | ||
[10 Jun 2010 15:05]
Matthias Leich
SQL grammar
Attachment: 2.yy (application/octet-stream, text), 643 bytes.
[10 Jun 2010 15:06]
Matthias Leich
Data generation grammar, but the test does not use these tables
Attachment: 2.zz (application/octet-stream, text), 1.30 KiB.
[10 Jun 2010 15:15]
Matthias Leich
My MySQL says it's a 5.5.5-m3-debug-log .
[1 Jul 2010 11:31]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/112662 3069 Jon Olav Hauglid 2010-07-01 Bug #54401 assert in Diagnostics_area::set_eof_status , HANDLER This assert checks that the server does not try to send EOF to the client if there has been some error during processing. This to make sure that the error is in fact sent to the client. The problem was that any errors during processing of WHERE conditions in HANDLER ... READ statements where not detected by the handler code. The handler code therefore still tried to send EOF to the client, triggering the assert. The bug was only noticeable in debug builds. This patch fixes the problem by making sure that the handler code checks for errors during condition processing and acts accordingly.
[5 Jul 2010 12:06]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/112883 3076 Jon Olav Hauglid 2010-07-05 Bug #54401 assert in Diagnostics_area::set_eof_status , HANDLER This assert checks that the server does not try to send EOF to the client if there has been some error during processing. This to make sure that the error is in fact sent to the client. The problem was that any errors during processing of WHERE conditions in HANDLER ... READ statements where not detected by the handler code. The handler code therefore still tried to send EOF to the client, triggering the assert. The bug was only noticeable in debug builds. This patch fixes the problem by making sure that the handler code checks for errors during condition processing and acts accordingly.
[5 Jul 2010 12:08]
Jon Olav Hauglid
Patch pushed to mysql-trunk-runtime (5.5.6).
[4 Aug 2010 7:51]
Bugs System
Pushed into mysql-trunk 5.5.6-m3 (revid:alik@sun.com-20100731131027-1n61gseejyxsqk5d) (version source revid:marko.makela@oracle.com-20100621094008-o9fa153s3f09merw) (merge vers: 5.1.49) (pib:18)
[4 Aug 2010 8:10]
Bugs System
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804080001-bny5271e65xo34ig) (version source revid:marko.makela@oracle.com-20100621094008-o9fa153s3f09merw) (merge vers: 5.1.49) (pib:18)
[4 Aug 2010 8:26]
Bugs System
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804081533-c1d3rbipo9e8rt1s) (version source revid:marko.makela@oracle.com-20100621094008-o9fa153s3f09merw) (merge vers: 5.1.49) (pib:18)
[4 Aug 2010 9:05]
Bugs System
Pushed into mysql-next-mr (revid:alik@ibmvm-20100804081630-ntapn8bf9pko9vj3) (version source revid:marko.makela@oracle.com-20100621094008-o9fa153s3f09merw) (pib:20)
[12 Aug 2010 19:54]
Paul DuBois
Noted in 5.5.6 changelog. Errors during processing of WHERE conditions in HANDLER ... READ statements were not detected, so the handler code still tried to send EOF to the client, raising an assertion.
Description: The assert happens in sql_error.cc line 390 : --------------------------------------------- void Diagnostics_area::set_eof_status(THD *thd) { DBUG_ENTER("set_eof_status"); /* Only allowed to report eof if has not yet reported an error */ DBUG_ASSERT(! is_set()); <-------- Result on mysql-trunk-runtime revno: 3051 2010-06-10 ---------------------------------------------------- ... Thread 1 (Thread 6515): #0 0x000000382860bd02 in pthread_kill () from /lib64/libpthread.so.0 #1 0x0000000000b59791 in my_write_core (sig=6) at stacktrace.c:326 #2 0x00000000006993fb in handle_segfault (sig=6) at mysqld.cc:2791 #3 <signal handler called> #4 0x0000003827a30265 in raise () from /lib64/libc.so.6 #5 0x0000003827a31d10 in abort () from /lib64/libc.so.6 #6 0x0000003827a296e6 in __assert_fail () from /lib64/libc.so.6 #7 0x00000000007638ca in Diagnostics_area::set_eof_status (this=0x1e2b5268, thd=0x1e2b2798) at sql_error.cc:390 #8 0x00000000005a3992 in my_eof (thd=0x1e2b2798) at sql_class.h:2765 #9 0x00000000005a26a8 in mysql_ha_read (thd=0x1e2b2798, tables=0x1e2bd718, mode=RNEXT, keyname=0x0, key_expr=0x1e2bdb90, ha_rkey_mode=HA_READ_KEY_EXACT, cond=0x1e2bec28, select_limit_cnt=1, offset_limit_cnt=0) at sql_handler.cc:747 #10 0x00000000006b07a6 in mysql_execute_command (thd=0x1e2b2798) at sql_parse.cc:4071 #11 0x00000000006b29ed in mysql_parse (thd=0x1e2b2798, inBuf=0x1e2bd568 "HANDLER handler_a READ FIRST WHERE testdb_S . f13 () = 13", length=57, parser_state=0x49d1d9b0) at sql_parse.cc:5889 #12 0x00000000006b3f49 in dispatch_command (command=COM_QUERY, thd=0x1e2b2798, packet=0x1e2b54d9 "", packet_length=57) at sql_parse.cc:1114 #13 0x00000000006b5476 in do_command (thd=0x1e2b2798) at sql_parse.cc:800 #14 0x00000000006a34d9 in do_handle_one_connection (thd_arg=0x1e2b2798) at sql_connect.cc:1194 #15 0x00000000006a359f in handle_one_connection (arg=0x1e2b2798) at sql_connect.cc:1133 #16 0x000000382860673d in start_thread () from /lib64/libpthread.so.0 #17 0x0000003827ad3d1d in clone () from /lib64/libc.so.6 BTW: I had during the RQG grammar simplification various more or less different assertions and crashes but all time the statement HANDLER handler_a READ FIRST WHERE testdb_S . f13 () caused the problem. Please note that - the function f13 uses a not existing table - there are concurrent session which try to remove and recreate teh SCHEMA testdb_S whicgh contains the function and the tables used. How to repeat: perl runall.pl \ --gendata=./2.zz \ --duration=10 \ --queries=100 \ --reporter=Deadlock,Backtrace,Shutdown \ --threads=8 \ --basedir=/data0/mleich/repo/mysql-trunk-runtime/ \ --mysqld=--lock-wait-timeout=2 \ --mysqld=--log-output=table \ --mysqld=--secure-file-priv=/tmp/ \ --mysqld=--loose-innodb-lock-wait-timeout=1 \ --grammar=./2.yy \ --vardir=/dev/shm/var_1276099884 \ --seed=54 I will upload the grammars used.