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

Crashes on Debian Wheezy After Upgrade to 5.5.35 from Repository

        Details

        • Type: Bug
        • Status: Closed
        • Priority: Major
        • Resolution: Duplicate
        • Affects Version/s: 5.5.35-galera
        • Fix Version/s: None
        • Component/s: None
        • Labels:
        • Environment:
          Debian Wheezy x86_64, VirtualBox VM, Core i5, 2GB allocated RAM

          Description

          After upgrade, I get a stack dump in syslog and a db crash after a query with joins:

          STACK TRACE

          Mar  3 07:58:33 vm-dev mysqld: 140303  7:58:33 [ERROR] mysqld got signal 11 ;
Mar  3 07:58:33 vm-dev mysqld: This could be because you hit a bug. It is also possible that this binary
Mar  3 07:58:33 vm-dev mysqld: or one of the libraries it was linked against is corrupt, improperly built,
Mar  3 07:58:33 vm-dev mysqld: or misconfigured. This error can also be caused by malfunctioning hardware.
Mar  3 07:58:33 vm-dev mysqld: 
Mar  3 07:58:33 vm-dev mysqld: To report this bug, see http://kb.askmonty.org/en/reporting-bugs
Mar  3 07:58:33 vm-dev mysqld: 
Mar  3 07:58:33 vm-dev mysqld: We will try our best to scrape up some info that will hopefully help
Mar  3 07:58:33 vm-dev mysqld: diagnose the problem, but since we have already crashed, 
Mar  3 07:58:33 vm-dev mysqld: something is definitely wrong and this may fail.
Mar  3 07:58:33 vm-dev mysqld: 
Mar  3 07:58:33 vm-dev mysqld: Server version: 5.5.35-MariaDB-1~wheezy-wsrep-log
Mar  3 07:58:33 vm-dev mysqld: key_buffer_size=134217728
Mar  3 07:58:33 vm-dev mysqld: read_buffer_size=2097152
Mar  3 07:58:33 vm-dev mysqld: max_used_connections=1
Mar  3 07:58:33 vm-dev mysqld: max_threads=102
Mar  3 07:58:33 vm-dev mysqld: thread_count=1
Mar  3 07:58:33 vm-dev mysqld: It is possible that mysqld could use up to 
Mar  3 07:58:33 vm-dev mysqld: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 759610 K  bytes of memory
Mar  3 07:58:33 vm-dev mysqld: Hope that's ok; if not, decrease some variables in the equation.
Mar  3 07:58:33 vm-dev mysqld: 
Mar  3 07:58:33 vm-dev mysqld: Thread pointer: 0x0x7f63b4e7c000
Mar  3 07:58:33 vm-dev mysqld: Attempting backtrace. You can use the following information to find out
Mar  3 07:58:33 vm-dev mysqld: where mysqld died. If you see no messages after this, something went
Mar  3 07:58:33 vm-dev mysqld: terribly wrong...
Mar  3 07:58:33 vm-dev mysqld: stack_bottom = 0x7f63b63b4db0 thread_stack 0x48000
Mar  3 07:58:33 vm-dev mysqld: /usr/sbin/mysqld(my_print_stacktrace+0x2b)[0x7f63eb212e8b]
Mar  3 07:58:33 vm-dev mysqld: /usr/sbin/mysqld(handle_fatal_signal+0x422)[0x7f63eae458f2]
Mar  3 07:58:33 vm-dev mysqld: /lib/x86_64-linux-gnu/libpthread.so.0(+0xf030)[0x7f63ea51c030]
Mar  3 07:58:33 vm-dev mysqld: /usr/sbin/mysqld(_ZN10Item_field10fix_fieldsEP3THDPP4Item+0x198)[0x7f63eae657a8]
Mar  3 07:58:33 vm-dev mysqld: /usr/sbin/mysqld(_ZN9Item_func10fix_fieldsEP3THDPP4Item+0x1b0)[0x7f63eae94480]
Mar  3 07:58:33 vm-dev mysqld: /usr/sbin/mysqld(_Z11setup_condsP3THDP10TABLE_LISTR4ListIS1_EPP4Item+0x1e7)[0x7f63eacb7c27]
Mar  3 07:58:33 vm-dev mysqld: /usr/sbin/mysqld(+0x3eb052)[0x7f63ead36052]
Mar  3 07:58:33 vm-dev mysqld: /usr/sbin/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x870)[0x7f63ead41d40]
Mar  3 07:58:33 vm-dev mysqld: /usr/sbin/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x2c3)[0x7f63ead48373]
Mar  3 07:58:33 vm-dev mysqld: /usr/sbin/mysqld(+0x3a4c41)[0x7f63eacefc41]
Mar  3 07:58:33 vm-dev mysqld: /usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x49c4)[0x7f63eacfa6a4]
Mar  3 07:58:33 vm-dev mysqld: /usr/sbin/mysqld(+0x3b1d37)[0x7f63eacfcd37]
Mar  3 07:58:33 vm-dev mysqld: /usr/sbin/mysqld(+0x3b2127)[0x7f63eacfd127]
Mar  3 07:58:33 vm-dev mysqld: /usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1a6a)[0x7f63eacff0aa]
Mar  3 07:58:33 vm-dev mysqld: /usr/sbin/mysqld(_Z10do_commandP3THD+0x146)[0x7f63eacff896]
Mar  3 07:58:33 vm-dev mysqld: /usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x31b)[0x7f63eadb4c9b]
Mar  3 07:58:33 vm-dev mysqld: /usr/sbin/mysqld(handle_one_connection+0x51)[0x7f63eadb4d41]
Mar  3 07:58:33 vm-dev mysqld: /lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50)[0x7f63ea513b50]
Mar  3 07:58:33 vm-dev mysqld: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f63e8e240ed]
Mar  3 07:58:33 vm-dev mysqld: 
Mar  3 07:58:33 vm-dev mysqld: Trying to get some variables.
Mar  3 07:58:33 vm-dev mysqld: Some pointers may be invalid and cause the dump to abort.
Mar  3 07:58:33 vm-dev mysqld: Query (0x7f63b6c5c018): is an invalid pointer
Mar  3 07:58:33 vm-dev mysqld: Connection ID (thread ID): 52
Mar  3 07:58:33 vm-dev mysqld: Status: NOT_KILLED
Mar  3 07:58:33 vm-dev mysqld: 
Mar  3 07:58:33 vm-dev mysqld: 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=off
Mar  3 07:58:33 vm-dev mysqld: 
Mar  3 07:58:33 vm-dev mysqld: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
Mar  3 07:58:33 vm-dev mysqld: information that should help you find out what is causing the crash.

          THE QUERY

          SELECT `t`.`userId` AS `t0_c0`, `t`.`idPerson` AS `t0_c1`, `t`.`password` AS `t0_c2`, `t`.`created` AS `t0_c3`, `t`.`modified` AS `t0_c4`, `t`.`lastLogin` AS `t0_c5`, `t`.`lastreset` AS `t0_c6`, `t`.`logins` AS `t0_c7`, `t`.`edits` AS `t0_c8`, `t`.`resets` AS `t0_c9`, `t`.`bConcise` AS `t0_c10`, `t`.`bDisabled` AS `t0_c11`, `t`.`pwResetToken` AS `t0_c12`, `t`.`szJSONPrefs` AS `t0_c13`, `person`.`idPerson` AS `t1_c0`, `person`.`firstname` AS `t1_c1`, `person`.`lastname` AS `t1_c2`, `person`.`company` AS `t1_c3`, `loginEmail`.`emailId` AS `t2_c0`, `loginEmail`.`idPerson` AS `t2_c1`, `loginEmail`.`emailTypeId` AS `t2_c2`, `loginEmail`.`emailAddress` AS `t2_c3`, `loginEmail`.`isPrimary` AS `t2_c4`, `loginEmail`.`isLogin` AS `t2_c5`, `loginEmail`.`szDescription` AS `t2_c6`, `loginEmail_emailType`.`emailTypeId` AS `t3_c0`, `loginEmail_emailType`.`emailType` AS `t3_c1`, `loginEmail_emailType`.`emailTypeShort` AS `t3_c2`, `adjuster`.`adjusterId` AS `t4_c0`, `adjuster`.`userId` AS `t4_c1`, `adjuster`.`statusTypeId` AS `t4_c2`, `adjuster`.`idTeamLead` AS `t4_c3`, `adjuster`.`NPN` AS `t4_c4`, `adjuster`.`XactNetAddress` AS `t4_c5`, `adjuster`.`XactimateKeycode` AS `t4_c6`, `adjuster`.`dailyResRoster` AS `t4_c7`, `adjuster`.`dailyComRoster` AS `t4_c8`, `adjuster`.`catResRoster` AS `t4_c9`, `adjuster`.`catComRoster` AS `t4_c10`, `adjuster`.`willingToDeploy` AS `t4_c11`, `adjuster`.`unavailableUntil` AS `t4_c12`, `adjuster`.`unavailableNote` AS `t4_c13`, `adjuster`.`nfipCertified` AS `t4_c14`, `adjuster`.`nfipLicenseNo` AS `t4_c15`, `adjuster`.`nfipExpiration` AS `t4_c16`, `adjuster`.`bilingual` AS `t4_c17`, `adjuster`.`languages` AS `t4_c18`, `adjuster`.`bTomb` AS `t4_c19` FROM `user` `t` LEFT OUTER JOIN ( SELECT `userId`  FROM rbac_authassignment  GROUP BY `userId` ) AS `filter_rbac_authassignment` ON (`filter_rbac_authassignment`.`userId` = t.`userId`)  LEFT OUTER JOIN `person` `person` ON (`t`.`idPerson`=`person`.`idPerson`)  LEFT OUTER JOIN `email` `loginEmail` ON (`loginEmail`.`idPerson`=`t`.`idPerson`)  LEFT OUTER JOIN `email_type` `loginEmail_emailType` ON (`loginEmail`.`emailTypeId`=`loginEmail_emailType`.`emailTypeId`)  LEFT OUTER JOIN `adjuster` `adjuster` ON (`adjuster`.`userId`=`t`.`userId`)  WHERE (((adjuster.adjusterId IS NULL OR `filter_rbac_authassignment`.`userId` IS NOT NULL) OR (`adjuster`.`adjusterId` IS NOT NULL AND `adjuster`.`statusTypeId`=3)) AND (bDisabled=0)) AND (loginEmail.islogin=1) ORDER BY person.firstname, person.lastname ASC

            Gliffy Diagrams

              Attachments

                Activity

                Ascending order - Click to sort in descending order
                Hide
                Permalink
                nirbhay_c Nirbhay Choubey added a comment -

                Looks quite similar to : https://mariadb.atlassian.net/browse/MDEV-5617

                Show
                nirbhay_c Nirbhay Choubey added a comment - Looks quite similar to : https://mariadb.atlassian.net/browse/MDEV-5617
                Hide
                Permalink
                nirbhay_c Nirbhay Choubey added a comment -

                Hi Jason,
                I couldn't reproduce it using the specified query over some sample data on 5.5.35-galera.
                However, I believe this failure might not be specific to galera as a similar issue has been
                reported and fixed in 5.5.36. (see https://mariadb.atlassian.net/browse/MDEV-5617).
                Could you to try the query on mariadb-5.5.36 and let me know if that worked?

                Show
                nirbhay_c Nirbhay Choubey added a comment - Hi Jason, I couldn't reproduce it using the specified query over some sample data on 5.5.35-galera. However, I believe this failure might not be specific to galera as a similar issue has been reported and fixed in 5.5.36. (see https://mariadb.atlassian.net/browse/MDEV-5617 ). Could you to try the query on mariadb-5.5.36 and let me know if that worked?
                Hide
                Permalink
                EggplantSystems Jason Stewart added a comment -

                Will do.

                Thanks!

                JS
                On Mar 6, 2014 9:37 PM, "Nirbhay Choubey (JIRA)" <jira@mariadb.atlassian.net>

                Show
                EggplantSystems Jason Stewart added a comment - Will do. Thanks! JS On Mar 6, 2014 9:37 PM, "Nirbhay Choubey (JIRA)" <jira@mariadb.atlassian.net>
                Hide
                Permalink
                nirbhay_c Nirbhay Choubey added a comment -

                Hi Jason,
                Did you get chance to try this? I am closing this issue for now as duplicate of MDEV#5617.

                Show
                nirbhay_c Nirbhay Choubey added a comment - Hi Jason, Did you get chance to try this? I am closing this issue for now as duplicate of MDEV#5617.

                  People

                  • Assignee:
                    nirbhay_c Nirbhay Choubey
                    Reporter:
                    EggplantSystems Jason Stewart
                  • Votes:
                    0 Vote for this issue
                    Watchers:
                    4 Start watching this issue

                    Dates

                    • Created:
                      Updated:
                      Resolved: