[MDEV-23220] MythTV SELECT request causes Mariadb server to get a segmentation violation Created: 2020-07-19  Updated: 2020-08-11  Resolved: 2020-07-20

Status: Closed
Project: MariaDB Server
Component/s: Data types
Affects Version/s: 10.4.13
Fix Version/s: 10.5.4, 10.4.14

Type: Bug Priority: Major
Reporter: Göran Uddeborg Assignee: Alexander Barkov
Resolution: Duplicate Votes: 0
Labels: mythtv
Environment:

Fedora 32 on x86_64
mariadb-server-10.4.13-2.fc32.x86_64


Attachments: File g.glbal     File g.local     File gdb_output.log     File mariadb.log     File mysqld.core.xz     File mysqld.xz    
Issue Links:
Duplicate
duplicates MDEV-20261 NULL passed to String::eq, SEGV, serv... Closed
Relates
relates to MDEV-21629 MythTV query causes MariaDB crash Closed
relates to MDEV-22050 OR + incorrect bound null causes segf... Closed

 Description   

This was first discovered when trying to watch TV on my MythTV box. The screen went black for a few moments, and then returned to the menu.

Digging for the cause, I found my way to the mariadb log, which explained the server had got a segmentation violation. I attach a log where I first restart the Mariadb server, then go over to the MythTV machine (not the same box) and select "watch TV". As you can see, it explains it gets signal 11, and then produce a lot of information I hope can help understand what the issue is.

In that log, there is a SELECT statement. The crash always happens on the same statement. I have tried to run the same statement using the mysql command line tool. I am not able to trigger the problem that way, even after doing a cut-and-paste of the query, even including all the spaces verbatim.

I also attach the core file produced. (I've been trying to look a little myself, and can see the cause is a null pointer being used, created as sa in Type_handler_string_result::Item_const_eq. But I would need much more understanding why this call produces a null pointer.)

The mysqld binary is the standard binary from the Fedora distribution, but for convenience I attach that too.



 Comments   
Comment by Daniel Black [ 2020-07-19 ]

Extracting query from log is:

Some pointers may be invalid and cause the dump to abort.
Query (0x7f580dc3c0e0): SELECT recordid, category,        (category = NULL) AS catmatch,        (category = '') AS typematch
FROM record
WHERE type = 11 AND       (category = NULL OR category = ''        OR category = 'Default') ORDER BY catmatch DESC, typematch DESC

Can you include:

show create table record;
explain {query};

Comment by Daniel Black [ 2020-07-20 ]

Looking at the differences between your global variables and the session variables in the core dump is that mythtv has set:

sql_mode=0
character_set_client=utf8mb4
character_set_results=utf8mb4
collation_database=utf8_general_ci /*note not "mb4" */
collation_connection=utf8mb4_general_ci
time_zone={changed - can't quite tell what to but didn't seem relevant to query}

To validate if these are indeed contributing to the crash can you please try:

set sql_mode='', character_set_client='utf8mb4', character_set_results='utf8mb4', collation_database='utf8_general_ci',collation_connection='utf8mb4_general_ci';
{query};

goeran, thanks for the great bug report.

Comment by Göran Uddeborg [ 2020-07-20 ]

I need to work on my search-fu, I ought to have found at least some of those other reports.

The experiments you asked me to do danielblack is no longer relevant I suppose, as the problem was fixed already in another Jira.

Thanks!

Comment by Daniel Black [ 2020-07-20 ]

Correct, nothing required. Thanks for considering it. I need to better search-fu too.

Generated at Thu Feb 08 09:20:46 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.