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

Mariadb server crashed during insert

Details

    • Bug
    • Status: Open (View Workflow)
    • Critical
    • Resolution: Unresolved
    • 11.4.4
    • 11.4
    • Galera
    • None

    Description

      250213 13:36:55 [ERROR] mysqld got signal 11 ;
      Sorry, we probably made a mistake, and this is a bug.
       
      Your assistance in bug reporting will enable us to fix this for the next release.
      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: 11.4.4-MariaDB-log source revision: e9a502df08bad16aa8a354e854f3c014b1380e32
      key_buffer_size=33554432
      read_buffer_size=131072
      max_used_connections=7
      max_threads=502
      thread_count=12
      It is possible that mysqld could use up to 
      key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1138533 K  bytes of memory
      Hope that's ok; if not, decrease some variables in the equation.
       
      WSREP: Suppressing further logging
      WSREP: Shutting down network communications
       
      Thread pointer: 0x7f4d20000c68
      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 = 0x7f4df412d000 thread_stack 0x49000
      Printing to addr2line failed
      /opt/bitnami/mariadb/sbin/mysqld(my_print_stacktrace+0x2e)[0x557e756c8dee]
      /opt/bitnami/mariadb/sbin/mysqld(handle_fatal_signal+0x2c3)[0x557e7520d653]
      /lib/x86_64-linux-gnu/libc.so.6(+0x3c050)[0x7f4e16d82050]
      /opt/bitnami/mariadb/sbin/mysqld(get_table_key+0x0)[0x557e74eeb6d0]
      /opt/bitnami/mariadb/sbin/mysqld(my_hash_first_from_hash_value+0x7b)[0x557e756b0b0b]
      /opt/bitnami/mariadb/sbin/mysqld(my_hash_search+0x11)[0x557e756b0c61]
      /opt/bitnami/mariadb/sbin/mysqld(_ZN10Rpl_filter9tables_okEPKcP10TABLE_LIST+0x122)[0x557e74eec312]
      /opt/bitnami/mariadb/sbin/mysqld(_ZN19Table_map_log_event14do_apply_eventEP14rpl_group_info+0x5f3)[0x557e75347353]
      /opt/bitnami/mariadb/sbin/mysqld(_ZN9Log_event11apply_eventEP14rpl_group_info+0x7d)[0x557e75337b7d]
      /opt/bitnami/mariadb/sbin/mysqld(_Z18wsrep_apply_eventsP3THDP14Relay_log_infoPKvm+0xeb)[0x557e754b45db]
      /opt/bitnami/mariadb/sbin/mysqld(+0xd3c9a9)[0x557e754999a9]
      /opt/bitnami/mariadb/sbin/mysqld(_ZN21Wsrep_applier_service15apply_write_setERKN5wsrep7ws_metaERKNS0_12const_bufferERNS0_14mutable_bufferE+0xb3)[0x557e7549a9a3]
      /opt/bitnami/mariadb/sbin/mysqld(+0x1005715)[0x557e75762715]
      /opt/bitnami/mariadb/sbin/mysqld(+0x101604f)[0x557e7577304f]
      /opt/bitnami/mariadb/lib/libgalera_smm.so(+0x57798)[0x7f4e0696e798]
      /opt/bitnami/mariadb/lib/libgalera_smm.so(+0x64bf4)[0x7f4e0697bbf4]
      /opt/bitnami/mariadb/lib/libgalera_smm.so(+0x6a616)[0x7f4e06981616]
      /opt/bitnami/mariadb/lib/libgalera_smm.so(+0x93331)[0x7f4e069aa331]
      /opt/bitnami/mariadb/lib/libgalera_smm.so(+0x93d07)[0x7f4e069aad07]
      /opt/bitnami/mariadb/lib/libgalera_smm.so(+0x6aa61)[0x7f4e06981a61]
      /opt/bitnami/mariadb/lib/libgalera_smm.so(+0x48908)[0x7f4e0695f908]
      /opt/bitnami/mariadb/sbin/mysqld(_ZN5wsrep18wsrep_provider_v2611run_applierEPNS_21high_priority_serviceE+0xe)[0x557e7577363e]
      /opt/bitnami/mariadb/sbin/mysqld(+0xd596ed)[0x557e754b66ed]
      2025-02-13 13:36:56 0 [Note] WSREP: (ef3d61ee-966c, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://11.127.4.37:4567 tcp://11.127.5.37:4567 
      /opt/bitnami/mariadb/sbin/mysqld(_Z15start_wsrep_THDPv+0x246)[0x557e754a64b6]
      /opt/bitnami/mariadb/sbin/mysqld(+0xce60b7)[0x557e754430b7]
      /lib/x86_64-linux-gnu/libc.so.6(+0x891c4)[0x7f4e16dcf1c4]
      /lib/x86_64-linux-gnu/libc.so.6(__clone+0x40)[0x7f4e16e4eac0]
       
      Trying to get some variables.
      Some pointers may be invalid and cause the dump to abort.

      Attachments

        Activity

          gktomar Gaurav Tomar added a comment -

          We are also facing the same issue on 10.6.16.

          gktomar Gaurav Tomar added a comment - We are also facing the same issue on 10.6.16.
          Sahai Har Gagan added a comment -

          Any update on this issue ?

          Sahai Har Gagan added a comment - Any update on this issue ?
          Sahai Har Gagan added a comment -

          This is a crash happening in our environment. Any update on this ?

          Sahai Har Gagan added a comment - This is a crash happening in our environment. Any update on this ?
          seppo Seppo Jaakola added a comment -

          Sahai Do you have replication filtering in your configuration, especially are there replicate* variables used in the my.cnf?

          seppo Seppo Jaakola added a comment - Sahai Do you have replication filtering in your configuration, especially are there replicate* variables used in the my.cnf?
          Sahai Har Gagan added a comment -

          Yes, we are using the "replicate_ignore_table" configuration for a table.

          Is that configuration causing this crash?
          Is this crash happening due to some special case when this configuration is enabled?

          Sahai Har Gagan added a comment - Yes, we are using the "replicate_ignore_table" configuration for a table. Is that configuration causing this crash? Is this crash happening due to some special case when this configuration is enabled?
          gktomar Gaurav Tomar added a comment - - edited

          Same is the case with us, we use `replicate_ignore_table=mysql.gtid_slave_pos`, and we are doing it because of MDEV-35627

          gktomar Gaurav Tomar added a comment - - edited Same is the case with us, we use `replicate_ignore_table=mysql.gtid_slave_pos`, and we are doing it because of MDEV-35627
          sysprg Julius Goryavsky added a comment -

          gktomar Sahai Can you test this on version 11.4.5 where there should be a fix for a MDEV-34924?

          sysprg Julius Goryavsky added a comment - gktomar Sahai Can you test this on version 11.4.5 where there should be a fix for a MDEV-34924 ?
          Sahai Har Gagan added a comment -

          Hi Julius Gorysky,

          Thanks for looking into this issue.

          I am not clear if the suggested build 11.4.5 which has fix for MDEV-34924 is related to current coredump issue or not? The other bug (MDEV-34924) doesn't really have crash reported. Could you please confirm this before we move our version to the suggested one?

          In our use case, the parameter 'replicate ignore table' is used not for table mysql.gtid_slave_pos but one of the internal custom tables. Would this crash also happen in that case irrespective to any table?

          Sahai Har Gagan added a comment - Hi Julius Gorysky, Thanks for looking into this issue. I am not clear if the suggested build 11.4.5 which has fix for MDEV-34924 is related to current coredump issue or not? The other bug ( MDEV-34924 ) doesn't really have crash reported. Could you please confirm this before we move our version to the suggested one? In our use case, the parameter 'replicate ignore table' is used not for table mysql.gtid_slave_pos but one of the internal custom tables. Would this crash also happen in that case irrespective to any table?

          People

            sysprg Julius Goryavsky
            Sahai Har Gagan
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

              Created:
              Updated:

              Git Integration

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