Details

    Description

      Even though I used version 10.5.11 previously and reinstalled it with 10.10.2 after the issue occurred, the same error occurs.
      The error usually works normally, but when select query is executed, it shuts down after 3 seconds.
      Additionally, SET STATEMENT max_statement_time=5000 FOR is automatically appended to queries remaining in the err file. Why is that?
      Of course, there are also unattached queries.

      [ERROR] mysqld got exception 0xc0000005 ;
      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.10.2-MariaDB
      key_buffer_size=805306368
      read_buffer_size=25165824
      max_used_connections=37
      max_threads=65537
      thread_count=23
      It is possible that mysqld could use up to 
      key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 5906501846 K  bytes of memory
      Hope that's ok; if not, decrease some variables in the equation.
       
      Thread pointer: 0x21f27b97ef8
      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...
      server.dll!ha_maria::extra()[ha_maria.cc:2682]
      server.dll!JOIN::cleanup()[sql_select.cc:14901]
      server.dll!JOIN::join_free()[sql_select.cc:14773]
      server.dll!do_select()[sql_select.cc:21408]
      server.dll!JOIN::exec_inner()[sql_select.cc:4823]
      server.dll!mysql_select()[sql_select.cc:5081]
      server.dll!handle_select()[sql_select.cc:581]
      server.dll!execute_sqlcom_select()[sql_parse.cc:6261]
      server.dll!mysql_execute_command()[sql_parse.cc:3945]
      server.dll!mysql_parse()[sql_parse.cc:8025]
      server.dll!dispatch_command()[sql_parse.cc:1896]
      server.dll!do_command()[sql_parse.cc:1407]
      server.dll!tp_callback()[threadpool_common.cc:245]
      KERNEL32.DLL!LCMapStringEx()
      ntdll.dll!RtlAddRefActivationContext()
      ntdll.dll!RtlAcquireSRWLockExclusive()
      KERNEL32.DLL!BaseThreadInitThunk()
      ntdll.dll!RtlUserThreadStart()
       
      Trying to get some variables.
      Some pointers may be invalid and cause the dump to abort.
      Query (0x193f57092d0): SET STATEMENT max_statement_time=5000 FOR 
              SELECT ATTACH_GRP_NO    
                   , ATTACH
                   , MODULE
                   , trim(CD_FILE_TYPE) AS CD_FILE_TYPE
                   , NAME
                   , CONCAT(LEFT(NAME, INSTR(NAME, SUBSTRING_INDEX(NAME, '_', -1))-2), '.', FORMAT) AS ORIGIN_NAME
                   , PATH
                   , FORMAT
                   , FILE_SIZE
                     , @ROWNUM := @ROWNUM +1 AS SEQ_DSP
                   , MEMO
                   , CNT_DOWNLOAD
                   , DATE_C
                   , DATE_E
                   , THUMB_YN
                FROM SYS_ATTACH , (SELECT @ROWNUM := 0)RN
               WHERE CD_DEL = '1'
                AND ATTACH_GRP_NO = '1234'
              ORDER BY SEQ_DSP,DATE_C DESC
      Connection ID (thread ID): 4362
      Status: NOT_KILLED
       
      Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on,not_null_range_scan=off
       
      The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
      information that should help you find out what is causing the crash.
      Writing a core file at C:\Program Files\MariaDB 10.5\data\
      

      When the query is executed, it works without problems.

      Attachments

        Issue Links

          Activity

            jbpark Jongbeom Park added a comment -

            Since setting it as an exception folder for scanning of Antivirus, permission issues have not occurred until now.
            The cause of the issue seems to be an application conflict between antivirus and mariadb.
            Monitoring is still ongoing.
            Thank you for your efforts in resolving the issue.

            jbpark Jongbeom Park added a comment - Since setting it as an exception folder for scanning of Antivirus, permission issues have not occurred until now. The cause of the issue seems to be an application conflict between antivirus and mariadb. Monitoring is still ongoing. Thank you for your efforts in resolving the issue.
            danblack Daniel Black added a comment -

            Thanks for the feedback jbpark.

            wlad's workaround only keeps trying 50 times on a 10ms between retries, so 0.5 seconds. Its enough to avoid small transitory interruptions, but per MDEV-30162 we're still blaming the AV for not enough sharing on what aren't its files.

            danblack Daniel Black added a comment - Thanks for the feedback jbpark . wlad 's workaround only keeps trying 50 times on a 10ms between retries, so 0.5 seconds. Its enough to avoid small transitory interruptions, but per MDEV-30162 we're still blaming the AV for not enough sharing on what aren't its files.

            First part of the patch, setting table->file=NULL is not needed as we set it a few lines later and there is nothing in between that can use it.
            The second part of the patch is ok (will probably not help but not harm either). I will push this to 10.5 as the original problem originated from there

            monty Michael Widenius added a comment - First part of the patch, setting table->file=NULL is not needed as we set it a few lines later and there is nothing in between that can use it. The second part of the patch is ok (will probably not help but not harm either). I will push this to 10.5 as the original problem originated from there

            I may have found the issue.

            The problem is probably that when we close a temporary file, we don't set created to 0, which causes wrong cleanup code to be executed later.
            I will push a fix for this in 10.5 shortly. Hopefully this makes this problem go away

            monty Michael Widenius added a comment - I may have found the issue. The problem is probably that when we close a temporary file, we don't set created to 0, which causes wrong cleanup code to be executed later. I will push a fix for this in 10.5 shortly. Hopefully this makes this problem go away

            Pushed fix that 'should' fix the issue.
            Cannot test as there is no reproducible test case.

            monty Michael Widenius added a comment - Pushed fix that 'should' fix the issue. Cannot test as there is no reproducible test case.

            People

              monty Michael Widenius
              jbpark Jongbeom Park
              Votes:
              0 Vote for this issue
              Watchers:
              8 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.