[MDEV-19838] mariadb odbc driver 3.1.1-ga sometimes crashes mariadb-server 10.3.16 Created: 2019-06-23  Updated: 2021-10-04  Resolved: 2020-10-29

Status: Closed
Project: MariaDB Server
Component/s: Prepared Statements
Affects Version/s: 10.3.16, 10.4, 10.5
Fix Version/s: 10.2.35, 10.3.26, 10.4.16, 10.5.7

Type: Bug Priority: Blocker
Reporter: Matthias Schröder Assignee: Oleksandr Byelkin
Resolution: Fixed Votes: 0
Labels: odbc
Environment:

Debian Stretch, Mariadb 10.3.16, Mariadb ODBC Driver 3.1.1-ga


Attachments: Text File expect_need_data-test.patch     Text File mdev-19838.c     Text File mdev-19838extv3.c     Text File segv_mdb_10_3_16_rel.test.patch    
Issue Links:
Problem/Incident
causes MDEV-24146 latest update (10.5.7) breaks communi... Closed
Relates
relates to MDEV-17334 Crash on prepared SELECT statement Closed
relates to MDEV-26761 main.mysql_client_test test_mdev19838... Closed

 Description   

The attached test-case for mariadb odbc driver 3.1.1 causes mariadb 10.3.16 server to crash with different stack-traces, this is indeed a problem of the odbc driver however the server shouldn't crash. I consider this bug critical because it is too easy to bring the server down and mdb 10.3 is about to become the new stable version of debian.

Edit: I have attached a better test segv_mdb_10_3_16_rel.test.patch, the first one didn't crash the release build of mdb server.

Stack-Trace One:

190623 13:03:51 [ERROR] mysqld got signal 11 ;
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.
 
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
 
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.
 
Server version: 10.3.16-MariaDB-debug-log
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=2
max_threads=2050
thread_count=8
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 4639127 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x7f9648000b00
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...
stack_bottom = 0x7f99688d7d40 thread_stack 0x49000
mysys/stacktrace.c:269(my_print_stacktrace)[0x55b3976e6256]
sql/signal_handler.cc:209(handle_fatal_signal)[0x55b396f3af55]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110e0)[0x7f99818730e0]
sql/log_event.cc:1148(append_query_string(charset_info_st const*, String*, char const*, unsigned long, bool))[0x55b397068864]
sql/item.cc:4764(Item_param::value_query_val_str(THD*, String*) const)[0x55b396f62735]
sql/item.cc:4780(Item_param::query_val_str(THD*, String*) const)[0x55b396f627cb]
sql/item.cc:5125(Item_param::append_for_log(THD*, String*))[0x55b396f6366d]
sql/item.h:564(Copy_query_with_rewrite::append(Rewritable_query_parameter*))[0x55b396b733da]
sql/sql_prepare.cc:847(insert_params_with_log(Prepared_statement*, unsigned char*, unsigned char*, unsigned char*, String*))[0x55b396c623a8]
sql/sql_prepare.cc:4135(Prepared_statement::set_parameters(String*, unsigned char*, unsigned char*))[0x55b396c69ba8]
sql/sql_prepare.cc:4205(Prepared_statement::execute_loop(String*, bool, unsigned char*, unsigned char*))[0x55b396c69cde]
sql/sql_prepare.cc:3235(mysql_stmt_execute_common(THD*, unsigned long, unsigned char*, unsigned char*, unsigned long, bool, bool))[0x55b396c67694]
sql/sql_prepare.cc:3133(mysqld_stmt_execute(THD*, char*, unsigned int))[0x55b396c6722f]
sql/sql_parse.cc:1801(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x55b396c3ba38]
sql/sql_parse.cc:1403(do_command(THD*))[0x55b396c3a809]
sql/sql_connect.cc:1402(do_handle_one_connection(CONNECT*))[0x55b396da3ca1]
sql/sql_connect.cc:1309(handle_one_connection)[0x55b396da3a18]
nptl/pthread_create.c:456(start_thread)[0x7f99818694a4]
x86_64/clone.S:99(clone)[0x7f997f99ed0f]

Stack-Trace Two:

Version: '10.3.16-MariaDB-debug-log'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution
mysqld: /usr/local/src/mariadb/sql/sql_type.cc:999: static const Type_handler* Type_handler::get_handler_by_field_type(enum_field_types): Assertion `0' failed.
190623 13:06:30 [ERROR] mysqld got signal 6 ;
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.
 
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
 
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.
 
Server version: 10.3.16-MariaDB-debug-log
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=1
max_threads=2050
thread_count=7
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 4639127 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x7f765c000b00
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...
stack_bottom = 0x7f796d0f6d40 thread_stack 0x49000
mysys/stacktrace.c:269(my_print_stacktrace)[0x55833b0b2256]
sql/signal_handler.cc:209(handle_fatal_signal)[0x55833a906f55]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110e0)[0x7f79888d50e0]
linux/raise.c:51(__GI_raise)[0x7f798694afff]
stdlib/abort.c:91(__GI_abort)[0x7f798694c42a]
assert/assert.c:92(__assert_fail_base)[0x7f7986943e67]
/lib/x86_64-linux-gnu/libc.so.6(+0x2bf12)[0x7f7986943f12]
sql/sql_type.cc:1001(Type_handler::get_handler_by_field_type(enum_field_types))[0x55833a7f2a05]
sql/sql_prepare.cc:733(Item_param::setup_conversion(THD*, unsigned char))[0x55833a62df9e]
sql/sql_prepare.cc:974(set_conversion_functions(Prepared_statement*, unsigned char**, unsigned char*))[0x55833a62e97d]
sql/sql_prepare.cc:995(setup_conversion_functions(Prepared_statement*, unsigned char**, unsigned char*, bool))[0x55833a62ea7a]
sql/sql_prepare.cc:4135(Prepared_statement::set_parameters(String*, unsigned char*, unsigned char*))[0x55833a635b83]
sql/sql_prepare.cc:4205(Prepared_statement::execute_loop(String*, bool, unsigned char*, unsigned char*))[0x55833a635cde]
sql/sql_prepare.cc:3235(mysql_stmt_execute_common(THD*, unsigned long, unsigned char*, unsigned char*, unsigned long, bool, bool))[0x55833a633694]
sql/sql_prepare.cc:3133(mysqld_stmt_execute(THD*, char*, unsigned int))[0x55833a63322f]
sql/sql_parse.cc:1801(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x55833a607a38]
sql/sql_parse.cc:1403(do_command(THD*))[0x55833a606809]
sql/sql_connect.cc:1402(do_handle_one_connection(CONNECT*))[0x55833a76fca1]
sql/sql_connect.cc:1309(handle_one_connection)[0x55833a76fa18]
nptl/pthread_create.c:456(start_thread)[0x7f79888cb4a4]
x86_64/clone.S:99(clone)[0x7f7986a00d0f]



 Comments   
Comment by Oleksandr Byelkin [ 2019-10-15 ]

Lawrin If you can make from this something I can test, please do, if no, just reassign it to me please.

Comment by Lawrin Novitsky [ 2020-10-20 ]

I've attached C API test reliably repeating crash. It should be equivalent to the ODBC test. But It's been a while since I created it, so wanted to verify that once again today, but had some issue with that. But it really should be equivalent.

Comment by Oleksandr Byelkin [ 2020-10-21 ]

10.1 and 10.2 are OK

Comment by Lawrin Novitsky [ 2020-10-26 ]

I've attached extended( and minimized) test version - mdev-19838extv3.c

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