[MDEV-2180] LP:676945 - Reproducable crash, without backtrace Created: 2010-11-23  Updated: 2012-10-04  Resolved: 2012-10-04

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Andrew (Inactive) Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: Launchpad

Attachments: XML File LPexportBug676945.xml    

 Description   

On all clients with Joomla installed, there is a reproducable bug, even though they work on different databases and have different prefixes for table names. All tables are MyISAM. The problem occured before and after mysql_upgrade was performed. The query and client-side error is:

MySQL server has gone away SQL=SELECT c.*, g.name AS groupname, cc.title AS name, u.name AS editor, f.content_id AS frontpage, s.title AS section_name, v.name AS author FROM dau_content AS c LEFT JOIN dau_categories AS cc ON cc.id = c.catid LEFT JOIN dau_sections AS s ON s.id = c.sectionid LEFT JOIN dau_groups AS g ON g.id = c.access LEFT JOIN dau_users AS u ON u.id = c.checked_out LEFT JOIN dau_users AS v ON v.id = c.created_by LEFT JOIN dau_content_frontpage AS f ON f.content_id = c.id WHERE c.state != -2 ORDER BY section_name , section_name, cc.title, c.ordering LIMIT 0, 100

and MySQL's error log does not print any backtrace:

101118 6:27:25 - 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.
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.

key_buffer_size=2147483648
read_buffer_size=2097152
max_used_connections=8
max_threads=2002
threads_connected=2
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 10318104 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x0
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...
101118 06:27:25 mysqld_safe Number of processes running now: 0
101118 06:27:25 mysqld_safe mysqld restarted
101118 6:27:25 [Warning] The syntax '-log_slow_queries' is deprecated and will be removed in MySQL 7.0. Please use 'slow_query_log'/'-log-slow-file' instead.
............

 Comments   
Comment by Andrew (Inactive) [ 2010-11-18 ]

Re: Reproducable crash, without backtrace
my.cnf:

http://gdr.pastebin.pl/30721

Comment by Andrew (Inactive) [ 2010-11-18 ]

Re: Reproducable crash, without backtrace
Also - this bug started appearing after upgrade to ourdelta. With stock centos mysql it never happened.

Comment by Kristian Nielsen [ 2010-11-21 ]

Re: Reproducable crash, without backtrace
Please specify

  • Exactly which version of Ourdelta is used
  • Exact packages which were installed (url, ...), and how they were installed (yum, rpm -i, etc).
  • Operating system.
Comment by Rasmus Johansson (Inactive) [ 2010-11-22 ]

Re: Reproducable crash, without backtrace

  • Exactly which version of Ourdelta is used

MariaDB-OurDelta-5.1.39

  • Exact packages which were installed (url, ...), and how they were installed (yum, rpm -i, etc).

Using yum, installed packages were:

MariaDB-OurDelta-client-5.1.39-67.el5.x86_64.rpm

MariaDB-OurDelta-server-5.1.39-67.el5.x86_64.rpm

MariaDB-OurDelta-shared-5.1.39-67.el5.x86_64.rpm

I also tried to get a backtrace (no luck) and use gdb (gdb crashed) on a test machine where I additionally installed:

MariaDB-OurDelta-debuginfo-5.1.39-67.el5.x86_64.rpm

  • Operating system.
  1. cat /etc/redhat-release

CentOS release 5. 5 (Final)

After upgrading to 5.2 the problem is gone, but 5.1 is supposed to be stable and 5.2 to be not yet ready...

Comment by Kristian Nielsen [ 2010-11-23 ]

Re: Reproducable crash, without backtrace
Thanks for the additional information!

Actually, MariaDB 5.2.3 is now release as stable. So it should be fine to use.

Of course, it should be fixed in MariaDB 5.1 also. However, 5.1.39 is quite old by now, and it seems likely that if there is a fix for this in 5.2, the fix might also be in the latest 5.1 (5.1.51). So we would need to know if the bug is reproducable in 5.1.51 also or not.

If it is in 5.1.51, we should try to get a backtrace some way, or otherwise get more information to understand what the underlying problem is.

Comment by Rasmus Johansson (Inactive) [ 2010-11-23 ]

Re: Reproducable crash, without backtrace
I'm not going back to 5.1 on a production machine but I may try to install it on the test one.

How do I get 5.1.51? The latest version provided by CentOS repo is 5.1.42:

http://master.ourdelta.org/yum/CentOS-MariaDB51/5Server/x86_64/RPMS/

Comment by Kristian Nielsen [ 2010-11-23 ]

Re: Reproducable crash, without backtrace
Unfortunately, the reporistories are not updated, but you can download the newest .rpms and install manually from here:

http://askmonty.org/wiki/MariaDB:Download

Comment by Rasmus Johansson (Inactive) [ 2010-11-23 ]

Re: Reproducable crash, without backtrace
I have good news - with new MariaDB the query doesn't crash the server. An issue that remains unsolved is the missing backtrace - but it's not very important to me as the database doesn't crash anymore.

Comment by Rasmus Johansson (Inactive) [ 2011-09-05 ]

Launchpad bug id: 676945

Generated at Thu Feb 08 06:40:07 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.