Reproducable crash, without backtrace

Bug #676945 reported by Andrew
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MariaDB
Fix Released
Undecided
Unassigned
OurDelta
New
Undecided
Unassigned

Bug 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.
............

Revision history for this message
Andrew (andrew-cloudaccess) wrote :
Revision history for this message
Andrew (andrew-cloudaccess) wrote :

Also - this bug started appearing after upgrade to ourdelta. With stock centos mysql it never happened.

Revision history for this message
Kristian Nielsen (knielsen) wrote :

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.

Revision history for this message
GDR! (gdr.name) wrote :

 - 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...

Revision history for this message
Kristian Nielsen (knielsen) wrote :

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.

Revision history for this message
GDR! (gdr.name) wrote :

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/

Revision history for this message
Kristian Nielsen (knielsen) wrote :

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

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

Revision history for this message
GDR! (gdr.name) wrote :

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.

Changed in maria:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.