On 5.2 (and 5.1) when running the attached test script with a fairly large number of bind variables containing integers, we get a segfault crash. The same query with less bind variables works fine. We have tried stock perl-DBD-MySQL shipped with RHEL5 and also updated to latest CPAN version with no success. We tried both the stock mysql and the upcoming mysql errata packages also. This same query works find in RHEL4 running mysql-5.x from the Application Stacks product (what live Bugzilla is using). [root@rhel52 tmp]# rpm -q perl-DBD-MySQL perl-DBI mysql perl-DBD-MySQL-4.006-1.el5s2 perl-DBI-1.604-1.el5s2 mysql-5.0.45-7.el5 [root@rhel52 tmp]# uname -a Linux rhel52.devel.redhat.com 2.6.18-84.el5xen #1 SMP Fri Feb 29 16:42:34 EST 2008 x86_64 x86_64 x86_64 GNU/Linux [root@rhel52 tmp]# gdb --args /usr/bin/perl /tmp/object.pl 2>&1 | tee gdb-perl.txt output is attached Also attaching test script we use to cause the query to crash. Thanks Dave
Created attachment 303201 [details] Perl backtrace showing segfault in perl-DBD-MySQL
Created attachment 303202 [details] Perl script with SQL to reproduce segfault Attaching script that shows sample SQL that causes the segfault on RHEL5.
This blocks our planned upgrade to Bugzilla 3.2
Changing component to mysql. I was able the mysql srpm from RHEL-4-Stacks-V1 and recompile it on RHEL5. This alleviated the segfault for me. I also had to recompile perl-DBD-mysql against the older mysql. [root@bz-web2-test SPECS]# rpm -q mysql mysql-5.0.44-1.el4s1.1 [root@bz-web2-test SPECS]# rpm -q perl-DBD-mysql perl-DBD-mysql-4.006-1.el5 So somewhere this occured between 5.0.44 and 5.0.45. Let me know any other information I can provide. Dave
Hmm, on my F8 x86_64 machine it dumps core against either 5.0.44 or 5.0.50 (haven't tried 5.0.45). Would you confirm what was the working combination you used before? I'm kinda suspecting an unintentional ABI break (mysql have been guilty of that before). Robin, can you say exactly which mysql RPM version perl-DBD-MySQL-4.006-1.el5s2 was built against?
Okay, I'm bouncing this one back, because it's a bug in DBD-MySQL. The problem occurs in this line of code in selectall_arrayref: ST(0) =dbixst_bounce_method("DBD::mysql::db::SUPER::selectall_arrayref", items); Examining the generated assembly code, the address ST(0) is computed before calling the bounce function. But in the particular case we are looking at here, the function eats all the remaining SV arena space and forces more to be allocated, and *that moves the Perl stack*. So on return we store into what turns out to be the number-of-items count of the just-added arena, and at program exit when that's relied on to determine how far to scan, the scan goes off into never never land. The correct coding must of course be tmpvar = dbixst_bounce_method("DBD::mysql::db::SUPER::selectall_arrayref", items); ST(0) = tmpvar; There seem to be quite a boatload of occurrences of this pattern in mysql.xsi, and I say that every one of them is a crash waiting to happen.
Could you point me in which package and in which version did you find "dbixst_bounce_method"? I wasn't successful in perl-DBD-MySQL.
I haven't finished the previous edit; i apologize for the confusion it has brought. :-( It took me some time, but I found out that mysql.xsi is just a slightly modified copy of .../auto/DBI/Driver.xst, from package perl-DBI. So I'm changing the component of this bug to perl-DBI and creating two clones to record the need to rebuild the perl-DBD-* packages.
This bugzilla has Keywords: Regression. Since no regressions are allowed between releases, it is also being proposed as a blocker for this release. Please resolve ASAP.
Removing these from the Bugzilla 3 upgrade tracker as these are ongoing and will be finished after the upgrade.
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 therefore 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/RHBA-2008-0918.html