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

MariaDB crashed

        Details

        • Type: Bug
        • Status: Open
        • Priority: Major
        • Resolution: Unresolved
        • Affects Version/s: 10.0.20
        • Fix Version/s: None
        • Component/s: None
        • Labels:
          None

          Description

          150625 21:40:52 [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 http://kb.askmonty.org/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.0.19-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=1
max_threads=153
thread_count=1
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0x7ff6bd068e88
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 = 0x7ff6bb7d9dc0 thread_stack 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7ff6bb28e37d]
/usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7ff6bae06e3d]
/lib64/libpthread.so.0(+0x3775a10430)[0x7ff6ba4a9430]
/usr/libexec/mysqld(+0x8688a4)[0x7ff6bb1408a4]
/usr/libexec/mysqld(+0x7b51b2)[0x7ff6bb08d1b2]
/usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7ff6bad9b74c]
/usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7ff6bad9db30]
/usr/libexec/mysqld(+0x602a8f)[0x7ff6baedaa8f]
/usr/libexec/mysqld(+0x602f3d)[0x7ff6baedaf3d]
/usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7ff6baeecff8]
/usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7ff6bad3f82a]
/usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7ff6baca8d64]
/usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7ff6bacaccd3]
/usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7ff6bacae701]
/usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7ff6bad72b82]
/usr/libexec/mysqld(handle_one_connection+0x40)[0x7ff6bad72c20]
/lib64/libpthread.so.0(+0x3775a07555)[0x7ff6ba4a0555]
/lib64/libc.so.6(clone+0x6d)[0x7ff6b8a37f3d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7ff678004c60): update `taganka-demo`.`appl_profile_doc` set `series` = '1' , `number` = '1' , `date_of_issue` = '2015-06-12' where `id_doc` = '6b5cb828-e89e-11e4-a546-0050563c3a6d' and `id_profile` = '6b4183ee-e89e-11e4-a546-0050563c3a6d' and `id_doc_type` = '1' and `series` is null and `number` is null and `date_of_issue` is null and `date_of_expire` is null and `authority` is null and `subdivision_code` is null and `priority_type` is null and `ldate` is null and `mdate` = '2015-04-22 05:19:43'
Connection ID (thread ID): 3
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=off,table_elimination=on,extended_keys=on,exists_to_in=on

            Gliffy Diagrams

              Attachments

              1. appl_profile_doc.ibd
                144 kB
              2. appl_profile_doc.sql
                5 kB
              3. mariadb.log
                112 kB
              4. mariadb.log
                9 kB
              5. mysqlcheck.log
                11 kB
              6. variables.txt
                339 kB
              7. vmi25208.contabo.net.err
                286 kB

                Activity

                Ascending order - Click to sort in descending order
                7 older comments
                Hide
                Permalink
                elenst Elena Stepanova added a comment -

                Mikhail Gavrilov,

                Did you manage to fix/restore the table? Have you experienced the problem since then?

                Show
                elenst Elena Stepanova added a comment - Mikhail Gavrilov , Did you manage to fix/restore the table? Have you experienced the problem since then?
                Hide
                Permalink
                mikhail Mikhail Gavrilov added a comment -

                Which utility can fix/restore table?

                When I launch first time mysqlcheck -A --auto-repair show warnings:

                taganka-demo.appl_profile_account
Warning  : InnoDB: Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL!
status   : OK
taganka-demo.appl_profile_addr
Warning  : InnoDB: Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL!
status   : OK
taganka-demo.appl_profile_contact
Warning  : InnoDB: Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL!
status   : OK
taganka-demo.appl_profile_doc
Warning  : InnoDB: Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL!
status   : OK

                after second run this messages is gone, but after restart mariadb they returned again

                Show
                mikhail Mikhail Gavrilov added a comment - Which utility can fix/restore table? When I launch first time mysqlcheck -A --auto-repair show warnings: taganka-demo.appl_profile_account Warning : InnoDB: Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! status : OK taganka-demo.appl_profile_addr Warning : InnoDB: Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! status : OK taganka-demo.appl_profile_contact Warning : InnoDB: Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! status : OK taganka-demo.appl_profile_doc Warning : InnoDB: Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! status : OK after second run this messages is gone, but after restart mariadb they returned again
                Hide
                Permalink
                elenst Elena Stepanova added a comment - - edited

                Mikhail Gavrilov,

                As said above, in this case the easiest way to restore the table would be to use the SQL dump that you provided – you can check it in a different schema first, and if it works all right, just drop the corrupted table and use the new one.

                Show
                elenst Elena Stepanova added a comment - - edited Mikhail Gavrilov , As said above, in this case the easiest way to restore the table would be to use the SQL dump that you provided – you can check it in a different schema first, and if it works all right, just drop the corrupted table and use the new one.
                Hide
                Permalink
                mikhail Mikhail Gavrilov added a comment -

                In comment comment-72914 I am said that already doing this. (create and restore from dump, after it problem is gone, means became non reproducible)

                I thought it would be interesting to understand why the server is crashed, because is not really good when all running parallel queries terminated when it occurs. (for experiments I make copy database folder and restore on my home computer for investigation)

                Show
                mikhail Mikhail Gavrilov added a comment - In comment comment-72914 I am said that already doing this. (create and restore from dump, after it problem is gone, means became non reproducible) I thought it would be interesting to understand why the server is crashed, because is not really good when all running parallel queries terminated when it occurs. (for experiments I make copy database folder and restore on my home computer for investigation)
                Hide
                Permalink
                elenst Elena Stepanova added a comment -

                Mikhail Gavrilov,

                In comment comment-72914 I am said that already doing this. (create and restore from dump, after it problem is gone, means became non reproducible)

                Yes, I know. What I meant was, I assume you have been using the restored table for a while now, did you have any problems since then? Did the table become corrupted again, or did you see any error messages in the error log, etc.?

                I thought it would be interesting to understand why the server is crashed, because is not really good when all running parallel queries terminated when it occurs. (for experiments I make copy database folder and restore on my home computer for investigation)

                Yes, indeed, it is very interesting and important, too, but as you correctly pointed out in the comment-72933, it's going to be difficult since we don't know when the problem started and how the table got corrupted.
                Still, even though the table is corrupted, it's no good that the server actually crashes. It could have been acceptable if it gracefully went down, but crashes could cause further corruption. I will try to imitate it by tampering with the data, and if I manage to do it, we'll see if anything can be done about it.

                Show
                elenst Elena Stepanova added a comment - Mikhail Gavrilov , In comment comment-72914 I am said that already doing this. (create and restore from dump, after it problem is gone, means became non reproducible) Yes, I know. What I meant was, I assume you have been using the restored table for a while now, did you have any problems since then? Did the table become corrupted again, or did you see any error messages in the error log, etc.? I thought it would be interesting to understand why the server is crashed, because is not really good when all running parallel queries terminated when it occurs. (for experiments I make copy database folder and restore on my home computer for investigation) Yes, indeed, it is very interesting and important, too, but as you correctly pointed out in the comment-72933 , it's going to be difficult since we don't know when the problem started and how the table got corrupted. Still, even though the table is corrupted, it's no good that the server actually crashes. It could have been acceptable if it gracefully went down, but crashes could cause further corruption. I will try to imitate it by tampering with the data, and if I manage to do it, we'll see if anything can be done about it.

                  People

                  • Assignee:
                    elenst Elena Stepanova
                    Reporter:
                    mikhail Mikhail Gavrilov
                  • Votes:
                    0 Vote for this issue
                    Watchers:
                    4 Start watching this issue

                    Dates

                    • Created:
                      Updated: