From: Rich Prohaska Date: June 8 2012 1:32pm Subject: Re: possible overactive assert in pfs.cc line 3701 List-Archive: http://lists.mysql.com/internals/38527 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, Hope this helps: (gdb) bt #0 0x0000003006e0c63c in pthread_kill () from /lib64/libpthread.so.0 #1 0x0000000000a61f97 in my_write_core (sig=3D6) at /home/prohaska/mysql566-build/mysql-5.6.6-labs-june-2012/mysys/stacktrace.c= :433 #2 0x000000000070b613 in handle_fatal_signal (sig=3D6) at /home/prohaska/mysql566-build/mysql-5.6.6-labs-june-2012/sql/signal_handler= .cc:248 #3 #4 0x0000003006a32885 in raise () from /lib64/libc.so.6 #5 0x0000003006a34065 in abort () from /lib64/libc.so.6 #6 0x0000003006a2b9fe in __assert_fail_base () from /lib64/libc.so.6 #7 0x0000003006a2bac0 in __assert_fail () from /lib64/libc.so.6 #8 0x0000000000d00b37 in end_table_io_wait_v1 (locker=3D0x7ff1b37e9820) at /home/prohaska/mysql566-build/mysql-5.6.6-labs-june-2012/storage/perfsch= ema/pfs.cc:3701 #9 0x000000000062a8fb in handler::ha_delete_row (this=3D0x7ff18c00ade0, buf=3D0x7ff18c008520 "\371\001") at /home/prohaska/mysql566-build/mysql-5.6.6-labs-june-2012/sql/handler.cc:706= 1 #10 0x000000000098e39f in mysql_delete (thd=3D0x388c870, table_list=3D0x7ff1880050b0, conds=3D0x0, order_list=3D0x388f230, limit=3D18446744073709551615, options=3D0) at /home/prohaska/mysql566-build/mysql-5.6.6-labs-june-2012/sql/sql_del= ete.cc:368 #11 0x00000000007d7552 in mysql_execute_command (thd=3D0x388c870) at /home/prohaska/mysql566-build/mysql-5.6.6-labs-june-2012/sql/sql_parse.cc:3= 471 #12 0x00000000007de98b in mysql_parse (thd=3D0x388c870, rawbuf=3D0x7ff188004fe0 "delete from foo", length=3D15, parser_state=3D0x7ff1b37eb660) at /home/prohaska/mysql566-build/mysql-5.6.6-labs-june-2012/sql/sql_par= se.cc:6110 #13 0x00000000007d2031 in dispatch_command (command=3DCOM_QUERY, thd=3D0x388c870, packet=3D0x3961fc1 "delete from foo", packet_length=3D15) at /home/prohaska/mysql566-build/mysql-5.6.6-labs-june-2012/sql/sql_par= se.cc:1314 #14 0x00000000007d121c in do_command (thd=3D0x388c870) at /home/prohaska/mysql566-build/mysql-5.6.6-labs-june-2012/sql/sql_parse.cc:1= 036 #15 0x0000000000776ab1 in do_handle_one_connection (thd_arg=3D0x388c870) at /home/prohaska/mysql566-build/mysql-5.6.6-labs-june-2012/sql/sql_connect= .cc:969 #16 0x000000000077658d in handle_one_connection (arg=3D0x388c870) at /home/prohaska/mysql566-build/mysql-5.6.6-labs-june-2012/sql/sql_connect.cc= :885 #17 0x0000000000cfcf77 in pfs_spawn_thread (arg=3D0x38bb180) at /home/prohaska/mysql566-build/mysql-5.6.6-labs-june-2012/storage/perfschema= /pfs.cc:1827 #18 0x0000003006e077f1 in start_thread () from /lib64/libpthread.so.0 #19 0x0000003006ae592d in clone () from /lib64/libc.so.6 (gdb) fr 8 #8 0x0000000000d00b37 in end_table_io_wait_v1 (locker=3D0x7ff1b37e9820) at /home/prohaska/mysql566-build/mysql-5.6.6-labs-june-2012/storage/perfsch= ema/pfs.cc:3701 3701 (state->m_index =3D=3D MAX_INDEXES)); (gdb) p *state $1 =3D {m_flags =3D 7, m_io_operation =3D PSI_TABLE_DELETE_ROW, m_table =3D 0x7ff1ba3ea080, m_table_share =3D 0x1, m_thread =3D 0x7ff1ba1c8000, m_timer_start =3D 14706903268427, m_timer =3D 0xda116c , m_wait =3D 0x7ff1ba1c8150, m_inde= x =3D 0} (gdb) p *table $2 =3D {m_io_enabled =3D true, m_lock_enabled =3D true, m_io_timed =3D true= , m_lock_timed =3D true, m_has_io_stats =3D true, m_has_lock_stats =3D true, m_lock =3D {m_state =3D 2, m_version =3D 1}, m_thread_owner =3D 0x7ff1ba1c8000, m_share =3D 0x7ff1bb719780, m_identity =3D 0x7ff18c00ade0, m_table_stat =3D {m_index_stat =3D {{m_has_data =3D false, m_fetch =3D {m_count =3D 0, m_sum =3D 0, m_min =3D 18446744073709551615, m_max =3D 0}, m_insert =3D {m_count =3D 0, m_sum =3D 0, m_min =3D 18446744073709551615, m_max =3D 0}, m_update =3D {m_count =3D 0, m_sum =3D 0, m_min =3D 18446744073709551615, m_max =3D 0}, m_delete =3D {m_count =3D 0, m_sum =3D 0, m_min =3D 18446744073709551615, m_max =3D 0}} , {m_has_data =3D true, m_fetch =3D {m_count =3D 1, m_sum =3D 65245, m_min =3D 65245, m_max =3D 65245}, m_insert =3D {m_count =3D 3, m_sum =3D 27360, m_min =3D 2154, m_max =3D 22251}, m_update =3D {m_count =3D 0, m_sum =3D 0, m_min =3D 18446744073709551615, m_max =3D 0}, m_delete =3D {m_count =3D 0, m_sum =3D 0, m_min =3D 18446744073709551615, m_max =3D 0}}}, m_lock_stat =3D {m_stat =3D {{m_count =3D 0, m_sum =3D 0, m_min =3D 18446744073709551615, m_max =3D 0}, {m_count =3D 0, m_sum =3D 0, m_min =3D 18446744073709551615, m_max =3D 0}, {m_count =3D 0, m_sum =3D 0, m_min =3D 18446744073709551615, m_max =3D 0}, {m_count =3D 0, m_sum =3D 0, m_min =3D 18446744073709551615, m_max =3D 0}, {m_count =3D 2, m_sum =3D 6485, m_min =3D 3056, m_max =3D 3429}, {m_count =3D 0, m_sum =3D 0, m_min =3D 18446744073709551615, m_max =3D 0}, {m_count =3D 0, m_sum =3D 0, m_min =3D 18446744073709551615, m_max =3D 0}, {m_count =3D 0, m_sum =3D 0, m_min =3D 18446744073709551615, m_max =3D 0}, {m_count =3D 0, m_sum =3D 0, m_min =3D 18446744073709551615, m_max =3D 0}, {m_count =3D 0, m_sum =3D 0, m_min =3D 18446744073709551615, m_max =3D 0}, = { m_count =3D 2, m_sum =3D 49092, m_min =3D 24111, m_max =3D 24981}= }}, static g_reset_template =3D {m_index_stat =3D {{m_has_data =3D false, m_fetch =3D {m_count =3D 0, m_sum =3D 0, m_min =3D 18446744073709551615, m_max =3D 0}, m_insert =3D {m_count =3D 0, m_sum =3D 0, m_min = =3D 18446744073709551615, m_max =3D 0}, m_update =3D {m_count =3D 0, m_sum =3D = 0, m_min =3D 18446744073709551615, m_max =3D 0}, m_delete =3D { m_count =3D 0, m_sum =3D 0, m_min =3D 18446744073709551615, m_max =3D 0}} }, m_lock_stat =3D {m_stat =3D {{m_count = =3D 0, m_sum =3D 0, m_min =3D 18446744073709551615, m_max =3D 0} }}, static g_reset_template =3D }}} On Fri, Jun 8, 2012 at 2:46 AM, Marc Alff wrote: > > > Hi Rich, > > > On 6/7/12 11:49 PM, Rich Prohaska wrote: >> >> Hello, >> >> Some of our tests assert when running on the MySQL 5.6.6 labs june >> release, =A0The assert is at pfs.cc line 3701. =A0In our case, >> state->m_index =3D=3D 0 and table->m_share->m_key_count =3D=3D 0, so the >> assert fires. =A0Is this assert correct? > > > The assert is: > > =A0DBUG_ASSERT((state->m_index < table->m_share->m_key_count) || > =A0 =A0 =A0 =A0 =A0 =A0 =A0(state->m_index =3D=3D MAX_INDEXES)); > > which looks correct. > > What it means is: > - table io done using an index should use m_index in the [0, m_key_count-= 1] range. > For example with 10 indexes, [0, 9] > - table io done using no index at all should be done using m_index =3D MA= X_INDEXES > > In this case, m_index =3D 0 (using the first index) with a table that has= no index (m_key_count =3D 0) looks like a bug in the caller. > > It would help to have more details about the call stack leading to this p= oint, to see where the index value passed comes from. > > Regards, > -- Marc Alff, Oracle. > > > > > -- > MySQL Internals Mailing List > For list archives: http://lists.mysql.com/internals > To unsubscribe: =A0 =A0http://lists.mysql.com/internals >