php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

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: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: jullrich at sans dot org
New email:
PHP Version: OS:

 

 [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
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Tue Dec 03 17:01:29 2024 UTC