Description of problem: MySQL privileges adjustments from java fail using the current package. I'm not sure who (Redhat, MySQL, or java) this should go to. The problem only seems to hapen when working with the mysql table. I've used the same code with other Redhat releases with no problems. See the below segfaults from java and mysqld. Once the problem happens, mysql will hang and not let any new user log in. The locked process that is changing the grant tables is not killable. At this poing a "kill -9" is the only way to stop the server. Version-Release number of selected component (if applicable): Linux localhost.localdomain 2.4.21-9.EL #1 Thu Jan 8 16:58:25 EST 2004 x86_64 x86_64 x86_64 GNU/Linux j2sdk-1.4.2_04-fcs mysql-3.23.58-1 mysql-server-3.23.58-1 Connector/J 3.0.11 How reproducible: Try java scripts with lots of permission calls using Connector/J Steps to Reproduce: 1. re-install mysql and create database 2. program a java app to modify and create permissions in the database 3. Actual results: from /var/log/messages Apr 30 21:25:45 localhost kernel: java[8603]: segfault at 0000000000000004 rip 0000000057bf32c0 rsp 0000000069bb86f8 error 4 Apr 30 21:30:12 localhost kernel: mysqld[11197]: segfault at 0000000000000000 rip 0000002a960ba1e1 rsp 00000000400171f0 error 6 Expected results: Additional info: I'm not sure how to debug this. Perhaps you need a better example to reproduce?
Created attachment 99852 [details] java source file for demostrating GRANT privileges bug in Mysql on AMD64 I felt bad about not giving you good reproducibility. Try the attached java file after you have created a new mysql database on AMD64 and set the root mysql user's password as "new". Don't forget to run mysql_install_db You'll need java and the Connector/J binaries (3.0.11) to try it out. Other versions of Connector/J display the same problem. Don't forget to compile the java file :). Run it, and watch it hang up mysql good once it gets to the GRANT USAGE statement. You won't be able to kill the connection it makes and you won't be able to connect to mysql afterwards. I was happily surprised to see that this was all it took to reproduce.
Correction. I just tried it again, and I had to run the Test.class java program twice to get the hang-up. This is very weird!!
Even more information: After killing and restarting mysql (without installing the default database), and running: ======================= use mysql; REPAIR table users; ======================= We get the following in the log: ======================= 040501 12:35:01 Warning: Found 5 of 4 rows when repairing './mysql/user' =======================
(Sorry about slow response to this...) I would say this is definitely a problem to pass to MySQL AB, if you didn't already. I would suggest though that it may be fixed in mysql 4.1, which is what we are currently shipping. Have you tried it with newer mysql releases? How about on non-AMD64 hardware? Can you trigger the failure if you don't use java (perhaps just by typing the same commands into the mysql tool)? Since we aren't supporting Connector/J in RHEL3, it'll be difficult for me to do much with this problem unless it can be reproduced without that.
Sorry, it has been so long that I had forgotten about this! I hope I gave you good reproducibility though. Actually, I need to thank you because this bug forced me to use another operating system. I'm sorry that Redhat couldn't provide immediate support, we needed this for a development system that couldn't be caught up waiting for a year. When I switched to Gentoo, the problem seemed to go completely away. Good luck with the bug, I no longer have the redhat environment to test or report bugs from.
This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you.