Bug #5109 Crash with key_buffer_size>4GByte (64 Bit System)

Submitted: 19 Aug 2004 15:49 Modified: 1 Oct 2004 13:47
Reporter: Johannes Ullrich Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server Severity:S2 (Serious)
Version:4.0.20-standard-log OS:Linux (Suse Linux 9.1)
Assigned to: Assigned Account CPU Architecture:Any

[19 Aug 2004 15:49] Johannes Ullrich
Description:
If the key_buffer_size is increased beyond 4 GByte (either on startup, or while 
mysql is running with 'set global'), mysqld will run happily until it actually attempts to 
increase the key_buffer beyond 4 GByte. As soon as the key buffer exceeds 4 GByte, it 
crashes. 
 
If it is 'illegal' to use key buffers that large, I would expect an error message (or that it 
just ignores the larger setting). 
 
This is on a Suse 9.1 system for AMD64, using the x86_64 version of mysql 
(recompiled from src rpms) 
 
Overall, mysql happily uses more then 4 GBytes total. Just not for the key buffer. 

How to repeat:
1. start mysql 
2. set global key_buffer_size=5000000000 
3. issue queries until the key_buffer exceeds 4 GByte 

Suggested fix:
either ignore key_buffer_size settings that exceed 4 GByte, or move to a 64 bit 
implementation.
[20 Aug 2004 16:37] MySQL Verification Team
Can you provide us with an access to your machine.

If you could, we would like to have 6 GB or more available for testing. 

Is that possible.

If yes, send us your e-mail address, so that we can exchange keys privately.
[20 Aug 2004 17:27] Sergei Golubchik
no, we don't really need this, thank you very much.

We have an 8GB box in-house.
[23 Aug 2004 19:49] Matthew Lord
Hi,

Just to verify, what distribution are you using?  I see the version, but what did you download 
from the website (filename)?  I just want to make sure that you are using a 64 bit version of 
MySQL as well.

Best Regards
[23 Aug 2004 20:06] Johannes Ullrich
I am using the 64 bit version of mysql. I downloaded the src rpm from mysql.com 
(4.0.20-0) and rebuild it for the 'x86_64' target. At the time, the binary rpm would 
not run at all (separate bug which I think has been resolved by now)
[23 Aug 2004 21:03] Matthew Lord
Hi,

I was unable to repeat this crash 4.0.20 or 4.1.4, both compiled on an SGI Altix box with IA 64 
processors.  I set the key buffer to 6GB.

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 4.0.20

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> show variables like "key_buffer_size";
+-----------------+------------+
| Variable_name   | Value      |
+-----------------+------------+
| key_buffer_size | 6442450944 |
+-----------------+------------+
1 row in set (0.00 sec)

Please let me know what binary installation you downloaded.

Best Regards
[23 Aug 2004 21:10] Matthew Lord
Hi,

I apologize, you had already mentioned the installation method you used.  I'm sorry you had to 
provide that again.

So you can set the key_buffer to 5GB but you can use more than 4GB?  This may be related to 
this bug:
http://bugs.mysql.com/bug.php?id=3827

When you see the limit reached, see what top reports as the total memory usage for mysqld?

Best Regards
[23 Aug 2004 22:30] Sergei Golubchik
reopened for more testing
[23 Aug 2004 22:45] Matthew Lord
Hi,

We're still looking into this.  We're trying to get an AMD64 machine set up with > 4GB of memory 
to see if it's glibc, something with the thread library or anything else.

We will update this bug ASAP.

Best Regards
[1 Oct 2004 13:47] Dean Ellis
The problem is that you should have been prevented from setting key_buffer_size larger than 4GB (bug 5731 relates to that), which is the maximum value supported currently.  This does result in a crash once actual key buffer usage exceeds the real amount of RAM allocated, however I am going to mark this as a duplicate of 5731, as a fix for that will prevent this crash.

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.060 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.