Bug #78292 | Assertion `pfs->m_processlist_id != 0' failed in table_session_connect.cc:254 | ||
---|---|---|---|
Submitted: | 31 Aug 2015 16:48 | Modified: | 13 Nov 2015 13:48 |
Reporter: | Ramesh Sivaraman | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: DML | Severity: | S3 (Non-critical) |
Version: | 5.6.22 | OS: | CentOS (CentOS 7) |
Assigned to: | CPU Architecture: | Any | |
Tags: | debug |
[31 Aug 2015 16:48]
Ramesh Sivaraman
[31 Aug 2015 16:48]
Ramesh Sivaraman
Testcase bundle
Attachment: 1440997028_bug_bundle.tar.gz (application/gzip, text), 1012.32 KiB.
[31 Aug 2015 21:11]
MySQL Verification Team
Thank you for the bug report. No repeatable on 5.7 version. 2015-08-31 17:52:57 8852 [Note] 5.6\bin\mysqld: ready for connections. Version: '5.6.27-debug' socket: '' port: 3306 Source distribution PULL: 2015/08/14 Assertion failed: pfs->m_processlist_id != 0, file C:\ago14.2015\mysql-5.6\storage\perfschema\table_session_connect.cc, line 254 R6010 - abort() has been called 20:53:16 UTC - mysqld got exception 0x80000003 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=8388608 read_buffer_size=131072 max_used_connections=1 max_threads=1 thread_count=1 connection_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 10358 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x99e736b280 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... 7ff607e5b0f5 mysqld.exe!my_sigabrt_handler()[my_thr_init.c:458] 7ff6084380cf mysqld.exe!raise()[winsig.c:594] 7ff608444ee0 mysqld.exe!abort()[abort.c:82] 7ff608434948 mysqld.exe!_wassert()[assert.c:156] 7ff6083406be mysqld.exe!table_session_connect::make_row()[table_session_connect.cc:254] 7ff608340e7e mysqld.exe!cursor_by_thread_connect_attr::rnd_next()[cursor_by_thread_connect_attr.cc:37] 7ff6082fa152 mysqld.exe!ha_perfschema::rnd_next()[ha_perfschema.cc:332] 7ff6079651e2 mysqld.exe!handler::ha_rnd_next()[handler.cc:2688] 7ff607b94348 mysqld.exe!rr_sequential()[records.cc:480] 7ff607d1ef0d mysqld.exe!join_init_read_record()[sql_executor.cc:2400] 7ff607d1dd42 mysqld.exe!sub_select()[sql_executor.cc:1256] 7ff607d239ac mysqld.exe!do_select()[sql_executor.cc:933] 7ff607d220c5 mysqld.exe!JOIN::exec()[sql_executor.cc:194] 7ff607ca34ae mysqld.exe!mysql_execute_select()[sql_select.cc:1103] 7ff607c962f9 mysqld.exe!mysql_select()[sql_select.cc:1221] 7ff607c95f0d mysqld.exe!handle_select()[sql_select.cc:110] 7ff607aa4743 mysqld.exe!execute_sqlcom_select()[sql_parse.cc:5134] 7ff607a961a5 mysqld.exe!mysql_execute_command()[sql_parse.cc:2656] 7ff607a94c3a mysqld.exe!mysql_parse()[sql_parse.cc:6389] 7ff607a9e282 mysqld.exe!dispatch_command()[sql_parse.cc:1343] 7ff607a9d345 mysqld.exe!do_command()[sql_parse.cc:1037] 7ff607aee7b2 mysqld.exe!do_handle_one_connection()[sql_connect.cc:982] 7ff60791289f mysqld.exe!handle_connection_in_main_thread()[mysqld.cc:6036] 7ff607922247 mysqld.exe!create_new_thread()[mysqld.cc:6163] 7ff60791a279 mysqld.exe!handle_connections_sockets()[mysqld.cc:6442] 7ff60791a2f8 mysqld.exe!handle_connections_sockets_thread()[mysqld.cc:6452] 7ff6083113b5 mysqld.exe!pfs_spawn_thread()[pfs.cc:1862] 7ff607e59696 mysqld.exe!pthread_start()[my_winthread.c:62] 7ff608448725 mysqld.exe!_callthreadstartex()[threadex.c:376] 7ff608448977 mysqld.exe!_threadstartex()[threadex.c:359] 7ff867472d92 KERNEL32.DLL!BaseThreadInitThunk() 7ff867519f64 ntdll.dll!RtlUserThreadStart() Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (99e7646390): select * from performance_schema.session_connect_attrsConnection ID (thread ID): 1 Status: NOT_KILLED
[31 Aug 2015 21:12]
MySQL Verification Team
c:\dbs>5.6\bin\mysql -uroot Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 1 Server version: 5.6.27-debug Source distribution PULL: 2015/08/14 Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> DROP DATABASE test;CREATE DATABASE test;USE test; Query OK, 0 rows affected (0.00 sec) Query OK, 1 row affected (0.00 sec) Database changed mysql> select * from performance_schema.session_connect_attrs; ERROR 2013 (HY000): Lost connection to MySQL server during query mysql> exit Bye
[13 Nov 2015 13:48]
Paul DuBois
Noted in 5.6.29, 5.7.11, 5.8.0 changelogs. If server was started with --thread-handling=no-threads, no foreground thread was created for a client connection. The Performance Schema did not account for the possibility of no foreground threads for queries on the session_connect_attrs table, causing an assertion to be raised.