PHP :: Bug #42378 :: bind_result memory exhaustion

Bug #42378

bind_result memory exhaustion

Submitted:

2007-08-22 11:33 UTC

Modified:

2008-03-25 19:09 UTC

Votes:	7
Avg. Score:	4.4 ± 0.7
Reproduced:	6 of 7 (85.7%)
Same Version:	2 (33.3%)
Same OS:	3 (50.0%)

From:

jullrich at sans dot org

Assigned:

andrey (profile)

Status:

Wont fix

Package:

MySQLi related

PHP Version:

5.2.3

OS:

Linux (CentOS 4.5)

Private report:

CVE-ID:

None

[2007-08-22 11:33 UTC] jullrich at sans dot org

Description:
------------
The use of the mysql command "format" will lead to memory exhaustion on bind_results. Here sample code that does cause the issue:

$sQuery="select targetport,format(trend,2) from trends where current_targets>10 and trend is not null order by trend desc limit 100";

$oStmt=$oDB->prepare($sQuery);
$oStmt->execute();
$oStmt->store_result();
$oStmt->bind_result($nPort,$nTrend);

This code works fine if $sQuery is replaced with:
$sQuery="select targetport,trend from trends where current_targets>10 and trend is not null order by trend desc limit 100";

removing 'store_result' has no effect. Other changes to the SQL statement have no effect either.

Error message logged:

PHP Fatal error:  Allowed memory size of 83886080 bytes exhausted (tried to allocate 1431655788 bytes) in query.html on line 4


Reproduce code:
---------------
$sQuery="select targetport,format(trend,2) from trends where current_targets>10 and trend is not null order by trend desc limit 100";

$oStmt=$oDB->prepare($sQuery);
$oStmt->execute();
$oStmt->store_result();
$oStmt->bind_result($nPort,$nTrend);

Expected result:
----------------
I expected the query to "happen" and get executed.



Actual result:
--------------
PHP Fatal error:  Allowed memory size of 83886080 bytes exhausted (tried to allocate 1431655788 bytes) in query.html on line 4

(Line number corresponds to the 'bind_result' statement)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

[2007-08-22 11:44 UTC] jullrich at sans dot org

'cast' can be used as a workaround:

works:  cast(format(trend,2) as char(10)))

does not work (same memory error): cast(format(trend,2) as char)

[2007-08-23 10:42 UTC] jani@php.net

Assigned to the Mysqli maintainer.

[2007-09-03 14:52 UTC] uwendel at mysql dot com

Can you add the table definition to the bug report?

[2007-09-03 18:55 UTC] jullrich at sans dot org

as requested, the table definition:

CREATE TABLE `trends` (
  `targetport` int(11) NOT NULL default '0',
  `sources` double(17,4) default NULL,
  `current_sources` double(17,0) default NULL,
  `reports` double(17,4) default NULL,
  `current_reports` double(17,0) default NULL,
  `targets` double(17,4) default NULL,
  `current_targets` double(17,0) default NULL,
  `maxsources` int(11) default NULL,
  `maxtargets` int(11) default NULL,
  `maxreports` int(11) default NULL,
  `trend` float default NULL,
  PRIMARY KEY  (`targetport`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

[2007-09-04 16:50 UTC] uwendel at mysql dot com

Thanks! May I also ask you for the MySQL Server version?

I've written a test which reads 100 rows from a table which has a column that I use FORMAT() on. The test checks all *INT* types, FLOAT and DECIMAL. So far I have not been able to reproduce your problem with PHP 5_2 CVS and PHP 6. 

I'll give it another try with your table definition...

[2007-09-04 18:22 UTC] uwendel at mysql dot com

Bug is verified. I can reproduce it on a box with PHP5.2.4RC1-dev and MySQL 5.1.20-beta.

[2007-09-04 18:53 UTC] jullrich at sans dot org

mysql version: 5.0.26-max-log
mysql is running on a SUSE Enterprise server Version 10 (x86_64).

[2008-03-25 19:09 UTC] andrey@php.net

 Hi,
unfortunately that's a server side problem. I reproduce the problem if there is no store_result() call, so this is a workaround. The server sends wrong metadata which fools mysqli. Another workaround will be using mysqlnd instead of libmysql once 5.3 is released. mysqlnd handles this case well better and shows no problems.
I have opened a bug report at bugs.mysql.com :
(http://bugs.mysql.com/35558)
Bug #35558 Wrong server metadata blows up the client