List:Internals« Previous MessageNext Message »
From:Rich Prohaska Date:June 8 2012 1:32pm
Subject:Re: possible overactive assert in pfs.cc line 3701
View as plain text  
Hello,
Hope this helps:

(gdb) bt
#0  0x0000003006e0c63c in pthread_kill () from /lib64/libpthread.so.0
#1  0x0000000000a61f97 in my_write_core (sig=6) at
/home/prohaska/mysql566-build/mysql-5.6.6-labs-june-2012/mysys/stacktrace.c:433
#2  0x000000000070b613 in handle_fatal_signal (sig=6) at
/home/prohaska/mysql566-build/mysql-5.6.6-labs-june-2012/sql/signal_handler.cc:248
#3  <signal handler called>
#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=0x7ff1b37e9820)
at /home/prohaska/mysql566-build/mysql-5.6.6-labs-june-2012/storage/perfschema/pfs.cc:3701
#9  0x000000000062a8fb in handler::ha_delete_row (this=0x7ff18c00ade0,
buf=0x7ff18c008520 "\371\001") at
/home/prohaska/mysql566-build/mysql-5.6.6-labs-june-2012/sql/handler.cc:7061
#10 0x000000000098e39f in mysql_delete (thd=0x388c870,
table_list=0x7ff1880050b0, conds=0x0, order_list=0x388f230,
limit=18446744073709551615, options=0)
    at /home/prohaska/mysql566-build/mysql-5.6.6-labs-june-2012/sql/sql_delete.cc:368
#11 0x00000000007d7552 in mysql_execute_command (thd=0x388c870) at
/home/prohaska/mysql566-build/mysql-5.6.6-labs-june-2012/sql/sql_parse.cc:3471
#12 0x00000000007de98b in mysql_parse (thd=0x388c870,
rawbuf=0x7ff188004fe0 "delete from foo", length=15,
parser_state=0x7ff1b37eb660)
    at /home/prohaska/mysql566-build/mysql-5.6.6-labs-june-2012/sql/sql_parse.cc:6110
#13 0x00000000007d2031 in dispatch_command (command=COM_QUERY,
thd=0x388c870, packet=0x3961fc1 "delete from foo", packet_length=15)
    at /home/prohaska/mysql566-build/mysql-5.6.6-labs-june-2012/sql/sql_parse.cc:1314
#14 0x00000000007d121c in do_command (thd=0x388c870) at
/home/prohaska/mysql566-build/mysql-5.6.6-labs-june-2012/sql/sql_parse.cc:1036
#15 0x0000000000776ab1 in do_handle_one_connection (thd_arg=0x388c870)
at /home/prohaska/mysql566-build/mysql-5.6.6-labs-june-2012/sql/sql_connect.cc:969
#16 0x000000000077658d in handle_one_connection (arg=0x388c870) at
/home/prohaska/mysql566-build/mysql-5.6.6-labs-june-2012/sql/sql_connect.cc:885
#17 0x0000000000cfcf77 in pfs_spawn_thread (arg=0x38bb180) 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=0x7ff1b37e9820)
at /home/prohaska/mysql566-build/mysql-5.6.6-labs-june-2012/storage/perfschema/pfs.cc:3701
3701	              (state->m_index == MAX_INDEXES));
(gdb) p *state
$1 = {m_flags = 7, m_io_operation = PSI_TABLE_DELETE_ROW, m_table =
0x7ff1ba3ea080, m_table_share = 0x1, m_thread = 0x7ff1ba1c8000,
m_timer_start = 14706903268427,
  m_timer = 0xda116c <my_timer_cycles>, m_wait = 0x7ff1ba1c8150, m_index = 0}
(gdb) p *table
$2 = {m_io_enabled = true, m_lock_enabled = true, m_io_timed = true,
m_lock_timed = true, m_has_io_stats = true, m_has_lock_stats = true,
m_lock = {m_state = 2, m_version = 1},
  m_thread_owner = 0x7ff1ba1c8000, m_share = 0x7ff1bb719780,
m_identity = 0x7ff18c00ade0, m_table_stat = {m_index_stat =
{{m_has_data = false, m_fetch = {m_count = 0, m_sum = 0,
          m_min = 18446744073709551615, m_max = 0}, m_insert =
{m_count = 0, m_sum = 0, m_min = 18446744073709551615, m_max = 0},
m_update = {m_count = 0, m_sum = 0, m_min = 18446744073709551615,
          m_max = 0}, m_delete = {m_count = 0, m_sum = 0, m_min =
18446744073709551615, m_max = 0}} <repeats 64 times>, {m_has_data =
true, m_fetch = {m_count = 1, m_sum = 65245, m_min = 65245,
          m_max = 65245}, m_insert = {m_count = 3, m_sum = 27360,
m_min = 2154, m_max = 22251}, m_update = {m_count = 0, m_sum = 0,
m_min = 18446744073709551615, m_max = 0}, m_delete = {m_count = 0,
          m_sum = 0, m_min = 18446744073709551615, m_max = 0}}},
m_lock_stat = {m_stat = {{m_count = 0, m_sum = 0, m_min =
18446744073709551615, m_max = 0}, {m_count = 0, m_sum = 0,
          m_min = 18446744073709551615, m_max = 0}, {m_count = 0,
m_sum = 0, m_min = 18446744073709551615, m_max = 0}, {m_count = 0,
m_sum = 0, m_min = 18446744073709551615, m_max = 0}, {m_count = 2,
          m_sum = 6485, m_min = 3056, m_max = 3429}, {m_count = 0,
m_sum = 0, m_min = 18446744073709551615, m_max = 0}, {m_count = 0,
m_sum = 0, m_min = 18446744073709551615, m_max = 0}, {m_count = 0,
          m_sum = 0, m_min = 18446744073709551615, m_max = 0},
{m_count = 0, m_sum = 0, m_min = 18446744073709551615, m_max = 0},
{m_count = 0, m_sum = 0, m_min = 18446744073709551615, m_max = 0}, {
          m_count = 2, m_sum = 49092, m_min = 24111, m_max = 24981}}},
static g_reset_template = {m_index_stat = {{m_has_data = false,
m_fetch = {m_count = 0, m_sum = 0, m_min = 18446744073709551615,
            m_max = 0}, m_insert = {m_count = 0, m_sum = 0, m_min =
18446744073709551615, m_max = 0}, m_update = {m_count = 0, m_sum = 0,
m_min = 18446744073709551615, m_max = 0}, m_delete = {
            m_count = 0, m_sum = 0, m_min = 18446744073709551615,
m_max = 0}} <repeats 65 times>}, m_lock_stat = {m_stat = {{m_count =
0, m_sum = 0, m_min = 18446744073709551615,
            m_max = 0} <repeats 11 times>}}, static g_reset_template =
<same as static member of an already seen type>}}}

On Fri, Jun 8, 2012 at 2:46 AM, Marc Alff <marc.alff@stripped> 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,  The assert is at pfs.cc line 3701.  In our case,
>> state->m_index == 0 and table->m_share->m_key_count == 0, so the
>> assert fires.  Is this assert correct?
>
>
> The assert is:
>
>  DBUG_ASSERT((state->m_index < table->m_share->m_key_count) ||
>              (state->m_index == 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 = MAX_INDEXES
>
> In this case, m_index = 0 (using the first index) with a table that has no index
> (m_key_count = 0) looks like a bug in the caller.
>
> It would help to have more details about the call stack leading to this point, 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:    http://lists.mysql.com/internals
>
Thread
possible overactive assert in pfs.cc line 3701Rich Prohaska7 Jun
  • Re: possible overactive assert in pfs.cc line 3701Marc Alff8 Jun
    • Re: possible overactive assert in pfs.cc line 3701Rich Prohaska8 Jun