Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-23220

MythTV SELECT request causes Mariadb server to get a segmentation violation

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Duplicate
    • 10.4.13
    • 10.5.4, 10.4.14
    • Data types
    • Fedora 32 on x86_64
      mariadb-server-10.4.13-2.fc32.x86_64

    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.

      Attachments

        1. g.glbal
          5 kB
        2. g.local
          5 kB
        3. gdb_output.log
          18 kB
        4. mariadb.log
          14 kB
        5. mysqld.core.xz
          1.41 MB
        6. mysqld.xz
          5.26 MB

        Issue Links

          Activity

            danblack Daniel Black added a comment -

            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};
            

            danblack Daniel Black added a comment - 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};
            danblack Daniel Black added a comment - - edited

            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.

            danblack Daniel Black added a comment - - edited 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.

            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!

            goeran Göran Uddeborg added a comment - 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!
            danblack Daniel Black added a comment -

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

            danblack Daniel Black added a comment - Correct, nothing required. Thanks for considering it. I need to better search-fu too.

            People

              bar Alexander Barkov
              goeran Göran Uddeborg
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.