MySQL Bugs: #4062: mysqld crashes on Suse 9.1 x86

Bug #4062	mysqld crashes on Suse 9.1 x86_64
Submitted:	8 Jun 2004 20:03	Modified:	27 Jul 2004 22:52
Reporter:	Johannes Ullrich	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Server	Severity:	S2 (Serious)
Version:	4.0.20	OS:	Linux (Suse 9.1 x86_64)
Assigned to:	Assigned Account	CPU Architecture:	Any

Description:
whenever I start mysqld (either via mysqld_safe, or just directly as the 
'mysql' user), it crashes 
 
error message: 
 
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=8388600 
read_buffer_size=131072 
max_used_connections=0 
max_connections=100 
threads_connected=0 
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 
225791 K 
bytes of memory 
Hope that's ok; if not, decrease some variables in the equation. 
 
 
------------ 
 
System details: dual opteron, 16 GByte RAM. same issue on AMD64-3200 (single 
CPU system) with 1 GByte of RAM.  
 
I did try various my.cnf files (including 'none at all').  
 
The mysql client crashes as well. 
 
 

How to repeat:
- Install Suse 9.1 (without Suse supplied mysql, or remove Suse supplied 
mysql) 
- install mysql 4.0.20 x86_64 rpms 
 
now either: 
- /etc/init.d/mysql start 
 
or  
- su - mysql 
- /usr/sbin/mysqld 
 
mysql will immediatly crash. 
 
 

Suggested fix:
Suse supplied 4.0.18 works ok, but appears to be unstable over time. (the 
reason I did try 4.0.20 was to figure out if it is more stable) 
 
the 'mysqld-max' version appears to start up, but the client will still crash 
(guess no surprise) with a segmentation fault.

well, I rebuild the rpms from src, and the rebuild version works fine so far. 
The rebuild rpms can be found here: http://www.cablemodemhelp.com/mysql 
 
808885e0b6ec3e0849c1c6e4a7513a7b  MySQL-bench-4.0.20-0.x86_64.rpm 
c9be42257a175e5bca83cd345d8a185d  MySQL-client-4.0.20-0.x86_64.rpm 
b49b1ca69c7621e4f59fa6b299ccf8a4  MySQL-devel-4.0.20-0.x86_64.rpm 
34801061718a597ee2fa38b3177067b7  MySQL-embedded-4.0.20-0.x86_64.rpm 
b296e6f1a239bcf381ebb0fe01912421  MySQL-Max-4.0.20-0.x86_64.rpm 
038b07950f0c6403ed634bca8304997b  MySQL-server-4.0.20-0.x86_64.rpm 
51afe08c078734753f3ce19214625267  MySQL-shared-4.0.20-0.x86_64.rpm

We also had other reports of crashes on startup.
It seems like compatibility issues between different x86_64
Linux distributions are the cause for this.

For now we can only recommend to either use plain x86 RPMs
or compiling your own binaries.

We are also having this problem on Fedora core 2, x86_64.

I rebuilt the 4.0.20 version from src.rpm and the problem continues.

It may not be relevant, but this server I'm trying to build is a slave, and
it dies while catching up with the master change logs.

On a related note, using the same boxes and Fedora core 2, x86_64
(amd's opteron), we have seen similar segfaults with sun's java jdk
jdk-1.5.0-beta2

I would like to confirm that the rpms provided by Johannes Ullrich work fine on a fedora core 2 system running on a quad Opteron with 12 gigs memory

Bug #1853 is I guess the same problem as this one.

This bug has been marked as a duplicate of bug #1853