Red Hat Bugzilla – Bug 443495
Perl DBI segfault when issuing query with large number of bind variables
Last modified: 2013-04-12 15:41:06 EDT
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
[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.
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
[root@bz-web2-test SPECS]# rpm -q perl-DBD-mysql
So somewhere this occured between 5.0.44 and 5.0.45.
Let me know any other information I can provide.
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
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.