Details
-
Type:
Bug
-
Status: Closed
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: None
-
Labels:
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.
............
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Re: Reproducable crash, without backtrace
Also - this bug started appearing after upgrade to ourdelta. With stock centos mysql it never happened.
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.
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.
- 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...
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.
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/
Re: Reproducable crash, without backtrace
Unfortunately, the reporistories are not updated, but you can download the newest .rpms and install manually from here:
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.
Launchpad bug id: 676945
Re: Reproducable crash, without backtrace
my.cnf:
http://gdr.pastebin.pl/30721