Bug #52573 [Csd]: SplFileObject::fscanf Segmentation fault
Edit report at http://bugs.php.net/bug.php?id=52573&edit=1 ID: 52573 Updated by: fel...@php.net Reported by:ti dot bugmenot at gmail dot com Summary:SplFileObject::fscanf Segmentation fault Status: Closed Type: Bug Package:SPL related Operating System: FreeBSD PHP Version:PHP 5.3.99-dev (snapshot 201008160630) Assigned To:felipe Block user comment: N New Comment: Thanks for the feedback, I've fixed this issue in SVN. Thanks. Previous Comments: [2010-08-18 03:59:39] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revision&revision=302420 Log: - Improved fix for bug #52573 [2010-08-16 09:04:46] ti dot bugmenot at gmail dot com Fail. CODE: fscanf('fscanf('http://snaps.php.net/php-trunk-201008160630.tar.bz2 [2010-08-11 00:37:31] fel...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2010-08-11 00:37:26] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revision&revision=302085 Log: - Fixed bug #52573 (SplFileObject::fscanf Segmentation fault) [2010-08-10 10:15:00] ti dot bugmenot at gmail dot com Description: Segmentation fault when using additional parameters SplFileObject::fscanf Test script: --- fscanf('fscanf(' Notice: Undefined variable: result in /tmp/fail.php on line 7 Notice: Undefined variable: result in /tmp/fail.php on line 8 TEST 2: Warning: Parameter 3 to fscanf() expected to be a reference, value given in /tmp/fail.php on line 15 Segmentation fault -- Edit this bug report at http://bugs.php.net/bug.php?id=52573&edit=1
Bug #52621 [Opn]: pdo-oci fails to locate 64-bit Oracle installations
Edit report at http://bugs.php.net/bug.php?id=52621&edit=1 ID: 52621 Updated by: ka...@php.net Reported by:jbnance at tresgeek dot net Summary:pdo-oci fails to locate 64-bit Oracle installations Status: Open Type: Bug -Package:Compile Failure +Package:Oracle related Operating System: Linux PHP Version:5.3.3 -Assigned To: +Assigned To:sixd Block user comment: N New Comment: Chris, now there is a patch for it, might be worth reviewing from an Oracle standpoint :) Previous Comments: [2010-08-16 23:19:55] jbnance at tresgeek dot net Notes for end users, in order to use this you have to rebuild configure (buildconf --force after applying the patch). After applying and rebuilding, the following should work: ./configure --with-pdo-oci=instantclient,/usr,10.2.0.4 or ./configure --with-pdo-oci=shared,instantclient,/usr,10.2.0.4 Note that this is different from the non-PDO OCI configure option: --with-oci8=instantclient,/usr/lib/oracle/10.2.0.4/client64/lib or --with-oci8=shared,instantclient,/usr/lib/oracle/10.2.0.4/client64/lib (the version is a parameter in the PDO OCI option). [2010-08-16 23:18:54] jbnance at tresgeek dot net Added patches for 5.2 and 5.3 series. [2010-08-16 23:16:35] jbnance at tresgeek dot net Description: This is the same as bug 44989, but 44989 isn't getting any attention even though I have submitted a fix for the issue, and I'm not the original reporter so I can't update status. Test script: --- Using the Oracle provided 64bit InstantClient RPMs (currently using 11.1.0.1-1): ./configure --with-pdo-oci=instantclient,/usr/include,11.1.0 ... Produces: checking Oracle OCI support for PDO... yes checking Oracle Install-Dir... instantclient,/usr/include,11.1.0 checking if that is sane... yes checking for oci.h... configure: error: I'm too dumb to figure out where the include dir is in your Instant Client install Expected result: Libraries and headers located, compile succeeds. Actual result: -- Configure exits unable to locate libraries or headers. -- Edit this bug report at http://bugs.php.net/bug.php?id=52621&edit=1
Bug #52630 [Asn]: additional syntax for closures
Edit report at http://bugs.php.net/bug.php?id=52630&edit=1 ID: 52630 Updated by: ka...@php.net Reported by:giorgio dot liscio at email dot it Summary:additional syntax for closures Status: Assigned Type: Bug Package:Variables related Operating System: all PHP Version:5.3.3 Assigned To:stas Block user comment: N New Comment: I like the: function($x) use($y) {return $x * $y;}(22); approach, its consistent with that of other languages, like JavaScript Previous Comments: [2010-08-17 22:41:04] giorgio dot liscio at email dot it any alternative syntax can be good if the result is the same, defining end invoking on the same instruction without using any var now: $f = function($x) use($y){return $x * $y;}; $f(22); request: (function($x) use($y) {return $x * $y;})(22); or function($x) use($y) {return $x * $y;}(22); or function($x) use($y) invoke(22) {return $x * $y;}; etc [2010-08-17 22:21:17] ka...@php.net I belive stas' had a patch for this? Or atleast function call chaining, but I assume if implemented it would allow this syntax? [2010-08-17 22:17:26] giorgio dot liscio at email dot it Description: hi, would be nice having this syntax for closures $this->addResult ( ( function ($param) use ($x) { return $x*$param; } )($result) ); a closure defined and executed in the same instruction, as JavaScript allows -- Edit this bug report at http://bugs.php.net/bug.php?id=52630&edit=1
Bug #52630 [Com]: additional syntax for closures
Edit report at http://bugs.php.net/bug.php?id=52630&edit=1 ID: 52630 Comment by: giorgio dot liscio at email dot it Reported by:giorgio dot liscio at email dot it Summary:additional syntax for closures Status: Assigned Type: Bug Package:Variables related Operating System: all PHP Version:5.3.3 Assigned To:stas Block user comment: N New Comment: any alternative syntax can be good if the result is the same, defining end invoking on the same instruction without using any var now: $f = function($x) use($y){return $x * $y;}; $f(22); request: (function($x) use($y) {return $x * $y;})(22); or function($x) use($y) {return $x * $y;}(22); or function($x) use($y) invoke(22) {return $x * $y;}; etc Previous Comments: [2010-08-17 22:21:17] ka...@php.net I belive stas' had a patch for this? Or atleast function call chaining, but I assume if implemented it would allow this syntax? [2010-08-17 22:17:26] giorgio dot liscio at email dot it Description: hi, would be nice having this syntax for closures $this->addResult ( ( function ($param) use ($x) { return $x*$param; } )($result) ); a closure defined and executed in the same instruction, as JavaScript allows -- Edit this bug report at http://bugs.php.net/bug.php?id=52630&edit=1
Bug #52596 [Com]: SOAP result empty NULL lastResponse filled
Edit report at http://bugs.php.net/bug.php?id=52596&edit=1 ID: 52596 Comment by: christian dot gnoth at arcor dot de Reported by:christian dot gnoth at arcor dot de Summary:SOAP result empty NULL lastResponse filled Status: Open Type: Bug Package:SOAP related Operating System: Linux PHP Version:5.2.14 Block user comment: N New Comment: ?? Previous Comments: [2010-08-14 23:43:29] christian dot gnoth at arcor dot de has anyone an idea??? [2010-08-12 22:40:05] christian dot gnoth at arcor dot de Description: I have a script which makes a WSDL SOAP call and the result is empty. No error. The __getLastResponse() is filled. Test script: --- please take a look at: http://files.it-gnoth.de/software/source/php/soap_sample/wsdl-native.php this directory you can browse: http://files.it-gnoth.de/software/source/php/soap_sample with right mouse click it should be possible to download the file. auth token: 49fb1f08bfd34d2b92949af0f9b9bb61 client id: 225 method: get status: active -- Edit this bug report at http://bugs.php.net/bug.php?id=52596&edit=1
Req #52628 [Csd]: substr() returns false for empty string
Edit report at http://bugs.php.net/bug.php?id=52628&edit=1 ID: 52628 Updated by: ka...@php.net Reported by:david at grudl dot com Summary:substr() returns false for empty string Status: Closed Type: Feature/Change Request Package:Strings related PHP Version:Irrelevant Assigned To:kalle -Block user comment: N +Block user comment: Y New Comment: Then check the return value of substr(): if(($string = substr($old_string, 0, 5)) === false) { /* error */ } There is a million ways to over come this problem, simply check the string first before trying to substring it Previous Comments: [2010-08-17 22:22:31] david at grudl dot com Example: I have string $s and want to short it to 5 characters: $res = substr($s, 0, 5); Question: is $res string of boolean? [2010-08-17 22:19:54] ka...@php.net I don't think it makes any sense to pass an empty string directly to substr and make it behave weirdly. Just wrap it inside an if statement to check if the string is empty if you are using userdata. In either case, calling sub string on an empty string would return nothing, simply casting it to a string makes it empty: $string = (string) substr('', 0, 2); [2010-08-17 18:22:33] david at grudl dot com Description: substr() should not return FALSE if is used with empty string. Yes, it is documented behaviour (If $string is less than or equal to $start characters long, FALSE will be returned), but it is not expected behaviour. There is no way to use "smaller $start". Test script: --- substr('x', 0, 2) // returns again 'x' substr('', 0, 2) // returns FALSE but '' is expected -- Edit this bug report at http://bugs.php.net/bug.php?id=52628&edit=1
Req #52628 [Csd]: substr() returns false for empty string
Edit report at http://bugs.php.net/bug.php?id=52628&edit=1 ID: 52628 User updated by:david at grudl dot com Reported by:david at grudl dot com Summary:substr() returns false for empty string Status: Closed Type: Feature/Change Request Package:Strings related PHP Version:Irrelevant Assigned To:kalle Block user comment: N New Comment: Example: I have string $s and want to short it to 5 characters: $res = substr($s, 0, 5); Question: is $res string of boolean? Previous Comments: [2010-08-17 22:19:54] ka...@php.net I don't think it makes any sense to pass an empty string directly to substr and make it behave weirdly. Just wrap it inside an if statement to check if the string is empty if you are using userdata. In either case, calling sub string on an empty string would return nothing, simply casting it to a string makes it empty: $string = (string) substr('', 0, 2); [2010-08-17 18:22:33] david at grudl dot com Description: substr() should not return FALSE if is used with empty string. Yes, it is documented behaviour (If $string is less than or equal to $start characters long, FALSE will be returned), but it is not expected behaviour. There is no way to use "smaller $start". Test script: --- substr('x', 0, 2) // returns again 'x' substr('', 0, 2) // returns FALSE but '' is expected -- Edit this bug report at http://bugs.php.net/bug.php?id=52628&edit=1
Bug #52630 [Opn]: additional syntax for closures
Edit report at http://bugs.php.net/bug.php?id=52630&edit=1 ID: 52630 Updated by: ka...@php.net Reported by:giorgio dot liscio at email dot it Summary:additional syntax for closures Status: Open Type: Bug Package:Variables related Operating System: all PHP Version:5.3.3 -Assigned To: +Assigned To:stas Block user comment: N New Comment: I belive stas' had a patch for this? Or atleast function call chaining, but I assume if implemented it would allow this syntax? Previous Comments: [2010-08-17 22:17:26] giorgio dot liscio at email dot it Description: hi, would be nice having this syntax for closures $this->addResult ( ( function ($param) use ($x) { return $x*$param; } )($result) ); a closure defined and executed in the same instruction, as JavaScript allows -- Edit this bug report at http://bugs.php.net/bug.php?id=52630&edit=1
Req #52628 [Opn->Csd]: substr() returns false for empty string
Edit report at http://bugs.php.net/bug.php?id=52628&edit=1 ID: 52628 Updated by: ka...@php.net Reported by:david at grudl dot com Summary:substr() returns false for empty string -Status: Open +Status: Closed Type: Feature/Change Request Package:Strings related PHP Version:Irrelevant -Assigned To: +Assigned To:kalle Block user comment: N New Comment: I don't think it makes any sense to pass an empty string directly to substr and make it behave weirdly. Just wrap it inside an if statement to check if the string is empty if you are using userdata. In either case, calling sub string on an empty string would return nothing, simply casting it to a string makes it empty: $string = (string) substr('', 0, 2); Previous Comments: [2010-08-17 18:22:33] david at grudl dot com Description: substr() should not return FALSE if is used with empty string. Yes, it is documented behaviour (If $string is less than or equal to $start characters long, FALSE will be returned), but it is not expected behaviour. There is no way to use "smaller $start". Test script: --- substr('x', 0, 2) // returns again 'x' substr('', 0, 2) // returns FALSE but '' is expected -- Edit this bug report at http://bugs.php.net/bug.php?id=52628&edit=1
[PHP-BUG] Bug #52630 [NEW]: additional syntax for closures
From: Operating system: all PHP version: 5.3.3 Package: Variables related Bug Type: Bug Bug description:additional syntax for closures Description: hi, would be nice having this syntax for closures $this->addResult ( ( function ($param) use ($x) { return $x*$param; } )($result) ); a closure defined and executed in the same instruction, as JavaScript allows -- Edit bug report at http://bugs.php.net/bug.php?id=52630&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52630&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52630&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52630&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52630&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52630&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52630&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52630&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52630&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52630&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52630&r=support Expected behavior: http://bugs.php.net/fix.php?id=52630&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52630&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52630&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52630&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52630&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52630&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52630&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52630&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52630&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52630&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52630&r=mysqlcfg
Req #52517 [Csd]: E_COMPILE_WARNING is not
Edit report at http://bugs.php.net/bug.php?id=52517&edit=1 ID: 52517 Updated by: ka...@php.net Reported by:david at grudl dot com Summary:E_COMPILE_WARNING is not Status: Closed Type: Feature/Change Request Package:Compile Warning PHP Version:5.3.3 Assigned To:kalle -Block user comment: N +Block user comment: Y New Comment: There is alot of difference between them. Using your example code the declare statement is hit at compile time, so before the the executor is triggered that hooks into the error handler the warning is already thrown. Same things goes for includes, although they are as you rightly put it, executed at runtime. This is how the Zend Engine is designed and not going to change. Previous Comments: [2010-08-17 21:47:22] david at grudl dot com There is not difference between compile time or execution time. Compilation is invoked by "include" or "require" or "eval" in run time. So statements "require" throw E_COMPILE_WARNING and you cannot handle them using user-defined error handler. [2010-08-17 20:20:11] ka...@php.net Yes it is, as declare is evaluated at compile time, not execution time hence its not possible to catch the warning anyway as its thrown before the executor is hit. [2010-08-17 18:43:36] david at grudl dot com It is not about declare struct, it is about handing warnings & notices by user-handler (and logging them e.g.). I am unable to catch and log this warning. Please re-open this issue. [2010-08-16 21:42:34] ka...@php.net The declare struct have meaning for the script at compile time, not execution time hence its an E_COMPILE_WARNING. [2010-08-02 18:54:03] david at grudl dot com "run-time error" -> "runtime warning" The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52517 -- Edit this bug report at http://bugs.php.net/bug.php?id=52517&edit=1
Req #52517 [Csd]: E_COMPILE_WARNING is not
Edit report at http://bugs.php.net/bug.php?id=52517&edit=1 ID: 52517 User updated by:david at grudl dot com Reported by:david at grudl dot com Summary:E_COMPILE_WARNING is not Status: Closed Type: Feature/Change Request Package:Compile Warning PHP Version:5.3.3 Assigned To:kalle Block user comment: N New Comment: There is not difference between compile time or execution time. Compilation is invoked by "include" or "require" or "eval" in run time. So statements "require" throw E_COMPILE_WARNING and you cannot handle them using user-defined error handler. Previous Comments: [2010-08-17 20:20:11] ka...@php.net Yes it is, as declare is evaluated at compile time, not execution time hence its not possible to catch the warning anyway as its thrown before the executor is hit. [2010-08-17 18:43:36] david at grudl dot com It is not about declare struct, it is about handing warnings & notices by user-handler (and logging them e.g.). I am unable to catch and log this warning. Please re-open this issue. [2010-08-16 21:42:34] ka...@php.net The declare struct have meaning for the script at compile time, not execution time hence its an E_COMPILE_WARNING. [2010-08-02 18:54:03] david at grudl dot com "run-time error" -> "runtime warning" [2010-08-02 18:51:39] david at grudl dot com Description: E_COMPILE_WARNING is the only run-time error not catchable by user-defined error handler function (via set_error_handler). I suggest change this behavior. Test script: --- http://bugs.php.net/bug.php?id=52517&edit=1
Req #49576 [Com]: Filter var for validating email is not validating emails correctly
Edit report at http://bugs.php.net/bug.php?id=49576&edit=1 ID: 49576 Comment by: michael at squiloople dot com Reported by:mparkin at de-facto dot com Summary:Filter var for validating email is not validating emails correctly Status: Feedback Type: Feature/Change Request Package:*General Issues Operating System: * PHP Version:5.* Assigned To:rasmus Block user comment: N New Comment: You might find this useful, taken directly from my article on E-mail address validation, in deciding whether or not to allow single-label domain names: "There is some confusion over whether or not single-label domain names are allowed â mich...@squiloople, for example. People often cite the following section in RFC 5321 to argue that they are not allowed: "'Only resolvable, fully-qualified domain names (FQDNs) are permitted when domain names are used in SMTP. In other words, names that can be resolved to MX RRs or address (i.e., A or ) RRs (as discussed in Section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or address RRs. Local nicknames or unqualified names MUST NOT be used.' "The implicit premise here is that TLD-only domain names cannot be resolved to MX RRs. This is simply untrue: both checkdnsrr('ai', 'MX') and getmxrr('ai', $array) return true, showing that single-label domain names can, and do, resolve to MX RRs. Additionally, http://www.to/ is a valid, and active, domain. Therefore, mich...@squiloople is valid (although in this example, âsquiloopleâ is not a TLD). "And as an extra note, hereâs another excerpt from RFC 5321: "'In the case of a top-level domain used by itself in an email address, a single string is used without any dots.'" Previous Comments: [2010-08-15 02:09:23] paj...@php.net Have you tried with 5.2.14 or 5.3.3? [2010-08-14 21:10:33] grangeway at hotmail dot com Additionally: 1) at the moment, I believe the current regex does not allow f...@com as an email address. Albeit, it's going back almost 10 years now - I'm pretty sure I received an email from someone @tld, complaining that a regex did not allow their valid email address to sign up. 2) The issue the user hit is the phpmailer class contains the following code to validate email addresses against FILTER_VALIDATE_EMAIL regardless of whether SMTP or mail() is the sending method. 550 public static function ValidateAddress($address) { 551if (function_exists('filter_var')) { //Introduced in PHP 5.2 ... else regex [2010-08-14 20:48:24] ka...@php.net Re-opened, the last comment seems quite valid to me, don't you think so Rasmus? [2010-08-05 16:41:58] alexsander dot rosa at gmail dot com The format "usern...@box" for local networks IS allowed when the mail() method is used. I quote RFC 5321: "local aliases MUST NOT appear in any SMTP transaction." They say NOTHING about mail() method in the RFC. [2010-04-02 19:57:45] ras...@php.net A much better RFC-compliant regex has been committed now. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=49576 -- Edit this bug report at http://bugs.php.net/bug.php?id=49576&edit=1
Bug #52070 [Opn->Csd]: imagedashedline() - dashed line sometimes is not visible
Edit report at http://bugs.php.net/bug.php?id=52070&edit=1 ID: 52070 User updated by:tgabor72 at freemail dot hu Reported by:tgabor72 at freemail dot hu Summary:imagedashedline() - dashed line sometimes is not visible -Status: Open +Status: Closed Type: Bug Package:GD related Operating System: WinXP - IIS -fastcgi PHP Version:5.3.2 Block user comment: N New Comment: You can use the imagepatternedline() function with extra features instead of imagedashedline() to give a visible dashedlines and other any kind of patterned lines on your images. The routine also manages the thickness of the line. Have fun! // imagepatternedline() function // Routine was developed to draw any kind of straight line with thickness. Routine uses imageline() function to draw line. // Parameters are (similar to imageline() function): // $image: (resource) imagefile // $xstart, $ystart: (int) x,y coordinates for first point // $xend, $yend: (int) x,y coordinates for last point // $color: (int) color identifier that created with imagecolorallocate() // extra parameters: // $thickness: (int) thickness of line in pixel // $pattern: (string) pattern of line, which repeats continuously while line is being drawed. // If there is '1' in the pattern that means the actual dot of line is visible, // '0' means dot is not visible (space between two line elements). // All characters regard for one pixel. Default: 1 dot wide dashed line with 4-4 dots and spaces. // Examples for pattern: // "1" or "" continuous line // "10" close dotline // "1" dotline // "001100" dotline for design drawing // "11001100110011" double dotline // some examples for using imagepatternedline(): // imagepatternedline($image,300,300,442,442,$color,200,""); // a square with 200 length of edge and rotated 45 degrees // imagepatternedline($image,100,200,289,200,$color,100, // "11001100110011001100111100" // ."00110000110011110011001100" // ."11110011110000" // ."00110011111100110011"); // barcode function imagepatternedline($image, $xstart, $ystart, $xend, $yend, $color, $thickness=1, $pattern="1111") { $pattern=(!strlen($pattern)) ? "1" : $pattern; $x=$xend-$xstart; $y=$yend-$ystart; $length=floor(sqrt(pow(($x),2)+pow(($y),2))); $fullpattern=$pattern; while (strlen($fullpattern)<$length) $fullpattern.=$pattern; if (!$length) { if ($fullpattern[0]) imagefilledellipse($image, $xstart, $ystart, $thickness, $thickness, $color); return; } $x1=$xstart; $y1=$ystart; $x2=$x1; $y2=$y1; $mx=$x/$length; $my=$y/$length; $line=""; for($i=0;$i<$length;$i++){ if (strlen($line)==0 or $fullpattern[$i]==$line[0]) { $line.=$fullpattern[$i]; }else{ $x2+=strlen($line)*$mx; $y2+=strlen($line)*$my; if ($line[0]) imageline($image, round($x1), round($y1), round($x2-$mx), round($y2-$my), $color); $k=1; for($j=0;$j<$thickness-1;$j++) { $k1=-(($k-0.5)*$my)*(floor($j*0.5)+1)*2; $k2= (($k-0.5)*$mx)*(floor($j*0.5)+1)*2; $k=1-$k; if ($line[0]) { imageline($image, round($x1)+$k1, round($y1)+$k2, round($x2-$mx)+$k1, round($y2-$my)+$k2, $color); if ($y) imageline($image, round($x1)+$k1+1, round($y1)+$k2, round($x2-$mx)+$k1+1, round($y2-$my)+$k2, $color); if ($x) imageline($image, round($x1)+$k1, round($y1)+$k2+1, round($x2-$mx)+$k1, round($y2-$my)+$k2+1, $color); } } $x1=$x2; $y1=$y2; $line=$fullpattern[$i]; } } $x2+=strlen($line)*$mx; $y2+=strlen($line)*$my; if ($line[0]) imageline($image, round($x1), round($y1), round($xend), round($yend), $color); $k=1; for($j=0;$j<$thickness-1;$j++) { $k1=-(($k-0.5)*$my)*(floor($j*0.5)+1)*2; $k2= (($k-0.5)*$mx)*(floor($j*0.5)+1)*2; $k=1-$k; if ($line[0]) { imageline($image, round($x1)+$k1, round($y1)+$k2, round($xend)+$k1, round($yend)+$k2, $color); if ($y) imageline($image, round($x1)+$k1+1, round($y1)+$k2, round($xend)+$k1+1, round($yend)+$k2, $color); if ($x) imageline($image, round($x1)+$k1, round($y1)+$k2+1, round($xend)+$k1, round($yend)+$k2+1, $color); } } } Previous Comments: [2010-06-13 00:28:12] tgabor72 at freemail dot hu Description: This bug first was realized by me in php 5.3.1. imagedashedline() function is not work properly. Tipically horizontal and sharp-angled dashed lines is not visible after running this function. Could so
Bug #36561 [Com]: PDO_ODBC/MSSQL does not work with bound params in subquery
Edit report at http://bugs.php.net/bug.php?id=36561&edit=1 ID: 36561 Comment by: kraven at kraven dot org Reported by:travis at raybold dot com Summary:PDO_ODBC/MSSQL does not work with bound params in subquery Status: Bogus Type: Bug Package:PDO related Operating System: Windows XP PHP Version:5.2.4 Assigned To:fmk Block user comment: N New Comment: This is caused by a long standing MS SQL ODBC Client bug. http://connect.microsoft.com/SQLServer/feedback/details/521409/odbc-client-mssql-does-not-work-with-bound-parameters-in-subquery Last update on 8/3/2010 was that it would be resolved in a future release of the SQL Server Native Access Client. Previous Comments: [2009-04-25 14:37:25] j...@php.net Not PHP bug -> bogus. [2008-03-03 20:50:31] auroraeosr...@php.net This appears to be a bug with prepared statements in the underlying microsoft client driver implementation... Even the microsoft SQL Server 2005 Driver for php suffers from this bug so it appears the issue is upstream and we have to wait for microsoft.. [2008-01-06 23:02:41] emil at troxy dot net I was able to reproduce this error using the 2008-01-05 snapshot of PDO_ODBC. Reproduce code: --- setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); $db->exec('CREATE TABLE #foo (id INT NOT NULL)'); $db->exec('INSERT INTO #foo VALUES(1)'); $stmt = $db->prepare('SELECT id FROM #foo WHERE id IN (SELECT id FROM #foo WHERE id = ?)'); $stmt->bindValue(1, 1, PDO::PARAM_INT); $stmt->execute(); var_dump($stmt->fetch(PDO::FETCH_ASSOC)); ?> Expected result: array(1) { ["id"]=> string(1) "1" } Actual result: -- PHP Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[42000]: Syntax error or access violation: 306 [Microsoft][ODBC SQL Server Driver][SQL Server]The text, ntext, and image data types cannot be compared or sorted, except when using IS NULL or LIKE operator. (SQLExecute[306] at ..\pecl_5_2\pdo_odbc\odbc_stmt.c:133)' A trace using the Profiler tool shows that the bound integer value is incorrectly interpreted as text: CREATE TABLE #foo (id INT NOT NULL) go INSERT INTO #foo VALUES(1) go declare @P1 int set @P1=NULL exec sp_prepare @P1 output, N'@P1 text', N'SELECT id FROM #foo WHERE id IN (SELECT id FROM #foo WHERE id = @P1)', 1 select @P1 go Incorrect: N'@P1 text' It should be: N'@P1 int' [2007-08-31 07:35:18] j...@php.net Assigned to the maintainer. [2007-08-31 07:33:12] j...@php.net Very nice that you didn't bother trying with the RCs.. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=36561 -- Edit this bug report at http://bugs.php.net/bug.php?id=36561&edit=1
Bug #44643 [Com]: bound parameters ignore explicit type definitions
Edit report at http://bugs.php.net/bug.php?id=44643&edit=1 ID: 44643 Comment by: kraven at kraven dot org Reported by:ethan dot nelson at ltd dot org Summary:bound parameters ignore explicit type definitions Status: Open Type: Bug Package:PDO related Operating System: * PHP Version:5.2CVS-2009-03-20 Block user comment: N New Comment: This is caused by a long standing MS SQL ODBC Client bug. http://connect.microsoft.com/SQLServer/feedback/details/521409/odbc-client-mssql-does-not-work-with-bound-parameters-in-subquery Last update on 8/3/2010 was that it would be resolved in a future release of the SQL Server Native Access Client. Previous Comments: [2009-05-21 21:49:40] ethan dot nelson at ltd dot org This also happens for the new Native Client 10.0 driver for SQL 2008. SELECT * FROM (SELECT 'test' = :id) a WHERE a.test = :id2 Array ( [0] => 42000 [1] => 402 [2] => [Microsoft][SQL Server Native Client 10.0][SQL Server]The data types text and text are incompatible in the equal to operator. (SQLExecute[402] at ext\pdo_odbc\odbc_stmt.c:133) [3] => 42000 ) PHP Version 5.2.9-2 System Windows NT LTD-PWWW2 5.2 build 3790 Build Date Apr 9 2009 08:22:37 Configure Command cscript /nologo configure.js "--enable-snapshot- build" "--enable-debug-pack" "--with-snapshot-template=d:\php- sdk\snap_5_2\vc6\x86\template" "--with-php-build=d:\php- sdk\snap_5_2\vc6\x86\php_build" "--with-pdo-oci=D:\php- sdk\oracle\instantclient10\sdk,shared" "--with-oci8=D:\php- sdk\oracle\instantclient10\sdk,shared" Server API ISAPI [2009-03-20 17:12:18] phpbugs at matthewboehm dot com RHEL-5.3 php5.2-200903201530 Invalid character value for cast specification: 206 [FreeTDS][SQL Server]Operand type clash: text is incompatible with int (SQLExecute[206] at /usr/src/php5.2- 200903201530/ext/pdo_odbc/odbc_stmt.c:133 [2008-10-28 17:37:00] ethan dot nelson at ltd dot org prepare($query); echo $query."\n"; $id = 1; $stm->bindParam(':id',$id,PDO::PARAM_INT); $id2 = 1; $stm->bindParam(':id2',$id2,PDO::PARAM_INT); echo "\n"; if ($stm->execute()) print_r($stm->fetchAll(PDO::FETCH_ASSOC)); else print_r( $stm->errorInfo()); echo "\n"; phpinfo(); ?> ---The above returns the below result: SELECT * FROM (SELECT 'test' = :id) a WHERE a.test = :id2 Array ( [0] => 42000 [1] => 402 [2] => [Microsoft][SQL Native Client][SQL Server]The data types text and text are incompatible in the equal to operator. (SQLExecute[402] at ext\pdo_odbc\odbc_stmt.c:133) [3] => 42000 ) PHP Version 5.2.7RC2-dev [2008-04-05 00:19:04] ethan dot nelson at ltd dot org Description: There is a type switching problem with bound parameters in PDO when the query contains a WHERE clause: works - "SELECT * FROM (SELECT 'test' = 1) a" works - "SELECT * FROM (SELECT 'test' = 1) a WHERE a.test = 1" fails - "SELECT * FROM (SELECT 'test' = :id) a WHERE a.test = 1" works - "SELECT * FROM (SELECT 'test' = 1) a WHERE a.test = :id" fails - "SELECT * FROM (SELECT 'test' = :id) a WHERE a.test = :id2" Reproduce code: --- $con = new PDO('odbc:Brokerage EPC Database'); $query = "SELECT * FROM (SELECT 'test' = 1) a"; $stm = $con->prepare($query); echo $query."\n"; if ($stm->execute()) echo "Yea!\n"; else echo "Boo!\n"; $query = "SELECT * FROM (SELECT 'test' = 1) a WHERE a.test = 1"; $stm = $con->prepare($query); echo $query."\n"; if ($stm->execute()) echo "Yea!\n"; else echo "Boo!\n"; $query = "SELECT * FROM (SELECT 'test' = :id) a WHERE a.test = 1"; $stm = $con->prepare($query); echo $query."\n"; $id = 1; $stm->bindParam(':id',$id,PDO::PARAM_INT); if ($stm->execute()) echo "Yea!\n"; else echo "Boo!\n"; $query = "SELECT * FROM (SELECT 'test' = 1) a WHERE a.test = :id2"; $stm = $con->prepare($query); echo $query."\n"; $id2 = 1; $stm->bindParam(':id2',$id2,PDO::PARAM_INT); if ($stm->execute()) echo "Yea!\n"; else echo "Boo!\n"; $query = "SELECT * FROM (SELECT 'test' = :id) a WHERE a.test = :id2"; $stm = $con->prepare($query); echo $query."\n"; $id = 1; $stm->bindParam(':id',$id,PDO::PARAM_INT); $id2 = 1; $stm->bindParam(':id2',$id2,PDO::PARAM_INT); if ($stm->execute()) echo "Yea!\n"; else echo "Boo!\n"; Expected result: SELECT * FROM (SELECT 'test' = 1) a Yea! SELECT * FROM (SELECT 'test' = 1) a WHERE a.test = 1 Yea! SELECT * FROM (SELECT 'test' = :id) a WHERE a.test = 1 Yea! SELECT * FROM (SELECT 'test' = 1) a WHERE a.test = :id2 Yea! SELECT * FROM (SELECT 'test' = :id) a WHER
Req #52517 [Csd]: E_COMPILE_WARNING is not
Edit report at http://bugs.php.net/bug.php?id=52517&edit=1 ID: 52517 Updated by: ka...@php.net Reported by:david at grudl dot com Summary:E_COMPILE_WARNING is not Status: Closed Type: Feature/Change Request Package:Compile Warning PHP Version:5.3.3 Assigned To:kalle Block user comment: N New Comment: Yes it is, as declare is evaluated at compile time, not execution time hence its not possible to catch the warning anyway as its thrown before the executor is hit. Previous Comments: [2010-08-17 18:43:36] david at grudl dot com It is not about declare struct, it is about handing warnings & notices by user-handler (and logging them e.g.). I am unable to catch and log this warning. Please re-open this issue. [2010-08-16 21:42:34] ka...@php.net The declare struct have meaning for the script at compile time, not execution time hence its an E_COMPILE_WARNING. [2010-08-02 18:54:03] david at grudl dot com "run-time error" -> "runtime warning" [2010-08-02 18:51:39] david at grudl dot com Description: E_COMPILE_WARNING is the only run-time error not catchable by user-defined error handler function (via set_error_handler). I suggest change this behavior. Test script: --- http://bugs.php.net/bug.php?id=52517&edit=1
Bug #52613 [Asn->Csd]: crash in mysqlnd
Edit report at http://bugs.php.net/bug.php?id=52613&edit=1 ID: 52613 Updated by: and...@php.net Reported by:manuel at mausz dot at Summary:crash in mysqlnd -Status: Assigned +Status: Closed Type: Bug Package:MySQL related Operating System: Unix PHP Version:5.3.3 Assigned To:andrey Block user comment: N Previous Comments: [2010-08-17 20:08:26] and...@php.net alrighty, then I will commit it. If something happens feel free to reopen or create a new report with reference to this one. [2010-08-17 20:08:26] and...@php.net Automatic comment from SVN on behalf of andrey Revision: http://svn.php.net/viewvc/?view=revision&revision=302398 Log: Fix for Bug #52613 crash in mysqlnd [2010-08-17 19:16:17] manuel at mausz dot at Did that already. No memory corruption for now. If it happens again I'll tell you. [2010-08-17 19:04:56] and...@php.net Can you test on the server, which exposed this memory problem? If it is ok, then I will commit the patch to the repository. Thanks! [2010-08-17 18:47:19] manuel at mausz dot at Patch works. No crashes anymore. Although I have to say that I added a check for current_row[col] myself and got some very weird memory corruptions on one webserver (out of ~40) after executing a simple mysql query. Don't know why they occured after adding that check.. Applying your patch to 5.3.3 didn't work, so I added your changes by hand and rediffed: http://pastie.org/private/lu8ajelnwwijjiebzzrrta The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52613 -- Edit this bug report at http://bugs.php.net/bug.php?id=52613&edit=1
Bug #52613 [Asn]: crash in mysqlnd
Edit report at http://bugs.php.net/bug.php?id=52613&edit=1 ID: 52613 Updated by: and...@php.net Reported by:manuel at mausz dot at Summary:crash in mysqlnd Status: Assigned Type: Bug Package:MySQL related Operating System: Unix PHP Version:5.3.3 Assigned To:andrey Block user comment: N New Comment: alrighty, then I will commit it. If something happens feel free to reopen or create a new report with reference to this one. Previous Comments: [2010-08-17 19:16:17] manuel at mausz dot at Did that already. No memory corruption for now. If it happens again I'll tell you. [2010-08-17 19:04:56] and...@php.net Can you test on the server, which exposed this memory problem? If it is ok, then I will commit the patch to the repository. Thanks! [2010-08-17 18:47:19] manuel at mausz dot at Patch works. No crashes anymore. Although I have to say that I added a check for current_row[col] myself and got some very weird memory corruptions on one webserver (out of ~40) after executing a simple mysql query. Don't know why they occured after adding that check.. Applying your patch to 5.3.3 didn't work, so I added your changes by hand and rediffed: http://pastie.org/private/lu8ajelnwwijjiebzzrrta [2010-08-17 18:28:26] and...@php.net This looks strange. ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090== Access not within mapped region at address 0x8 current_row in the calling function is NULL. Dereferencing NULL with index gives use first 0x0, then 0x4 and 0x8 - you are on 32bit system, thus 3 fields, in this case, on 64bit, this should have been the second field. But how is current_row NULL when there is explicit check just before that call. Anyway, could you try this patch (it is against 5.3.4-dev) and tell me whether it works for you. Your sources are a bit different, put it will probably apply without problem, with some notices. http://hristov.com/tmp/52613.patch.txt Thanks! [2010-08-17 18:13:07] manuel at mausz dot at ==22090== Memcheck, a memory error detector ==22090== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==22090== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==22090== Command: /root/php-5.3.3/sapi/cli/php -dmemory_limit=390 crash2.php ==22090== Fatal error: Allowed memory size of 390 bytes exhausted (tried to allocate 20 bytes) in /var/www/test2/crash2.php on line 12 ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==22090== ==22090== ==22090== Process terminating with default action of signal 11 (SIGSEGV) ==22090== Access not within mapped region at address 0x8 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: p
Bug #52613 [Fbk->Asn]: crash in mysqlnd
Edit report at http://bugs.php.net/bug.php?id=52613&edit=1 ID: 52613 User updated by:manuel at mausz dot at Reported by:manuel at mausz dot at Summary:crash in mysqlnd -Status: Feedback +Status: Assigned Type: Bug Package:MySQL related Operating System: Unix PHP Version:5.3.3 Assigned To:andrey Block user comment: N New Comment: Did that already. No memory corruption for now. If it happens again I'll tell you. Previous Comments: [2010-08-17 19:04:56] and...@php.net Can you test on the server, which exposed this memory problem? If it is ok, then I will commit the patch to the repository. Thanks! [2010-08-17 18:47:19] manuel at mausz dot at Patch works. No crashes anymore. Although I have to say that I added a check for current_row[col] myself and got some very weird memory corruptions on one webserver (out of ~40) after executing a simple mysql query. Don't know why they occured after adding that check.. Applying your patch to 5.3.3 didn't work, so I added your changes by hand and rediffed: http://pastie.org/private/lu8ajelnwwijjiebzzrrta [2010-08-17 18:28:26] and...@php.net This looks strange. ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090== Access not within mapped region at address 0x8 current_row in the calling function is NULL. Dereferencing NULL with index gives use first 0x0, then 0x4 and 0x8 - you are on 32bit system, thus 3 fields, in this case, on 64bit, this should have been the second field. But how is current_row NULL when there is explicit check just before that call. Anyway, could you try this patch (it is against 5.3.4-dev) and tell me whether it works for you. Your sources are a bit different, put it will probably apply without problem, with some notices. http://hristov.com/tmp/52613.patch.txt Thanks! [2010-08-17 18:13:07] manuel at mausz dot at ==22090== Memcheck, a memory error detector ==22090== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==22090== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==22090== Command: /root/php-5.3.3/sapi/cli/php -dmemory_limit=390 crash2.php ==22090== Fatal error: Allowed memory size of 390 bytes exhausted (tried to allocate 20 bytes) in /var/www/test2/crash2.php on line 12 ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==22090== ==22090== ==22090== Process terminating with default action of signal 11 (SIGSEGV) ==22090== Access not within mapped region at address 0x8 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== If you believe this happened as a result of a stack ==22090== overflow in your program's main thread (unlikely but ==22090== possible), you can try to increa
Bug #47021 [Com]: SoapClient stumbles over WSDL delivered with "Transfer-Encoding: chunked"
Edit report at http://bugs.php.net/bug.php?id=47021&edit=1 ID: 47021 Comment by: n dot engyozov at taxundo dot com Reported by:daniel dot gorski at develnet dot org Summary:SoapClient stumbles over WSDL delivered with "Transfer-Encoding: chunked" Status: To be documented Type: Bug Package:SOAP related Operating System: Linux PHP Version:5.3CVS-2009-01-06 (CVS) Block user comment: N New Comment: I can confirm the problem is still present in my PHP version 5.3.3 even after recompiling with changes made by Dmitry and with disabled curlwrapper. The problem breaks wsdls from yahoo i google APIs. Previous Comments: [2010-03-03 12:26:58] pcdinh at gmail dot com Have you tried to recompile PHP with --without-curlwrapper? I solved my case. [2009-05-17 05:18:55] shadda at gmail dot com I ran into this bug today myself, and after having compiled the latest snapshot as of 8:00pm CST 2009-05-16 I am still experiencing this error. [2009-04-16 10:56:27] bj...@php.net This was fixed by introducing an 'dechunk' stream filter, see http://news.php.net/php.cvs/57042 [2009-04-16 10:34:48] dmi...@php.net This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2009-01-26 10:54:53] giovanni at giacobbi dot net Please see related discussion: http://marc.info/?t=12329199332&r=1&w=2 See also bug report #43069 which actually caused this bug. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=47021 -- Edit this bug report at http://bugs.php.net/bug.php?id=47021&edit=1
Bug #52613 [Asn->Fbk]: crash in mysqlnd
Edit report at http://bugs.php.net/bug.php?id=52613&edit=1 ID: 52613 Updated by: and...@php.net Reported by:manuel at mausz dot at Summary:crash in mysqlnd -Status: Assigned +Status: Feedback Type: Bug Package:MySQL related Operating System: Unix PHP Version:5.3.3 Assigned To:andrey Block user comment: N Previous Comments: [2010-08-17 19:04:56] and...@php.net Can you test on the server, which exposed this memory problem? If it is ok, then I will commit the patch to the repository. Thanks! [2010-08-17 18:47:19] manuel at mausz dot at Patch works. No crashes anymore. Although I have to say that I added a check for current_row[col] myself and got some very weird memory corruptions on one webserver (out of ~40) after executing a simple mysql query. Don't know why they occured after adding that check.. Applying your patch to 5.3.3 didn't work, so I added your changes by hand and rediffed: http://pastie.org/private/lu8ajelnwwijjiebzzrrta [2010-08-17 18:28:26] and...@php.net This looks strange. ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090== Access not within mapped region at address 0x8 current_row in the calling function is NULL. Dereferencing NULL with index gives use first 0x0, then 0x4 and 0x8 - you are on 32bit system, thus 3 fields, in this case, on 64bit, this should have been the second field. But how is current_row NULL when there is explicit check just before that call. Anyway, could you try this patch (it is against 5.3.4-dev) and tell me whether it works for you. Your sources are a bit different, put it will probably apply without problem, with some notices. http://hristov.com/tmp/52613.patch.txt Thanks! [2010-08-17 18:13:07] manuel at mausz dot at ==22090== Memcheck, a memory error detector ==22090== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==22090== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==22090== Command: /root/php-5.3.3/sapi/cli/php -dmemory_limit=390 crash2.php ==22090== Fatal error: Allowed memory size of 390 bytes exhausted (tried to allocate 20 bytes) in /var/www/test2/crash2.php on line 12 ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==22090== ==22090== ==22090== Process terminating with default action of signal 11 (SIGSEGV) ==22090== Access not within mapped region at address 0x8 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== If you believe this happened as a result of a stack ==22090== overflow in your program's main thread (unlikely but ==22090== possible), you can try to increase the size of the ==22090== main thread stack using the --main-stacksize= flag. ==22090== The main th
Bug #52613 [Asn]: crash in mysqlnd
Edit report at http://bugs.php.net/bug.php?id=52613&edit=1 ID: 52613 Updated by: and...@php.net Reported by:manuel at mausz dot at Summary:crash in mysqlnd Status: Assigned Type: Bug Package:MySQL related Operating System: Unix PHP Version:5.3.3 Assigned To:andrey Block user comment: N New Comment: Can you test on the server, which exposed this memory problem? If it is ok, then I will commit the patch to the repository. Thanks! Previous Comments: [2010-08-17 18:47:19] manuel at mausz dot at Patch works. No crashes anymore. Although I have to say that I added a check for current_row[col] myself and got some very weird memory corruptions on one webserver (out of ~40) after executing a simple mysql query. Don't know why they occured after adding that check.. Applying your patch to 5.3.3 didn't work, so I added your changes by hand and rediffed: http://pastie.org/private/lu8ajelnwwijjiebzzrrta [2010-08-17 18:28:26] and...@php.net This looks strange. ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090== Access not within mapped region at address 0x8 current_row in the calling function is NULL. Dereferencing NULL with index gives use first 0x0, then 0x4 and 0x8 - you are on 32bit system, thus 3 fields, in this case, on 64bit, this should have been the second field. But how is current_row NULL when there is explicit check just before that call. Anyway, could you try this patch (it is against 5.3.4-dev) and tell me whether it works for you. Your sources are a bit different, put it will probably apply without problem, with some notices. http://hristov.com/tmp/52613.patch.txt Thanks! [2010-08-17 18:13:07] manuel at mausz dot at ==22090== Memcheck, a memory error detector ==22090== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==22090== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==22090== Command: /root/php-5.3.3/sapi/cli/php -dmemory_limit=390 crash2.php ==22090== Fatal error: Allowed memory size of 390 bytes exhausted (tried to allocate 20 bytes) in /var/www/test2/crash2.php on line 12 ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==22090== ==22090== ==22090== Process terminating with default action of signal 11 (SIGSEGV) ==22090== Access not within mapped region at address 0x8 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== If you believe this happened as a result of a stack ==22090== overflow in your program's main thread (unlikely but ==22090== possible), you can try to increase the size of the ==22090== main thread stack using the --main-stacksize= flag. ==22090== The main thread stack size used in this run was 8388608. ==22090== ==22090== HEAP SUMMARY: ==22090== in use at exit: 5,336,261 byte
Bug #50830 [Com]: FILTER_VALIDATE_IP incorrectly validates a compressed IPv4-mapped IPv6 address
Edit report at http://bugs.php.net/bug.php?id=50830&edit=1 ID: 50830 Comment by: michael at squiloople dot com Reported by:mikerushton at hotmail dot co dot uk Summary:FILTER_VALIDATE_IP incorrectly validates a compressed IPv4-mapped IPv6 address Status: Open Type: Bug Package:Filter related Operating System: * PHP Version:5.*, 6 Block user comment: N New Comment: It has come to my attention that the regular expression I provided above uses RFC 5321 as the authority on IPv6 address format. This differs from RFC 4291 however, which is the ACTUAL authority on IPv6 address format. The key difference between the two is that 4291 allows a double colon to represent just ONE 16-bit group of zeros whereas 5321 requires that it represent at least TWO groups. As such, I have provided a modified regular expression which conforms with 4291 in this respect (and have also removed the unnecessary capturing groups present in my earlier regex) (?:(?:(?:(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){7})|(?:(?!(?:.*[a-f0- 9](?::|$)){8,})(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,6})?::(?:[a-f0- 9]{1,4}(?::[a-f0-9]{1,4}){0,6})?)))|(?:(?:(?:(?:[a-f0-9]{1,4}(?::[a-f0- 9]{1,4}){5}:)|(?:(?!(?:.*[a-f0-9]:){6,})(?:[a-f0-9]{1,4}(?::[a-f0- 9]{1,4}){0,4})?::(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,4}:)?)))?(?:25[0-5]|2[0- 4][0-9]|1[0-9]{2}|[1-9]?[0-9])(?:\.(?:25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0- 9])){3})) Previous Comments: [2010-02-01 15:34:13] mikerushton at hotmail dot co dot uk An addition: here's my solution (as a regular expression): (?:(?:(?:(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){7})|(?:(?!(?:.*[a-f0-9](? ::|$)){7,})(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,5})?::(?:[a-f0-9]{1,4}(? ::[a-f0-9]{1,4}){0,5})?)))|(?:(?:(?:[a-f0-9]{1,4}(?::[a-f0- 9]{1,4}){5}:)|(?:(?!(?:.*[a-f0-9]:){5,})(?:[a-f0-9]{1,4}(?::[a-f0- 9]{1,4}){0,3})?::(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,3}:)?))?(?:(? :25[0-5])|(?:2[0-4][0-9])|(?:1[0-9]{2})|(?:[1-9]?[0-9]))(?:\.(?:(?:25[0- 5])|(?:2[0-4][0-9])|(?:1[0-9]{2})|(?:[1-9]?[0-9]))){3})) [2010-01-24 15:45:29] mikerushton at hotmail dot co dot uk Description: FILTER_VALIDATE_IP validates the incorrect 0:::255.255.255.255 and does not validate the correct 0::255.255.255.255 According to RFC 5321, the correct syntax is: [IPv6-hex *3(":" IPv6-hex)] "::" [IPv6-hex *3(":" IPv6-hex) ":"] IPv4- address-literal This does not allow for three consecutive colons. Reproduce code: --- // First filter_var(':::255.255.255.255', FILTER_VALIDATE_IP); // Second filter_var('::255.255.255.255', FILTER_VALIDATE_IP); Expected result: // First bool(false) // Second string(21) '::255.255.255.255' Actual result: -- // First string(22) ':::255.255.255.255' // Second bool(false) -- Edit this bug report at http://bugs.php.net/bug.php?id=50830&edit=1
Bug #52613 [Fbk->Asn]: crash in mysqlnd
Edit report at http://bugs.php.net/bug.php?id=52613&edit=1 ID: 52613 User updated by:manuel at mausz dot at Reported by:manuel at mausz dot at Summary:crash in mysqlnd -Status: Feedback +Status: Assigned Type: Bug Package:MySQL related Operating System: Unix PHP Version:5.3.3 Assigned To:andrey Block user comment: N New Comment: Patch works. No crashes anymore. Although I have to say that I added a check for current_row[col] myself and got some very weird memory corruptions on one webserver (out of ~40) after executing a simple mysql query. Don't know why they occured after adding that check.. Applying your patch to 5.3.3 didn't work, so I added your changes by hand and rediffed: http://pastie.org/private/lu8ajelnwwijjiebzzrrta Previous Comments: [2010-08-17 18:28:26] and...@php.net This looks strange. ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090== Access not within mapped region at address 0x8 current_row in the calling function is NULL. Dereferencing NULL with index gives use first 0x0, then 0x4 and 0x8 - you are on 32bit system, thus 3 fields, in this case, on 64bit, this should have been the second field. But how is current_row NULL when there is explicit check just before that call. Anyway, could you try this patch (it is against 5.3.4-dev) and tell me whether it works for you. Your sources are a bit different, put it will probably apply without problem, with some notices. http://hristov.com/tmp/52613.patch.txt Thanks! [2010-08-17 18:13:07] manuel at mausz dot at ==22090== Memcheck, a memory error detector ==22090== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==22090== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==22090== Command: /root/php-5.3.3/sapi/cli/php -dmemory_limit=390 crash2.php ==22090== Fatal error: Allowed memory size of 390 bytes exhausted (tried to allocate 20 bytes) in /var/www/test2/crash2.php on line 12 ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==22090== ==22090== ==22090== Process terminating with default action of signal 11 (SIGSEGV) ==22090== Access not within mapped region at address 0x8 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== If you believe this happened as a result of a stack ==22090== overflow in your program's main thread (unlikely but ==22090== possible), you can try to increase the size of the ==22090== main thread stack using the --main-stacksize= flag. ==22090== The main thread stack size used in this run was 8388608. ==22090== ==22090== HEAP SUMMARY: ==22090== in use at exit: 5,336,261 bytes in 31,521 blocks ==22090== total heap usage: 87,945 allocs, 56,424 frees, 11,136,282 bytes allocated ==22090== ==22090== LEAK SUMMARY: ==22090==definitely lost: 0 bytes in 0 blocks ==22090==indirectly
Req #52517 [Csd]: E_COMPILE_WARNING is not
Edit report at http://bugs.php.net/bug.php?id=52517&edit=1 ID: 52517 User updated by:david at grudl dot com Reported by:david at grudl dot com Summary:E_COMPILE_WARNING is not Status: Closed Type: Feature/Change Request Package:Compile Warning PHP Version:5.3.3 Assigned To:kalle Block user comment: N New Comment: It is not about declare struct, it is about handing warnings & notices by user-handler (and logging them e.g.). I am unable to catch and log this warning. Please re-open this issue. Previous Comments: [2010-08-16 21:42:34] ka...@php.net The declare struct have meaning for the script at compile time, not execution time hence its an E_COMPILE_WARNING. [2010-08-02 18:54:03] david at grudl dot com "run-time error" -> "runtime warning" [2010-08-02 18:51:39] david at grudl dot com Description: E_COMPILE_WARNING is the only run-time error not catchable by user-defined error handler function (via set_error_handler). I suggest change this behavior. Test script: --- http://bugs.php.net/bug.php?id=52517&edit=1
Bug #52627 [Opn->Csd]: Iterators & trigger_error causes crash
Edit report at http://bugs.php.net/bug.php?id=52627&edit=1 ID: 52627 User updated by:david at grudl dot com Reported by:david at grudl dot com Summary:Iterators & trigger_error causes crash -Status: Open +Status: Closed Type: Bug Package:Reproducible crash PHP Version:5.3.3 Block user comment: N New Comment: Closing Previous Comments: [2010-08-17 18:36:21] david at grudl dot com I am sorry, this bug affects only 5.1.3 - 5.3.2 and is fixed in 5.3.3. [2010-08-17 18:16:12] ahar...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. I can't reproduce this on OS X or Linux. Besides needing a backtrace, we'll also need to know what operating system you're running. [2010-08-17 18:11:32] david at grudl dot com Description: Throwing any error in foreach causes PHP to crash since PHP 5.1.3 Test script: --- class MyFilterIterator extends FilterIterator { function accept() { return TRUE; } } $iterator = new RecursiveArrayIterator(array(1)); $iterator = new RecursiveIteratorIterator($iterator); $iterator = new MyFilterIterator($iterator); foreach ($iterator as $component) { trigger_error('User error', E_USER_ERROR); // or trigger fatal error by calling undefined function xyz() } -- Edit this bug report at http://bugs.php.net/bug.php?id=52627&edit=1
Bug #52627 [Fbk->Opn]: Iterators & trigger_error causes crash
Edit report at http://bugs.php.net/bug.php?id=52627&edit=1 ID: 52627 User updated by:david at grudl dot com Reported by:david at grudl dot com Summary:Iterators & trigger_error causes crash -Status: Feedback +Status: Open Type: Bug Package:Reproducible crash PHP Version:5.3.3 Block user comment: N New Comment: I am sorry, this bug affects only 5.1.3 - 5.3.2 and is fixed in 5.3.3. Previous Comments: [2010-08-17 18:16:12] ahar...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. I can't reproduce this on OS X or Linux. Besides needing a backtrace, we'll also need to know what operating system you're running. [2010-08-17 18:11:32] david at grudl dot com Description: Throwing any error in foreach causes PHP to crash since PHP 5.1.3 Test script: --- class MyFilterIterator extends FilterIterator { function accept() { return TRUE; } } $iterator = new RecursiveArrayIterator(array(1)); $iterator = new RecursiveIteratorIterator($iterator); $iterator = new MyFilterIterator($iterator); foreach ($iterator as $component) { trigger_error('User error', E_USER_ERROR); // or trigger fatal error by calling undefined function xyz() } -- Edit this bug report at http://bugs.php.net/bug.php?id=52627&edit=1
Bug #52613 [Asn->Fbk]: crash in mysqlnd
Edit report at http://bugs.php.net/bug.php?id=52613&edit=1 ID: 52613 Updated by: and...@php.net Reported by:manuel at mausz dot at Summary:crash in mysqlnd -Status: Assigned +Status: Feedback Type: Bug Package:MySQL related Operating System: Unix PHP Version:5.3.3 Assigned To:andrey Block user comment: N New Comment: This looks strange. ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090== Access not within mapped region at address 0x8 current_row in the calling function is NULL. Dereferencing NULL with index gives use first 0x0, then 0x4 and 0x8 - you are on 32bit system, thus 3 fields, in this case, on 64bit, this should have been the second field. But how is current_row NULL when there is explicit check just before that call. Anyway, could you try this patch (it is against 5.3.4-dev) and tell me whether it works for you. Your sources are a bit different, put it will probably apply without problem, with some notices. http://hristov.com/tmp/52613.patch.txt Thanks! Previous Comments: [2010-08-17 18:13:07] manuel at mausz dot at ==22090== Memcheck, a memory error detector ==22090== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==22090== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==22090== Command: /root/php-5.3.3/sapi/cli/php -dmemory_limit=390 crash2.php ==22090== Fatal error: Allowed memory size of 390 bytes exhausted (tried to allocate 20 bytes) in /var/www/test2/crash2.php on line 12 ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==22090== ==22090== ==22090== Process terminating with default action of signal 11 (SIGSEGV) ==22090== Access not within mapped region at address 0x8 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== If you believe this happened as a result of a stack ==22090== overflow in your program's main thread (unlikely but ==22090== possible), you can try to increase the size of the ==22090== main thread stack using the --main-stacksize= flag. ==22090== The main thread stack size used in this run was 8388608. ==22090== ==22090== HEAP SUMMARY: ==22090== in use at exit: 5,336,261 bytes in 31,521 blocks ==22090== total heap usage: 87,945 allocs, 56,424 frees, 11,136,282 bytes allocated ==22090== ==22090== LEAK SUMMARY: ==22090==definitely lost: 0 bytes in 0 blocks ==22090==indirectly lost: 0 bytes in 0 blocks ==22090== possibly lost: 363,504 bytes in 3,303 blocks ==22090==still reachable: 4,972,757 bytes in 28,218 blocks ==22090== suppressed: 0 bytes in 0 blocks ==22090== Rerun with --leak-check=full to see details of leaked memory ==22090== ==22090== For counts of detected and suppressed errors, rerun with: -v ==22090== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 7 from 7) Segmentation fault [2010
[PHP-BUG] Req #52628 [NEW]: substr() returns false for empty string
From: Operating system: PHP version: Irrelevant Package: Strings related Bug Type: Feature/Change Request Bug description:substr() returns false for empty string Description: substr() should not return FALSE if is used with empty string. Yes, it is documented behaviour (If $string is less than or equal to $start characters long, FALSE will be returned), but it is not expected behaviour. There is no way to use "smaller $start". Test script: --- substr('x', 0, 2) // returns again 'x' substr('', 0, 2) // returns FALSE but '' is expected -- Edit bug report at http://bugs.php.net/bug.php?id=52628&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52628&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52628&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52628&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52628&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52628&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52628&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52628&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52628&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52628&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52628&r=support Expected behavior: http://bugs.php.net/fix.php?id=52628&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52628&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52628&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52628&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52628&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52628&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52628&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52628&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52628&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52628&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52628&r=mysqlcfg
Bug #52627 [Opn->Fbk]: Iterators & trigger_error causes crash
Edit report at http://bugs.php.net/bug.php?id=52627&edit=1 ID: 52627 Updated by: ahar...@php.net Reported by:david at grudl dot com Summary:Iterators & trigger_error causes crash -Status: Open +Status: Feedback Type: Bug Package:Reproducible crash PHP Version:5.3.3 Block user comment: N New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. I can't reproduce this on OS X or Linux. Besides needing a backtrace, we'll also need to know what operating system you're running. Previous Comments: [2010-08-17 18:11:32] david at grudl dot com Description: Throwing any error in foreach causes PHP to crash since PHP 5.1.3 Test script: --- class MyFilterIterator extends FilterIterator { function accept() { return TRUE; } } $iterator = new RecursiveArrayIterator(array(1)); $iterator = new RecursiveIteratorIterator($iterator); $iterator = new MyFilterIterator($iterator); foreach ($iterator as $component) { trigger_error('User error', E_USER_ERROR); // or trigger fatal error by calling undefined function xyz() } -- Edit this bug report at http://bugs.php.net/bug.php?id=52627&edit=1
Bug #52613 [Fbk->Asn]: crash in mysqlnd
Edit report at http://bugs.php.net/bug.php?id=52613&edit=1 ID: 52613 User updated by:manuel at mausz dot at Reported by:manuel at mausz dot at Summary:crash in mysqlnd -Status: Feedback +Status: Assigned Type: Bug Package:MySQL related Operating System: Unix PHP Version:5.3.3 Assigned To:andrey Block user comment: N New Comment: ==22090== Memcheck, a memory error detector ==22090== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==22090== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==22090== Command: /root/php-5.3.3/sapi/cli/php -dmemory_limit=390 crash2.php ==22090== Fatal error: Allowed memory size of 390 bytes exhausted (tried to allocate 20 bytes) in /var/www/test2/crash2.php on line 12 ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==22090== ==22090== ==22090== Process terminating with default action of signal 11 (SIGSEGV) ==22090== Access not within mapped region at address 0x8 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== If you believe this happened as a result of a stack ==22090== overflow in your program's main thread (unlikely but ==22090== possible), you can try to increase the size of the ==22090== main thread stack using the --main-stacksize= flag. ==22090== The main thread stack size used in this run was 8388608. ==22090== ==22090== HEAP SUMMARY: ==22090== in use at exit: 5,336,261 bytes in 31,521 blocks ==22090== total heap usage: 87,945 allocs, 56,424 frees, 11,136,282 bytes allocated ==22090== ==22090== LEAK SUMMARY: ==22090==definitely lost: 0 bytes in 0 blocks ==22090==indirectly lost: 0 bytes in 0 blocks ==22090== possibly lost: 363,504 bytes in 3,303 blocks ==22090==still reachable: 4,972,757 bytes in 28,218 blocks ==22090== suppressed: 0 bytes in 0 blocks ==22090== Rerun with --leak-check=full to see details of leaked memory ==22090== ==22090== For counts of detected and suppressed errors, rerun with: -v ==22090== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 7 from 7) Segmentation fault Previous Comments: [2010-08-17 17:53:41] and...@php.net If PHP hits the memory limit then mysqlnd loses all control, because Zend takes it. Can you show more information about the crash? Just the bt, without line numbers doesn't help. valgrind output will be even better. [2010-08-15 17:45:22] manuel at mausz dot at Description: mysqlnd trys to free memory which must not be valid (e.g. if memory_limit prevents that) Test script: --- * create a database table with a bunch of string-columns and fill in a lot of data * write a php script which fetches the content of the whole table and stores the content in an array * run the php script in a shell loop which increases the memory limit by a few kB per step. e.g: for i in $(seq 1 100); do let mem=$i*10; echo $mem; .
[PHP-BUG] Bug #52627 [NEW]: Iterators & trigger_error causes crash
From: Operating system: PHP version: 5.3.3 Package: Reproducible crash Bug Type: Bug Bug description:Iterators & trigger_error causes crash Description: Throwing any error in foreach causes PHP to crash since PHP 5.1.3 Test script: --- class MyFilterIterator extends FilterIterator { function accept() { return TRUE; } } $iterator = new RecursiveArrayIterator(array(1)); $iterator = new RecursiveIteratorIterator($iterator); $iterator = new MyFilterIterator($iterator); foreach ($iterator as $component) { trigger_error('User error', E_USER_ERROR); // or trigger fatal error by calling undefined function xyz() } -- Edit bug report at http://bugs.php.net/bug.php?id=52627&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52627&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52627&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52627&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52627&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52627&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52627&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52627&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52627&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52627&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52627&r=support Expected behavior: http://bugs.php.net/fix.php?id=52627&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52627&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52627&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52627&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52627&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52627&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52627&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52627&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52627&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52627&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52627&r=mysqlcfg
[PHP-BUG] Req #52626 [NEW]: New magic method for procedural calls on object.
From: Operating system: * PHP version: Irrelevant Package: Class/Object related Bug Type: Feature/Change Request Bug description:New magic method for procedural calls on object. Description: Classic style: Object style: ksort(); $oa->is_array(); //implemented in ObjArray ?> But what if : (SplTypes project is dead and I need object types.) Now it is not possible to control, what functions are executed on object. If a language function is used on a object, php would Variant 1) try to call object function of the same name, Variant 2) call magic method __callOnObject if exists Both variants can be implemented together. Possible problem in variant 1) Programmer would need to take care, to really implement exact same structure of parameters, with all optional parameters, elze it would throw errors on different arguments. There could by a variant 1a) where, called function doesn't list all arguments, but passes an array of arguments. But that would make object calls too different from procedural. Test script: --- Variant 1) class ObjArray extends ArrayIterator{ public function is_array( $var ){ return is_array( $this->storage ); } public function is_object( $var ){ return is_object( $this->storage ); } } $obj = new ObjArray( Array( 1, 2 ) ); var_dump( is_array( $obj ) ); var_dump( is_object( $obj ) ); Variant 2) class ObjArray extends ArrayIterator{ public function __callOnObject( $calledFunction, $params ){ switch $calledFunction { case "is_array": return $this->is_array( $params[0] ); break; case "is_object": return $this->is_object( $params[0] ); break; default: return $calledFunction( insert_params_irrelevant_how( $params ) ); } } public function is_array( $var ){ return is_array( $this->storage ); } public function is_object( $var ){ return is_object( $this->storage ); } } $obj = new ObjArray( Array( 1, 2 ) ); var_dump( is_array( $obj ) ); var_dump( is_object( $obj ) ); Expected result: Variant 1) //$obj = new ObjArray( Array( 1, 2 ) ); //var_dump( is_array( $obj ) ); //should translate to var_dump( $obj->is_array( $obj ) ); bool(true) //var_dump( is_object( $obj ) ); //should translate to var_dump( $obj->is_object( $obj ) ); bool(false) Variant 2) //$obj = new ObjArray( Array( 1, 2 ) ); //var_dump( is_array( $obj ) ); //should translate to var_dump( $obj->__callOnObject( "is_array", Array( $obj ) ) ); //swith/case finds function is_array and calls $obj->is_array( $obj ); bool(true) //var_dump( is_object( $obj ) ); //should translate to var_dump( $obj->__callOnObject( "is_object", Array( $obj ) ) ); //swith/case finds function is_object and calls $obj->is_object( $obj ); bool(false) Actual result: -- //$obj = new ObjArray( Array( 1, 2 ) ); //var_dump( is_array( $obj ) ); bool(false) //var_dump( is_object( $obj ) ); bool(true) -- Edit bug report at http://bugs.php.net/bug.php?id=52626&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52626&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52626&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52626&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52626&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52626&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52626&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52626&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52626&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52626&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52626&r=support Expected behavior: http://bugs.php.net/fix.php?id=52626&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52626&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52626&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52626&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52626&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52626&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52626&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52626&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52626&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52626&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52626&r=mys
Bug #52613 [Asn->Fbk]: crash in mysqlnd
Edit report at http://bugs.php.net/bug.php?id=52613&edit=1 ID: 52613 Updated by: and...@php.net Reported by:manuel at mausz dot at Summary:crash in mysqlnd -Status: Assigned +Status: Feedback Type: Bug Package:MySQL related Operating System: Unix PHP Version:5.3.3 Assigned To:andrey Block user comment: N New Comment: If PHP hits the memory limit then mysqlnd loses all control, because Zend takes it. Can you show more information about the crash? Just the bt, without line numbers doesn't help. valgrind output will be even better. Previous Comments: [2010-08-15 17:45:22] manuel at mausz dot at Description: mysqlnd trys to free memory which must not be valid (e.g. if memory_limit prevents that) Test script: --- * create a database table with a bunch of string-columns and fill in a lot of data * write a php script which fetches the content of the whole table and stores the content in an array * run the php script in a shell loop which increases the memory limit by a few kB per step. e.g: for i in $(seq 1 100); do let mem=$i*10; echo $mem; ./sapi/cli/php -dmemory_limit=$mem crash.php; done Expected result: no crash Actual result: -- (gdb) bt #0 0x0838b494 in mysqlnd_palloc_zval_ptr_dtor () #1 0x0838bbc2 in php_mysqlnd_res_free_buffered_data_pub () #2 0x0838be4a in php_mysqlnd_res_free_result_buffers_pub () #3 0x0838bf4f in mysqlnd_internal_free_result_contents () #4 0x0838bfa8 in mysqlnd_internal_free_result () #5 0x0838f984 in php_mysqlnd_res_free_result_pub () #6 0x081ef818 in _free_mysql_result () #7 0x08408ecc in list_entry_destructor () #8 0x08406e2f in zend_hash_apply_deleter () #9 0x08406f13 in zend_hash_graceful_reverse_destroy () #10 0x0840902e in zend_destroy_rsrc_list () #11 0x083fa116 in zend_deactivate () #12 0x0839adfb in php_request_shutdown () #13 0x084b6b22 in main () -- Edit this bug report at http://bugs.php.net/bug.php?id=52613&edit=1
Req #50667 [Asn->Csd]: Deprecate mysql_list_databases
Edit report at http://bugs.php.net/bug.php?id=50667&edit=1 ID: 50667 Updated by: and...@php.net Reported by:rtshilston at gmail dot com Summary:Deprecate mysql_list_databases -Status: Assigned +Status: Closed Type: Feature/Change Request Package:*General Issues PHP Version:5.3.1 Assigned To:andrey Block user comment: N New Comment: Deprecated in trunk, if next minor release is 5.4.0, then it will be there. Thanks! Previous Comments: [2010-08-17 15:40:13] and...@php.net I removed aliases in MySQLi. I haven't touched ext/mysql [2010-08-16 23:06:02] ka...@php.net Andrey, didn't you remove those aliases not so long ago, if so could you re-classify this if needed to a documentation issue? [2010-01-05 10:56:43] rtshilston at gmail dot com Description: mysql_list_tables and mysql_list_fields have both been deprecated. For consistency, I think that mysql_list_dbs should be deprecated as it too can be performed with a simple SQL query: "SHOW databases". Reproduce code: --- --- >From manual page: function.mysql-list-dbs --- -- Edit this bug report at http://bugs.php.net/bug.php?id=50667&edit=1
Bug #52617 [Opn->Bgs]: call_user_func_array don't properly get parameters to a method
Edit report at http://bugs.php.net/bug.php?id=52617&edit=1 ID: 52617 Updated by: johan...@php.net Reported by:s dot cimini at email dot it Summary:call_user_func_array don't properly get parameters to a method -Status: Open +Status: Bogus Type: Bug Package:Unknown/Other Function Operating System: Ubuntu Server 10.04 32 bit PHP Version:5.3.3 Block user comment: N New Comment: The behavior of PHP 5.2 was wrong and got fixed. bind_param expects references, so you have to pass an array of referenced variables to the method. If you have full error reporting you should receive an error message about this. Previous Comments: [2010-08-17 03:32:27] fel...@php.net I cannot reproduce any problem using the follow sample code: var_dump(call_user_func_array(array(new simplexmlelement(''), 'xpath'), array('//a'))); [2010-08-16 11:24:18] s dot cimini at email dot it Description: The PHP version is 5.3.2 and not 5.3.3, but 5.3.2 is not present in the combo. When i try do execute a script that with PHP 5.2.9 on a Windows pc works in a Ubuntu server 10.04 with PHP 5.3.2 don't work. It appears that the second part of the function, the part relative to the parameters, don't get the parameters to the method of the first part. Test script: --- $db_user="root"; $db_password="password"; $db_host="localhost"; $mysqli = new mysqli($db_host, $db_user, $db_password, "database"); $query = "select id from table where name like ?"; $types="s"; $values[]="a%"; $stmt = $mysqli->prepare($query); call_user_func_array(array($stmt, "bind_param"), array_merge(array($types),$values)); $stmt->execute(); $stmt->bind_result($id); while($stmt->fetch()){ echo($id.""); } $mysqli->close(); Expected result: A list of ids. Actual result: -- Nothing and the excution don't give any errors -- Edit this bug report at http://bugs.php.net/bug.php?id=52617&edit=1
Req #43948 [Com]: IMAP: Add imap_myrights() function
Edit report at http://bugs.php.net/bug.php?id=43948&edit=1 ID: 43948 Comment by: p at rdus dot de Reported by:diegows at xtech dot com dot ar Summary:IMAP: Add imap_myrights() function Status: Feedback Type: Feature/Change Request Package:IMAP related PHP Version:trunk Assigned To:pajoye Block user comment: N New Comment: We tracked the status of the uw imap c-client annotation patch here: https://issues.kolab.org/merge10 I resubmitted the patch three years ago (http://mailman2.u.washington.edu/pipermail/imap-uw/2007-March/001202.html) and it was stalled as Marc Crispin wanted to wait for the ANNOTATEMORE draft to become a real RFC (http://mailman2.u.washington.edu/pipermail/imap-uw/2007-March/001203.html). While this has happened in the meantime (http://mailman.rfc-editor.org/pipermail/rfc-dist/2009-February/002184.html) c-client development seems to have ceased in the meantime, too. For Kolab I'm pretty certain we will switch to the newer Horde_Imap_Client library. I already prepared it with the necessary extensions (https://issues.kolab.org/msg21509). Horde_Imap_Client seems to run faster than the c-client based code though I have to admit that this is just a result from the simple test script and no solid benchmark. As Hored_Imap_Client is not really released yet and would make a bunch of other updates necessary for the Kolab server we'd be quite happy though if annotation support would already work with the imap_* functions available within PHP. I know the situation concerning c-client is messy. Is there anything we can do in order to get the patch accepted? Previous Comments: [2010-07-30 13:51:37] mkoppa...@php.net Updated the annotations patch to add HAVE_IMAP_ANNOTATIONS [2010-07-30 13:51:12] mkoppa...@php.net The following patch has been added/updated: Patch Name: imap_annotation.patch Revision: 1280490672 URL: http://bugs.php.net/patch-display.php?bug=43948&patch=imap_annotation.patch&revision=1280490672 [2010-07-30 10:28:10] paj...@php.net Right, c-client needs to be patched. It does not sound too good to me but I would like to add some HAVE_ to the c-client patch for cleaner detection. I also dropped a mail to the the uw imap mailing list to ask what's the status of this patch (if has been actually proposed, rejected, etc.). [2010-07-29 20:15:43] mkoppa...@php.net It looks like c-client needs to be patched to support annotations: http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/patches/imap/ Can't find annotation support in upstream c-client 2007e. [2010-07-29 19:32:57] clint at ubuntu dot com Thanks for taking this on pajoye. We are tracking this bug in Ubuntu here: https://bugs.launchpad.net/ubuntu/+source/php5/+bug/610630 As soon as its committed, we'll most likely apply the patches to 5.3.2 or 5.3.3 for release with Maverick 10.10 to make Kolab function properly. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=43948 -- Edit this bug report at http://bugs.php.net/bug.php?id=43948&edit=1
Req #50667 [Asn]: Deprecate mysql_list_databases
Edit report at http://bugs.php.net/bug.php?id=50667&edit=1 ID: 50667 Updated by: and...@php.net Reported by:rtshilston at gmail dot com Summary:Deprecate mysql_list_databases Status: Assigned Type: Feature/Change Request Package:*General Issues PHP Version:5.3.1 Assigned To:andrey Block user comment: N New Comment: I removed aliases in MySQLi. I haven't touched ext/mysql Previous Comments: [2010-08-16 23:06:02] ka...@php.net Andrey, didn't you remove those aliases not so long ago, if so could you re-classify this if needed to a documentation issue? [2010-01-05 10:56:43] rtshilston at gmail dot com Description: mysql_list_tables and mysql_list_fields have both been deprecated. For consistency, I think that mysql_list_dbs should be deprecated as it too can be performed with a simple SQL query: "SHOW databases". Reproduce code: --- --- >From manual page: function.mysql-list-dbs --- -- Edit this bug report at http://bugs.php.net/bug.php?id=50667&edit=1
[PHP-BUG] Bug #52624 [NEW]: tempnam() in SAFE Mode
From: Operating system: RHEL 5 PHP version: 5.2.14 Package: Unknown/Other Function Bug Type: Bug Bug description:tempnam() in SAFE Mode Description: Dear php Team, We are using php 5.2.13 and Safe_mod is ON. we have a problem using tempnam, at first we had tempnam('',tempfile); This did not work - error "can not access /tmp Later I investigated and have written the testscript and have following behavior. Attention script must be owned by non root user the script with 7th line $tmp_name = tempnam ( 'tmp', 'tempname' ); works fine also with safe_mode when i change it to $tmp_name = tempnam ( '/tmp', 'tempname' ); a safe_mode restriction takes effect (the one with compares UID/GID and puts out Warning: tempnam() [function.tempnam]: SAFE MODE Restriction in effect. The script whose uid/gid is 506/506 is not allowed to access /tmp owned by uid/gid 0/0 in /home/httpd/html/default/tempfile.php on line 7 but why does it work without the beginning '/'? Can you clarify this behavior please? and another issuse is that when i try with $tmp_name = tempnam ( '/tmp', 'tempname' ); it does not make a diference putting /tmp to openbasedir or safe_mode_includedir it dies not work. I have also read the changelog and have found that since PHP 5.2.12 some issues with tempname and safe_mode have been fixed - there was a bug that tempnam ignores safe_mode. And this correct because i tested with php 5.2.11 and it worked with /tmp also. Can you tell me ehat exactly is changed saince version 5.2.12? Test script: --- '; for ( $x = 0; $x <= 5; $x++ ) { $tmp_name = tempnam ( 'tmp', 'tempname' ); echo $tmp_name . ''; } $str = 'standing in a tempfile'; $tmp_file = fopen ( $tmp_name, 'w' ); fputs ( $tmp_file, $str ); fclose ( $tmp_file ); $fp = fopen ( $tmp_name, 'r' ); $str = fgets ( $fp, 50 ); fclose ( $fp ); echo $str; ?> Expected result: script above works fine also in safe mode change 7th line from $tmp_name = tempnam ( 'tmp', 'tempname' ); to $tmp_name = tempnam ( '/tmp', 'tempname' ); bringe a safe_mode restriction which is also ok, but why does it work without / and why does it not make a diference putting /tmp to openbasedir or safe_mode_include_dir -- Edit bug report at http://bugs.php.net/bug.php?id=52624&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52624&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52624&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52624&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52624&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52624&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52624&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52624&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52624&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52624&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52624&r=support Expected behavior: http://bugs.php.net/fix.php?id=52624&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52624&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52624&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52624&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52624&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52624&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52624&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52624&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52624&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52624&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52624&r=mysqlcfg
Bug #52284 [Ver->Bgs]: Reproducible crash using curl_multi functions with FTP
Edit report at http://bugs.php.net/bug.php?id=52284&edit=1 ID: 52284 Updated by: il...@php.net Reported by:ahar...@php.net Summary:Reproducible crash using curl_multi functions with FTP -Status: Verified +Status: Bogus Type: Bug Package:cURL related Operating System: Ubuntu 10.04 (and others) PHP Version:5.3SVN-2010-07-08 (SVN) Block user comment: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Not a PHP bug, the issue exists within libcurl. Previous Comments: [2010-07-28 16:22:10] profy dot net at gmail dot com I think recompile will help. But I prefer to use distro's php versions for maintainability. We use several ubuntu versions in production. Anyway, I added workaround in my code to switch into one-thread mode when dealing with FTP urls while bug still exists in packaged php5-curl extension. [2010-07-27 17:18:14] paj...@php.net @srinata I don't think there is a release after 7.21.0. We have to wait for it :) [2010-07-27 16:49:14] srina...@php.net Ok, been debugging this since morning for fun. As Pierre mentioned earlier, this bug turns out to be a libcurl bug and a recent commit within libcurl fixes the underlying multi handler issue. now, ubuntu has not shipped with recent versions of libcurl yet. so, you will need to manually download libcurl from below: and install to say /usr/local http://curl.haxx.se/snapshots/ once this new curl is installed, you will need to recompile php with --with- curl=/usr/local if this satisfies ur concern, then we can close this bug. hope this helps. [2010-07-27 07:48:00] profy dot net at gmail dot com Reproduced every time when call test script. Test script: --- $url) { $curly[$id] = curl_init(); curl_setopt($curly[$id], CURLOPT_URL, $url); curl_setopt($curly[$id], CURLOPT_RETURNTRANSFER, true); // I've add this opt to speed up request, bug appearing with or without this line curl_setopt($curly[$id], CURLOPT_NOBODY, true); curl_multi_add_handle($mh, $curly[$id]); } $running = null; do { $status = curl_multi_exec($mh, $running); usleep(1000); } while($status == CURLM_CALL_MULTI_PERFORM || $running); foreach ($curly as $id => $c) { $result[$id] = curl_multi_getcontent($c); curl_multi_remove_handle($mh, $c); curl_close($c); } curl_multi_close($mh); return $result; } $urls = array( "4358521" => "ftp://ftp.ea.com/pub/ea/patches/nfs-underground/pc/en-uk/NFSU_EUROPE_PATCH_4.exe";, "7458288" => "ftp://ftp.nero.com/software/plugins/WMAPlugin20937.exe";, ); echo ""; print_R(multi_request($urls)); echo ""; [2010-07-27 04:57:11] srina...@php.net able to reproduce this issue. here is the stack trace: (gdb) where #0 0x00520a58 in curl_write_header (data=0x18d3b78 "221 Goodbye.\r\nomplete.\r", size=1, nmemb=14, ctx=0x1876e58) at /home/sriramn/dev/php-src/branches/PHP_5_3/ext/curl/interface.c:1123 #1 0x7f106e187c26 in ?? () from /usr/lib/libcurl.so.4 #2 0x7f106e1885ad in ?? () from /usr/lib/libcurl.so.4 #3 0x7f106e18b2ed in ?? () from /usr/lib/libcurl.so.4 #4 0x7f106e18c64f in ?? () from /usr/lib/libcurl.so.4 #5 0x7f106e18c792 in ?? () from /usr/lib/libcurl.so.4 #6 0x7f106e18e9b2 in ?? () from /usr/lib/libcurl.so.4 #7 0x7f106e1a4813 in curl_multi_cleanup () from /usr/lib/libcurl.so.4 #8 0x00527208 in _php_curl_multi_close (rsrc=0x1871970) at /home/sriramn/dev/php-src/branches/PHP_5_3/ext/curl/multi.c:327 #9 0x007f246e in list_entry_destructor (ptr=0x1871970) at /home/sriramn/dev/php-src/branches/PHP_5_3/Zend/zend_list.c:184 #10 0x007efa3b in zend_hash_del_key_or_index (ht=0xe1eaf0, arKey=0x0, nKeyLength=0, h=4, flag=1) at /home/sriramn/dev/php-src/branches/PHP_5_3/Zend/zend_hash.c:497 #11 0x007f1fa0 in _zend_list_delete (id=4) at /home/sriramn/dev/php
Bug #52397 [Opn->Bgs]: json_encode display_errors dependency
Edit report at http://bugs.php.net/bug.php?id=52397&edit=1 ID: 52397 Updated by: il...@php.net Reported by:david at grudl dot com Summary:json_encode display_errors dependency -Status: Open +Status: Bogus Type: Bug Package:JSON related PHP Version:5.3.3RC3 Block user comment: N New Comment: The return values are the same and so is the operation... Previous Comments: [2010-07-22 01:00:35] david at grudl dot com Description: Invalid UTF-8 string throws E_WARNING depending on the configuration directive display_errors: ini_set('display_errors', 0); json_encode("\xFF"); // PHP Warning: json_encode(): Invalid UTF-8 sequence in argument (in error log) ini_set('display_errors', 1); json_encode("\xFF"); // *nothing* This directive determines whether errors should be printed to the screen as part of the output or if they should be hidden from the user. It should not be used to change json_encode behaviour. The same bug affects htmlentities() and htmlspecialchars() Test script: --- ini_set('display_errors', 0); json_encode("\xFF"); htmlspecialchars("\xFF", ENT_COMPAT, 'utf-8'); htmlentities("\xFF", ENT_COMPAT, 'utf-8'); -- Edit this bug report at http://bugs.php.net/bug.php?id=52397&edit=1
Req #42965 [Asn->Csd]: copy() should support context parameters for URLs
Edit report at http://bugs.php.net/bug.php?id=42965&edit=1 ID: 42965 Updated by: ka...@php.net Reported by:mmatson at apple dot com Summary:copy() should support context parameters for URLs -Status: Assigned +Status: Closed Type: Feature/Change Request Package:*General Issues Operating System: OS X 10.4.10 PHP Version:5.2.4 Assigned To:kalle Block user comment: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Fixed for 5.3.4, see svn logs for more info why it wasn't working in 5.3.0-5.3.3 Previous Comments: [2010-08-16 23:56:37] ka...@php.net Automatic comment from SVN on behalf of kalle Revision: http://svn.php.net/viewvc/?view=revision&revision=302376 Log: Fixed the context parameter on copy() to actually have an effect # After looking at the logs, Jani did a bad merge into 5.3, so that # the context parameter sent to copy() actually isn't used at all. This # relatively simple patch fixes that for trunk. # # See FR #42965 # internals: # This changes the php_copy_*() decls to contain an additional parameter for stream contexts [2007-10-15 02:21:55] mmatson at apple dot com Description: The copy function should accept context parameters since it can accept URL's of the fopen wrapper variety. Specific situation where this is needed is when using ftp:// url's you should be able to specify overwrite context for the destination URL. Reproduce code: --- N/A: feature request for filesystem function Expected result: copy should be able to over write a destination file when using ftp:// url's Actual result: -- Throws error: PHP Warning: copy(ftp://@host.com/testFTP/test): failed to open stream: Remote file already exists and overwrite context option not specified. -- Edit this bug report at http://bugs.php.net/bug.php?id=42965&edit=1
[PHP-BUG] Req #52623 [NEW]: PDO::MYSQL_ATTR_MAX_BUFFER_SIZE not supported in mysqlnd
From: Operating system: any PHP version: 5.3SVN-2010-08-17 (SVN) Package: MySQL related Bug Type: Feature/Change Request Bug description:PDO::MYSQL_ATTR_MAX_BUFFER_SIZE not supported in mysqlnd Description: Seems as if mysqlnd driver doesn't support PDO::MYSQL_ATTR_MAX_BUFFER_SIZE constant. In pdo_mysql.c (from svn http://svn.php.net/repository/php/php- src/branches/PHP_5_3/ext/pdo_mysql/pdo_mysql.c), I can see: #ifndef PDO_USE_MYSQLND REGISTER_PDO_CLASS_CONST_LONG("MYSQL_ATTR_MAX_BUFFER_SIZE", (long)PDO_MYSQL_ATTR_MAX_BUFFER_SIZE); ... #endif So, this constant (and some others) are only defined when mysqlnd isn't the active driver. Test script: --- echo PDO::MYSQL_ATTR_MAX_BUFFER_SIZE; Expected result: Output 1005 Actual result: -- Fatal error: Undefined class constant 'MYSQL_ATTR_MAX_BUFFER_SIZE' in php shell code on line 1 -- Edit bug report at http://bugs.php.net/bug.php?id=52623&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52623&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52623&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52623&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52623&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52623&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52623&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52623&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52623&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52623&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52623&r=support Expected behavior: http://bugs.php.net/fix.php?id=52623&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52623&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52623&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52623&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52623&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52623&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52623&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52623&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52623&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52623&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52623&r=mysqlcfg