[MDEV-16761] show_all_plugins core dumps on debug builds Created: 2018-07-14  Updated: 2018-10-05  Resolved: 2018-10-05

Status: Closed
Project: MariaDB Server
Component/s: Plugins
Affects Version/s: 10.3.8, 10.4
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Michael Widenius Assignee: Sergei Golubchik
Resolution: Cannot Reproduce Votes: 0
Labels: need_feedback


 Description   

BUILD/compile-pentium64-valgrind-max
mtr --no-reorder plugins.show_all_plugins
worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019
plugins.show_all_plugins                 [ pass ]    139
***Warnings generated in error logs during shutdown after running tests: plugins.show_all_plugins
180714 13:57:48 [ERROR] mysqld got signal 11 ;

However there is no stack trace in the error log.

Valgrind shows the following:

==12986== Thread 6:
==12986== Jump to the invalid address stated on the next line
==12986==    at 0x106B4EB0: ???
==12986==    by 0x4E3E4E1: __nptl_deallocate_tsd (in /lib64/libpthread-2.22.so)
==12986==    by 0x4E3E736: start_thread (in /lib64/libpthread-2.22.so)
==12986==    by 0x719FE8C: clone (in /lib64/libc-2.22.so)
==12986==  Address 0x106b4eb0 is 11,232 bytes inside a block of size 32,816 free'd
==12986==    at 0x4C2B1E0: free (vg_replace_malloc.c:530)
==12986==    by 0x716B3BC: closedir (in /lib64/libc-2.22.so)
==12986==    by 0x134FA63: my_dir (my_lib.c:172)
==12986==    by 0x83B8B8: find_files(THD*, Dynamic_array<st_mysql_const_lex_string*>*, st_mysql_const_lex_string*, char const*, st_mysql_const_lex_string const*) (sql_show.cc:1034)
==12986==    by 0x8458C4: make_table_name_list(THD*, Dynamic_array<st_mysql_const_lex_string*>*, LEX*, st_lookup_field_values*, st_mysql_const_lex_string*) (sql_show.cc:4421)
==12986==    by 0x846FC6: get_all_tables(THD*, TABLE_LIST*, Item*) (sql_show.cc:5144)
==12986==    by 0x85704A: get_schema_tables_result(JOIN*, enum_schema_table_state) (sql_show.cc:8775)
==12986==    by 0x7F2118: JOIN::exec_inner() (sql_select.cc:4039)
==12986==    by 0x7F179F: JOIN::exec() (sql_select.cc:3870)
==12986==    by 0x7F2A62: mysql_select(THD*, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*) (sql_select.cc:4275)
==12986==    by 0x7E43D5: handle_select(THD*, LEX*, select_result*, unsigned long) (sql_select.cc:382)
==12986==    by 0x7AFB3C: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:6545)
==12986==    by 0x7A64BA: mysql_execute_command(THD*) (sql_parse.cc:3768)
==12986==    by 0x6CEED5: sp_instr_stmt::exec_core(THD*, unsigned int*) (sp_head.cc:3566)
==12986==    by 0x6CE377: sp_lex_keeper::reset_lex_and_exec_core(THD*, unsigned int*, bool, sp_instr*) (sp_head.cc:3294)
==12986==    by 0x6CEADD: sp_instr_stmt::execute(THD*, unsigned int*) (sp_head.cc:3472)
==12986==  Block was alloc'd at
==12986==    at 0x4C2A0E6: malloc (vg_replace_malloc.c:299)
==12986==    by 0x716B1E0: __alloc_dir (in /lib64/libc-2.22.so)
==12986==    by 0x716B2E2: opendir_tail (in /lib64/libc-2.22.so)
==12986==    by 0x134F84F: my_dir (my_lib.c:124)
==12986==    by 0x83B8B8: find_files(THD*, Dynamic_array<st_mysql_const_lex_string*>*, st_mysql_const_lex_string*, char const*, st_mysql_const_lex_string const*) (sql_show.cc:1034)
==12986==    by 0x8458C4: make_table_name_list(THD*, Dynamic_array<st_mysql_const_lex_string*>*, LEX*, st_lookup_field_values*, st_mysql_const_lex_string*) (sql_show.cc:4421)
==12986==    by 0x846FC6: get_all_tables(THD*, TABLE_LIST*, Item*) (sql_show.cc:5144)
==12986==    by 0x85704A: get_schema_tables_result(JOIN*, enum_schema_table_state) (sql_show.cc:8775)
==12986==    by 0x7F2118: JOIN::exec_inner() (sql_select.cc:4039)
==12986==    by 0x7F179F: JOIN::exec() (sql_select.cc:3870)
==12986==    by 0x7F2A62: mysql_select(THD*, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*) (sql_select.cc:4275)
==12986==    by 0x7E43D5: handle_select(THD*, LEX*, select_result*, unsigned long) (sql_select.cc:382)
==12986==    by 0x7AFB3C: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:6545)
==12986==    by 0x7A64BA: mysql_execute_command(THD*) (sql_parse.cc:3768)
==12986==    by 0x6CEED5: sp_instr_stmt::exec_core(THD*, unsigned int*) (sp_head.cc:3566)
==12986==    by 0x6CE377: sp_lex_keeper::reset_lex_and_exec_core(THD*, unsigned int*, bool, sp_instr*) (sp_head.cc:3294)
==12986== Invalid read of size 1
==12986==    at 0x106B4EB0: ???
==12986==    by 0x4E3E4E1: __nptl_deallocate_tsd (in /lib64/libpthread-2.22.so)
==12986==    by 0x4E3E736: start_thread (in /lib64/libpthread-2.22.so)
==12986==    by 0x719FE8C: clone (in /lib64/libc-2.22.so)
==12986==  Address 0x1 is not stack'd, malloc'd or (recently) free'd
180714 13:49:14 [ERROR] mysqld got signal 11 ;

printing of stack seems to fail as the stack contains wrong information (valgrind warns about this too, but not related to the problem).



 Comments   
Comment by Sergei Golubchik [ 2018-08-09 ]

I cannot repeat it:

BUILD/compile-pentium64-valgrind-max
./mtr --no-reorder plugins.show_all_plugins
worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019
plugins.show_all_plugins                 [ pass ]    278
--------------------------------------------------------------------------
The servers were restarted 0 times
Spent 0.278 of 5 seconds executing testcases
 
Completed: All 1 tests were successful.

Anything else I should try?

Comment by Elena Stepanova [ 2018-09-10 ]

I'm not getting it either, regular test passes, and with valgrind it only produces "blocks are still reachable".
However, given oddities like MDEV-15174 (which happens upon 340th execution of SELECT), I can' imagine something can be specific to the machine or exact set of plugins it produces, or whatever. I suppose the full list of stuff in the plugin datadir might help.

Comment by Michael Widenius [ 2018-10-05 ]

I upgraded my system to latest OpenSuse 15.0 and could not repeat the problem anymore with the latest 10.3 branch
I tested with and without valgrind without any issues.

So either it's fixed or then the issue was somehow related to my system.
Strange, but not much that can be done now for this.

Comment by Michael Widenius [ 2018-10-05 ]

Can't repeat anymore

Generated at Thu Feb 08 08:31:21 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.