#25310 [NoF-Bgs]: HTTP::head() wont work over a proxy
ID: 25310 Updated by: paj...@php.net Reported By: Progman2002 at gmx dot de -Status: No Feedback +Status: Bogus -Bug Type: PEAR related +Bug Type: Unknown/Other Function Operating System: Linux -PHP Version: Irrelevant +PHP Version: 4 Assigned To: pajoye New Comment: pear stuff. Previous Comments: [2005-05-24 01:00:03] pear-dev at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2005-05-16 12:00:49] tony2...@php.net Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2004-05-02 07:14:23] helgi at trance dot is Hmm It's gone again :( [2004-03-07 11:47:59] Progman2002 at gmx dot de sure. http://test.therusher.de/HTTP.diff [2004-03-07 11:22:41] m...@php.net The URL of the patch does not exist anymore. Can you please upload it again? 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/25310 -- Edit this bug report at http://bugs.php.net/?id=25310edit=1
#35980 [NoF-Csd]: touch() works on files but not on directories (on Linux this works perfectly)
ID: 35980 Updated by: paj...@php.net Reported By: pavel dot hlousek at gmail dot com -Status: No Feedback +Status: Closed Bug Type: Filesystem function related Operating System: win32 only PHP Version: 5.2.4 (?) Assigned To: pajoye New Comment: 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. Previous Comments: [2008-08-25 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2008-08-15 19:06:44] j...@php.net PHP 5.3 will have better portable support for quite a few filesystem functions. Please try using this CVS snapshot: Windows (zip): http://snaps.php.net/win32/php5.3-win32-latest.zip Windows (installer): http://snaps.php.net/win32/php5.3-win32-installer-latest.msi [2008-07-13 16:11:30] j...@php.net Nuno, as Sara isn't doing anything anymore, I guess it's up to you now to fix this..? [2007-09-05 13:54:39] j...@php.net Sara, what's the status on this? (version was weird, never saw this before checking what people have now invented as version..) [2006-04-16 03:03:02] poll...@php.net I'll try looking for unencumbered information to develop a fix that avoids GPL licensing complications first. If it's indeed the result of a bug in the microsoft OS implementation there should be sufficient information out there to develop a fix that doesn't involve reusing restrictively licensed code. 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/35980 -- Edit this bug report at http://bugs.php.net/?id=35980edit=1
#47554 [Opn-Bgs]: call_user_func_array returns NULL (instead of FALSE) for invalid callbacks
ID: 47554
Updated by: ka...@php.net
Reported By: jimmy at basicmatrix dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 5.2.9
New Comment:
Calling a function/method with invalid parameter, eg. parameters that
does not pass parameter parsing internally all return NULL. In this case
FALSE is returned if something fails after the parameter parsing have
passed.
Previous Comments:
[2009-03-03 23:47:58] jimmy at basicmatrix dot com
Description:
call_user_func_array() claims it Returns the function result, or FALSE
on error.
My testing shows it returns NULL if the callback function is not a
valid callback.
Reproduce code:
---
?php
function callable()
{ return 'Good.'; }
$return = call_user_func_array('callable',array());
var_dump($return);
$return = call_user_func_array('not_callable',array());
var_dump($return);
?
Expected result:
string(5) Good.
Warning: call_user_func_array() [function.call-user-func-array]: First
argument is expected to be a valid callback, 'not_callable' was given in
___ on line 9
FALSE
Actual result:
--
string(5) Good.
Warning: call_user_func_array() [function.call-user-func-array]: First
argument is expected to be a valid callback, 'not_callable' was given in
___ on line 9
NULL
--
Edit this bug report at http://bugs.php.net/?id=47554edit=1
#40568 [NoF-Csd]: filemtime shifted by one hour on win32
ID: 40568
Updated by: paj...@php.net
Reported By: JPlissonneauDuquene at bellhelicopter dot textr
-Status: No Feedback
+Status: Closed
Bug Type: Filesystem function related
Operating System: win32 only - WinXP
PHP Version: 5.2.1
Assigned To: pajoye
New Comment:
We use the new API now in 5.3+.
Previous Comments:
[2008-12-11 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2008-12-03 13:36:42] paj...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
I changed the underlying code to use the windows native APIs. Please
try it.
[2008-07-02 10:18:50] marcello at vezz dot it
Very easy reproduce code (should try it during daylight saving time):
?php
$fullfilename='test.dll';
$ft=filemtime($fullfilename);
touch($fullfilename.'.md5',$ft);
$nt=filemtime($fullfilename.'.md5');
echo $ft.' : '.$nt;
?
Please get test.dll from http://www.vezz.it/php/test.zip
Original file modification date: 19 feb 2008, 19.08.47
The script output:
1203440927 : 1203437327
The touched file date is one hour back.
19 feb 2008, 18.08.47 instead of 19 feb 2008, 19.08.47
In my opinion, this should really be fixed.
[2008-05-01 00:38:37] louis at steelbytes dot com
I've build a PHP extension to workaround this ...
http://www.steelbytes.com/?mid=46
[2008-03-30 17:15:43] kbrobst at surveyresearchpartners dot com
The same Microsoft feature is found under Windows Server 2003,
64-bit. Though previous test cases are well done, this one may be
helpful as well:
Try this experiment:
$timestamp_str = 2005.02.06 14:45:33;
$timestamp_pieces=split('[. :]',$timestamp_str);
$timestamp=mktime($timestamp_pieces[3], $timestamp_pieces[4],
$timestamp_pieces[5], $timestamp_pieces[1], $timestamp_pieces[2],
$timestamp_pieces[0]);
touch(c:\\timestamp_test.txt,$timestamp);
The file timestamp_test.txt shows up in the operating system as having
a modification date of Sunday, February 06, 2005, 2:45:33 PM - which
is the desired result.
But now look at the results of filemtime (only when in DST - it will
report the correct timestamp during standard time):
$compare_timestamp=filemtime(c:\\timestamp_test.txt);
$compare_timestamp_str = date(Y.m.d H:i:s,$compare_timestamp);
echo $timestamp ($timestamp_str) is the original timestamp.br /\n;
echo $compare_timestamp ($compare_timestamp_str) is the timestamp on
the file.br /\n;
The output looks like this:
1107726333 (2005.02.06 14:45:33) is the original timestamp.
1107722733 (2005.02.06 13:45:33) is the timestamp on the file.
The filemtime function reports a timestamp different from what the OS
reports.
I understand the Microsoft should do it right concept. But this
issue is forcing me to have different PHP code based on the server OS -
something I've not had to do much until 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/40568
--
Edit this bug report at http://bugs.php.net/?id=40568edit=1
#36050 [NoF-Opn]: imagecolorallocatealpha returns false
ID: 36050 Updated by: paj...@php.net Reported By: phpbug at phpandmore dot com -Status: No Feedback +Status: Open Bug Type: GD related Operating System: Windows NT LAPTOP 5.1 build 2600 PHP Version: 5.1.2 Assigned To: pajoye New Comment: 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. Previous Comments: [2006-01-25 01:00:06] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2006-01-17 16:24:28] paj...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Fixed in cvs. You can now use ($trans === FALSE) Note the === usage, zero being a perfectly valid color index, you have to check for both the type and the value (bool and false). [2006-01-17 16:11:38] paj...@php.net Something is wrong, not in GD but in the casting ops. [2006-01-17 15:52:05] sni...@php.net RTFM: $image=imagecreatetruecolor... [2006-01-17 14:44:12] phpbug at phpandmore dot com Description: When I try to allocate a transparent color as the background of an image, eg: the first color allocated, imagecolorallocatealpha returns false. I am using php 5.1.1, and gd bundled 2.0.28 compatable Reproduce code: --- $baseImage = imagecreate($_REQUEST['width'], $_REQUEST['height']); if($trans = imagecolorallocatealpha($baseImage, 255, 255, 255, 63)) echo 'good'; else echo 'bad'; Expected result: good Actual result: -- bad -- Edit this bug report at http://bugs.php.net/?id=36050edit=1
#43547 [NoF-Asn]: imagefilledarc has a defect filling
ID: 43547 Updated by: paj...@php.net Reported By: stas at metalinfo dot ru -Status: No Feedback +Status: Assigned Bug Type: GD related Operating System: WinXP PHP Version: 5.2.5 Assigned To: pajoye Previous Comments: [2008-11-10 01:00:05] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2008-11-02 13:22:20] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2007-12-10 06:40:52] stas at metalinfo dot ru Works fine on my hosting company machine PHP Version 5.2.5 Server API CGI Apache/1.3.37 Linux saturn 2.6.22-NX.13-saturn #2 GD Version bundled (2.0.34 compatible) [2007-12-09 21:12:47] paj...@php.net I can reproduce on all platforms. Which gd library do you use with your extension linux? Bundled or external? If external, which version on which linux? The bug seems to be in the polygon function, the clipping looks like the cause. What you are looking (as a work 'round) may be: imagefilledarc($im,$corRad, 399-$corRad, $corRad*2,$corRad*2, 90, 180, $arcFillColor, IMG_ARC_PIE); As the actual postion of the last line is 399, not 400. But the bug is valid assigned. [2007-12-09 20:44:13] stas at metalinfo dot ru Description: imagefilledarc has a defect filling on Win XP, Works fine on Linux system Reproduce code: --- $im = imagecreatetruecolor (600, 400); $corRad = 60; $rectFillColor = imagecolorallocate ($im, 255, 255, 255); imagefilledrectangle($im, 0, 400-$corRad, $corRad, 600-$corRad, $rectFillColor); $arcFillColor = imagecolorallocate ($im, 0, 0, 0); imagecolortransparent($im, $arcFillColor); imagefilledarc($im,$corRad,400-$corRad,$corRad*2,$corRad*2,90,180,$arcFillColor,IMG_ARC_PIE); header (Content-type: image/jpeg); imagejpeg($im); Expected result: Rounded right bottom corner Actual result: -- Uploaded buggy result image is here http://ww9.ru/foo.jpg Because of invalid fill ther is a black line on the right bottom corner -- Edit this bug report at http://bugs.php.net/?id=43547edit=1
#43641 [NoF-Csd]: ZipArchive::open() fails to open some archives
ID: 43641 Updated by: paj...@php.net Reported By: max630 at gmail dot com -Status: No Feedback +Status: Closed Bug Type: Zip Related Operating System: linux/amd64 PHP Version: 5.2.5 Assigned To: pajoye New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Previous Comments: [2008-06-25 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2008-06-17 18:39:47] paj...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.3-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.3-win32-installer-latest.msi [2007-12-22 17:15:14] paj...@php.net ah? please drop one in pierre dot dev at gmail dot com [2007-12-22 17:09:26] j...@php.net Pierre: I have also sent you several mail without any answer.. [2007-12-20 13:29:49] paj...@php.net To make it slighty clearer, 0.8.1 (and cvs versions) has large support but in a complete unportable way. There is already unportable issues in the libzip code (patches have been sent) about binary streams and tempfiles. For some reasons, they did not have been applied upstream. I have sent some mails recently but did not get yet an answer. I also tried to motivate them to use an issue tracker to ease the developments. 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/43641 -- Edit this bug report at http://bugs.php.net/?id=43641edit=1
#44382 [NoF-Csd]: php_zip: zip CRC failed (corrupt) causes freeze of php!
ID: 44382 Updated by: paj...@php.net Reported By: ecc at camya dot com -Status: No Feedback +Status: Closed Bug Type: Reproducible crash Operating System: Windows PHP Version: 5.2.5 Assigned To: pajoye New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Previous Comments: [2008-03-17 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2008-03-09 17:55:00] paj...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi I can't reproduce your problem with current 5.2-cvs (5.2.6RC). Please try again using a snapshot. [2008-03-09 16:37:30] ecc at camya dot com Description: If i try to unpack an corrupt zip file (crc check failed for an file in the zip) using the php_zip extension, the php process freezes. I have to kill the process. Maybe its possible to throw an exception for this problem. I use php-cli! Reproduce code: --- You can download an corrupt zip file here: http://www.camya.com/dl/zip-crc-corrupt.zip Expected result: The windows php-cli freezes! -- Edit this bug report at http://bugs.php.net/?id=44382edit=1
#44974 [NoF-Csd]: ZipArchive can't open large archives
ID: 44974
Updated by: paj...@php.net
Reported By: florian dot ember at gmail dot com
-Status: No Feedback
+Status: Closed
Bug Type: Zip Related
Operating System: Debian
PHP Version: 5.2.6
Assigned To: pajoye
New Comment:
Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at
http://www.php.net/downloads.php
Previous Comments:
[2008-08-26 01:00:03] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2008-08-18 07:35:43] paj...@php.net
You can try using our pre-built binaries or windows or on any other
linux distributions using our src packages. PHP does not have to be
installed to test a fresh build.
[2008-08-08 00:31:49] florian dot ember at gmail dot com
Sorry, I can't do that. I ran the reproduce code on a shared host and I
don't have a Debian / Linux installation at hand.
[2008-08-07 23:43:08] paj...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.3-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.3-win32-installer-latest.msi
[2008-07-29 11:07:39] vadim at vadiaz dot com
This looks like exactly the same bug as
http://bugs.php.net/bug.php?id=44055 - zip archive with more than 1000
entries in root or archive produce an error on 64bit Linux systems
I fixed it and rebuild php from source for my servers
the patch is:
--- php-5.2.6.orig/ext/zip/lib/zip_open.c 2008-01-14 05:19:41.0
+0200
+++ php-5.2.6/ext/zip/lib/zip_open.c2008-07-29 14:04:36.0
+0300
@@ -313,7 +313,7 @@
/* go to start of cdir and read it entry by entry */
bufp = NULL;
clearerr(fp);
- fseek(fp, -(cd-size+cd-comment_len+EOCDLEN), SEEK_END);
+ fseek(fp, -((long)(cd-size+cd-comment_len+EOCDLEN)), SEEK_END);
if (ferror(fp) || ((unsigned int)ftell(fp) != cd-offset)) {
/* seek error or offset of cdir wrong */
if (ferror(fp))
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/44974
--
Edit this bug report at http://bugs.php.net/?id=44974edit=1
#47314 [NoF-Opn]: SoapClient leave tcp connections in time_wait
ID: 47314 User updated by: bernd dot ott at k-m dot info Reported By: bernd dot ott at k-m dot info -Status: No Feedback +Status: Open Bug Type: SOAP related Operating System: Windows PHP Version: 5.2CVS-2009-02-05 (snap) Assigned To: dmitry New Comment: No feedback was provided is not correct. Previous Comments: [2009-03-03 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2009-03-02 08:34:22] bernd dot ott at k-m dot info i created the sample on a old xp machine with apache 2.2 installed. i have tested the webservice with different Clients made with different languages. no other client keep the connections in time_wait. [2009-02-23 11:21:16] paj...@php.net Do you have IPv6 installed (by default on Vista or later, needs an extra package for XP/2k). If yes, edit: C:\windows\system32\drivers\etc\hosts and comment the following line: ::1 localhost becomes: #::1 localhost Restart the web server and test again. [2009-02-23 11:11:00] bernd dot ott at k-m dot info open the socket with fsocketopen / fclose doesnt leave timewait connections. the problem is, this causes my .net soap server to a not response state. this is because all workers are allocated. i cant use keep alive, my page is using ajax to a php page which contains the soapclient. [2009-02-18 15:41:39] dmi...@php.net According to http://tangentsoft.net/wskfaq/articles/debugging-tcp.html and http://www.developerweb.net/forum/showthread.php?t=2941 it's a normal TCP behaviour. (In case you run Apache benchmark you can see a lot of connections in TCP_WAIT state too) In case you call SOAP functions on the same SoapClient object and your Web Server responds with keep-alive HTTP header all the functions will use a single TCP connection. 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/47314 -- Edit this bug report at http://bugs.php.net/?id=47314edit=1
#47557 [NEW]: New Collection not working on Packages
From: biton at compuserve dot com Operating system: Vista / Linux PHP version: 5.2.9 PHP Bug Type: OCI8 related Bug description: New Collection not working on Packages Description: oci_new_collection() works fine on a 'TYPE' created by a user. However, if the 'TYPE' is created as part of a package, oci_new_collection() appears not to find it. ?php $c = oci_pconnect(...); // Works. sql = 'create or replace type email_array as varray(200) of varchar2(20); $s = oci_parse($c, $sql); oci_execute($s, $sql); $collec = oci_new_collection($c, 'EMAIL_ARRAY'); // Fails sql = 'create or replace type package.email_array as varray(200) of varchar2(20); $s = oci_parse($c, $sql); oci_execute($s, $sql); $collec = oci_new_collection($c, 'PACKAGE.EMAIL_ARRAY'); ? If the TYPE is created as part of the package (and not through PHP), this also fails. Any combination of user/package/type_name appears not to work. The workaround is to create a TYPE in teh user global area of the same type as that in the package, and use that in a wrapper PL/SQL block. While this works... it kindda defeats the point behind packages. Reproduce code: --- --- From manual page: function.oci-new-collection --- -- Edit bug report at http://bugs.php.net/?id=47557edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47557r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47557r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47557r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47557r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47557r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47557r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47557r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47557r=needscript Try newer version: http://bugs.php.net/fix.php?id=47557r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47557r=support Expected behavior: http://bugs.php.net/fix.php?id=47557r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47557r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47557r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47557r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47557r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47557r=dst IIS Stability: http://bugs.php.net/fix.php?id=47557r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47557r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47557r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47557r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47557r=mysqlcfg
#46075 [NoF-Csd]: repeated calls of strftime() consumes memory
ID: 46075
Updated by: paj...@php.net
Reported By: acc_php at riggers dot me dot uk
-Status: No Feedback
+Status: Closed
Bug Type: Date/time related
-Operating System: win32 only
+Operating System: *
PHP Version: 5.2CVS-2008-09-15
Assigned To: pajoye
New Comment:
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.
Previous Comments:
[2009-01-04 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2008-12-18 14:58:29] paj...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2008-12-18 14:57:55] paj...@php.net
please try the next 5.3/HEAD snapshots (could be related to #46889).
[2008-09-15 19:10:39] acc_php at riggers dot me dot uk
Same problem I'm afraid:
C:\php-latestphp.exe C:\php-gtk2\andy\symftest\strftime.test.php
=== strftime() ===
Start: 59072
End: 124488
=== date() ===
Start: 124488
End: 124456
C:\php-latestphp -v
PHP 5.2.7-dev (cli) (built: Aug 6 2008 03:00:55)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
[2008-09-14 12:12:14] acc_php at riggers dot me dot uk
Description:
strftime() called many times results in increasing memory usage. date()
is OK. This is on Vista x64. PHP 5.1.6 (only version i have at the
moment) on linux does not exhibit the same problem.
Reproduce code:
---
?php
echo === strftime() ===\n;
echo Start: .memory_get_usage().\n;
for($i = 0; $i 1; $i++ ) {
strftime(%d);
}
echo End: .memory_get_usage().\n\n;
echo === date() ===\n;
echo Start: .memory_get_usage().\n;
for($i = 0; $i 1; $i++ ) {
date(d);
}
echo End: .memory_get_usage().\n;
?
Expected result:
End memory usage for strftime() should be close to Start memory usage.
Actual result:
--
C:\php-gtk2php andy\symftest\strftime.test.php
=== strftime() ===
Start: 54384
End: 119800
=== date() ===
Start: 119800
End: 119768
C:\php-gtk2php -v
PHP 5.2.6 (cli) (built: May 2 2008 19:37:32)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
C:\php-gtk2
--
Edit this bug report at http://bugs.php.net/?id=46075edit=1
#36050 [Opn-Csd]: imagecolorallocatealpha returns false
ID: 36050 Updated by: paj...@php.net Reported By: phpbug at phpandmore dot com -Status: Open +Status: Closed Bug Type: GD related Operating System: Windows NT LAPTOP 5.1 build 2600 PHP Version: 5.1.2 Assigned To: pajoye Previous Comments: [2009-03-04 10:29:55] paj...@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. [2006-01-25 01:00:06] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2006-01-17 16:24:28] paj...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Fixed in cvs. You can now use ($trans === FALSE) Note the === usage, zero being a perfectly valid color index, you have to check for both the type and the value (bool and false). [2006-01-17 16:11:38] paj...@php.net Something is wrong, not in GD but in the casting ops. [2006-01-17 15:52:05] sni...@php.net RTFM: $image=imagecreatetruecolor... 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/36050 -- Edit this bug report at http://bugs.php.net/?id=36050edit=1
#47558 [NEW]: ini_set not returning FALSE upon failure
From: jan dot ptacek at gmail dot com
Operating system: linux
PHP version: 5.2.9
PHP Bug Type: PHP options/info functions
Bug description: ini_set not returning FALSE upon failure
Description:
ini_set is not returning FALSE upon failure
Reproduce code:
---
ini_set('include_path', APP_DIR . DS . PATH_SEPARATOR .
ini_get('include_path'));
Expected result:
updated include_path or FALSE return value
Actual result:
--
old include_path is returned but new one is not set,
because include_path was configured using php_admin_value
--
Edit bug report at http://bugs.php.net/?id=47558edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47558r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47558r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47558r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47558r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47558r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47558r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47558r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47558r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47558r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47558r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47558r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47558r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47558r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47558r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47558r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47558r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47558r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47558r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47558r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47558r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47558r=mysqlcfg
#46683 [Fbk]: fopen() file name in warning is upper cased if the arguments are invalid
ID: 46683 Updated by: a...@php.net Reported By: a...@php.net Status: Feedback Bug Type: Filesystem function related Operating System: win32 only PHP Version: 5.3CVS-2008-11-26 (snap) Assigned To: pajoye New Comment: Yes I agree the updated error message is better than the previous invalid argument message. On the subject of clear tests I don't actually find this test too bad. The code has logic to test a bunch of different conditions and so requires some eye balling to understand. Each iteration includes the current item (see below). I find this approach preferable to unrolling the loop and duplicating the code as I think that would make the test significantly less maintainable. --c:\/-- file in root --c:\fopen11.tmpdirTwo\/-- file in fopen11.tmpdirTwo --c:\fopen11.tmpdirTwo\-- file in fopen11.tmpdirTwo Previous Comments: [2009-03-02 21:06:42] paj...@php.net UNC path begins with \\, that's why it was necessary to upper case the path. However, why do you expect an invalid argument in this case? Here is what I get, which makes more sense (after the fix for the correct path in the error message): 018+ Warning: fopen(\\fopen_variation11.tmp): failed to open stream: No such file or directory in ext\standard\test\file\fopen_variation11-win32.php on line 52 018- Warning: fopen(\\fopen_variation11.tmp): failed to open stream: Invalid argument in %s on line %d 025+ Warning: fopen(/\fopen_variation11.tmp): failed to open stream: No such file or directory in ext\standard\tests\file\fopen_variation11-win32.php on line 52 025- Warning: fopen(\\fopen_variation11.tmp): failed to open stream: Invalid argument in %s on line %d [2009-03-02 20:28:05] paj...@php.net Side note: Please (PLEASE!!) try to create tests we can read. Like having an index telling which iteration we are or other similar tricks to ease the debugging. I already asked for cleaner tests many times on php-qa, without much success :) [2008-11-26 18:03:22] a...@php.net These tests are also now checked into 6.0. [2008-11-26 10:24:26] a...@php.net Description: The following test was ported from 5.2.X and behaves differently on 5.3. In particular the file name in the warning message is upper cased for no apparent reason? ext/standard/tests/file/fopen_variation11-win32.phpt Reproduce code: --- See the test now checked into CVS: ext/standard/tests/file/fopen_variation11-win32.phpt Expected result: Warning: fopen(\\fopen_variation11.tmp): failed to open stream: Invalid argument in %s on line %d Actual result: -- Warning: fopen(\\FOPEN_VARIATION11.TMP): failed to open stream: Invalid argument in %s on line %d -- Edit this bug report at http://bugs.php.net/?id=46683edit=1
#47559 [NEW]: Several always reproducable bags of segmentatio fault
From: pahan at hubbitus dot info Operating system: Linux PHP version: 5.3.0beta1 PHP Bug Type: Reproducible crash Bug description: Several always reproducable bags of segmentatio fault Description: PCRE subsystem of PHP has severul critical bugs which cause segmentation fault. 2 such bugs I report before: http://bugs.php.net/bug.php?id=47376 http://bugs.php.net/bug.php?id=47520 And many others too, for example: http://bugs.php.net/bug.php?id=27492 http://bugs.php.net/bug.php?id=47376 http://bugs.php.net/bug.php?id=27310 and others. All this bugs closed as Bogus and feedback after it with questions why it is bogus but not bug have been ignored. The main question is - segmentation fault from any reason may be not bug??? I can understand what it may be very hard to fix, but completely do not understand why it have been marked as Bogus! -- Edit bug report at http://bugs.php.net/?id=47559edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47559r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47559r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47559r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47559r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47559r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47559r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47559r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47559r=needscript Try newer version: http://bugs.php.net/fix.php?id=47559r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47559r=support Expected behavior: http://bugs.php.net/fix.php?id=47559r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47559r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47559r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47559r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47559r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47559r=dst IIS Stability: http://bugs.php.net/fix.php?id=47559r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47559r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47559r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47559r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47559r=mysqlcfg
#47560 [NEW]: explode()'s limit parameter odd behaviour
From: RQuadling at GMail dot com
Operating system: Windows XP SP3
PHP version: 5.3CVS-2009-03-04 (snap)
PHP Bug Type: Strings related
Bug description: explode()'s limit parameter odd behaviour
Description:
With regard to #47546, the behaviour of no $limit supplied and $limit
supplied as the default now match, but the output is wrong.
I've run the following code for V5.2.8, V5.2.10-dev and V5.3.0beta2-
dev (the devs are the latest win32 snapshots).
Here is a summary ...
V5.2.8
No limit - 4 entries
Limit of -4 - No entries
Limit of -3 - 1 entry
Limit of -2 - 2 entries
Limit of -1 - 4 entries *** Should be 3 entries
Limit of 0 - 1 entry
Limit of 1 - 1 entry
Limit of 2 - 2 entries
Limit of 3 - 3 entries
Limit of 4 - 4 entries *** Matches No Limit
5.2.10-dev and 5.3.0beta2-dev
No limit - 4 entries
Limit of -4 - No entries
Limit of -3 - 1 entry
Limit of -2 - 2 entries
Limit of -1 - 4 entries *** Should be 3 entries but does match No
Limit
Limit of 0 - 1 entry
Limit of 1 - 1 entry
Limit of 2 - 2 entries
Limit of 3 - 3 entries
Limit of 4 - 4 entries *** Matches No Limit
It would seem that the idea of limit has a static value default is
inappropriate. If anything the default for limit is the number of
elements in no limiting takes place.
Also a limit of -1 should be returning 3 elements and not 4.
Richard.
Reproduce code:
---
?php
$s_Imploded = 'one.two.three.four';
$s_Exploded = serialize(explode('.', $s_Imploded));
echo PHP_VERSION, PHP_EOL;
echo 'No limit supplied.', PHP_EOL, var_export(explode('.', $s_Imploded),
True), PHP_EOL;
for ($i_Limit = -4 ; $i_Limit = 4 ; ++$i_Limit)
{
echo Testing limit of $i_Limit, PHP_EOL, var_export(explode('.',
$s_Imploded, $i_Limit), True), PHP_EOL;
if (serialize(explode('.', $s_Imploded, $i_Limit)) === $s_Exploded)
{
echo A limit of $i_Limit matches the output when no limit has
been
supplied., PHP_EOL;
}
echo PHP_EOL;
}
--
Edit bug report at http://bugs.php.net/?id=47560edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47560r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47560r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47560r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47560r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47560r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47560r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47560r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47560r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47560r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47560r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47560r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47560r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47560r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47560r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47560r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47560r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47560r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47560r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47560r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47560r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47560r=mysqlcfg
#47558 [Opn-Bgs]: ini_set not returning FALSE upon failure
ID: 47558
Updated by: scott...@php.net
Reported By: jan dot ptacek at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: PHP options/info functions
Operating System: linux
PHP Version: 5.2.9
New Comment:
I can't reproduce this with 5.2.9
var_dump(ini_set('include_path', '/fooo/bar'));
results in a return of bool (false)
Previous Comments:
[2009-03-04 12:16:36] jan dot ptacek at gmail dot com
Description:
ini_set is not returning FALSE upon failure
Reproduce code:
---
ini_set('include_path', APP_DIR . DS . PATH_SEPARATOR .
ini_get('include_path'));
Expected result:
updated include_path or FALSE return value
Actual result:
--
old include_path is returned but new one is not set,
because include_path was configured using php_admin_value
--
Edit this bug report at http://bugs.php.net/?id=47558edit=1
#47558 [Bgs]: ini_set not returning FALSE upon failure
ID: 47558
User updated by: jan dot ptacek at gmail dot com
Reported By: jan dot ptacek at gmail dot com
Status: Bogus
Bug Type: PHP options/info functions
Operating System: linux
PHP Version: 5.2.9
New Comment:
I am really sorry for reporting wron version
I am actually on 5.2.6 and can't change that.
Previous Comments:
[2009-03-04 12:37:44] scott...@php.net
I can't reproduce this with 5.2.9
var_dump(ini_set('include_path', '/fooo/bar'));
results in a return of bool (false)
[2009-03-04 12:16:36] jan dot ptacek at gmail dot com
Description:
ini_set is not returning FALSE upon failure
Reproduce code:
---
ini_set('include_path', APP_DIR . DS . PATH_SEPARATOR .
ini_get('include_path'));
Expected result:
updated include_path or FALSE return value
Actual result:
--
old include_path is returned but new one is not set,
because include_path was configured using php_admin_value
--
Edit this bug report at http://bugs.php.net/?id=47558edit=1
#47558 [Bgs]: ini_set not returning FALSE upon failure
ID: 47558
Updated by: scott...@php.net
Reported By: jan dot ptacek at gmail dot com
Status: Bogus
Bug Type: PHP options/info functions
Operating System: linux
-PHP Version: 5.2.9
+PHP Version: 5.2.6
New Comment:
Bug reports should only be against the latest version, since I can't
reproduce this on 5.2.9, it can be assumed its fixed.
Previous Comments:
[2009-03-04 12:50:24] jan dot ptacek at gmail dot com
I am really sorry for reporting wron version
I am actually on 5.2.6 and can't change that.
[2009-03-04 12:37:44] scott...@php.net
I can't reproduce this with 5.2.9
var_dump(ini_set('include_path', '/fooo/bar'));
results in a return of bool (false)
[2009-03-04 12:16:36] jan dot ptacek at gmail dot com
Description:
ini_set is not returning FALSE upon failure
Reproduce code:
---
ini_set('include_path', APP_DIR . DS . PATH_SEPARATOR .
ini_get('include_path'));
Expected result:
updated include_path or FALSE return value
Actual result:
--
old include_path is returned but new one is not set,
because include_path was configured using php_admin_value
--
Edit this bug report at http://bugs.php.net/?id=47558edit=1
#47554 [Bgs]: call_user_func_array returns NULL (instead of FALSE) for invalid callbacks
ID: 47554
User updated by: jimmy at basicmatrix dot com
Reported By: jimmy at basicmatrix dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 5.2.9
New Comment:
I never knew that functions/methods that fail parameter validation will
always return NULL. Thanks for clearing that up for me!
But how is it that an uncallable callback is detected as a parameter
failure during the internal parameter validation? I would think it would
be checking for $callback to be a string or array(2) (vs. something
obviously wrong, i.e., a resource). After that, the check for an
invalid callback would be detected once call_user_func_array() attempts
to call it. In which case, it would fail to complete its task and
return FALSE.
If the callback type is validated fully outside of
call_user_func_array()'s control--and if the change I'm suggesting is
impossible to make, i.e., if other functions besides call_user_func*()
will crash if given an invalid callback--could the documentation for
call_user_func* be updated to read:
Returns the function result, NULL for an invalid callback, and FALSE
for all other errors.?
That addition would have saved me a lot of development time. My code
was expecting FALSE from call_user_func_array() OR the callback to mean
stop the callback loop for any reason. (NULL from the callback
function is acceptable.) I have fixed my code by calling the
is_callable() function first.
Thank for your help!
Previous Comments:
[2009-03-04 10:14:51] ka...@php.net
Calling a function/method with invalid parameter, eg. parameters that
does not pass parameter parsing internally all return NULL. In this case
FALSE is returned if something fails after the parameter parsing have
passed.
[2009-03-03 23:47:58] jimmy at basicmatrix dot com
Description:
call_user_func_array() claims it Returns the function result, or FALSE
on error.
My testing shows it returns NULL if the callback function is not a
valid callback.
Reproduce code:
---
?php
function callable()
{ return 'Good.'; }
$return = call_user_func_array('callable',array());
var_dump($return);
$return = call_user_func_array('not_callable',array());
var_dump($return);
?
Expected result:
string(5) Good.
Warning: call_user_func_array() [function.call-user-func-array]: First
argument is expected to be a valid callback, 'not_callable' was given in
___ on line 9
FALSE
Actual result:
--
string(5) Good.
Warning: call_user_func_array() [function.call-user-func-array]: First
argument is expected to be a valid callback, 'not_callable' was given in
___ on line 9
NULL
--
Edit this bug report at http://bugs.php.net/?id=47554edit=1
#47562 [NEW]: About Client API version / libmysql.dll
From: bluephp at gmail dot com Operating system: Windows 2003 Server PHP version: 5.2.9 PHP Bug Type: MySQL related Bug description: About Client API version / libmysql.dll Description: My server: Windwos 2003 Server PHP version: 5.2.9 Mysql: 5.0.45 phpMyAdmin: 2.11.0 php-5.2.4/libmysql.dll : 5.0.45 php-5.2.9/libmysql.dll : 5.0.51a -- Today I upgrade my php version from 5.2.4 to 5.2.9, I finish it,everything is OK, the php file running OK. It s good. But when login in the phpMyAdmin ,it warning me : -- Your PHP MySQL library version 5.0.51a differs from your MySQL server version 5.0.45. This may cause unpredictable behavior. -- So I copy php-5.2.4/libmysql.dll instead of php-5.2.9/libmysql.dll ,then the phpMyAdmin without the warning .It is all OK. But I think the warning maybe not important. Can I use php-5.2.9/libmysql.dll in my php with phpMyAdmin warning ? -- Edit bug report at http://bugs.php.net/?id=47562edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47562r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47562r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47562r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47562r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47562r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47562r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47562r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47562r=needscript Try newer version: http://bugs.php.net/fix.php?id=47562r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47562r=support Expected behavior: http://bugs.php.net/fix.php?id=47562r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47562r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47562r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47562r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47562r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47562r=dst IIS Stability: http://bugs.php.net/fix.php?id=47562r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47562r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47562r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47562r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47562r=mysqlcfg
#47563 [NEW]: can't get it to work with ldap
From: dnguyen at stewleonards dot com Operating system: window server 2003 PHP version: 5.2.9 PHP Bug Type: *Directory/Filesystem functions Bug description: can't get it to work with ldap Description: i am trying to enable microsoft active directory with php so i went in php.ini to enable the line extension=php_ldap.dll and it still doesn't work. i tried to install jdiagnostic in joomla 1.5 and it says this LDAP: authentication (crit) PHP LDAP Library not detected. can you tell me what else do i have to do with php to solve the problem? thanks -- Edit bug report at http://bugs.php.net/?id=47563edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47563r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47563r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47563r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47563r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47563r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47563r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47563r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47563r=needscript Try newer version: http://bugs.php.net/fix.php?id=47563r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47563r=support Expected behavior: http://bugs.php.net/fix.php?id=47563r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47563r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47563r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47563r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47563r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47563r=dst IIS Stability: http://bugs.php.net/fix.php?id=47563r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47563r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47563r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47563r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47563r=mysqlcfg
#47564 [NEW]: unpacking unsigned long 32bit bit endian returns wrong result
From: laacz at laacz dot lv
Operating system: 6.1-STABLE FreeBSD (amd64)
PHP version: 5.2.9
PHP Bug Type: Strings related
Bug description: unpacking unsigned long 32bit bit endian returns wrong result
Description:
Unpacking unsigned long (32bit; always big endian; N) on 64bit
system returns 64bit signed int instead of 32bit.
You can do 0x on unpacked value, and get desired result,
but that's still a bug.
Reproduce code:
---
?php
list(,$command_id) = unpack('N', chr(0x80) . chr(0x00) . chr(0x00) .
chr(0x09));
echo hexdec(dechex($command_id)) . \n0x . dechex($command_id) . \n;
?
Expected result:
2147483657
0x8009
Actual result:
--
1.8446744071562E+19
0x8009
--
Edit bug report at http://bugs.php.net/?id=47564edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47564r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47564r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47564r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47564r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47564r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47564r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47564r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47564r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47564r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47564r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47564r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47564r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47564r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47564r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47564r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47564r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47564r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47564r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47564r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47564r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47564r=mysqlcfg
#47563 [Opn-Bgs]: can't get it to work with ldap
ID: 47563 Updated by: der...@php.net Reported By: dnguyen at stewleonards dot com -Status: Open +Status: Bogus Bug Type: *Directory/Filesystem functions Operating System: window server 2003 PHP Version: 5.2.9 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. . Previous Comments: [2009-03-04 16:41:58] dnguyen at stewleonards dot com Description: i am trying to enable microsoft active directory with php so i went in php.ini to enable the line extension=php_ldap.dll and it still doesn't work. i tried to install jdiagnostic in joomla 1.5 and it says this LDAP: authentication (crit) PHP LDAP Library not detected. can you tell me what else do i have to do with php to solve the problem? thanks -- Edit this bug report at http://bugs.php.net/?id=47563edit=1
#47559 [Com]: Several always reproducable bags of segmentatio fault
ID: 47559 Comment by: crrodriguez at opensuse dot org Reported By: pahan at hubbitus dot info Status: Open Bug Type: Reproducible crash Operating System: Linux PHP Version: 5.3.0beta1 New Comment: They are marked as BOGUS because they are not a problem in PHP, this is a known issue with the PCRE library, please read the manual carefully, PCRE may overflow the stack, and is expected to abort with segmentation fault in the case. Previous Comments: [2009-03-04 12:30:44] pahan at hubbitus dot info Description: PCRE subsystem of PHP has severul critical bugs which cause segmentation fault. 2 such bugs I report before: http://bugs.php.net/bug.php?id=47376 http://bugs.php.net/bug.php?id=47520 And many others too, for example: http://bugs.php.net/bug.php?id=27492 http://bugs.php.net/bug.php?id=47376 http://bugs.php.net/bug.php?id=27310 and others. All this bugs closed as Bogus and feedback after it with questions why it is bogus but not bug have been ignored. The main question is - segmentation fault from any reason may be not bug??? I can understand what it may be very hard to fix, but completely do not understand why it have been marked as Bogus! -- Edit this bug report at http://bugs.php.net/?id=47559edit=1
#38111 [Com]: PHP crashes IIS worker process and application pool
ID: 38111 Comment by: info at cmiwebstudio dot com Reported By: svendavidh at hotmail dot com Status: No Feedback Bug Type: IIS related Operating System: Windows Server 2003 Std. Ed. R2 PHP Version: 5.2.8 Assigned To: pajoye New Comment: PHP 5.2.9 IIS 6 WIN Server 2003 Standard MySQL 5.1.31 Same problem indicating a problem with php_mbstring.dll . Also getting Invalid access to memory location. on PHP pages. Previous Comments: [2009-02-19 04:59:39] sikle at stx dot net i've resorted to just using apache (via xampp) instead... hrmph. but atleast now it doesn't crash =) [2009-02-18 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2009-02-10 21:50:51] paj...@php.net Yes, a simple phpinfo and then restart IIS is all it need to crash. (Note: I am using IIS on Vista 64, and have to create a new Application Pool and then enable 32-bit application) As for why we stick with ISAPI: 1. We have an php extension for handling proprietary protocol and it has significant overhead on startup. We will try FastCGI, but in the meantime we keep in in ISAPI mode so that it won't get loaded and unloaded frequently. That should not be a problem at all. 2. FastCGI could be way better, but ISAPI is still a legitimate mode for PHP. So I am a bit surprise to see you persuade others to use FastCGI as a way to avoid this bug. Well of course, use Apache or Linux also fix this problem as well. Nobody maintains it and it is likely to be dropped. It was never stable and it is very unlikely that we will fix it any time soon. It is also the recommend way, according to the IIS team (and I work with them on that). BTW, FastCGI is an excellent idea to make PHP more stable. But I am worry it becomes a way to hide all the thread-safe, memory leak issues and allow them not being fixed properly. There is no tread safety issue with fastcgi because this SAPI is not threaded (like ISAPI or some apache2 sapi). I do not understand your point with the memory leaks. [2009-02-10 20:55:56] tser at deltacontrols dot com Just to clarify again. The crash could be duplicated without any extension loaded, our own extension is not loaded neither. [2009-02-10 20:52:28] tser at deltacontrols dot com Yes, a simple phpinfo and then restart IIS is all it need to crash. (Note: I am using IIS on Vista 64, and have to create a new Application Pool and then enable 32-bit application) As for why we stick with ISAPI: 1. We have an php extension for handling proprietary protocol and it has significant overhead on startup. We will try FastCGI, but in the meantime we keep in in ISAPI mode so that it won't get loaded and unloaded frequently. 2. FastCGI could be way better, but ISAPI is still a legitimate mode for PHP. So I am a bit surprise to see you persuade others to use FastCGI as a way to avoid this bug. Well of course, use Apache or Linux also fix this problem as well. BTW, FastCGI is an excellent idea to make PHP more stable. But I am worry it becomes a way to hide all the thread-safe, memory leak issues and allow them not being fixed 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/38111 -- Edit this bug report at http://bugs.php.net/?id=38111edit=1
#47514 [Bgs]: memory leak in PDO::prepare while using pdo_pgsql
ID: 47514
User updated by: lukasz at fsi dot pl
Reported By: lukasz at fsi dot pl
Status: Bogus
Bug Type: PDO related
Operating System: FreeBSD 6.4
PHP Version: 5.2.8
New Comment:
The problem this exists in 5.2.9. I think that for some reason in my
case native prepared statements are not used.
Previous Comments:
[2009-03-03 01:18:19] il...@php.net
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP --
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php
If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to Open.
Again, thank you for your continued support of PHP.
memory usage does not appear to change is latest cvs
[2009-02-26 23:25:52] lukasz at fsi dot pl
Description:
Calling prepare() for pdo_pgsql connection consumes memory which is
never being freed. Specified query doesn't matter. It seems that this
happen because in my case pdo_pgsql does not use native prepared
statements, but I can't find the reason for this. I think so because
calling prepare(foo) does not cause an error as it does when I use
pdo_mysql.
Reproduce code:
---
$a = new PDO('pgsql:'.$some_pdo_pgsql_dsn);
for ($i = 0; $i 100; $i++)
{
$st = $a-prepare();
print(memory_get_usage(true).\n);
unset($st);
}
Expected result:
constant memory usage
Actual result:
--
increasing memory usage
--
Edit this bug report at http://bugs.php.net/?id=47514edit=1
#47514 [Bgs]: memory leak in PDO::prepare while using pdo_pgsql
ID: 47514
User updated by: lukasz at fsi dot pl
Reported By: lukasz at fsi dot pl
Status: Bogus
Bug Type: PDO related
Operating System: FreeBSD 6.4
-PHP Version: 5.2.8
+PHP Version: 5.2.9
New Comment:
I've tried to change bug status to open but I can't do this.
Previous Comments:
[2009-03-04 18:49:48] lukasz at fsi dot pl
The problem this exists in 5.2.9. I think that for some reason in my
case native prepared statements are not used.
[2009-03-03 01:18:19] il...@php.net
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP --
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php
If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to Open.
Again, thank you for your continued support of PHP.
memory usage does not appear to change is latest cvs
[2009-02-26 23:25:52] lukasz at fsi dot pl
Description:
Calling prepare() for pdo_pgsql connection consumes memory which is
never being freed. Specified query doesn't matter. It seems that this
happen because in my case pdo_pgsql does not use native prepared
statements, but I can't find the reason for this. I think so because
calling prepare(foo) does not cause an error as it does when I use
pdo_mysql.
Reproduce code:
---
$a = new PDO('pgsql:'.$some_pdo_pgsql_dsn);
for ($i = 0; $i 100; $i++)
{
$st = $a-prepare();
print(memory_get_usage(true).\n);
unset($st);
}
Expected result:
constant memory usage
Actual result:
--
increasing memory usage
--
Edit this bug report at http://bugs.php.net/?id=47514edit=1
#12802 [Com]: gethostbyname/gethostbyaddr timeout
ID: 12802 Comment by: adifranco at tagged dot com Reported By: cheapsalsa at yahoo dot com Status: Open Bug Type: Feature/Change Request Operating System: Linux (N/A) PHP Version: 4.0CVS-2001-08-16 New Comment: Any intent to fix this? This kind of indeterminism is very crippling to trying to use these functions in a feature that interacts with the user. Previous Comments: [2003-08-10 22:54:12] grimtraffic at hotmail dot com To be honest, no timeout has really made it hard to log users. There is no point of logging IP's because they change too often for dial-up users, and with my page timing out every third time someone goes to it, I now have troubles. By the way, 2 out of 3 who use gethostbyaddr have an issue with it timing out constantly. [2003-02-05 06:19:54] sergi at millorsoft dot es Is this bug still open? I think it's a really important bug and can cause very long retards when the DNS lookup doesn't respond or some DNS server is unreacheable. [2001-08-16 21:03:38] cheapsalsa at yahoo dot com I propose creating a timeout argument on the gethostbyname and gethostbyaddr. I have a script that uses these, and if my internet connection goes down it takes 1:30-2:00 minutes for 3 gethostbyname's to timeout. This is way to long, and it would help if I could specify a timeout. -- Edit this bug report at http://bugs.php.net/?id=12802edit=1
#38111 [NoF-Bgs]: PHP crashes IIS worker process and application pool
ID: 38111 Updated by: paj...@php.net Reported By: svendavidh at hotmail dot com -Status: No Feedback +Status: Bogus Bug Type: IIS related Operating System: Windows Server 2003 Std. Ed. R2 PHP Version: 5.2.8 Assigned To: pajoye New Comment: For the 100th time, never use mysql 5.1 DLL with PHP. Closing this bug as well as no useful information has been provided and the ISAPI is going to be deprecated anyway. Use FastCGI istead with IIS5/6/7. Previous Comments: [2009-03-04 18:46:44] info at cmiwebstudio dot com PHP 5.2.9 IIS 6 WIN Server 2003 Standard MySQL 5.1.31 Same problem indicating a problem with php_mbstring.dll . Also getting Invalid access to memory location. on PHP pages. [2009-02-19 04:59:39] sikle at stx dot net i've resorted to just using apache (via xampp) instead... hrmph. but atleast now it doesn't crash =) [2009-02-18 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2009-02-10 21:50:51] paj...@php.net Yes, a simple phpinfo and then restart IIS is all it need to crash. (Note: I am using IIS on Vista 64, and have to create a new Application Pool and then enable 32-bit application) As for why we stick with ISAPI: 1. We have an php extension for handling proprietary protocol and it has significant overhead on startup. We will try FastCGI, but in the meantime we keep in in ISAPI mode so that it won't get loaded and unloaded frequently. That should not be a problem at all. 2. FastCGI could be way better, but ISAPI is still a legitimate mode for PHP. So I am a bit surprise to see you persuade others to use FastCGI as a way to avoid this bug. Well of course, use Apache or Linux also fix this problem as well. Nobody maintains it and it is likely to be dropped. It was never stable and it is very unlikely that we will fix it any time soon. It is also the recommend way, according to the IIS team (and I work with them on that). BTW, FastCGI is an excellent idea to make PHP more stable. But I am worry it becomes a way to hide all the thread-safe, memory leak issues and allow them not being fixed properly. There is no tread safety issue with fastcgi because this SAPI is not threaded (like ISAPI or some apache2 sapi). I do not understand your point with the memory leaks. [2009-02-10 20:55:56] tser at deltacontrols dot com Just to clarify again. The crash could be duplicated without any extension loaded, our own extension is not loaded neither. 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/38111 -- Edit this bug report at http://bugs.php.net/?id=38111edit=1
#47565 [NEW]: Extend serialize and unserialize with encryption key.
From: martin at itmission dot com Operating system: PHP version: 5.3.0beta1 PHP Bug Type: Feature/Change Request Bug description: Extend serialize and unserialize with encryption key. Description: Request: Add simple encryption support to serialize and unserialize. Rationale: It is useful to be able to serialize an object and hide it in a form variable on a web page. This is vulnerable to tampering by the end user. serialize(mixed $value[, string $key]) unserialize(string $str[, string $key]) This new definition won't break existing code and could be implemented using a TEA variant in a few lines. It would be nice if objects didn't have to be persisted in $_SESSION, because some power users want to use multiple windows to work with different objects simultaneously (editing two invoice objects at the same time, but commiting only complete changes of each). -- Edit bug report at http://bugs.php.net/?id=47565edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47565r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47565r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47565r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47565r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47565r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47565r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47565r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47565r=needscript Try newer version: http://bugs.php.net/fix.php?id=47565r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47565r=support Expected behavior: http://bugs.php.net/fix.php?id=47565r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47565r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47565r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47565r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47565r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47565r=dst IIS Stability: http://bugs.php.net/fix.php?id=47565r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47565r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47565r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47565r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47565r=mysqlcfg
#47566 [NEW]: PCNTL Waitpid exit status incorrect
From: james at jamesreno dot com
Operating system: linux-2.6
PHP version: 5.2.9
PHP Bug Type: PCNTL related
Bug description: PCNTL Waitpid exit status incorrect
Description:
The $status exitcode returned by pcntl_waitpid() is incorrectly casted
resulting in an invalid number being returned.
I believe the int is converted to a long in ext/pcntl/pcntl.c, resulting
in an invalid integer being returned to the parent.
zval *z_status = NULL;
int status;
convert_to_long_ex(z_status);
status = Z_LVAL_P(z_status);
child_id = waitpid((pid_t) pid, status, options);
Z_LVAL_P(z_status) = status;
z_status is a long, but status is an int...
Reproduce code:
---
?
$pid = pcntl_fork();
if ($pid == -1) {
echo Unable to fork;
exit;
} elseif ($pid) {
$epid = pcntl_waitpid(-1,$status);
echo PARENT: {$pid}/{$epid} exited {$status}\n;
exit(128);
} else {
echo CHILD: Exiting with exit code 128\n;
exit(128);
}
?
Expected result:
[ja...@localhost ~]$ php test.php
CHILD: Exiting with exit code 128
PARENT: 7598/7598 exited 128
[ja...@localhost ~]$ echo $?
128
[ja...@localhost ~]$
Actual result:
--
[ja...@localhost ~]$ php test.php
CHILD: Exiting with exit code 128
PARENT: 7598/7598 exited 32768
[ja...@localhost ~]$ echo $?
128
[ja...@localhost ~]$
--
Edit bug report at http://bugs.php.net/?id=47566edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47566r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47566r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47566r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47566r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47566r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47566r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47566r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47566r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47566r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47566r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47566r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47566r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47566r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47566r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47566r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47566r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47566r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47566r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47566r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47566r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47566r=mysqlcfg
#47567 [NEW]: Problem Overloading arrays with __set.
From: vyk2rr at gmail dot com
Operating system: Ubuntu 8.10
PHP version: 5.2.9
PHP Bug Type: Scripting Engine problem
Bug description: Problem Overloading arrays with __set.
Description:
I can't add values to an array using __set($k, $v){...}
This look like this other bug http://bugs.php.net/bug.php?id=39449 but is
not the same
This is the same bug http://bugs.php.net/bug.php?id=33941 but is closed
:S
So I'm researching in the manual
(http://www.php.net/manual/en/language.oop5.overloading.php), but there is
nothing about it
Reproduce code:
---
?php
class test {
private $vars = array();
public function __set($k, $v) { $this-vars[$k] = $v; }
public function showAll(){
echo pre;
foreach($this-vars as $k=$v){
echo $k: ;
print_r($v); echo br /;
}
echo /pre;
}
}
$t = new test();
$t-a = 'one';
$t-b = 'two';
$t-c = array('one','two');
$t-c[] = 'three';
$t-c[] = 'four';
$t-d = array( );
$t-d[] = 'one';
$t-e = 'three';
$t-showAll();
?
Expected result:
a: one
b: two
c: Array
(
[0] = one
[1] = two
[2] = three
[3] = four
)
d: Array
(
[0] = one
)
e: three
Actual result:
--
a: one
b: two
c: Array
(
[0] = one
[1] = two
)
d: Array
(
)
e: three
--
Edit bug report at http://bugs.php.net/?id=47567edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47567r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47567r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47567r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47567r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47567r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47567r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47567r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47567r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47567r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47567r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47567r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47567r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47567r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47567r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47567r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47567r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47567r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47567r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47567r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47567r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47567r=mysqlcfg
#47560 [Opn-Asn]: explode()'s limit parameter odd behaviour
ID: 47560
Updated by: fel...@php.net
Reported By: RQuadling at GMail dot com
-Status: Open
+Status: Assigned
Bug Type: Strings related
Operating System: Windows XP SP3
PHP Version: 5.3CVS-2009-03-04 (snap)
-Assigned To:
+Assigned To: Kalle
New Comment:
Hi Kalle,
This issue looks like documentation problem. I guess that your commit
to #47546 must be reverted.
Previous Comments:
[2009-03-04 12:37:37] RQuadling at GMail dot com
Description:
With regard to #47546, the behaviour of no $limit supplied and $limit
supplied as the default now match, but the output is wrong.
I've run the following code for V5.2.8, V5.2.10-dev and V5.3.0beta2-
dev (the devs are the latest win32 snapshots).
Here is a summary ...
V5.2.8
No limit - 4 entries
Limit of -4 - No entries
Limit of -3 - 1 entry
Limit of -2 - 2 entries
Limit of -1 - 4 entries *** Should be 3 entries
Limit of 0 - 1 entry
Limit of 1 - 1 entry
Limit of 2 - 2 entries
Limit of 3 - 3 entries
Limit of 4 - 4 entries *** Matches No Limit
5.2.10-dev and 5.3.0beta2-dev
No limit - 4 entries
Limit of -4 - No entries
Limit of -3 - 1 entry
Limit of -2 - 2 entries
Limit of -1 - 4 entries *** Should be 3 entries but does match No
Limit
Limit of 0 - 1 entry
Limit of 1 - 1 entry
Limit of 2 - 2 entries
Limit of 3 - 3 entries
Limit of 4 - 4 entries *** Matches No Limit
It would seem that the idea of limit has a static value default is
inappropriate. If anything the default for limit is the number of
elements in no limiting takes place.
Also a limit of -1 should be returning 3 elements and not 4.
Richard.
Reproduce code:
---
?php
$s_Imploded = 'one.two.three.four';
$s_Exploded = serialize(explode('.', $s_Imploded));
echo PHP_VERSION, PHP_EOL;
echo 'No limit supplied.', PHP_EOL, var_export(explode('.',
$s_Imploded), True), PHP_EOL;
for ($i_Limit = -4 ; $i_Limit = 4 ; ++$i_Limit)
{
echo Testing limit of $i_Limit, PHP_EOL, var_export(explode('.',
$s_Imploded, $i_Limit), True), PHP_EOL;
if (serialize(explode('.', $s_Imploded, $i_Limit)) === $s_Exploded)
{
echo A limit of $i_Limit matches the output when no limit has
been
supplied., PHP_EOL;
}
echo PHP_EOL;
}
--
Edit this bug report at http://bugs.php.net/?id=47560edit=1
#47559 [Opn-Bgs]: Several always reproducable bags of segmentatio fault
ID: 47559 Updated by: fel...@php.net Reported By: pahan at hubbitus dot info -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Linux PHP Version: 5.3.0beta1 New Comment: . Previous Comments: [2009-03-04 17:31:52] crrodriguez at opensuse dot org They are marked as BOGUS because they are not a problem in PHP, this is a known issue with the PCRE library, please read the manual carefully, PCRE may overflow the stack, and is expected to abort with segmentation fault in the case. [2009-03-04 12:30:44] pahan at hubbitus dot info Description: PCRE subsystem of PHP has severul critical bugs which cause segmentation fault. 2 such bugs I report before: http://bugs.php.net/bug.php?id=47376 http://bugs.php.net/bug.php?id=47520 And many others too, for example: http://bugs.php.net/bug.php?id=27492 http://bugs.php.net/bug.php?id=47376 http://bugs.php.net/bug.php?id=27310 and others. All this bugs closed as Bogus and feedback after it with questions why it is bogus but not bug have been ignored. The main question is - segmentation fault from any reason may be not bug??? I can understand what it may be very hard to fix, but completely do not understand why it have been marked as Bogus! -- Edit this bug report at http://bugs.php.net/?id=47559edit=1
#47545 [Opn-Asn]: compile fails: cannot find -lintl
ID: 47545 Updated by: fel...@php.net Reported By: hackert at vin-loesungen dot de -Status: Open +Status: Assigned Bug Type: Sybase-ct (ctlib) related Operating System: Suse Linux 9 PHP Version: 5.2.9 -Assigned To: +Assigned To: thekid New Comment: Assigned to maintainer. Previous Comments: [2009-03-02 15:33:50] hackert at vin-loesungen dot de Description: Hi, when running make after successfull configure --prefix=/usr --disable-all --disable-cgi --with-apxs2=/usr/sbin/apxs2-prefork --with-sybase-ct=/var/opt/sybase/OCS_15-0 the compile-process stops with /bin/sh /root/php/php-5.2.9/libtool --silent --preserve-dup-deps --mode=link gcc -g -O2 -rpath /root/php/php-5.2.9/libs -avoid-version -module -L/var/opt/sybase/OCS-15_0/lib -R /var/opt/sybase/OCS-15_0/lib ext/date/php_date.lo ext/date/lib/astro.lo ext/date/lib/dow.lo ext/date/lib/parse_date.lo ext/date/lib/parse_tz.lo ext/date/lib/timelib.lo ext/date/lib/tm2unixtime.lo ext/date/lib/unixtime2tm.lo ext/reflection/php_reflection.lo regex/regcomp.lo regex/regexec.lo regex/regerror.lo regex/regfree.lo ext/standard/array.lo ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo ext/standard/formatted_print.lo ext/standard/fsock.lo ext/standard/head.lo ext/standard/html.lo ext/standard/image.lo ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo ext/standard/link.lo ext/standard/mail.lo ext/standard/math.lo ext/standard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo ext/standard/pack.lo ext/standard/pageinfo.lo ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/reg.lo ext/standard/soundex.lo ext/standard/string.lo ext/standard/scanf.lo ext/standard/syslog.lo ext/standard/type.lo ext/standard/uniqid.lo ext/standard/url.lo ext/standard/url_scanner.lo ext/standard/var.lo ext/standard/versioning.lo ext/standard/assert.lo ext/standard/strnatcmp.lo ext/standard/levenshtein.lo ext/standard/incomplete_class.lo ext/standard/url_scanner_ex.lo ext/standard/ftp_fopen_wrapper.lo ext/standard/http_fopen_wrapper.lo ext/standard/php_fopen_wrapper.lo ext/standard/credits.lo ext/standard/css.lo ext/standard/var_unserializer.lo ext/standard/ftok.lo ext/standard/sha1.lo ext/standard/user_filters.lo ext/standard/uuencode.lo ext/standard/filters.lo ext/standard/proc_open.lo ext/standard/streamsfuncs.lo ext/standard/http.lo ext/sybase_ct/php_sybase_ct.lo TSRM/TSRM.lo TSRM/tsrm_strtok_r.lo TSRM/tsrm_virtual_cwd.lo main/main.lo main/snprintf.lo main/spprintf.lo main/php_sprintf.lo main/safe_mode.lo main/fopen_wrappers.lo main/alloca.lo main/php_scandir.lo main/php_ini.lo main/SAPI.lo main/rfc1867.lo main/php_content_types.lo main/strlcpy.lo main/strlcat.lo main/mergesort.lo main/reentrancy.lo main/php_variables.lo main/php_ticks.lo main/network.lo main/php_open_temporary_file.lo main/php_logos.lo main/output.lo main/streams/streams.lo main/streams/cast.lo main/streams/memory.lo main/streams/filter.lo main/streams/plain_wrapper.lo main/streams/userspace.lo main/streams/transports.lo main/streams/xp_socket.lo main/streams/mmap.lo Zend/zend_language_parser.lo Zend/zend_language_scanner.lo Zend/zend_ini_parser.lo Zend/zend_ini_scanner.lo Zend/zend_alloc.lo Zend/zend_compile.lo Zend/zend_constants.lo Zend/zend_dynamic_array.lo Zend/zend_execute_API.lo Zend/zend_highlight.lo Zend/zend_llist.lo Zend/zend_opcode.lo Zend/zend_operators.lo Zend/zend_ptr_stack.lo Zend/zend_stack.lo Zend/zend_variables.lo Zend/zend.lo Zend/zend_API.lo Zend/zend_extensions.lo Zend/zend_hash.lo Zend/zend_list.lo Zend/zend_indent.lo Zend/zend_builtin_functions.lo Zend/zend_sprintf.lo Zend/zend_ini.lo Zend/zend_qsort.lo Zend/zend_multibyte.lo Zend/zend_ts_hash.lo Zend/zend_stream.lo Zend/zend_iterators.lo Zend/zend_interfaces.lo Zend/zend_exceptions.lo Zend/zend_strtod.lo Zend/zend_objects.lo Zend/zend_object_handlers.lo Zend/zend_objects_API.lo Zend/zend_default_classes.lo Zend/zend_execute.lo sapi/apache2handler/mod_php5.lo sapi/apache2handler/sapi_apache2.lo sapi/apache2handler/apache_config.lo sapi/apache2handler/php_functions.lo main/internal_functions.lo -lcrypt -lsybtcl -lintl -lcomn -lct -lcs -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -lcrypt -o libphp5.la /usr/lib/gcc-lib/powerpc-suse-linux/3.3.3/../../../../powerpc-suse-linux/bin/ld: cannot find -lintl collect2: ld returned 1 exit status make: *** [libphp5.la] Error 1 Tried the patches at bug report #45393 but none worked. -- Edit this bug report at http://bugs.php.net/?id=47545edit=1
#47566 [Opn-Bgs]: PCNTL Waitpid exit status incorrect
ID: 47566
Updated by: fel...@php.net
Reported By: james at jamesreno dot com
-Status: Open
+Status: Bogus
Bug Type: PCNTL related
Operating System: linux-2.6
PHP Version: 5.2.9
New Comment:
You need to use the pcntl_wexitstatus().
http://docs.php.net/manual/en/function.pcntl-wexitstatus.php
http://www.mkssoftware.com/docs/man3/waitpid.3.asp
Previous Comments:
[2009-03-04 21:59:01] james at jamesreno dot com
Description:
The $status exitcode returned by pcntl_waitpid() is incorrectly casted
resulting in an invalid number being returned.
I believe the int is converted to a long in ext/pcntl/pcntl.c,
resulting in an invalid integer being returned to the parent.
zval *z_status = NULL;
int status;
convert_to_long_ex(z_status);
status = Z_LVAL_P(z_status);
child_id = waitpid((pid_t) pid, status, options);
Z_LVAL_P(z_status) = status;
z_status is a long, but status is an int...
Reproduce code:
---
?
$pid = pcntl_fork();
if ($pid == -1) {
echo Unable to fork;
exit;
} elseif ($pid) {
$epid = pcntl_waitpid(-1,$status);
echo PARENT: {$pid}/{$epid} exited {$status}\n;
exit(128);
} else {
echo CHILD: Exiting with exit code 128\n;
exit(128);
}
?
Expected result:
[ja...@localhost ~]$ php test.php
CHILD: Exiting with exit code 128
PARENT: 7598/7598 exited 128
[ja...@localhost ~]$ echo $?
128
[ja...@localhost ~]$
Actual result:
--
[ja...@localhost ~]$ php test.php
CHILD: Exiting with exit code 128
PARENT: 7598/7598 exited 32768
[ja...@localhost ~]$ echo $?
128
[ja...@localhost ~]$
--
Edit this bug report at http://bugs.php.net/?id=47566edit=1
#47568 [NEW]: autoload function with namespace aliasing
From: ice dot wynn at gmail dot com
Operating system: windows vista
PHP version: 5.3CVS-2009-03-05 (snap)
PHP Bug Type: Scripting Engine problem
Bug description: autoload function with namespace aliasing
Description:
The parameter of __autoload() is wrong when using a variable to
instantiate a namespaced class with aliasing namespace.
Reproduce code:
---
?php
//file 1
function __autoload($className){
var_dump($className);
//require($className.'.php');
exit;
}
use Foo as Bar;
new Bar\SomeClass;
?
?php
//file 2
function __autoload($className){
var_dump($className);
//require($className.'.php');
exit;
}
use Foo as Bar;
$class = 'Bar\SomeClass';
new $class;
?
Expected result:
file 1:
string(13) Foo\SomeClass
file 2:
string(13) Foo\SomeClass
Actual result:
--
file 1:
string(13) Foo\SomeClass
file 2:
string(13) Bar\SomeClass
--
Edit bug report at http://bugs.php.net/?id=47568edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47568r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47568r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47568r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47568r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47568r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47568r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47568r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47568r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47568r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47568r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47568r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47568r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47568r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47568r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47568r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47568r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47568r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47568r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47568r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47568r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47568r=mysqlcfg
