Bug #26774 Crash on ARM platform even after REPAIR TABLE
Submitted: 1 Mar 2007 22:16 Modified: 29 Oct 2007 16:41
Reporter: Christian Hammers (Silver Quality Contributor) (OCA) Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Server Severity:S3 (Non-critical)
Version:5.0.32, 5.0.37 OS:Linux (Debian GNU/Linux etch)
Assigned to: CPU Architecture:ARM
Tags: qc

[1 Mar 2007 22:16] Christian Hammers
Description:
As reported by martin.riondet@freesbee.fr in http://bugs.debian.org/411427

Attached you will find the complete database dump the reported sent me.
I cannot reproduce it on amd64 and asked for a GDB backtrace and if the
precompiled MySQL binaries work for him. But feel free to contact him
via email to <411427@bugs.debian.org>

bye,

-christian-

--------------------------------

Package: mysql-server
Version: 5.0.32-6
Severity: important

architecture : arm
debian-version : sid

Everything worked fine until the last upgrade (today).

The mysqld server crashes when certain queries are performed on the 
database (most queries except very simple queries with few lines/columns).

It seems that the "group by" command generates a crash.
mysql> SELECT * FROM phpwebgallery_categories;
shows 70 lines

mysql> SELECT * FROM phpwebgallery_categories GROUP BY id_uppercat;

ERROR 2013 (HY000): Lost connection to MySQL server during query

phpwebgallery_categories is a table and not a view.

It looks like this bug :
http://bugs.mysql.com/bug.php?id=25172

Patch seems to be included in 5.0.36

I tried to downgrade to 5.0.32-5, but I had the same pb (which is normal 
  if it corresponds to the bug I found on mysql website, as it is 
present from 5.0.30)

I tried to downgrade to  4.1_4.1.11a but I faced too many dependencies pb.

I have only 32Mo of memory, and I tried to adjust parameters to fit with 
that but I still have the pb.
Anyway, I had no problems with my settings with the previous version of 
mysql.

Here is a sample of syslog between the last restart and the crash :
Feb 18 22:57:45 localhost mysqld_safe[27179]: started
Feb 18 22:57:48 localhost mysqld[27182]: 070218 22:57:48  InnoDB: 
Started; log sequence number 0 43675
Feb 18 22:57:49 localhost mysqld[27182]: 070218 22:57:49 [Note] 
/usr/sbin/mysqld: ready for connections.
Feb 18 22:57:49 localhost mysqld[27182]: Version: '5.0.32-Debian_6-log' 
  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Debian etch 
distribution
Feb 18 22:57:53 localhost /etc/mysql/debian-start[27238]: Upgrading 
MySQL tables if necessary.
Feb 18 22:57:56 localhost /etc/mysql/debian-start[27246]: Checking for 
crashed MySQL tables.
Feb 18 22:58:25 localhost mysqld[27182]: mysqld got signal 11;
Feb 18 22:58:25 localhost mysqld[27182]: This could be because you hit a 
bug. It is also possible that this binary
Feb 18 22:58:25 localhost mysqld[27182]: or one of the libraries it was 
linked against is corrupt, improperly built,
Feb 18 22:58:25 localhost mysqld[27182]: or misconfigured. This error 
can also be caused by malfunctioning hardware.
Feb 18 22:58:25 localhost mysqld[27182]: We will try our best to scrape 
up some info that will hopefully help diagnose
Feb 18 22:58:25 localhost mysqld[27182]: the problem, but since we have 
already crashed, something is definitely wrong
Feb 18 22:58:25 localhost mysqld[27182]: and this may fail.
Feb 18 22:58:25 localhost mysqld[27182]:
Feb 18 22:58:25 localhost mysqld[27182]: key_buffer_size=4194304
Feb 18 22:58:25 localhost mysqld[27182]: read_buffer_size=1044480
Feb 18 22:58:25 localhost mysqld[27182]: max_used_connections=2
Feb 18 22:58:25 localhost mysqld[27182]: max_connections=3
Feb 18 22:58:25 localhost mysqld[27182]: threads_connected=1
Feb 18 22:58:25 localhost mysqld[27182]: It is possible that mysqld 
could use up to
Feb 18 22:58:25 localhost mysqld[27182]: key_buffer_size + 
(read_buffer_size + sort_buffer_size)*max_connections = 10227 K
Feb 18 22:58:25 localhost mysqld[27182]: bytes of memory
Feb 18 22:58:25 localhost mysqld[27182]: Hope that's ok; if not, 
decrease some variables in the equation.
Feb 18 22:58:25 localhost mysqld[27182]:
Feb 18 22:58:25 localhost mysqld_safe[27258]: Number of processes 
running now: 0
Feb 18 22:58:25 localhost mysqld_safe[27260]: restarted
Feb 18 22:58:27 localhost mysqld[27263]: 070218 22:58:27  InnoDB: 
Started; log sequence number 0 43675
Feb 18 22:58:27 localhost mysqld[27263]: 070218 22:58:27 [Note] 
Recovering after a crash using /var/log/mysql/mysql-bin
Feb 18 22:58:27 localhost mysqld[27263]: 070218 22:58:27 [Note] Starting 
crash recovery...
Feb 18 22:58:27 localhost mysqld[27263]: 070218 22:58:27 [Note] Crash 
recovery finished.
Feb 18 22:58:27 localhost mysqld[27263]: 070218 22:58:27 [Note] 
/usr/sbin/mysqld: ready for connections.
Feb 18 22:58:27 localhost mysqld[27263]: Version: '5.0.32-Debian_6-log' 
  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Debian etch 
distribution

Regards

Martin Riondet

How to repeat:
-

Suggested fix:
-
[1 Mar 2007 22:18] Christian Hammers
dump of database wpg2

Attachment: wpg2.dmp.bz2 (application/x-bzip, text), 84.28 KiB.

[1 Mar 2007 22:43] [ name withheld ]
for an eaysier test than the database sample that was send, the test describes in this bug works fine (in the way that I can reproduce the crash with it) :
http://bugs.mysql.com/bug.php?id=25172

It could be architecture dependant as I am on a Linksys NSLU2 hardware, using an ARM arcitecture.
[2 Mar 2007 6:54] Valeriy Kravchuk
Thank you for a problem report. As you identified bug #25172 as related, maybe, you should just wait for 5.0.36 sources/Debian build of 5.0.36 to be released officially, and check if that version will solve your problem also?
[3 Mar 2007 0:29] [ name withheld ]
Here is the gdb debugging result :
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 180236 (LWP 5297)]
0x001db2bc in JOIN::exec ()
(gdb) backtrace
#0  0x001db2bc in JOIN::exec ()
#1  0x001dc9a4 in mysql_select ()
#2  0x001dd1c8 in handle_select ()
#3  0x001941fc in mysql_execute_command ()
#4  0x001973e0 in mysql_parse ()
#5  0x001979e8 in dispatch_command ()
#6  0x00198ab8 in do_command ()
#7  0x00199570 in handle_one_connection ()
#8  0x40074fb0 in pthread_start_thread () from /lib/libpthread.so.0
Backtrace stopped: frame did not save the PC

> Oh and try the precompiled binaries you get from dev.mysql.com.
I really haven't seen the arm architecture (or it have an other name there).
It is sometimes called ixp4, but I can't see it either.
[3 Mar 2007 0:32] [ name withheld ]
The corrective patch mentionned in the (what I thought) related bug is supposed to be present in the 5.0.32 version on debian (dixit C. Hammers that is in charge of the mysql package in debian).
[3 Mar 2007 8:03] Valeriy Kravchuk
Martin,

Please, try to build 5.0.36 from sources and check with it. We do not have this platfrom here.
[7 Mar 2007 23:41] [ name withheld ]
Hi,

and where are the 5.0.36 sources?

I only fond the 5.0.33 or the 5.1.16.

Regards

Martin
[8 Mar 2007 9:02] Valeriy Kravchuk
Please, read http://dev.mysql.com/doc/refman/5.0/en/installing-source-tree.html on how to get 5.0.36 sources from development trees or wait for 5.0.35 sources released officially on the same page where we have 5.0.33 now.
[8 Mar 2007 21:29] [ name withheld ]
Awaiting for your answer (very fast as usual), I downloaded and compiled the 5.0.33 version.

As my hardware can be qualified of "tiny", it took 12h00 to obtain the binaries (compiled withe the "--debug" option).

It works fine.

So, regarding how long it takes to compile it, unless you have a strong argument to convince me to compile a newer version, I consider that it's ok for me

Regards

Martin
[9 Mar 2007 6:39] Valeriy Kravchuk
5.0.37 will be officially released (instead of 5.0.35) really soon. But if you do not need any fixes it will contain (please, check the manual), 5.0.33 may just be an answer for you.

I think, this report can be closed.
[25 Apr 2007 19:09] [ name withheld ]
I kept on investigating.

Thanks to my linux mailing list, I ended up by finding that the -02 CFLAGS compilation option causes this crash.

But, I was told that, if there is a crash with the O2 option, it means that there is a piece of code that is poorly written.

So, I am compiling mysql with all compilers warnings and mysql --with-debug="full" option.
I hope it will help correcting the code.

I'll send all logs tomorrow
[29 Apr 2007 20:30] [ name withheld ]
last mysql debugs between the last successfull command and the server crash

Attachment: crash.log (text/x-log), 4.00 KiB.

[29 Apr 2007 20:33] [ name withheld ]
full mysql debugging logs from the lient startup

Attachment: full_crash.log.tar.gz (application/x-gzip, text), 127.99 KiB.

[29 Apr 2007 20:34] [ name withheld ]
Compilation log

Attachment: compile_debug.log.gz (application/x-gzip, text), 137.84 KiB.

[29 Apr 2007 20:43] [ name withheld ]
If additionnal logs are required, please let me know (and tell me how to obtain them)

Regards

Martin Riondet
[29 Apr 2007 21:34] [ name withheld ]
mysqld logs (probably more interesting). Complete log on request.

Attachment: crash_part_mysqld.log.gz (application/x-gzip, text), 17.16 KiB.

[2 May 2007 17:57] Christian Hammers
Hi! I reopen this bug as the original submitter said that the crash does occur even on 5.0.38 when compiled with -O2 (his statement that 5.0.36 was fine most probably was due to a self compile without any -O options).

bye,

-christian-
[29 Sep 2007 16:41] Valeriy Kravchuk
Please, try to repeat with a newer version, 5.0.45, and inform about the results.
[21 Oct 2007 12:47] [ name withheld ]
Thank you.

I works now, using directely the debian package, that is (I guess) compiled with the optimisation options.

Regards

Martin Riondet.
[30 Oct 2007 0:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".