Description of problem: mysql estimates available stack space for a thread as the requested stack size less a constant (16KB in our current builds). However, it turns out that glibc actually allocates the requested stack size less a "guard area" that by default is the same size as a hardware page. The existing constant value implicitly includes enough room for a typical guard area of 4KB. But RHEL5 changes the hardware page size to 64KB on ppc64 (maybe ppc also, I'm not certain). On this platform mysql does not allow enough stack headroom and therefore will crash on overly-complex queries, rather than returning a suitable error message as intended. Version-Release number of selected component (if applicable): mysql-5.0.45-6 How reproducible: 100% Steps to Reproduce: 1. Try to run the package's regression tests Actual results: execution_constants test, which intentionally exercises mysql's stack overflow defenses, reports a crash. Expected results: Tests should all pass. Additional info: This could easily be seen as a security bug, since a malicious query could cause a transient DOS for all users of a mysql database. Since there are lots of possible denials of service available to an attacker with the ability to issue arbitrary SQL, I don't think it's worth treating as a security exercise. But it seems sufficiently important to propose as an exception for RHEL 5.2, especially since we are already turning mysql in 5.2. The correct fix is to account for the guard area while setting the requested stack space. This problem has already been encountered on the Fedora build machines (which run RHEL5 kernels) and the proposed patch has been tested there.
See also bug #435337. However, unless I can convince Jakub that the behavior is a glibc bug, we're going to need to work around it in mysql.
BTW, the reason this problem wasn't seen long ago is that our build machines still run RHEL4, which uses smaller page sizes. The problem became apparent only after the Fedora build machines were updated to RHEL5 kernels. I understand that sometime soon the brew machines will be updated to RHEL5 kernels, which will mean that mysql will fail to be buildable at all unless it gets this patch. Shipping a package that we know we can no longer rebuild from source doesn't seem like a good policy...
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2008-0364.html