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:
Category:MySQL Server Severity:S2 (Serious)
Version:4.0.20 OS:Linux (Suse 9.1 x86_64)
Assigned to: Assigned Account CPU Architecture:Any

[8 Jun 2004 20:03] Johannes Ullrich
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. 
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 
- install mysql 4.0.20 x86_64 rpms 
now either: 
- /etc/init.d/mysql start 
- 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.
[9 Jun 2004 15:27] Johannes Ullrich
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
[11 Jun 2004 21:25] Hartmut Holzgraefe
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.
[23 Jun 2004 20:28] allan bailey
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.
[23 Jun 2004 20:32] allan bailey
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
[2 Jul 2004 3:54] Richard Thomas
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
[6 Jul 2004 12:59] Jaakko Hyvätti
Bug #1853 is I guess the same problem as this one.
[27 Jul 2004 22:52] Lenz Grimmer
This bug has been marked as a duplicate of bug #1853