[PHP-BUG] Bug #51857 [NEW]: deleteName() for directories returns True on non-success
From:
Operating system: Linux 2.6.27
PHP version: 5.2.13
Package: Zip Related
Bug Type: Bug
Bug description:deleteName() for directories returns True on non-success
Description:
When trying to delete a non-empty directory in a ZIP file with deleteName()
the function will return True and not delete the directory if it is not
empty. Expectation would be to return False if the directory can not be
deleted.
Also the directory handling should be better documentated (usage of
trailing slashes, examples).
Test script:
---
$zip = new ZipArchive;
if( $zip->open('archive.zip', ZipArchive::CREATE) ) {
$zip->addEmptyDir('folder');
$zip->addFile('folder/file.txt');
if( ! $zip->deleteName('folder/') ) {
echo 'Should end up here if folder not deletable';
}
}
$zip->close();
Expected result:
Should echo.
Actual result:
--
Will not echo.
--
Edit bug report at http://bugs.php.net/bug.php?id=51857&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51857&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51857&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51857&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51857&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51857&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51857&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51857&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51857&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51857&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51857&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51857&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51857&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51857&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51857&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51857&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51857&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51857&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51857&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51857&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51857&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51857&r=mysqlcfg
Bug #51763 [Asn]: SplFileInfo::getType()
Edit report at http://bugs.php.net/bug.php?id=51763&edit=1 ID: 51763 Updated by: paj...@php.net Reported by: v-sumada at microsoft dot com Summary: SplFileInfo::getType() Status: Assigned Type: Bug Package: SPL related Operating System: All windows OS PHP Version: 5.3.2 Assigned To: pajoye New Comment: The problem is the same than ::isLink. It calls realpath which will resolve the link before calling the stat function. Previous Comments: [2010-05-19 07:14:15] ka...@php.net As noted, the issue here is within php_stat() and its way to detect links. php_stat() uses the S_ISLNK() macro to check if the stat.st_mode have the bits for a like, as on Unix. What we probably need to do is to use GetFileAttributes() and check for: FILE_ATTRIBUTE_REPARSE_POINT. After some further debugging it seems that the php_stream_stat_path_ex() function makes the fail. I only tried with symbolic-linked directories, but I would assume the cause would be the same on files. Which brings us to the point where the bug must be located within the url_stat function within the fopen() wrapper. [2010-05-08 05:07:06] cataphr...@php.net The comment should read "information is NOT conveyed in the stat structure". [2010-05-08 05:05:38] cataphr...@php.net This is unrelated to Spl. is_link/etc. are all also windows symbolic link agnostic. The problem here is that this information is conveyed in the stat structure. Strictly speaking, the return of getType is not completely incorrect -- the file type _S_IFREG and symbolic links are in fact files or (empty) directories with reparse point data. Maybe the best thing to do would be to change the stat function returned on windows so that the file type is replaced with _S_IFLNK when the directory is a junction/symlink or the file is a symlink. [2010-05-07 03:36:11] v-sumada at microsoft dot com Description: The SplFileInfo::getType() For Symbolic link returns "dir" which in turn should return "link" .This happens to be in 5.3.2 and occurs on all windows OS. It Correctly returns the type of file referenced which is for Dir and File . getType()); ?> Expected result :string(4)"Link" Actual result : string(3) "dir" Test script: --- getType()); ?> Expected result: string(4)"Link" Actual result: -- string(3) "dir" -- Edit this bug report at http://bugs.php.net/bug.php?id=51763&edit=1
Bug #47854 [Ver->Csd]: explode() misbehaves with very large negative limit
Edit report at http://bugs.php.net/bug.php?id=47854&edit=1
ID: 47854
Updated by: m...@php.net
Reported by: disas at mail dot ru
Summary: explode() misbehaves with very large negative limit
-Status: Verified
+Status: Closed
Type: Bug
Package: Strings related
Operating System: *
PHP Version: 5.*, 6CVS (2009-04-01)
-Assigned To:
+Assigned To: mike
New Comment:
Closed then, eh?
Previous Comments:
[2009-04-15 15:05:20] matt...@php.net
Jani, as you can tell from my explanation, -1e99 becomes 0 with 5.2, but
LONG_MIN with 5.3/6. In the explode() function, there is/was a int/long
mismatch, so overflow issues on 64-bit, causing an unexpected value of
"limit" in php_explode_negative_limit() and, I'm guessing, an invalid
read of "positions" there.
I fixed the long/int mismatch in 5.3/6 a couple weeks ago, so I assume
the strange results are gone? BTW, since 5.2 isn't using long where
needed, you should be able to break it (on 64-bit) by passing
-PHP_INT_MAX - 1 instead of -1e99.
[2009-04-15 15:02:08] matt...@php.net
What's happening with -1e9 is that it's small enough to fit in the range
of an integer (which explode()'s limit parameter expects). (Other larger
numbers that aren't in the integer range may or may not behave as
expected -- if there's integer overflow/"wraparound", with -3e9 for
example, negative may become positive, or vice versa, giving different
behavior than the sign of limit would suggest.)
However, when you give a much larger number like -1e99 and it gets cast
to an integer, it actually just becomes 0 which explains the behavior
you're seeing.
Additional info that the bug reporter can ignore if they want:
That explanation applies to PHP 5.2 and prior. But in 5.3 as of right
now, on *most* platforms (except Win64), *most* numbers out of integer
range (except between 2^31 and 2^32-1 on 32-bit platforms) have a "hard
limit" applied that keeps them at the negative/positive integer limit,
so no matter how large of a number you pass to explode(), even infinity,
it ends up being the integer limit (with same sign). Like I said, this
varies by platform, but that's the general behavior in 5.3 right now.
Overall, 5.3's conversion of large floats is currently inconsistent,
flawed, and changes prior behavior that's been around for years, which
is why I'm trying to get it sorted out. Now in cases like this, with
function parameters like a "limit," the new behavior makes sense (which
only happens in *most* cases, thanks to platform inconsistencies).
But wait, it gets better: Don't pass the parameter as a number, but as a
string, e.g. '-1e99', and you'll probably get a different result still!
Again, depending on platform -- absolute difference between platforms
and/or relative difference compared to a non-string version.
What a mess... And this applies to basically every function in 5.3 that
takes an integer parameter. My proposed changes take care of these
things and allow functions, like explode(), to use a new integer
conversion specifier, where desired, to limit a parameter to the range
of an integer *consistently*. Functions that aren't updated would simply
behave like 5.2 and prior.
[2009-04-01 11:00:26] j...@php.net
Very strange results with HEAD/PHP_5_3 too:
# build/php_6/sapi/cli/php -n -dmemory_limit=2G -r
'var_dump(explode(" "," 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ",
-1e99));'
Fatal error: Allowed memory size of 2147483648 bytes exhausted (tried
to allocate 18446744073383068122 bytes) in Command line code on line
1
# build/php_5_3/sapi/cli/php -n -dmemory_limit=2G -r
'var_dump(explode(" "," 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ",
-1e99));'
Fatal error: Allowed memory size of 2147483648 bytes exhausted (tried
to allocate 3792765909 bytes) in Command line code on line 1
# build/php_5_2/sapi/cli/php -n -dmemory_limit=2G -r
'var_dump(explode(" "," 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ",
-1e99));'
array(1) {
[0]=>
string(43) " 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 "
}
[2009-03-31 19:15:47] disas at mail dot ru
Description:
Bug on result where negative or positive number of limit is very high.
Reproduce code:
---
#Code:
var_export(
explode(" "," 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ", -1e99)
);
#Result:
array (
0 => ' 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ',
);
#Code:
var_export(
explode(" "," 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ", -1e9)
);
#Result:
array (
)
Expected result:
array (
0 => ' 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 1
Bug #51184 [Com]: DateInterval has incorrect days property on windows
Edit report at http://bugs.php.net/bug.php?id=51184&edit=1
ID: 51184
Comment by: pluk77 at gmail dot com
Reported by: s...@php.net
Summary: DateInterval has incorrect days property on windows
Status: Feedback
Type: Bug
Package: Date/time related
Operating System: Windows
PHP Version: 5.3.2RC3
New Comment:
There seems to be no windows snapshot available so unable to test if the
bugfix solved this problem as well.
Previous Comments:
[2010-03-25 13:26:21] ka...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Derick fixed #49778, did that fix the issue?
[2010-03-02 13:41:41] s...@php.net
Description:
On Windows, no matter what the dates are, the "days" property of the
DateInterval object returned by DateTime::diff() is always 6015.
Might be related to http://bugs.php.net/bug.php?id=49778 and
http://bugs.php.net/bug.php?id=49081
Test script:
---
$start = new DateTime('2010-06-06');
$end = new DateTime('2011-02-04');
echo $start->diff($end)->days;
$start = new DateTime('2005-01-01');
echo $start->diff($end)->days;
Expected result:
The right number of days, or at least always 42 :)
Actual result:
--
6015, always.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51184&edit=1
Bug #51184 [Fbk]: DateInterval has incorrect days property on windows
Edit report at http://bugs.php.net/bug.php?id=51184&edit=1
ID: 51184
Updated by: paj...@php.net
Reported by: s...@php.net
Summary: DateInterval has incorrect days property on windows
Status: Feedback
Type: Bug
Package: Date/time related
Operating System: Windows
PHP Version: 5.3.2RC3
New Comment:
It has been released, so try 5.3.2
Previous Comments:
[2010-05-19 11:38:49] pluk77 at gmail dot com
There seems to be no windows snapshot available so unable to test if the
bugfix solved this problem as well.
[2010-03-25 13:26:21] ka...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Derick fixed #49778, did that fix the issue?
[2010-03-02 13:41:41] s...@php.net
Description:
On Windows, no matter what the dates are, the "days" property of the
DateInterval object returned by DateTime::diff() is always 6015.
Might be related to http://bugs.php.net/bug.php?id=49778 and
http://bugs.php.net/bug.php?id=49081
Test script:
---
$start = new DateTime('2010-06-06');
$end = new DateTime('2011-02-04');
echo $start->diff($end)->days;
$start = new DateTime('2005-01-01');
echo $start->diff($end)->days;
Expected result:
The right number of days, or at least always 42 :)
Actual result:
--
6015, always.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51184&edit=1
Bug #51184 [Fbk->Csd]: DateInterval has incorrect days property on windows
Edit report at http://bugs.php.net/bug.php?id=51184&edit=1
ID: 51184
Updated by: s...@php.net
Reported by: s...@php.net
Summary: DateInterval has incorrect days property on windows
-Status: Feedback
+Status: Closed
Type: Bug
Package: Date/time related
Operating System: Windows
PHP Version: 5.3.2RC3
-Assigned To:
+Assigned To: seld
New Comment:
Confirmed working here. Kalle's comment came after 5.3.2 and I thought
the commit was younger too, but it seems good in 5.3.2 indeed.
Previous Comments:
[2010-05-19 11:43:47] paj...@php.net
It has been released, so try 5.3.2
[2010-05-19 11:38:49] pluk77 at gmail dot com
There seems to be no windows snapshot available so unable to test if the
bugfix solved this problem as well.
[2010-03-25 13:26:21] ka...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Derick fixed #49778, did that fix the issue?
[2010-03-02 13:41:41] s...@php.net
Description:
On Windows, no matter what the dates are, the "days" property of the
DateInterval object returned by DateTime::diff() is always 6015.
Might be related to http://bugs.php.net/bug.php?id=49778 and
http://bugs.php.net/bug.php?id=49081
Test script:
---
$start = new DateTime('2010-06-06');
$end = new DateTime('2011-02-04');
echo $start->diff($end)->days;
$start = new DateTime('2005-01-01');
echo $start->diff($end)->days;
Expected result:
The right number of days, or at least always 42 :)
Actual result:
--
6015, always.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51184&edit=1
Req #47780 [Com]: [FR] dns_get_record: possibility to specify nameserver that should be queried
Edit report at http://bugs.php.net/bug.php?id=47780&edit=1 ID: 47780 Comment by: bantu at phpbb dot com Reported by: valli at icsurselva dot ch Summary: [FR] dns_get_record: possibility to specify nameserver that should be queried Status: Assigned Type: Feature/Change Request Package: *Network Functions Operating System: * PHP Version: * Assigned To: pajoye New Comment: Duplicates #39671 IMO Previous Comments: [2009-03-25 22:38:27] paj...@php.net I was about to enable this feature on windows but it would have introduced some portability issues again. But I think it would be useful. I have a patch for windows to allow that, porting it to the other platforms. [2009-03-25 22:34:17] valli at icsurselva dot ch Description: Feature request for the dns_get_record function: It would be nice to specify an array of nameserver IP addresses that should be queried. Like in PEAR::Net_DNS (Net_DNS_Resolver::query()). See $nameservers array in: http://pear.php.net/manual/en/package.networking.net-dns.net-dns-resolver.query.php Only with this feature would it be possible to implement something like this. http://centralops.net/asp/co/NsLookup.vbs.asp (Of course it would be possible with PEAR::Net_DNS) Reproduce code: --- n/a Expected result: n/a Actual result: -- n/a -- Edit this bug report at http://bugs.php.net/bug.php?id=47780&edit=1
Req #39671 [Opn->Bgs]: dns_get_record whould allow selecting dns to query
Edit report at http://bugs.php.net/bug.php?id=39671&edit=1 ID: 39671 Updated by: paj...@php.net Reported by: overflow at interlink dot es Summary: dns_get_record whould allow selecting dns to query -Status: Open +Status: Bogus Type: Feature/Change Request -Package: Feature/Change Request +Package: *General Issues Operating System: Linux 2.6 PHP Version: 5.2.0 New Comment: Duplicate of #47780, which is more detailed. Previous Comments: [2006-11-29 00:31:15] overflow at interlink dot es Description: I think it would be nice if dns_get_record allowed to select which dns server you want to query. I have searched within the documentation and haven't found it to be implemented or referenced. Plus, i don't think it would be a very hard to add feature. Thanks. -- Edit this bug report at http://bugs.php.net/bug.php?id=39671&edit=1
Bug #47842 [Opn->Csd]: sscanf() does not support 64-bit values
Edit report at http://bugs.php.net/bug.php?id=47842&edit=1 ID: 47842 Updated by: m...@php.net Reported by: signe at cothlamadh dot net Summary: sscanf() does not support 64-bit values -Status: Open +Status: Closed Type: Bug Package: Strings related Operating System: * (64bit) PHP Version: 5.2.9 -Assigned To: +Assigned To: mike 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. Previous Comments: [2010-05-19 13:28:12] m...@php.net Automatic comment from SVN on behalf of mike Revision: http://svn.php.net/viewvc/?view=revision&revision=299484 Log: * fixed bug #47842 sscanf() does not support 64-bit values [2009-03-30 22:09:53] signe at cothlamadh dot net Note: sscanf %x and %X have the same behavior as %d and %u [2009-03-30 21:26:23] signe at cothlamadh dot net Description: On 64-bit operating systems, printf()'s %d and %u formatting codes support 64-bit integers. sscanf, which supposedly uses the same code (and has the same expected behavior) does not support 64-bit values. Also, printf is not outputting accurate values when it reaches numbers near the upper bounds of a 64-bit int. Reproduce code: --- Expected result: sscanf 32-bit signed int '2147483647' (2^31)-1 = 2147483647 sscanf 32-bit unsign int '4294967295' (2^32)-1 = 4294967295 sscanf 64-bit signed int '9223372036854775807' (2^63)-1 = 9223372036854775807 sscanf 64-bit unsign int '18446744073709551615' (2^64)-1 = 18446744073709551615 printf 64-bit signed int '9223372036854775807' (2^63)-1 = 9223372036854775807 printf 64-bit signed int '18446744073709551615' (2^64)-1 = 18446744073709551615 Actual result: -- sscanf 32-bit signed int '2147483647' (2^31)-1 = 2147483647 sscanf 32-bit unsign int '4294967295' (2^32)-1 = 4294967295 sscanf 64-bit signed int '9223372036854775807' (2^63)-1 = -1 sscanf 64-bit unsign int '18446744073709551615' (2^64)-1 = 4294967295 printf 64-bit signed int '9223372036854775807' (2^63)-1 = 9223372036854775807 printf 64-bit signed int '18446744073709551615' (2^64)-1 = 0 printf 64-bit signed int '18446744073609551615' ((2^64)-1 - 1) = 18446744073609551872 Output is 257 greater than input -- Edit this bug report at http://bugs.php.net/bug.php?id=47842&edit=1
Bug #51821 [Asn->Csd]: configure fails to pick up a custom prefix for libevent
Edit report at http://bugs.php.net/bug.php?id=51821&edit=1
ID: 51821
Updated by: f...@php.net
Reported by: admin at saltwaterc dot net
Summary: configure fails to pick up a custom prefix for
libevent
-Status: Assigned
+Status: Closed
Type: Bug
Package: FPM related
Operating System: Linux
PHP Version: 5.3.2
Assigned To: fat
New Comment:
fixed in trunk (revision 299485)
Previous Comments:
[2010-05-19 13:29:33] f...@php.net
Automatic comment from SVN on behalf of fat
Revision: http://svn.php.net/viewvc/?view=revision&revision=299485
Log: - #51821, fix --with-libevent-dir (patch by tony2001)
[2010-05-14 14:34:40] admin at saltwaterc dot net
Description:
Using a custom prefix for the libevent installation
(/usr/local/libevent-1.4.13) doesn't get picked up by the configure
script, even though I properly used the --with-libevent-dir option.
Unless the prefix for the libevent installation is a path that ldconfig
knows about, the configure fails.
I could "fix" it with:
export LD_LIBRARY_PATH=/usr/local/libevent-$libevent_version/lib
within my build script which gives me the idea that the configure fails
to properly set its environment. Still an arcane method though.
Test script:
---
./configure [...] --enable-fpm --with-fpm-user=php-fpm
--with-fpm-group=php-fpm --with-libevent-dir=/usr/local/libevent-1.4.13
Expected result:
To run configure without errors.
Actual result:
--
./configure says:
checking for FPM build... yes
checking for libevent >= 1.4.11 install prefix...
/usr/local/libevent-1.4.13
no
configure: error: build test failed. Please check the config.log for
details.
config.log says:
configure:9409: checking for libevent >= 1.4.11 install prefix
configure:9524: gcc -o conftest -g -O2 -fvisibility=hidden
-I/usr/local/libevent-1.4.13/include -L/usr/local/libevent-1.4.13/lib
conftest.c -levent 1>&5
configure:9724: gcc -o conftest -g -O2 -fvisibility=hidden conftest.c
-L/usr/local/libevent-1.4.13/lib -levent 1>&5
configure: failed program was:
#line 9713 "configure"
#include "confdefs.h"
char event_init();
int main() {
event_init();
return 0;
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=51821&edit=1
Bug #48507 [Com]: fgetcsv() ignoring special characters
Edit report at http://bugs.php.net/bug.php?id=48507&edit=1
ID: 48507
Comment by: pahan at hubbitus dot spb dot su
Reported by: krynble at yahoo dot com dot br
Summary: fgetcsv() ignoring special characters
Status: Bogus
Type: Bug
Package: Filesystem function related
Operating System: Unix
PHP Version: 5.*
New Comment:
> Quote from the docs:
> Note: Locale setting is taken into account by this function. If LANG
is e.g.
> en_US.UTF-8, files in one-byte encoding are read wrong by this
function.
Ok, bug documented as "are read wrong by this function" is better then
nothing.
But do you plan fix this wrong behaviour?
Previous Comments:
[2010-05-18 11:03:42] m...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Quote from the docs:
Note: Locale setting is taken into account by this function. If LANG is
e.g. en_US.UTF-8, files in one-byte encoding are read wrong by this
function.
[2009-12-12 11:40:29] pahan at hubbitus dot spb dot su
Sorry for duplicate (#50456 is my), but in it, additionally to there
described problem in fgetcsv I also suggest fix fputcvs to allow [force]
enclosing single words in field.
Off course it does *not* solve this problem of incorrect fgetcsv
parsing, because RFC allow not quoted values (
http://www.faqs.org/rfcs/rfc4180.html , section 2.5 ), but, it is make
pair fputcsv/fgetcsv as minimum compatible in PHP implementation.
[2009-12-12 01:33:51] j...@php.net
See also bug #50456
[2009-09-22 15:09:20] phofstetter at sensational dot ch
below you'll find a small script which shows how to implement a user
filter that can be used to on-the-fly utf8-encode the data so that
fgetcsv is happy and returns correct output even if the first character
in a field has its high-bit set and is not valid utf-8:
Remember: This is a workaround and impacts performance. This is not a
valid fix for the bug.
I didn't yet have time to deeply look into the C implementation for
fgetcsv, but all these calls to php_mblen() feel suspicious to me.
I'll try and have a look into this later today, but for now, I'm just
glad I have this workaround (quickly hacked together - keep that in
mind):
is_utf8($bucket->data))
$bucket->data = utf8_encode($bucket->data);
$consumed += $bucket->datalen;
stream_bucket_append($out, $bucket);
}
return PSFS_PASS_ON;
}
}
/* Register our filter with PHP */
stream_filter_register("utf8encode", "utf8encode_filter")
or die("Failed to register filter");
$fp = fopen($_SERVER['argv'][1], "r");
/* Attach the registered filter to the stream just opened */
stream_filter_prepend($fp, "utf8encode");
while($data = fgetcsv($fp, 0, ';', '"'))
print_r($data);
fclose($fp);
[2009-09-22 14:45:22] phofstetter at sensational dot ch
I was looking into this (after having been bitten by it) and I can add
another tidbit that might help tracking this down:
The bug doesn't happen if the file fgetcsv() is reading is in
UTF-8-format.
I have created a test-file in ISO-8859-1 and then used
file_put_contents(utf8encode(file_get_contents())) to create the
UTF8-version of it (explaining this here because I'm not sure whether
this would write a BOM or not - probably not though).
That version could be read correctly.
I'm now writing a stream filter that does the UTF-8 conversion on the
fly to hook that in between the file and fgetcsv() - while I would lose
a bit of performance, in my case, this is the cleanest workaround.
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=48507
--
Edit this bug report at http://bugs.php.net/bug.php?id=48507&edit=1
Bug #45132 [Asn->Tbd]: escapeshellcmd removes swedish characters
Edit report at http://bugs.php.net/bug.php?id=45132&edit=1
ID: 45132
Updated by: m...@php.net
Reported by: tom at collegit dot se
Summary: escapeshellcmd removes swedish characters
-Status: Assigned
+Status: To be documented
Type: Bug
Package: Strings related
Operating System: *
PHP Version: 5.*, 6CVS (2009-05-05)
-Assigned To: iliaa
+Assigned To:
New Comment:
Works here, but needs to be documented that escapeshell*() functions are
locale dependent.
Previous Comments:
[2009-05-07 13:52:06] j...@php.net
See also bug #44564 (and can still verify using latest CVS)
[2008-08-07 06:23:19] tstarling at wikimedia dot org
The issue is that previously 8-bit clean locales, like "C", are now
being validated for whatever character set they supposedly are, with
characters above 127 being removed.
The suggested fix, here and on
https://bugzilla.wikimedia.org/show_bug.cgi?id=14944 , appears to reopen
whatever security vulnerability it was that the patch fixed in the first
place.
$ LANG=C php eval.php
> setlocale(LC_CTYPE, 'en_US.UTF-8')
> echo escapeshellarg("\xC3\x96")
'Ö'
> passthru('locale')
LANG=C
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=
Because the environment variable LC_CTYPE is not set by setlocale(), the
spawned shell sees the old character set, not the new one. So the shell
can be passed an argument escaped for the wrong character set,
potentially opening a vulnerability.
I'm assuming that the attack scenario for this vulnerability is where an
attacker can set environment variables such as LANG to a vulnerable
character set, before starting PHP. Because if an attacker can set
environment variables during execution of a script, the bug is not
fixed. But in that case you're probably screwed anyway.
[2008-05-29 23:09:34] fel...@php.net
Try using:
setlocale(LC_CTYPE, "UTF8", "en_US.UTF-8");
[2008-05-29 22:55:58] j...@php.net
Ilia, did that fix get into actual release..?
[2008-05-29 22:53:54] tom at collegit dot se
Description:
Since my web server got updated to 5.2.6 escapeshellcmd() has started
removing all Swedish characters from user input. Looks a lot like bug
#44564.
'./configure' '--with-apxs2=/usr/local/apache/bin/apxs' '--with-
mysql=/usr/local/mysql' '--enable-debug=no' '--enable-track-vars' '--
with-imap=/usr/local/imap' '--with-mcrypt' '--with-mhash' '--with-dom'
'--with-gd' '--with-jpeg-dir' '--enable-ftp' '--with-freetype-
dir=/usr' '--with-zlib-dir=/usr' '--with-png-dir=/usr' '--enable-
dbase' '--with-gettext' '--with-zlib' '--enable-inline-optimization'
'--with-openssl' '--with-curl' '--with-curlwrappers' '--enable-exif'
'--with-imap-ssl' '--enable-bcmath' '--enable-mbstring' '--enable-
wddx' '--with-xsl' '--with-pdo-mysql=/usr/local/mysql' '--with-
mysqli=/usr/local/mysql/bin/mysql_config' '--enable-soap' '--enable-
sockets' '--with-mssql' '--with-ming' '--with-pspell' '--enable-
calendar' '--enable-bcmath' '--with-t1lib' '--with-
pgsql=/usr/local/pgsql' '--with-tidy' '--enable-zip'
Reproduce code:
---
$test = "åäö";
$test = (escapeshellcmd($test));
print $test;
Expected result:
"åäö"
Actual result:
--
""
--
Edit this bug report at http://bugs.php.net/bug.php?id=45132&edit=1
Bug #51367 [Opn->Fbk]: flush() doesn't inform headers_sent()'s filename or linenumber values
Edit report at http://bugs.php.net/bug.php?id=51367&edit=1
ID: 51367
Updated by: m...@php.net
Reported by: lefevre dot 10 at osu dot edu
Summary: flush() doesn't inform headers_sent()'s filename or
linenumber values
-Status: Open
+Status: Feedback
Type:Bug
Package: Output Control
PHP Version: 5.2.13
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
headers_sent() after flush() returns FALSE for me.
Previous Comments:
[2010-03-23 18:46:36] lefevre dot 10 at osu dot edu
Change the '1 = 1' to '$a = 1' in test script ;)
[2010-03-23 18:43:25] lefevre dot 10 at osu dot edu
Description:
If flush() is called, a subsequent call to headers_sent() with $filename
and $linenumber specified does not bind the actual file name and line
number of the line where flush() appeared. Instead the values are empty
string and 0, respectively.
Test script:
---
";
}
echo "Some text here.";
if ( headers_sent( $file, $line) ) {
echo "Headers sent at $file: $line";
}
Expected result:
Headers sent at '/var/www/flush_test.php', line 5.
Some text here.
Headers sent at '/var/www/flush_test.php', line 8.
Actual result:
--
Headers sent at '', line 0.
Some text here.
Headers sent at '/var/www/flush_test.php', line 8.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51367&edit=1
Bug #51304 [Opn->Fbk]: php://stderr stream logs to global apache log file instead of virtual host file
Edit report at http://bugs.php.net/bug.php?id=51304&edit=1
ID: 51304
Updated by: m...@php.net
Reported by: houdelou at hotmail dot com
Summary: php://stderr stream logs to global apache log file
instead of virtual host file
-Status: Open
+Status: Feedback
Type: Bug
Package: Output Control
Operating System: Ubuntu Server 9.04
PHP Version: Irrelevant
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2010-03-15 22:24:56] houdelou at hotmail dot com
Description:
PHP 5.2.6-3ubuntu4.5 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 6
2010 22:25:33)
/* This logs to global apache error_log file. */
$log = fopen("php://stderr", "a");
fwrite($log, "test message");
fclose($log);
/* This logs to virtual host error_log file */
trigger_error("test message");
php.ini settings :
log_errors = On
No value for error_log. It is commented out.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51304&edit=1
Bug #50750 [Opn]: stream_register_wrapper and imagejpeg
Edit report at http://bugs.php.net/bug.php?id=50750&edit=1
ID: 50750
Updated by: m...@php.net
Reported by: lgynove at 163 dot com
Summary: stream_register_wrapper and imagejpeg
Status: Open
Type: Bug
-Package: Systems problem
+Package: GD related
Operating System: windows xp
PHP Version: 5.2.12
New Comment:
Reclassified.
Previous Comments:
[2010-01-14 14:23:32] lgynove at 163 dot com
Description:
imagejpeg function not work in stream_register_wrapper.
Reproduce code:
---
class dbStream{...}
stream_register_wrapper("mysql123", "dbStream") or die("Failed to
register protocol");
$im = imagecreatetruecolor(120, 20);
$text_color = imagecolorallocate($im, 233, 14, 91);
imagestring($im, 1, 5, 5, 'A Simple Text String', $text_color);
imagejpeg($im, 'mysql123://simpletext.jpg');
imagedestroy($im);
Expected result:
no error.
Actual result:
--
Warning: imagejpeg(): Unable to open 'mysql123://simpletext.jpg' for
writing: Invalid argument.
--
Edit this bug report at http://bugs.php.net/bug.php?id=50750&edit=1
Bug #50750 [Opn->Bgs]: stream_register_wrapper and imagejpeg
Edit report at http://bugs.php.net/bug.php?id=50750&edit=1
ID: 50750
Updated by: m...@php.net
Reported by: lgynove at 163 dot com
Summary: stream_register_wrapper and imagejpeg
-Status: Open
+Status: Bogus
Type: Bug
Package: GD related
Operating System: windows xp
PHP Version: 5.2.12
New Comment:
Image functions (GD) do not use php streams.
Previous Comments:
[2010-05-19 14:50:12] m...@php.net
Reclassified.
[2010-01-14 14:23:32] lgynove at 163 dot com
Description:
imagejpeg function not work in stream_register_wrapper.
Reproduce code:
---
class dbStream{...}
stream_register_wrapper("mysql123", "dbStream") or die("Failed to
register protocol");
$im = imagecreatetruecolor(120, 20);
$text_color = imagecolorallocate($im, 233, 14, 91);
imagestring($im, 1, 5, 5, 'A Simple Text String', $text_color);
imagejpeg($im, 'mysql123://simpletext.jpg');
imagedestroy($im);
Expected result:
no error.
Actual result:
--
Warning: imagejpeg(): Unable to open 'mysql123://simpletext.jpg' for
writing: Invalid argument.
--
Edit this bug report at http://bugs.php.net/bug.php?id=50750&edit=1
Bug #51470 [Opn->Fbk]: Files on NTFS Mounted Volumes inaccessible
Edit report at http://bugs.php.net/bug.php?id=51470&edit=1 ID: 51470 Updated by: m...@php.net Reported by: benjamin at gnbit dot com Summary: Files on NTFS Mounted Volumes inaccessible -Status: Open +Status: Feedback Type: Bug -Package: Systems problem +Package: Filesystem function related Operating System: Linux PHP Version: 5.3.2 New Comment: Recalssified. Is Initializer.php within your include_path? Previous Comments: [2010-04-04 17:48:31] benjamin at gnbit dot com absolute paths work, but relative paths do not work [2010-04-04 07:33:00] benjamin at gnbit dot com Description: Description: Server Web: Linux Fedora 12 Partition: ext4 Apache 2.0 PHP 5.3.2 Server File: Windows Server 2008 Partition: Ntfs mount windows files in linux using Samba, example: mount -t cifs -o username=linux,password=###,rw,exec,dev,ntfs,iocharset=utf8,dir_mode=0777,file_m ode=0777 //192.168.1.70/files /var/www/html/winsamba/ include, reqire and include_path files the seem inaccessible to PHP 5.3.2 (5.2.x version do not show this problem) Test script: --- require_once "Initializer.php"; Expected result: including Actual result: -- Warning: require_once(Initializer.php) [function.require-once]: failed to open stream: No such file or directory in /var/www/html/winsamba/files/bootstrap.php on line 47 Fatal error: require_once() [function.require]: Failed opening required 'Initializer.php' in /var/www/html/winsamba/files/bootstrap.php on line 47 -- Edit this bug report at http://bugs.php.net/bug.php?id=51470&edit=1
Bug #51845 [Opn->Fbk]: preg_replace_callback anonymous function issue
Edit report at http://bugs.php.net/bug.php?id=51845&edit=1
ID: 51845
Updated by: m...@php.net
Reported by: jerry at jmweb dot net
Summary: preg_replace_callback anonymous function issue
-Status: Open
+Status: Feedback
Type: Bug
Package: Unknown/Other Function
Operating System: Linux
PHP Version: 5.3.2
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Works here.
Previous Comments:
[2010-05-17 18:30:10] jerry at jmweb dot net
Description:
Using an anonymous function as argument #2 in preg_replace_callback
issues the following warning:
preg_replace_callback() [function.preg-replace-callback]: Requires
argument 2, '', to be a valid callback
This warning was not thrown previously using PHP 5.3.1
Test script:
---
echo preg_replace_callback('~-([a-z])~', function ($match) {
return strtoupper($match[1]);
}, 'hello-world');
Expected result:
helloworld
Actual result:
--
hello-world + warning
--
Edit this bug report at http://bugs.php.net/bug.php?id=51845&edit=1
Bug #51184 [Com]: DateInterval has incorrect days property on windows
Edit report at http://bugs.php.net/bug.php?id=51184&edit=1
ID: 51184
Comment by: pluk77 at gmail dot com
Reported by: s...@php.net
Summary: DateInterval has incorrect days property on windows
Status: Closed
Type: Bug
Package: Date/time related
Operating System: Windows
PHP Version: 5.3.2RC3
Assigned To: seld
New Comment:
I am using this version:
PHP5.3.2 VC6 x86 Thread Safe (2010-Mar-04 20:11:08)
and the bug still shows.
Can anybody else confirm this bug is still open?
Previous Comments:
[2010-05-19 11:54:18] s...@php.net
Confirmed working here. Kalle's comment came after 5.3.2 and I thought
the commit was younger too, but it seems good in 5.3.2 indeed.
[2010-05-19 11:43:47] paj...@php.net
It has been released, so try 5.3.2
[2010-05-19 11:38:49] pluk77 at gmail dot com
There seems to be no windows snapshot available so unable to test if the
bugfix solved this problem as well.
[2010-03-25 13:26:21] ka...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Derick fixed #49778, did that fix the issue?
[2010-03-02 13:41:41] s...@php.net
Description:
On Windows, no matter what the dates are, the "days" property of the
DateInterval object returned by DateTime::diff() is always 6015.
Might be related to http://bugs.php.net/bug.php?id=49778 and
http://bugs.php.net/bug.php?id=49081
Test script:
---
$start = new DateTime('2010-06-06');
$end = new DateTime('2011-02-04');
echo $start->diff($end)->days;
$start = new DateTime('2005-01-01');
echo $start->diff($end)->days;
Expected result:
The right number of days, or at least always 42 :)
Actual result:
--
6015, always.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51184&edit=1
Bug #51184 [Csd]: DateInterval has incorrect days property on windows
Edit report at http://bugs.php.net/bug.php?id=51184&edit=1 ID: 51184 Updated by: s...@php.net Reported by: s...@php.net Summary: DateInterval has incorrect days property on windows Status: Closed Type: Bug Package: Date/time related Operating System: Windows PHP Version: 5.3.2RC3 Assigned To: seld New Comment: Can you try with VC9? Works here on latest VC9 Non Thread Safe Previous Comments: [2010-05-19 15:20:33] pluk77 at gmail dot com I am using this version: PHP5.3.2 VC6 x86 Thread Safe (2010-Mar-04 20:11:08) and the bug still shows. Can anybody else confirm this bug is still open? [2010-05-19 11:54:18] s...@php.net Confirmed working here. Kalle's comment came after 5.3.2 and I thought the commit was younger too, but it seems good in 5.3.2 indeed. [2010-05-19 11:43:47] paj...@php.net It has been released, so try 5.3.2 [2010-05-19 11:38:49] pluk77 at gmail dot com There seems to be no windows snapshot available so unable to test if the bugfix solved this problem as well. [2010-03-25 13:26:21] ka...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Derick fixed #49778, did that fix the issue? 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=51184 -- Edit this bug report at http://bugs.php.net/bug.php?id=51184&edit=1
Bug #51284 [Opn->Bgs]: foreach distroys objects in array
Edit report at http://bugs.php.net/bug.php?id=51284&edit=1
ID: 51284
Updated by: m...@php.net
Reported by: gerhard at tinned-software dot net
Summary: foreach distroys objects in array
-Status: Open
+Status: Bogus
Type: Bug
Package: Class/Object related
Operating System: MacOSX, Linux, ...
PHP Version: Irrelevant
New Comment:
I get a Warning: Parameter 2 to test_obj2::__construct() expected to be
a reference, value given in /tmp/phpbugs/51284.php on line 128
You lose the ref with func_get_args().
Previous Comments:
[2010-03-12 13:29:44] gerhard at tinned-software dot net
Description:
I have a script which tries to create configured objects of classes. The
method creating the object of the named class will generate a unique
identifier to be able to identify the invocation later in the class.
This
unique_id is basically calculated by adding the class name and all
constructor parameters into a ":"-seperetaed list. For doing this i used
This all functions well as long as there is not the following very
special
combination of parameters and class-parameterlist. If one of the
parameters
is an object, and this object is passed to the class as reference
(&$object).
In such a case, the foreach loop destroys somehow the $parameter array.
As
the $parameter array is not altered in the loop, there is no explanation
to
my way the loop influence the array.
To prove that the loop is causing this problem i changed the loop from
foreach() to for(). As you can see in the test script there are 2
methods in
the OM class. The get_object_OK() uses the for()-loop to generate the ID
and
the get_object_NOK() method uses the foreach()-loop to generate it.
With the for()-loop the script runs without any troubles. But with the
foreach()-loop the script returns an error while invocating the object.
This
error causes the object to be not created.
The error message which can be found in the webserver's / php's logfile
is
the following:
[error] [client 127.0.0.1] PHP Warning: Invocation of test_obj2's
constructor failed in /.../test.php on line 183, referer:
http://127.0.0.1:8080/
... The line references to "$obj =
$reflection_obj->newInstanceArgs($parameter);" at the get_object_NOK.()
function.
Test script:
---
class test_obj
{
var $test = "abc";
function __construct($str)
{
$this->test = $str;
}
function get()
{
echo get_class($this)." - string=".$this->test."\n";
}
function set($str)
{
$test = $str;
}
}
class test_obj2
{
var $test = "abc";
function __construct($string1, &$object)
{
echo get_class($this)." - string1=$string1\n";
$object->get();
}
}
//include_once(dirname(__FILE__).'/object_manager.class.php');
//include_once(dirname(__FILE__).'/element_container.class.php');
//
// Test execution
//
echo "PHP Version: ".phpversion()."\n";
$om = new OM();
$t1 = new test_obj("init-text-object-1");
$t1->get();
echo "Object of class 'Test_CLass' ... Finished.\n";
$t2 = $om->get_object_OK("test_obj2", "object-text-2", $t1);
echo "Object of class 'Test_CLass2' with for() loop ... Finished.\n";
$t2 = $om->get_object_NOK("test_obj2", "object-text-2", $t1);
echo "Object of class 'Test_CLass2' with foreach() loop ... Finished.\n";
//
// A short testing code from a much biger function / Class to
// demonstrate the behaviour
//
class OM
{
function get_object_OK()
{
$parameter = func_get_args();
$type = array_shift($parameter);
//
// create unique identifier for this object creation.
// Used in the original class to identify the object later in
the class.
//
$unique_id = "$type:";
// loop through all parameters
for($i=0; $i < count($parameter); $i++)
{
// if parameter is an object, get only the object name
if(is_object($parameter[$i]) === TRUE)
{
$unique_id .= get_class($parameter[$i]).':';
continue;
}
// get the variable content as string to the
identifier-string
$unique_id .= gettype($parameter[$i]).':';
}
//
// Creating the object by name
//
$reflection_obj = new ReflectionClass($type);
$obj = $reflection_obj->newInstanceArgs($parameter);
// return the created object
return $obj;
}
function get_object_NOK()
{
$parameter = func_get_args();
$type = array_shift($parameter);
//
// create unique identifier for this object creation.
Bug #51268 [Opn->Bgs]: fsockopen+fread behaves differently with port 443 vs. port 80
Edit report at http://bugs.php.net/bug.php?id=51268&edit=1 ID: 51268 Updated by: m...@php.net Reported by: arlo at arlomedia dot com Summary: fsockopen+fread behaves differently with port 443 vs. port 80 -Status: Open +Status: Bogus Type: Bug Package: Network related Operating System: Red Hat Linux PHP Version: 5.2.13 New Comment: Quoting documentation: Warning When reading from anything that is not a regular local file, such as streams returned when reading remote files or from popen() and fsockopen(), reading will stop after a packet is available. This means that you should collect the data together in chunks as shown in the examples below. Previous Comments: [2010-03-11 01:49:48] arlo at arlomedia dot com Description: If I open a network connection with fsockopen on port 80, then read the first chunk of the response with fread, I receive the response headers plus enough of the response body to fulfill the read length that I requested. However, if I do the same thing over port 443, I receive only the response headers in my initial fread command, regardless of their length. I don't receive any of the response body until I call fread again. The script below demonstrates this. If you run it as shown, you will see the header plus part of the body as response 1, and a continuation of the body as response 2. But if you change $connection_port to 443, you will see only the header as response 1, with the body starting at response 2. I repeated this issue on one server running PHP 5.2.13 and another running 5.3.0. Test script: --- \n".htmlentities($response_1); print "\n"; print "response 2:\n".htmlentities($response_2); ?> Expected result: I would expect fread to return the same results regardless of the port used for fsockopen. Actual result: -- The first instance of fread stops at the end of the headers when using port 443. -- Edit this bug report at http://bugs.php.net/bug.php?id=51268&edit=1
Bug #51184 [Com]: DateInterval has incorrect days property on windows
Edit report at http://bugs.php.net/bug.php?id=51184&edit=1 ID: 51184 Comment by: pluk77 at gmail dot com Reported by: s...@php.net Summary: DateInterval has incorrect days property on windows Status: Closed Type: Bug Package: Date/time related Operating System: Windows PHP Version: 5.3.2RC3 Assigned To: seld New Comment: Done so. Tested the VC6 and VC9 builds. The VC6 build still has this bug while the VC9 does not. Previous Comments: [2010-05-19 15:22:51] s...@php.net Can you try with VC9? Works here on latest VC9 Non Thread Safe [2010-05-19 15:20:33] pluk77 at gmail dot com I am using this version: PHP5.3.2 VC6 x86 Thread Safe (2010-Mar-04 20:11:08) and the bug still shows. Can anybody else confirm this bug is still open? [2010-05-19 11:54:18] s...@php.net Confirmed working here. Kalle's comment came after 5.3.2 and I thought the commit was younger too, but it seems good in 5.3.2 indeed. [2010-05-19 11:43:47] paj...@php.net It has been released, so try 5.3.2 [2010-05-19 11:38:49] pluk77 at gmail dot com There seems to be no windows snapshot available so unable to test if the bugfix solved this problem as well. 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=51184 -- Edit this bug report at http://bugs.php.net/bug.php?id=51184&edit=1
Bug #49617 [Ver->Fbk]: Problem with references
Edit report at http://bugs.php.net/bug.php?id=49617&edit=1
ID: 49617
Updated by: m...@php.net
Reported by: mstf at mstf dot name dot tr
Summary: Problem with references
-Status: Verified
+Status: Feedback
Type: Bug
Package: Reproducible crash
Operating System: *
PHP Version: 5.3, 6 (2009-09-22)
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2009-09-22 09:45:00] j...@php.net
# build/php_5_2/sapi/cli/php -n t.php
Fatal error: Cannot create references to/from string offsets nor
overloaded objects in /home/jani/src/t.php on line 8
# build/php_5_3/sapi/cli/php -n t.php
Segmentation fault
# build/php_6/sapi/cli/php -n t.php
Segmentation fault
[2009-09-22 09:30:11] sjo...@php.net
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x
0x00470df9 in ZEND_FETCH_DIM_W_SPEC_CV_CONST_HANDLER
(execute_data=0xb68040) at zend_vm_execute.h:23568
23568 Z_DELREF_PP(EX_T(opline->result.u.var).var.ptr_ptr);
(gdb) bt
#0 0x00470df9 in ZEND_FETCH_DIM_W_SPEC_CV_CONST_HANDLER
(execute_data=0xb68040) at zend_vm_execute.h:23568
#1 0x003ec80e in execute (op_array=0xa109f0) at zend_vm_execute.h:104
#2 0x003bd57a in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /Users/sjoerd/Sources/php-src-5.3/Zend/zend.c:1188
#3 0x0034193d in php_execute_script (primary_file=0xb7fc) at
/Users/sjoerd/Sources/php-src-5.3/main/main.c:2213
#4 0x0049650f in main (argc=4, argv=0xb8e8) at
/Users/sjoerd/Sources/php-src-5.3/sapi/cli/php_cli.c:1190
(gdb)
[2009-09-22 01:18:48] mstf at mstf dot name dot tr
Description:
Pointers problem.
Reproduce code:
---
$a = array('a' => array('b' => 'c'));
$b = &$a;
$b = &$b['a'];
$b = &$b['b'];
$b = &$b['c'];
echo $b;
Expected result:
NULL
Actual result:
--
Apache "Send Error Report"
Apache error.log:
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Child process is
running
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Acquired the start
mutex.
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Starting 150 worker
threads.
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Starting thread to
listen on port 80.
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Starting thread to
listen on port 443.
--
Edit this bug report at http://bugs.php.net/bug.php?id=49617&edit=1
Bug #51405 [Opn->Fbk]: segmentation fault at the "engine shutdown"
Edit report at http://bugs.php.net/bug.php?id=51405&edit=1 ID: 51405 Updated by: m...@php.net Reported by: miha dot vrhovnik at domenca dot com Summary: segmentation fault at the "engine shutdown" -Status: Open +Status: Feedback Type: Bug Package: Reproducible crash Operating System: Linux PHP Version: 5.3.2 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. No reproduce case, no chance to do anything, sorry. Previous Comments: [2010-03-27 19:46:56] miha dot vrhovnik at domenca dot com Just so there won't be any excuses that this is because I'm running under php-fpm Here is backtrace from apache2. a bit different configure -- removed fpm and added apache: ./configure '--with-apxs2=/usr/bin/apxs2' '--with-openssl' '--with-zlib' '--enable-bcmath' '--with-bz2' '--enable-calendar' '--with-curl' '--enable-exif' '--enable-ftp' '--with-gd' '--with-imap' '--with-imap-ssl' '--enable-mbstring' '--with-mcrypt' '--enable-pcntl' '--with-pdo-mysql' '--with-pdo-pgsql' '--with-pgsql' '--with-readline' '--with-mysql' '--enable-soap' '--enable-sockets' '--enable-sqlite-utf8' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--with-tidy' '--enable-wddx' '--with-xmlrpc' '--with-xsl' '--enable-zip' '--with-kerberos' '--with-mysqli' '--with-config-file-path=/usr/local/etc' '--with-config-file-scan-dir=/usr/local/etc/php.d' '--with-pear' '--with-jpeg-dir=/usr/lib' --with-freetype-dir=/usr/lib and now the actual backtrace (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. _zend_mm_free_int (heap=0xb979d180, p=0xb9946290) at /projects/php53/php-fpm-5.3.2/Zend/zend_alloc.c:2018 2018/projects/php53/php-fpm-5.3.2/Zend/zend_alloc.c: No such file or directory. in /projects/php53/php-fpm-5.3.2/Zend/zend_alloc.c (gdb) bt #0 _zend_mm_free_int (heap=0xb979d180, p=0xb9946290) at /projects/php53/php-fpm-5.3.2/Zend/zend_alloc.c:2018 #1 0xb6ff2498 in zend_hash_destroy (ht=0xba189ca0) at /projects/php53/php-fpm-5.3.2/Zend/zend_hash.c:526 #2 0xb7003fc3 in zend_object_std_dtor (object=0xba193830) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects.c:45 #3 0xb7003ff2 in zend_objects_free_object_storage (object=0xba193830) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects.c:114 #4 0xb70075fc in zend_objects_store_del_ref_by_handle_ex (handle=127, handlers=0xb74c65c0) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects_API.c:220 #5 0xb700762f in zend_objects_store_del_ref (zobject=0xba189ff0) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects_API.c:172 #6 0xb6fdbedf in _zval_dtor (zval_ptr=0xba1a6238) at /projects/php53/php-fpm-5.3.2/Zend/zend_variables.h:35 #7 _zval_ptr_dtor (zval_ptr=0xba1a6238) at /projects/php53/php-fpm-5.3.2/Zend/zend_execute_API.c:439 #8 0xb6ff2498 in zend_hash_destroy (ht=0xba19273c) at /projects/php53/php-fpm-5.3.2/Zend/zend_hash.c:526 #9 0xb6fe6945 in _zval_dtor_func (zvalue=0xba197ef4) at /projects/php53/php-fpm-5.3.2/Zend/zend_variables.c:43 #10 0xb6fdbedf in _zval_dtor (zval_ptr=0xba106080) at /projects/php53/php-fpm-5.3.2/Zend/zend_variables.h:35 ---Type to continue, or q to quit--- #11 _zval_ptr_dtor (zval_ptr=0xba106080) at /projects/php53/php-fpm-5.3.2/Zend/zend_execute_API.c:439 #12 0xb6ff2498 in zend_hash_destroy (ht=0xba12276c) at /projects/php53/php-fpm-5.3.2/Zend/zend_hash.c:526 #13 0xb7003fc3 in zend_object_std_dtor (object=0xb5e7013c) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects.c:45 #14 0xb7003ff2 in zend_objects_free_object_storage (object=0xb5e7013c) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects.c:114 #15 0xb70075fc in zend_objects_store_del_ref_by_handle_ex (handle=120, handlers=0xb74c65c0) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects_API.c:220 #16 0xb700762f in zend_objects_store_del_ref (zobject=0xba051424) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects_API.c:172 #17 0xb6fdbedf in _zval_dtor (zval_ptr=0xba1ac560) at /projects/php53/php-fpm-5.3.2/Zend/zend_variables.h:35 #18 _zval_ptr_dtor (zval_ptr=0xba1ac560) at /projects/php53/php-fpm-5.3.2/Zend/zend_execute_API.c:439 #19 0xb6ff2498 in zend_hash_destroy (ht=0xb9dbc140) at /projects/php53/php-fpm-5.3.2/Zend/zend_hash.c:526 #20 0xb6fe6945 in _zval_dtor_func (zvalue=0xb9d45c40) at /projects/php53/php-fpm-5.3.2/Zend/zend_v
Bug #48633 [Opn->Fbk]: str_pad() with giant lenth value and no memory limit infinite-loops or crashes
Edit report at http://bugs.php.net/bug.php?id=48633&edit=1 ID: 48633 Updated by: m...@php.net Reported by: gwy...@php.net Summary: str_pad() with giant lenth value and no memory limit infinite-loops or crashes -Status: Open +Status: Feedback Type: Bug Package: Reproducible crash Operating System: Darwin9 (MacOS X 10.5) PHP Version: 5.*, 6SVN (2009-07-25) New Comment: Doesn't do anything harmful for me. Previous Comments: [2009-07-18 01:41:59] gwy...@php.net Yes, it happens in all three branches. [2009-07-17 17:40:29] j...@php.net Does this happen with PHP_5_2 and/or HEAD? (if so, update the version properly) [2009-06-22 00:09:12] gwy...@php.net Description: Calling str_pad($anything, PHP_INT_MAX) causes one of four symptoms: 1) If memory_limit is set below 2GB, a fatal error is thrown saying the memory limit is exhausted with an attempt to allocate 2GB. This appears to be the expected result. 2) If memory_limit is set above 2GB, or is unset, PHP (in or out of GDB) enters a massive CPU-eating swap-file-smashing loop. 3) If PHP is being run under valgrind, PHP exits quickly with a memory allocation failure because valgrind's malloc() replacement refuses the "nonsense" allocation request. 4) If PHP is being run under valgrind *and* run-tests.php, PHP crashes with a NULL pointer reference. This is caused by two problems in the str_pad code: 1) The value of num_pad_chars is not bounds-checked in ext/standard/string.c:4830 2) The return value of emalloc() is not checked for NULL on the same line. Reproduce code: --- 1) $ sapi/cli/php ext/standard/tests/string/str_pad_variation5.phpt 2) $ sapi/cli/php -dmemory_limit=1 ext/standard/tests/string/str_pad_variation5.phpt 3) $ valgrind sapi/cli/php -dmemory_limit=1 ext/standard/tests/string/str_pad_variation5.phpt 4) $ PHP_TEST_EXECUTABLE=`pwd`/sapi/cli/php sapi/cli/php run-tests.php -m ext/standard/tests/string/str_pad_variation5.phpt Expected result: In all cases, str_pad() should recognize that its argument is ridiculous and return without trying to make the allocation. Actual result: -- 1) *** Testing str_pad() function: with large value for for 'pad_length' argument *** Fatal error: Allowed memory size of 134217728 bytes exhausted at ext/standard/string.c:4830 (tried to allocate 2147483648 bytes) in ext/standard/tests/strings/str_pad_variation5.phpt on line 25 2) PHP starts running at 100% CPU and eating huge amounts of swap space. 3) *** Testing str_pad() function: with large value for for 'pad_length' argument *** ==31081== Warning: silly arg (-2147221504) to malloc() Fatal error: Out of memory (allocated 524288) at ext/standard/string.c:4830 (tried to allocate 2147483648 bytes) in ext/standard/tests/strings/str_pad_variation5.phpt on line 25 4) ==31145== Warning: silly arg (-2147483648) to malloc() ==31145== Invalid write of size 1 ==31145==at 0x823B13: memcpy (mc_replace_strmem.c:482) ==31145==by 0x2B3F92: zif_str_pad (string.c:4855) ==31145==by 0x3E2D98: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:313) ==31145==by 0x3E9151: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1601) ==31145==by 0x3E1B59: execute (zend_vm_execute.h:104) ==31145==by 0x3AE947: zend_execute_scripts (zend.c:1188) ==31145==by 0x31E6CC: php_execute_script (main.c:2196) ==31145==by 0x499E5F: main (php_cli.c:1188) ==31145== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==31145== ==31145== Process terminating with default action of signal 10 (SIGBUS) ==31145== Non-existent physical address at address 0x0 ==31145==at 0x823B13: memcpy (mc_replace_strmem.c:482) ==31145==by 0x2B3F92: zif_str_pad (string.c:4855) ==31145==by 0x3E2D98: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:313) ==31145==by 0x3E9151: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1601) ==31145==by 0x3E1B59: execute (zend_vm_execute.h:104) ==31145==by 0x3AE947: zend_execute_scripts (zend.c:1188) ==31145==by 0x31E6CC: php_execute_script (main.c:2196) ==31145==by 0x499E5F: main (php_cli.c:1188) -- Edit this bug report at http://bugs.php.net/bug.php?id=48633&edit=1
[PHP-BUG] Bug #51859 [NEW]: Redeclare extended class function causes segmentation error.
From:
Operating system: Linux Ubuntu
PHP version: 5.3.2
Package: Class/Object related
Bug Type: Bug
Bug description:Redeclare extended class function causes segmentation error.
Description:
I am using phpmailer with php 5.3.2. I also had a segmentation fault when
using drupal and gallery 2 but I havent got the debug output from that.
I have a class e.g.
class test extends PHPMailer {
.
function send() {
...
}
}
Now the PHPMailer class has a function $this->Send(). I know this is bad
practice and have now changed the test class function to send_email and the
problem is resolved. First off, should there be a problem as they are
different cases and I'm on linux. Second, if there is a conflict should we
not get an error like "PHP warning cannot redeclare function bla bla bla"
and not a segmentation fault?
I'm always up to learn so if this is something I could fix myself with some
guidance I am up for helping.
Thanks Tim
--
Edit bug report at http://bugs.php.net/bug.php?id=51859&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51859&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51859&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51859&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51859&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51859&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51859&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51859&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51859&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51859&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51859&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51859&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51859&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51859&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51859&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51859&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51859&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51859&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51859&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51859&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51859&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51859&r=mysqlcfg
Bug #49561 [Ver->Wfx]: mcrypt warns about having no IV in ECB mode
Edit report at http://bugs.php.net/bug.php?id=49561&edit=1
ID: 49561
Updated by: m...@php.net
Reported by: terrafr...@php.net
Summary: mcrypt warns about having no IV in ECB mode
-Status: Verified
+Status: Wont fix
Type: Bug
Package: mcrypt related
Operating System: *
PHP Version: 5.2.10
New Comment:
No upstream activity since years.
Previous Comments:
[2009-09-21 12:26:52] sjo...@php.net
Filed bug:
https://sourceforge.net/tracker/?func=detail&aid=2863450&group_id=87941&atid=584893
[2009-09-20 18:17:57] sjo...@php.net
I think this is a bug in mcrypt. The libmcrypt function
mcrypt_enc_get_iv_size returns 16 for ECB. The manual says: "If it is
0 then the IV is ignored in that algorithm," which implies that
mcrypt_enc_get_iv_size should return 0 when the mode is ECB.
C-code example:
#include "mcrypt.h"
#include
int main()
{
MCRYPT td = mcrypt_module_open(MCRYPT_RIJNDAEL_128, NULL, MCRYPT_ECB,
NULL);
printf("IV size for ECB: %d\n", mcrypt_enc_get_iv_size(td)); // prints
'16'
}
[2009-09-15 12:58:34] terrafr...@php.net
Description:
mcrypt complains about their being no IV even if ECB mode is being used.
Since ECB mode doesn't use IVs, it seems like no such warning should be
produced.
Bug #43143 is fairly similar to this one, except that that one produced
a slightly different error. Also, that one was closed on the basis that
it had been fixed.
Reproduce code:
---
Expected result:
I would expect that to just run its course and output nothing.
Actual result:
--
I get the following:
Warning: mcrypt_generic_init(): Iv size incorrect; supplied length: 0,
needed: 16 in C:\php\test.php on line 3
--
Edit this bug report at http://bugs.php.net/bug.php?id=49561&edit=1
Bug #51859 [Opn->Fbk]: Redeclare extended class function causes segmentation error.
Edit report at http://bugs.php.net/bug.php?id=51859&edit=1
ID: 51859
Updated by: m...@php.net
Reported by: timothybrew at googlemail dot com
Summary: Redeclare extended class function causes segmentation
error.
-Status: Open
+Status: Feedback
Type: Bug
Package: Class/Object related
Operating System: Linux Ubuntu
PHP Version: 5.3.2
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Previous Comments:
[2010-05-19 16:06:52] timothybrew at googlemail dot com
Description:
I am using phpmailer with php 5.3.2. I also had a segmentation fault
when using drupal and gallery 2 but I havent got the debug output from
that.
I have a class e.g.
class test extends PHPMailer {
.
function send() {
...
}
}
Now the PHPMailer class has a function $this->Send(). I know this is
bad practice and have now changed the test class function to send_email
and the problem is resolved. First off, should there be a problem as
they are different cases and I'm on linux. Second, if there is a
conflict should we not get an error like "PHP warning cannot redeclare
function bla bla bla" and not a segmentation fault?
I'm always up to learn so if this is something I could fix myself with
some guidance I am up for helping.
Thanks Tim
--
Edit this bug report at http://bugs.php.net/bug.php?id=51859&edit=1
Bug #51184 [Com]: DateInterval has incorrect days property on windows
Edit report at http://bugs.php.net/bug.php?id=51184&edit=1 ID: 51184 Comment by: s...@php.net Reported by: s...@php.net Summary: DateInterval has incorrect days property on windows Status: Closed Type: Bug Package: Date/time related Operating System: Windows PHP Version: 5.3.2RC3 Assigned To: seld New Comment: VC6 NTS fails as well here. VC9 NTS works. Previous Comments: [2010-05-19 15:45:07] pluk77 at gmail dot com Done so. Tested the VC6 and VC9 builds. The VC6 build still has this bug while the VC9 does not. [2010-05-19 15:22:51] s...@php.net Can you try with VC9? Works here on latest VC9 Non Thread Safe [2010-05-19 15:20:33] pluk77 at gmail dot com I am using this version: PHP5.3.2 VC6 x86 Thread Safe (2010-Mar-04 20:11:08) and the bug still shows. Can anybody else confirm this bug is still open? [2010-05-19 11:54:18] s...@php.net Confirmed working here. Kalle's comment came after 5.3.2 and I thought the commit was younger too, but it seems good in 5.3.2 indeed. [2010-05-19 11:43:47] paj...@php.net It has been released, so try 5.3.2 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=51184 -- Edit this bug report at http://bugs.php.net/bug.php?id=51184&edit=1
Bug #51184 [Csd->ReO]: DateInterval has incorrect days property on windows
Edit report at http://bugs.php.net/bug.php?id=51184&edit=1 ID: 51184 Updated by: s...@php.net Reported by: s...@php.net Summary: DateInterval has incorrect days property on windows -Status: Closed +Status: Re-Opened Type: Bug Package: Date/time related Operating System: Windows -PHP Version: 5.3.2RC3 +PHP Version: 5.3.2 -Assigned To: seld +Assigned To: pajoye Previous Comments: [2010-05-19 16:20:08] s...@php.net VC6 NTS fails as well here. VC9 NTS works. [2010-05-19 15:45:07] pluk77 at gmail dot com Done so. Tested the VC6 and VC9 builds. The VC6 build still has this bug while the VC9 does not. [2010-05-19 15:22:51] s...@php.net Can you try with VC9? Works here on latest VC9 Non Thread Safe [2010-05-19 15:20:33] pluk77 at gmail dot com I am using this version: PHP5.3.2 VC6 x86 Thread Safe (2010-Mar-04 20:11:08) and the bug still shows. Can anybody else confirm this bug is still open? [2010-05-19 11:54:18] s...@php.net Confirmed working here. Kalle's comment came after 5.3.2 and I thought the commit was younger too, but it seems good in 5.3.2 indeed. 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=51184 -- Edit this bug report at http://bugs.php.net/bug.php?id=51184&edit=1
Bug #49004 [Ver->Bgs]: HTTP 1.1 streams painfully slow
Edit report at http://bugs.php.net/bug.php?id=49004&edit=1
ID: 49004
Updated by: m...@php.net
Reported by: andreas dot streichardt at globalpark dot com
Summary: HTTP 1.1 streams painfully slow
-Status: Verified
+Status: Bogus
Type: Bug
Package: Streams related
Operating System: Linux
PHP Version: 5.*, 6CVS (2009-07-26)
New Comment:
Add "header" => array("Connection: close") to the context options.
Previous Comments:
[2009-07-21 15:08:26] andreas dot streichardt at globalpark dot com
Description:
Whenever i try to fetch a file from my server using http 1.1 PHP takes
multiple seconds to load the file. The server is fine. Firefox and curl
load it at no time.
i noticed the same behaviour under PHP 5.2.10 (code a bit different as
the stream_context_set_default is new. But the result is the same.
When i fetch a bigger file i see readfile() hanging somewhere at 90% of
the file but i guess depends on the file ;)
Reproduce code:
---
array(
'method'=>"GET",
"protocol_version"=>1.1,
)
);
$default = stream_context_set_default($default_opts);
$start=microtime(true);
readfile("http://minsk/~mop/x";);
var_dump(microtime(true)-$start);
Expected result:
Time needed should be <0.01s
Actual result:
--
m...@minsk:~$ time curl http://minsk/~mop/x
LINE 0:
real0m0.005s
user0m0.004s
sys 0m0.000s
m...@minsk:~$ php x.php
LINE 0:
float(6.0235359668732)
Size doesn't matter it seems. It always hangs!
Output of a manual session:
m...@minsk:~$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /~mop/x HTTP/1.1
Host: minsk
Connection: close
HTTP/1.1 200 OK
Connection: close
Content-Type: application/octet-stream
Accept-Ranges: bytes
Content-Length: 89
Date: Tue, 21 Jul 2009 15:01:37 GMT
Server: lighttpd/1.4.19
LINE 0:
Connection closed by foreign host.
nothing fancy there :S
--
Edit this bug report at http://bugs.php.net/bug.php?id=49004&edit=1
Bug #51268 [Bgs]: fsockopen+fread behaves differently with port 443 vs. port 80
Edit report at http://bugs.php.net/bug.php?id=51268&edit=1 ID: 51268 User updated by: arlo at arlomedia dot com Reported by: arlo at arlomedia dot com Summary: fsockopen+fread behaves differently with port 443 vs. port 80 Status: Bogus Type: Bug Package: Network related Operating System: Red Hat Linux PHP Version: 5.2.13 New Comment: This comment doesn't address my issue. The issue is that the function behaves differently depending on the port used for the remote connection. Over port 80, I requested 4096 bytes of data from fread and got 4096 bytes of data, but over port 443 I only got the headers. Why is this not consistent? The practical result is that I set up a utility using port 80 on a testing server, then when I tried to implement it on port 443 on a development server, I had to troubleshoot and then rework the code because of this undocumented difference. Previous Comments: [2010-05-19 15:36:37] m...@php.net Quoting documentation: Warning When reading from anything that is not a regular local file, such as streams returned when reading remote files or from popen() and fsockopen(), reading will stop after a packet is available. This means that you should collect the data together in chunks as shown in the examples below. [2010-03-11 01:49:48] arlo at arlomedia dot com Description: If I open a network connection with fsockopen on port 80, then read the first chunk of the response with fread, I receive the response headers plus enough of the response body to fulfill the read length that I requested. However, if I do the same thing over port 443, I receive only the response headers in my initial fread command, regardless of their length. I don't receive any of the response body until I call fread again. The script below demonstrates this. If you run it as shown, you will see the header plus part of the body as response 1, and a continuation of the body as response 2. But if you change $connection_port to 443, you will see only the header as response 1, with the body starting at response 2. I repeated this issue on one server running PHP 5.2.13 and another running 5.3.0. Test script: --- \n".htmlentities($response_1); print "\n"; print "response 2:\n".htmlentities($response_2); ?> Expected result: I would expect fread to return the same results regardless of the port used for fsockopen. Actual result: -- The first instance of fread stops at the end of the headers when using port 443. -- Edit this bug report at http://bugs.php.net/bug.php?id=51268&edit=1
[PHP-BUG] Bug #51860 [NEW]: Include fails with toplevel symlink to /
From: Operating system: PHP version: 5.3.2 Package: Reproducible crash Bug Type: Bug Bug description:Include fails with toplevel symlink to / Description: Tarball: http://stephan-suerken.de/tmp/php53include.tar.gz Hi, with a certain directory setup (symlink pointing to /, see file tree in php53include.tar.gz) plus script call syntax (see scripts "ok" and "fail" scripts in tarball), including a file meekly fails. I have not completely debugged it, but afaics "php_resolve_path" fails were it should not; I suspect some of the "canonize path" functions wrongly give an error here. Thanks, Stephan Test script: --- Steps to reproduce: 1. Download: http://stephan-suerken.de/tmp/php53include.tar.gz [as root] 2. cd / 3. tar xfz php53include.tar.gz 4. /phptest/fail Expected result: # manwe(CHROOT:sid-ui): /phptest # root? ./ok /phpinclude/inc123.php: OK, INCLUDED Actual result: -- # manwe(CHROOT:sid-ui): /phptest # root? ./fail PHP Warning: require(/phplink/phpinclude/inc123.php): failed to open stream: No such file or directory in /phptest/test.php on line 2 PHP Fatal error: require(): Failed opening required '/phplink/phpinclude/inc123.php' (include_path='.:/usr/share/php:/usr/share/pear') in /phptest/test.php on line 2 -- Edit bug report at http://bugs.php.net/bug.php?id=51860&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51860&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51860&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51860&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51860&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51860&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51860&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51860&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51860&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51860&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51860&r=support Expected behavior: http://bugs.php.net/fix.php?id=51860&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51860&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51860&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51860&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51860&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51860&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51860&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51860&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51860&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51860&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51860&r=mysqlcfg
Bug #51298 [Com]: Error when loading php5apache2_2.dll
Edit report at http://bugs.php.net/bug.php?id=51298&edit=1 ID: 51298 Comment by: williams at uncc dot edu Reported by: trotsky_icepick at hotmail dot com Summary: Error when loading php5apache2_2.dll Status: Assigned Type: Bug Package: Apache2 related Operating System: Windows Vista SP2 PHP Version: 5.3.2 Assigned To: pajoye New Comment: There is still a problem with the Windows PHP binaries. From 4/19 pajoye seems to believe it is a date bug to "fix as soon as possible". It has been a month! I have php-5.3.2-Win32-VC6-x86 and httpd-2.2.15-win32-x86-no_ssl installed. If I run phpinfo() (in web page) more than once (first run - get results, second or later runs within a few seconds - get crash) I get this error message: AppName httpd.exe AppVer 2.2.15.0 ModName php5ts.dll ModVer 5.3.2.0 offset 001d79b5 I have searched for other versions of php5ts.dll - none I have NOT mixed vc9 PHP with Apache PHP seems to run okay in command-line, ie I can run phpinfo() in cmd box with no problem. I If run as test web page I get the error. Here are php -m /php -m -n results: C:\>php -m [PHP Modules] bcmath calendar com_dotnet Core ctype date dom ereg filter ftp hash iconv json libxml mcrypt mhash mysqlnd odbc pcre PDO Phar Reflection session SimpleXML SPL standard tokenizer wddx xml xmlreader xmlwriter zip zlib [Zend Modules] C:\>php -m -n [PHP Modules] bcmath calendar com_dotnet Core ctype date dom ereg filter ftp hash iconv json libxml mcrypt mhash mysqlnd odbc pcre PDO Phar Reflection session SimpleXML SPL standard tokenizer wddx xml xmlreader xmlwriter zip zlib [Zend Modules] I have disabled all but core modules. Previous Comments: [2010-04-30 15:43:09] slowchaos at msn dot com Update I have Apached 2.2.15 and PHP 5.3.2 running just fine (WinXP system). I'm not sure of the difference in 5.2 and 5.3 - I'm not a nuts and bolts php guy - but all is now well in my world :) [2010-04-30 06:55:02] slowchaos at msn dot com Had this problem with Apache 2.2.15 and PHP 5.2.13. Tried rolling back to earlier versions of PHP - back to PHP 5.2.10. Same thing. Rolled back to Apache 2.2.14 - still same issue. My apache crashes when trying to enable mysqli or mysql extension. System path is correct. Libmysql is in appropriate place. Mcrypt also crashes the server as well as a few others. [2010-04-20 01:48:09] paj...@php.net It happens to be a date bug (thread safety issue). We are trying to get a fix as soon as possible. [2010-04-20 01:00:40] downtrade at gmail dot com After installing: httpd-2.2.15-win32-x86-no_ssl.msi php-5.3.2-Win32-VC6-x86.msi got this error when started Apache: >From Win XP Event Viewer: Faulting application iexplore.exe, version 8.0.6001.18702, faulting module mshtml.dll, version 8.0.6001.18904, fault address 0x00331b8a. Faulting application httpd.exe, version 2.2.15.0, faulting module php5ts.dll, version 5.3.2.0, fault address 0x000e6d2c. [2010-04-13 16:22:04] paj...@php.net No, we did not change options. Can you manage to get it with the zip as well? I can't. Or maybe a back trace would be helpful. 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=51298 -- Edit this bug report at http://bugs.php.net/bug.php?id=51298&edit=1
Bug #51298 [Asn]: Error when loading php5apache2_2.dll
Edit report at http://bugs.php.net/bug.php?id=51298&edit=1 ID: 51298 Updated by: paj...@php.net Reported by: trotsky_icepick at hotmail dot com Summary: Error when loading php5apache2_2.dll Status: Assigned Type: Bug Package: Apache2 related Operating System: Windows Vista SP2 PHP Version: 5.3.2 Assigned To: pajoye New Comment: If you feel like you can fix this bug within days, heh, please go ahead. Previous Comments: [2010-05-19 17:10:33] williams at uncc dot edu There is still a problem with the Windows PHP binaries. From 4/19 pajoye seems to believe it is a date bug to "fix as soon as possible". It has been a month! I have php-5.3.2-Win32-VC6-x86 and httpd-2.2.15-win32-x86-no_ssl installed. If I run phpinfo() (in web page) more than once (first run - get results, second or later runs within a few seconds - get crash) I get this error message: AppName httpd.exe AppVer 2.2.15.0 ModName php5ts.dll ModVer 5.3.2.0 offset 001d79b5 I have searched for other versions of php5ts.dll - none I have NOT mixed vc9 PHP with Apache PHP seems to run okay in command-line, ie I can run phpinfo() in cmd box with no problem. I If run as test web page I get the error. Here are php -m /php -m -n results: C:\>php -m [PHP Modules] bcmath calendar com_dotnet Core ctype date dom ereg filter ftp hash iconv json libxml mcrypt mhash mysqlnd odbc pcre PDO Phar Reflection session SimpleXML SPL standard tokenizer wddx xml xmlreader xmlwriter zip zlib [Zend Modules] C:\>php -m -n [PHP Modules] bcmath calendar com_dotnet Core ctype date dom ereg filter ftp hash iconv json libxml mcrypt mhash mysqlnd odbc pcre PDO Phar Reflection session SimpleXML SPL standard tokenizer wddx xml xmlreader xmlwriter zip zlib [Zend Modules] I have disabled all but core modules. [2010-04-30 15:43:09] slowchaos at msn dot com Update I have Apached 2.2.15 and PHP 5.3.2 running just fine (WinXP system). I'm not sure of the difference in 5.2 and 5.3 - I'm not a nuts and bolts php guy - but all is now well in my world :) [2010-04-30 06:55:02] slowchaos at msn dot com Had this problem with Apache 2.2.15 and PHP 5.2.13. Tried rolling back to earlier versions of PHP - back to PHP 5.2.10. Same thing. Rolled back to Apache 2.2.14 - still same issue. My apache crashes when trying to enable mysqli or mysql extension. System path is correct. Libmysql is in appropriate place. Mcrypt also crashes the server as well as a few others. [2010-04-20 01:48:09] paj...@php.net It happens to be a date bug (thread safety issue). We are trying to get a fix as soon as possible. [2010-04-20 01:00:40] downtrade at gmail dot com After installing: httpd-2.2.15-win32-x86-no_ssl.msi php-5.3.2-Win32-VC6-x86.msi got this error when started Apache: >From Win XP Event Viewer: Faulting application iexplore.exe, version 8.0.6001.18702, faulting module mshtml.dll, version 8.0.6001.18904, fault address 0x00331b8a. Faulting application httpd.exe, version 2.2.15.0, faulting module php5ts.dll, version 5.3.2.0, fault address 0x000e6d2c. 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=51298 -- Edit this bug report at http://bugs.php.net/bug.php?id=51298&edit=1
Req #44187 [Com]: mail() function and newlines
Edit report at http://bugs.php.net/bug.php?id=44187&edit=1 ID: 44187 Comment by: lukas dot starecek at centrum dot cz Reported by: anzenews at volja dot net Summary: mail() function and newlines Status: Open Type: Feature/Change Request Package: Feature/Change Request Operating System: any PHP Version: 5.2.5 New Comment: Be careful with that. There have to be newlines in subject if subject is too long (see RFC 2047), but there must not be two newlines consecutively (two consecutive new lines are header separator). Previous Comments: [2008-02-20 15:07:11] anzenews at volja dot net Description: Most of PHP users are unaware of security implications of such "Send to friend" scripts: I propose change of parameters to mail(): mail(array $to, string $subject, string $message[, array $additional_headers [, string $additional_parameters ]] ); The function should throw a warning if there is a newline anywhere, even inside arrays, and should not process the mail. I agree that the programmer should know its tools, BUT: - the fact is that most of PHP users don't - most of the TUTORIALS are insecure! A quick search for "PHP mail example" reveals many prominent pages with such examples. This is a huge problem and spammers are abusing it extensively. As this will undoubtedly break some of the scripts (though the fix should be easy) I suggest adding a configuration statement that enables such mail() behaviour, Reproduce code: --- Expected result: Warning: newline in mail() function, line... Mail not sent or everything after newline ignored. Actual result: -- Mail sent to m...@example.com and to y...@example.com. -- Edit this bug report at http://bugs.php.net/bug.php?id=44187&edit=1
Bug #51284 [Bgs]: foreach distroys objects in array
Edit report at http://bugs.php.net/bug.php?id=51284&edit=1
ID: 51284
User updated by: gerhard at tinned-software dot net
Reported by: gerhard at tinned-software dot net
Summary: foreach distroys objects in array
Status: Bogus
Type: Bug
Package: Class/Object related
Operating System: MacOSX, Linux, ...
PHP Version: Irrelevant
New Comment:
This comment is simply not true!!!
How can it be that the function call func_get_args() destroys the
reference when one of this functions work and the other function does
not work? Both functions use this functionb call. But only in the
function get_object_NOK() the error message is shown. In the other
function, the object is created as expected.
So please explain me how the function call func_get_args() can cause
this?
Previous Comments:
[2010-05-19 15:23:49] m...@php.net
I get a Warning: Parameter 2 to test_obj2::__construct() expected to be
a reference, value given in /tmp/phpbugs/51284.php on line 128
You lose the ref with func_get_args().
[2010-03-12 13:29:44] gerhard at tinned-software dot net
Description:
I have a script which tries to create configured objects of classes. The
method creating the object of the named class will generate a unique
identifier to be able to identify the invocation later in the class.
This
unique_id is basically calculated by adding the class name and all
constructor parameters into a ":"-seperetaed list. For doing this i used
This all functions well as long as there is not the following very
special
combination of parameters and class-parameterlist. If one of the
parameters
is an object, and this object is passed to the class as reference
(&$object).
In such a case, the foreach loop destroys somehow the $parameter array.
As
the $parameter array is not altered in the loop, there is no explanation
to
my way the loop influence the array.
To prove that the loop is causing this problem i changed the loop from
foreach() to for(). As you can see in the test script there are 2
methods in
the OM class. The get_object_OK() uses the for()-loop to generate the ID
and
the get_object_NOK() method uses the foreach()-loop to generate it.
With the for()-loop the script runs without any troubles. But with the
foreach()-loop the script returns an error while invocating the object.
This
error causes the object to be not created.
The error message which can be found in the webserver's / php's logfile
is
the following:
[error] [client 127.0.0.1] PHP Warning: Invocation of test_obj2's
constructor failed in /.../test.php on line 183, referer:
http://127.0.0.1:8080/
... The line references to "$obj =
$reflection_obj->newInstanceArgs($parameter);" at the get_object_NOK.()
function.
Test script:
---
class test_obj
{
var $test = "abc";
function __construct($str)
{
$this->test = $str;
}
function get()
{
echo get_class($this)." - string=".$this->test."\n";
}
function set($str)
{
$test = $str;
}
}
class test_obj2
{
var $test = "abc";
function __construct($string1, &$object)
{
echo get_class($this)." - string1=$string1\n";
$object->get();
}
}
//include_once(dirname(__FILE__).'/object_manager.class.php');
//include_once(dirname(__FILE__).'/element_container.class.php');
//
// Test execution
//
echo "PHP Version: ".phpversion()."\n";
$om = new OM();
$t1 = new test_obj("init-text-object-1");
$t1->get();
echo "Object of class 'Test_CLass' ... Finished.\n";
$t2 = $om->get_object_OK("test_obj2", "object-text-2", $t1);
echo "Object of class 'Test_CLass2' with for() loop ... Finished.\n";
$t2 = $om->get_object_NOK("test_obj2", "object-text-2", $t1);
echo "Object of class 'Test_CLass2' with foreach() loop ... Finished.\n";
//
// A short testing code from a much biger function / Class to
// demonstrate the behaviour
//
class OM
{
function get_object_OK()
{
$parameter = func_get_args();
$type = array_shift($parameter);
//
// create unique identifier for this object creation.
// Used in the original class to identify the object later in
the class.
//
$unique_id = "$type:";
// loop through all parameters
for($i=0; $i < count($parameter); $i++)
{
// if parameter is an object, get only the object name
if(is_object($parameter[$i]) === TRUE)
{
$unique_id .= get_class($parameter[$i]).':';
continue;
}
// get the variable content as string to the
identifier-string
$uni
[PHP-BUG] Bug #51861 [NEW]: While loop executes even though Exception has been thrown
From: Operating system: CentOS 5 PHP version: 5.2.13 Package: Unknown/Other Function Bug Type: Bug Bug description:While loop executes even though Exception has been thrown Description: Test script is pretty self-explanatory: even though an exception is thrown a while(true) loop gets exectued afterwards. Test script: --- Expected result: We did not expected the while loop to execute. Actual result: -- The while loop executed. -- Edit bug report at http://bugs.php.net/bug.php?id=51861&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51861&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51861&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51861&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51861&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51861&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51861&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51861&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51861&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51861&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51861&r=support Expected behavior: http://bugs.php.net/fix.php?id=51861&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51861&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51861&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51861&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51861&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51861&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51861&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51861&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51861&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51861&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51861&r=mysqlcfg
Bug #49355 [Com]: Unable to properly fold To/Subject in emails
Edit report at http://bugs.php.net/bug.php?id=49355&edit=1
ID: 49355
Comment by: lukas dot starecek at centrum dot cz
Reported by: php dot net at chris dot cs278 dot org
Summary: Unable to properly fold To/Subject in emails
Status: Open
Type: Bug
Package: Mail related
Operating System: win32 only
PHP Version: 5.2.10
New Comment:
We have same problem on *nix system with PHP 5.1.6 and PHP 5.3.2. In
mail function is allowed to use only \r\n to separate chunks of subject,
but email with this subject is damaged when processed by microsoft SMTP
server (I think some kind of exchange server). In damaged email are
chunks of subjects followed by two new lines, which means end of header.
Below you can see broken email headers. The part after "MIME-Version:
1.0" is supposed to be message body, but you can se fragments of second
and following lines of chunked subject, and email headers, which was
after subject in original email.
--
Received: from * (*) by *
(*) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 19 May
2010 15:03:47 +0200
Received: from * (*) by
* (*) with Microsoft SMTP Server id
8.2.176.0; Wed, 19 May 2010 15:03:45 +0200
Received: by * (Postfix, from userid 48)id 72D6A36C2D; Wed,
19 May 2010 15:03:53 +0200 (CEST)
From: infooma <*>
To: *
Date: Wed, 19 May 2010 15:03:45 +0200
Subject:
=?Windows-1252?Q?Spam=5Fcsc:_POZOR!!_JEDN=C1_SE_O_TESTOVAC=CD_NOTIFIKACI_?=
=?Windows-1252?Q?=8EoP_?=
Thread-Topic:
=?Windows-1252?Q?Spam=5Fcsc:_POZOR!!_JEDN=C1_SE_O_TESTOVAC=CD_NOTIFIKACI_?=
=?Windows-1252?Q?=8EoP_?=
Thread-Index: Acr3U7hpsAXS9QjASjS/sZtv0YXFjg==
Message-ID: <3167228c-f54a-4a6b-b6c7-c7c1e5dc6...@*>
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-AuthSource: *
X-MS-Has-Attach:
X-MS-Exchange-Organization-SenderIdResult: None
X-MS-Exchange-Organization-PCL: 2
X-MS-Exchange-Organization-PRD: *
X-MS-TNEF-Correlator:
received-spf: None (*: * does not
designate permitted sender hosts)
x-tm-as-product-ver: CSC-0-6.0.1038-17392
x-tm-as-result: Yes-9.62-7.00-31-1
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
=?UTF-8?B?MSBwcm9qZWt0dSBDWi4xLjEwLzIuMi4wMC8wNC4xMTExMSBieWxhIHDFmWVk?=
=?UTF-8?B?w6FuYSBkbyBzdMOhZGlhICJTOC4xIEtvbnRyb2xhIDEuIHN0dXBuxJsgcHJv?=
=?UTF-8?B?dmVkZW5hIi4=?=
Received: from phpmailer ([*])
by * with HTTP (phpmailer);
Wed, 19 May 2010 15:03:53 +0200
Date: Wed, 19 May 2010 15:03:53 +0200
From: *
Message-ID:
X-Priority: 3
X-Mailer: phpmailer [version 1.65]
X-Mailer: PHP/5.1.6
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Previous Comments:
[2009-08-25 09:47:20] php dot net at chris dot cs278 dot org
Description:
The SKIP_LONG_HEADER_SEP macro only permits CR-LF-WSP as a separator
which works fine for SMTP, but sendmail under NIX requires LF as the new
line character. The macro doesn't skip over LF-WSP which causes the LF
to be replaced with a space, unfolding the header. This makes it near
impossible to use UTF-8/etc. encoded strings for these headers.
I posted to internals about this problem:
http://marc.info/?l=php-internals&m=125110373328523&w=2
Reproduce code:
---
mail('tes...@example.net', "Reproduction test e-mail for PHP bug
breaking the correct wrapping\n of e-mails with long To/Subject
headers.", 'Testing...');
Expected result:
To: tes...@example.net
Subject: Reproduction test e-mail for PHP bug breaking the correct
wrapping of e-mails with long To/Subject headers.
Testing...
Actual result:
--
To: tes...@example.net
Subject: Reproduction test e-mail for PHP bug breaking the correct
wrapping
of e-mails with long To/Subject headers.
Testing...
--
Edit this bug report at http://bugs.php.net/bug.php?id=49355&edit=1
[PHP-BUG] Bug #51862 [NEW]: Error in Zend-module when linking
From: Operating system: Mac OSX 10.5.8 PHP version: 5.2.13 Package: Compile Failure Bug Type: Bug Bug description:Error in Zend-module when linking Description: When trying to compile php, everything goes but linking produces this error: ld: duplicate symbol _yytext in Zend/zend_ini_scanner.o and Zend/zend_language_scanner.o for architecture i386 collect2: ld returned 1 exit status ld: duplicate symbol _yytext in Zend/zend_ini_scanner.o and Zend/zend_language_scanner.o for architecture x86_64 collect2: ld returned 1 exit status ld: duplicate symbol _yytext in Zend/zend_ini_scanner.o and Zend/zend_language_scanner.o for architecture ppc collect2: ld returned 1 exit status ld: duplicate symbol _yytext in Zend/zend_ini_scanner.o and Zend/zend_language_scanner.o for architecture ppc64 collect2: ld returned 1 exit status Test script: --- I have looked into other bug reports concerning this message, and came to the conclusion that the linked on Mac OSX is a bit more strict than on other platforms. To make the error go away, I modified the sourcefiles: Zend/zend_ini_scanner.c and Zend/zend_language_scanner.c Both zend_ini_scanner.c as well as zend_language_scanner.c contained a line with: char *yytext that I changed to become: extern char *yytext It's a quick-fix that makes the linker error go away, but I don't know whether it solves the problem. Expected result: does this solve the problem, or does it only do away with the linker error? -- Edit bug report at http://bugs.php.net/bug.php?id=51862&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51862&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51862&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51862&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51862&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51862&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51862&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51862&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51862&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51862&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51862&r=support Expected behavior: http://bugs.php.net/fix.php?id=51862&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51862&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51862&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51862&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51862&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51862&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51862&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51862&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51862&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51862&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51862&r=mysqlcfg
Bug #33957 [Csd]: gmdate('W')/date('W') sometimes returns wrong week number.
Edit report at http://bugs.php.net/bug.php?id=33957&edit=1
ID: 33957
User updated by: paul at stunning-stuff dot com
Reported by: paul at stunning-stuff dot com
Summary: gmdate('W')/date('W') sometimes returns wrong week
number.
Status: Closed
Type: Bug
Package: Date/time related
Operating System: *
PHP Version: 5CVS-2005-08-02
Assigned To: derick
New Comment:
Hi Warwick,
The 1st week of a year does not necessarily start on the first of
January
under the rules of ISO8601. I checked your examples and they seemed
fine.
Please read up on ISO8601.
-Paul
Previous Comments:
[2010-05-19 04:06:11] wps at wwe dot com
date('W', $timestamp) fails to return "01" for some January 1st years on
PHP version 5.3.2 and 5.2.8 on CentOS and Windows.
$year = 1970;
$month = 1;
$day = 1;
while ($year <= 2028) {
$timestamp = mktime(12, 0, 0, $month, $day, $year);
print $year . " :: " . date('W', $timestamp). " :: " . date('D',
$timestamp) . "\n";
$year++;
}
Expect 01 for every year
but instead get
1970 :: 01 :: Thu
1971 :: 53 :: Fri
1972 :: 52 :: Sat
1973 :: 01 :: Mon
1974 :: 01 :: Tue
1975 :: 01 :: Wed
1976 :: 01 :: Thu
1977 :: 53 :: Sat
1978 :: 52 :: Sun
...
2020 :: 01 :: Wed
2021 :: 53 :: Fri
2022 :: 52 :: Sat
2023 :: 52 :: Sun
2024 :: 01 :: Mon
2025 :: 01 :: Wed
2026 :: 01 :: Thu
2027 :: 53 :: Fri
2028 :: 52 :: Sat
1st falling on Friday returns 53
1st falling on Saturday/Sunday return 52
Checked dates using
http://www.tuxgraphics.org/toolbox/cal_year.html
Warwick Shaw
[2005-08-31 16:31:52] der...@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.
[2005-08-02 16:45:08] paul at stunning-stuff dot com
Thanks for your quick reply and thanks for doing such a great job on
PHP. You dev's really make this the best open source language today.
I hope you are able to solve this problem (I'm sure you will). One more
note though: This problem should reoccur every 28 years before and after
1992. This might help you in your testing.
Thanks,
Paul van der Maas
---
www.stunning-stuff.com
[2005-08-02 16:22:09] der...@php.net
Indeed a bug, will have a look at it - thanks for the reproducable case.
[2005-08-02 16:19:09] paul at stunning-stuff dot com
Here is some example code to reproduce the problem:
';
$timestamp = gmmktime(12, 0, 0, 12, 29, 1992);
echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' .
gmdate('W', $timestamp) . '';
$timestamp = gmmktime(12, 0, 0, 12, 30, 1992);
echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' .
gmdate('W', $timestamp) . '';
$timestamp = gmmktime(12, 0, 0, 12, 31, 1992);
echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' .
gmdate('W', $timestamp) . '';
$timestamp = gmmktime(12, 0, 0, 12, 28, 2020);
echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' .
gmdate('W', $timestamp) . '';
$timestamp = gmmktime(12, 0, 0, 12, 29, 2020);
echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' .
gmdate('W', $timestamp) . '';
$timestamp = gmmktime(12, 0, 0, 12, 30, 2020);
echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' .
gmdate('W', $timestamp) . '';
$timestamp = gmmktime(12, 0, 0, 12, 31, 2020);
echo 'Week number for ' . gmdate('D M d, Y H:i:s', $timestamp) . ': ' .
gmdate('W', $timestamp) . '';
?>
Expected result:
Week number for Mon Dec 28, 1992 12:00:00: 53
Week number for Tue Dec 29, 1992 12:00:00: 53
Week number for Wed Dec 30, 1992 12:00:00: 53
Week number for Thu Dec 31, 1992 12:00:00: 53
Week number for Mon Dec 28, 2020 12:00:00: 53
Week number for Tue Dec 29, 2020 12:00:00: 53
Week number for Wed Dec 30, 2020 12:00:00: 53
Week number for Thu Dec 31, 2020 12:00:00: 53
Actual result:
Week number for Mon Dec 28, 1992 12:00:00: 1
Week number for Tue Dec 29, 1992 12:00:00: 1
Week number for Wed Dec 30, 1992 12:00:00: 1
Week number for Thu Dec 31, 1992 12:00:00: 1
Week number for Mon Dec 28, 2020 12:00:00: 1
Week number for Tue Dec 29, 2020 12:00:00: 1
Week number for Wed Dec 30, 2020 12:00:00: 1
Week number for Thu Dec 31, 2020 12:00:00: 1
Check
http://www.timeanddate.com/calendar/custom.html?year=1992&month=12&typ=1&display=1&wno=1
and
http://www.timeanddate.com/calendar/custom.html?year=2020&mont
[PHP-BUG] Bug #51863 [NEW]: date format
From:
Operating system: RHEL 5 - linux
PHP version: 5.2.13
Package: PDO related
Bug Type: Bug
Bug description:date format
Description:
When using the PDO connection option to an Informix data base the date is
returned in the format -MM-DD instead of in the format that it is
stored in the database.
Test script:
---
try {
$pdo=new PDO('informix:host=$host; database=$db; server=$server;
protocol=onsoctcp;',"","",array(PDO::ATTR_PERSISTENT=>true));
} catch (PDOexception $e) {
echo "Failed to get DB handle: " . $e->getMessage() . "\n";
exit;
}
$sql = "SELECT dba_date,due_date FROM work_requests Where
work_id='6862105'";
$q = $pdo->prepare($sql);
$q->execute();
$q->setFetchMode(PDO::FETCH_BOTH);
while($sqlr = $q->fetch()){
print $sqlr['DBA_DATE'] ."";
print $sqlr['DUE_DATE'] ."";
}
Expected result:
mm/dd/
Actual result:
--
-mm-dd
--
Edit bug report at http://bugs.php.net/bug.php?id=51863&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51863&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51863&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51863&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51863&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51863&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51863&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51863&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51863&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51863&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51863&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51863&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51863&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51863&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51863&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51863&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51863&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51863&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51863&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51863&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51863&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51863&r=mysqlcfg
Bug #17461 [Com]: register_shutdown_function() timeout problem
Edit report at http://bugs.php.net/bug.php?id=17461&edit=1
ID: 17461
Comment by: xxleite at gmail dot com
Reported by: jason at thinkingman dot org
Summary: register_shutdown_function() timeout problem
Status: Bogus
Type: Bug
Package: Scripting Engine problem
Operating System: Windows 2000 SP2
PHP Version: 4.2.1
New Comment:
i try to play with all, but i got the same error...
set_time_limit doesnt works well with register_shutdown_function, please
fix it
for our php pride! ...
thanks anyway.
Previous Comments:
[2002-12-08 10:44:02] sni...@php.net
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.
Thank you for your interest in PHP.
Please add possible additional information here:
http://bugs.php.net/bug.php?id=14542
(no need for many reports about same issue)
[2002-09-17 11:51:55] jason at thinkingman dot org
I posted the following response in php.general and php.windows --
responding to users whom looked at the online help file for
REGISTER_SHUTDOWN_FUNCTION() on php.net and inquired whether this
TIMEOUT was actually a bug or a feature request:
--
It's a bug. spoke to Rasmus at some length about just before i posted
it in the bug report.
The online help page is inaccurate in describing the full functionality
of the function:
http://www.php.net/manual/en/function.register-shutdown-function.php
REGISTER_SHUTDOWN_FUNCTION() is suppose to kick-off when any one of the
following things happen -- Exit, Error, TIMEOUT or User Abort.
According to Rasmus, the TIMEOUT functionality of this function works
fine under Linux -- however, it's not working under Win32 !
There apparently is another bug with this function -- you are suppose to
be able to call more than one REGISTER_SHUTDOWN_FUNCTION(), and they are
suppose to executed in-order... some people are reporting that only the
first encountered REGISTER_SHUTDOWN_FUNCTION() is executed, then the
script exits.
Someone needs to go through this function, pretty thoroughly, and get it
working correctly. Being able to run code on a timeout, user-abort or
error is critical.
Jason
[2002-05-27 14:11:04] jason at thinkingman dot org
REGISTER_SHUTDOWN_FUNCTION() doesn't work on TIMEOUT for the Win32
platform.
I've tried this under PHP versions 4.1.1 and 4.2.1 -- same thing
happens. Here's a sample script:
1: ?>
2:
3: set_time_limit(1);
4:
5: function clean_up()
6: {
7: print("Script Terminated\n");
8: }
9:
10: register_shutdown_function("clean_up");
11:
12: while(1);
13:
14: ?>
Here's the error:
-
Fatal error: Maximum execution time of 1 second exceeded in
C:\timeout_code.php on line 7
When this script TIMES-OUT, the REGISTER_SHUTDOWN_FUNCTION() will
"attempt" to run the function "clean_up" but will *immediately* generate
the error above in the 1st line (line 7, in this case) of the "clean_up"
function -- no matter what it is, and then the script terminates.
Now -- if I use the REGISTER_SHUTDOWN_FUNCTION() with an EXIT (instead
of a TIMEOUT), the function works fine... it *just* seems to be a
TIMEOUT issue.
The REGISTER_SHUTDOWN_FUNCTION() needs to ignore the TIMEOUT (timer??)
-- and proceed to run any code it's programmed to run.
Just a Note: I understand that PRINT() and a few other functions will
not work when a REGISTER_SHUTDOWN_FUNCTION() is called and *run*
SERVER-SIDE -- however, I am running this script from the COMMAND-LINE
and PRINT() does work here, even with a REGISTER_SHUTDOWN_FUNCTION() --
so PRINT() isn't the problem... Just for giggles, I've replaced the
PRINT() function with an ERRORLOG() function, in an attempt to write the
output to disk -- SAME ERROR and exits on line 7 -- never executing the
code.
Thanks
Jason Caldwell
ja...@thinkingman.org
--
Edit this bug report at http://bugs.php.net/bug.php?id=17461&edit=1
[PHP-BUG] Req #51865 [NEW]: Make use of Apache httpd 2.2's mod_dbd connection pooling
From: Operating system: Any PHP version: 5.3.2 Package: *Database Functions Bug Type: Feature/Change Request Bug description:Make use of Apache httpd 2.2's mod_dbd connection pooling Description: Due to the fact that PHP doesn't really have pooled DB connections, or at least doesn't seem to be able to handle them: http://bugs.php.net/bug.php?id=46740 I was wondering if it would be possible to implement connection pooling using the apr_dbd API as provided by httpd, which can be configured via httpd.conf with mod_dbd. IMO, this would get the LAMP stack a bit closer to being an Application Server. -- Edit bug report at http://bugs.php.net/bug.php?id=51865&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51865&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51865&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51865&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51865&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51865&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51865&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51865&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51865&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51865&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51865&r=support Expected behavior: http://bugs.php.net/fix.php?id=51865&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51865&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51865&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51865&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51865&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51865&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51865&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51865&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51865&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51865&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51865&r=mysqlcfg
[PHP-BUG] Bug #51866 [NEW]: DateTime::createFromFormat does not match documentation
From: Operating system: * PHP version: 5.3SVN-2010-05-20 (SVN) Package: Date/time related Bug Type: Bug Bug description:DateTime::createFromFormat does not match documentation Description: The manual for DateTime::createFromFormat says: Format accepted by date(). If format does not contain the character ! then portions of the date/time value specified in format but not specified in time will be set to the current system time. However if you specify format like "d-m-Y H:i" and provide datetime string that does not contain time, parsing would fail - even though the manual says if time string does not contain parts from format it should use current system. Test script: --- string(19) "2007-10-25 18:58:31" ["timezone_type"]=> int(3) ["timezone"]=> string(19) "America/Los_Angeles" } Actual result: -- bool(false) -- Edit bug report at http://bugs.php.net/bug.php?id=51866&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51866&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51866&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51866&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51866&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51866&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51866&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51866&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51866&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51866&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51866&r=support Expected behavior: http://bugs.php.net/fix.php?id=51866&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51866&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51866&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51866&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51866&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51866&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51866&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51866&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51866&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51866&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51866&r=mysqlcfg
Bug #51866 [Opn]: DateTime::createFromFormat does not match documentation
Edit report at http://bugs.php.net/bug.php?id=51866&edit=1 ID: 51866 Updated by: s...@php.net Reported by: smalyshev at sugarcrm dot com Summary: DateTime::createFromFormat does not match documentation Status: Open Type: Bug Package: Date/time related Operating System: * PHP Version: 5.3SVN-2010-05-20 (SVN) New Comment: It also would be nice if this function could ignore extra input after the parsing and/or return where it stopped. Previous Comments: [2010-05-20 04:01:27] smalyshev at sugarcrm dot com Description: The manual for DateTime::createFromFormat says: Format accepted by date(). If format does not contain the character ! then portions of the date/time value specified in format but not specified in time will be set to the current system time. However if you specify format like "d-m-Y H:i" and provide datetime string that does not contain time, parsing would fail - even though the manual says if time string does not contain parts from format it should use current system. Test script: --- string(19) "2007-10-25 18:58:31" ["timezone_type"]=> int(3) ["timezone"]=> string(19) "America/Los_Angeles" } Actual result: -- bool(false) -- Edit this bug report at http://bugs.php.net/bug.php?id=51866&edit=1
Bug #51405 [Fbk->Opn]: segmentation fault at the "engine shutdown"
Edit report at http://bugs.php.net/bug.php?id=51405&edit=1 ID: 51405 User updated by: miha dot vrhovnik at domenca dot com Reported by: miha dot vrhovnik at domenca dot com Summary: segmentation fault at the "engine shutdown" -Status: Feedback +Status: Open Type: Bug Package: Reproducible crash Operating System: Linux PHP Version: 5.3.2 New Comment: Hi, Mike I've tried to strip it down to simple script, but without success. Would downloadable VmWare image where I'd strip away as much as I can, help? Previous Comments: [2010-05-19 15:47:13] m...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. No reproduce case, no chance to do anything, sorry. [2010-03-27 19:46:56] miha dot vrhovnik at domenca dot com Just so there won't be any excuses that this is because I'm running under php-fpm Here is backtrace from apache2. a bit different configure -- removed fpm and added apache: ./configure '--with-apxs2=/usr/bin/apxs2' '--with-openssl' '--with-zlib' '--enable-bcmath' '--with-bz2' '--enable-calendar' '--with-curl' '--enable-exif' '--enable-ftp' '--with-gd' '--with-imap' '--with-imap-ssl' '--enable-mbstring' '--with-mcrypt' '--enable-pcntl' '--with-pdo-mysql' '--with-pdo-pgsql' '--with-pgsql' '--with-readline' '--with-mysql' '--enable-soap' '--enable-sockets' '--enable-sqlite-utf8' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--with-tidy' '--enable-wddx' '--with-xmlrpc' '--with-xsl' '--enable-zip' '--with-kerberos' '--with-mysqli' '--with-config-file-path=/usr/local/etc' '--with-config-file-scan-dir=/usr/local/etc/php.d' '--with-pear' '--with-jpeg-dir=/usr/lib' --with-freetype-dir=/usr/lib and now the actual backtrace (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. _zend_mm_free_int (heap=0xb979d180, p=0xb9946290) at /projects/php53/php-fpm-5.3.2/Zend/zend_alloc.c:2018 2018/projects/php53/php-fpm-5.3.2/Zend/zend_alloc.c: No such file or directory. in /projects/php53/php-fpm-5.3.2/Zend/zend_alloc.c (gdb) bt #0 _zend_mm_free_int (heap=0xb979d180, p=0xb9946290) at /projects/php53/php-fpm-5.3.2/Zend/zend_alloc.c:2018 #1 0xb6ff2498 in zend_hash_destroy (ht=0xba189ca0) at /projects/php53/php-fpm-5.3.2/Zend/zend_hash.c:526 #2 0xb7003fc3 in zend_object_std_dtor (object=0xba193830) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects.c:45 #3 0xb7003ff2 in zend_objects_free_object_storage (object=0xba193830) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects.c:114 #4 0xb70075fc in zend_objects_store_del_ref_by_handle_ex (handle=127, handlers=0xb74c65c0) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects_API.c:220 #5 0xb700762f in zend_objects_store_del_ref (zobject=0xba189ff0) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects_API.c:172 #6 0xb6fdbedf in _zval_dtor (zval_ptr=0xba1a6238) at /projects/php53/php-fpm-5.3.2/Zend/zend_variables.h:35 #7 _zval_ptr_dtor (zval_ptr=0xba1a6238) at /projects/php53/php-fpm-5.3.2/Zend/zend_execute_API.c:439 #8 0xb6ff2498 in zend_hash_destroy (ht=0xba19273c) at /projects/php53/php-fpm-5.3.2/Zend/zend_hash.c:526 #9 0xb6fe6945 in _zval_dtor_func (zvalue=0xba197ef4) at /projects/php53/php-fpm-5.3.2/Zend/zend_variables.c:43 #10 0xb6fdbedf in _zval_dtor (zval_ptr=0xba106080) at /projects/php53/php-fpm-5.3.2/Zend/zend_variables.h:35 ---Type to continue, or q to quit--- #11 _zval_ptr_dtor (zval_ptr=0xba106080) at /projects/php53/php-fpm-5.3.2/Zend/zend_execute_API.c:439 #12 0xb6ff2498 in zend_hash_destroy (ht=0xba12276c) at /projects/php53/php-fpm-5.3.2/Zend/zend_hash.c:526 #13 0xb7003fc3 in zend_object_std_dtor (object=0xb5e7013c) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects.c:45 #14 0xb7003ff2 in zend_objects_free_object_storage (object=0xb5e7013c) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects.c:114 #15 0xb70075fc in zend_objects_store_del_ref_by_handle_ex (handle=120, handlers=0xb74c65c0) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects_API.c:220 #16 0xb700762f in zend_objects_store_del_ref (zobject=0xba051424) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects_API.c:172 #17 0xb6fdbedf in _zval_dtor (zval_ptr=0xba1ac560) at /projects/php53/php-fpm-5.3.2/Zend/zend_variables.h:35 #18 _zval_ptr_dtor (zval_ptr=0
Bug #51284 [Bgs]: foreach distroys objects in array
Edit report at http://bugs.php.net/bug.php?id=51284&edit=1
ID: 51284
Updated by: m...@php.net
Reported by: gerhard at tinned-software dot net
Summary: foreach distroys objects in array
Status: Bogus
Type: Bug
Package: Class/Object related
Operating System: MacOSX, Linux, ...
PHP Version: Irrelevant
New Comment:
That's true, sorry. You lose the reference because of foreach; try:
foreach ($parameter as $key => &$param) ...
Previous Comments:
[2010-05-19 17:45:19] gerhard at tinned-software dot net
This comment is simply not true!!!
How can it be that the function call func_get_args() destroys the
reference when one of this functions work and the other function does
not work? Both functions use this functionb call. But only in the
function get_object_NOK() the error message is shown. In the other
function, the object is created as expected.
So please explain me how the function call func_get_args() can cause
this?
[2010-05-19 15:23:49] m...@php.net
I get a Warning: Parameter 2 to test_obj2::__construct() expected to be
a reference, value given in /tmp/phpbugs/51284.php on line 128
You lose the ref with func_get_args().
[2010-03-12 13:29:44] gerhard at tinned-software dot net
Description:
I have a script which tries to create configured objects of classes. The
method creating the object of the named class will generate a unique
identifier to be able to identify the invocation later in the class.
This
unique_id is basically calculated by adding the class name and all
constructor parameters into a ":"-seperetaed list. For doing this i used
This all functions well as long as there is not the following very
special
combination of parameters and class-parameterlist. If one of the
parameters
is an object, and this object is passed to the class as reference
(&$object).
In such a case, the foreach loop destroys somehow the $parameter array.
As
the $parameter array is not altered in the loop, there is no explanation
to
my way the loop influence the array.
To prove that the loop is causing this problem i changed the loop from
foreach() to for(). As you can see in the test script there are 2
methods in
the OM class. The get_object_OK() uses the for()-loop to generate the ID
and
the get_object_NOK() method uses the foreach()-loop to generate it.
With the for()-loop the script runs without any troubles. But with the
foreach()-loop the script returns an error while invocating the object.
This
error causes the object to be not created.
The error message which can be found in the webserver's / php's logfile
is
the following:
[error] [client 127.0.0.1] PHP Warning: Invocation of test_obj2's
constructor failed in /.../test.php on line 183, referer:
http://127.0.0.1:8080/
... The line references to "$obj =
$reflection_obj->newInstanceArgs($parameter);" at the get_object_NOK.()
function.
Test script:
---
class test_obj
{
var $test = "abc";
function __construct($str)
{
$this->test = $str;
}
function get()
{
echo get_class($this)." - string=".$this->test."\n";
}
function set($str)
{
$test = $str;
}
}
class test_obj2
{
var $test = "abc";
function __construct($string1, &$object)
{
echo get_class($this)." - string1=$string1\n";
$object->get();
}
}
//include_once(dirname(__FILE__).'/object_manager.class.php');
//include_once(dirname(__FILE__).'/element_container.class.php');
//
// Test execution
//
echo "PHP Version: ".phpversion()."\n";
$om = new OM();
$t1 = new test_obj("init-text-object-1");
$t1->get();
echo "Object of class 'Test_CLass' ... Finished.\n";
$t2 = $om->get_object_OK("test_obj2", "object-text-2", $t1);
echo "Object of class 'Test_CLass2' with for() loop ... Finished.\n";
$t2 = $om->get_object_NOK("test_obj2", "object-text-2", $t1);
echo "Object of class 'Test_CLass2' with foreach() loop ... Finished.\n";
//
// A short testing code from a much biger function / Class to
// demonstrate the behaviour
//
class OM
{
function get_object_OK()
{
$parameter = func_get_args();
$type = array_shift($parameter);
//
// create unique identifier for this object creation.
// Used in the original class to identify the object later in
the class.
//
$unique_id = "$type:";
// loop through all parameters
for($i=0; $i < count($parameter); $i++)
{
// if parameter is an object, get only the object name
if(is_object($parameter[$i
Bug #51861 [Opn->Fbk]: While loop executes even though Exception has been thrown
Edit report at http://bugs.php.net/bug.php?id=51861&edit=1 ID: 51861 Updated by: m...@php.net Reported by: pim at lemonbit dot com Summary: While loop executes even though Exception has been thrown -Status: Open +Status: Feedback Type: Bug Package: Unknown/Other Function Operating System: CentOS 5 PHP Version: 5.2.13 New Comment: Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Bails out for me. Previous Comments: [2010-05-19 17:46:26] pim at lemonbit dot com Description: Test script is pretty self-explanatory: even though an exception is thrown a while(true) loop gets exectued afterwards. Test script: --- Expected result: We did not expected the while loop to execute. Actual result: -- The while loop executed. -- Edit this bug report at http://bugs.php.net/bug.php?id=51861&edit=1
Bug #51749 [Com]: header("Location:") changing HTTP status
Edit report at http://bugs.php.net/bug.php?id=51749&edit=1
ID: 51749
Comment by: theimp at iinet dot net dot au
Reported by: theimp at iinet dot net dot au
Summary: header("Location:") changing HTTP status
Status: Open
Type: Bug
Package: HTTP related
Operating System: Debian Lenny
PHP Version: 5.3.2
New Comment:
> header("HTTP/1.1 XXX") is just a hack
I did not realize this. So does that mean that, per RFC 3875, we're only
supposed to set the Status header and hope that the server does what we
expect?
The documentation specifically lists this "hack" as the correct way to
supply the Status-Line and, therefore, the Response Code. But I'm not
going to argue with you about this.
> I see no hard reason to introduce other hacks to support a hack in the
first place.
Well, that's fair enough.
> You are writing *pages*
I apologize. I tend to use far more words than I have to, in
anticipation of explaining myself poorly otherwise. I will try to be
more concise. Many of the details I felt were essential for
understanding how the fix SHOULD be handled, distinct from my personal
preferences.
> about code that's *years* old and worked that way for a long long
time, and there's very little chance to become that changed.
I understand from this, that you do not want to fix this in the way I
have suggested, which is fair enough; it doesn't seem to bother anyone
else and has trivial workarounds, and its very status as a bug is more
an matter of opinion than fact.
I'm bad at interpreting subtlety, though, and so I am not clear if I
should also conclude that:
1. This bug is closed, we've got more important things to fix, and this
is technically not even broken. Stop bothering me!
or:
2. If you want it fixed so bad, then submit a patch yourself and we'll
see if it's not too convoluted to keep.
I am not trying to be offensive, and understand that you weren't,
either.
Thank you for your patience.
Previous Comments:
[2010-05-18 09:47:14] m...@php.net
Maybe, but header("HTTP/1.1 XXX") is just a hack and I see no hard
reason to introduce other hacks to support a hack in the first place.
You are writing *pages* about code that's *years* old and worked that
way for a long long time, and there's very little chance to become that
changed. You know, PHP is an acronym for BC, or was it the other way
round...
[2010-05-12 14:19:48] theimp at iinet dot net dot au
@ mike at php dot net
I did more testing, and yes, if you use the additional parameters on the
occasion that you send the location header, the special handling of the
Location header does not override the explicit behavior.
So:
header("HTTP/1.1 503 Service Unavailable", true, 503);
header("Location: http://www.php.net/";);
Does not work; but:
header("HTTP/1.1 503 Service Unavailable");
header("Location: http://www.php.net/";, true, 503);
Does work.
Obvious, in hindsight. But very confusing at first. The documentation
for http_response_code simply says: "Forces the HTTP response code to
the specified value"; I read that as forcing the response code
irrespective of any other later action other than another
http_response_code. It's not quite a documentation bug, since it's not
strictly wrong, but it should probably be changed, because it is easy to
read other than as intended. I would accept changing this bug to a
documentation bug.
@ aharvey at php dot net
The functionality I expected exists; I simply did not understand it. But
I do agree with what you say also; it is questionable whether it should
behave the way that it does even aside from other functionality.
To really know how this should be treated requires, I think,
consideration of the points I have previously mentioned. Presumably,
this specific behavior was put into PHP for a reason, and it was not
changed much when the opportunity last arose. I do not know the specific
goals of the PHP project in this respect.
I would not have written this bug report if I had realized the correct
way to use the http_response_code parameter.
Also, the workaround mentioned in bug #25044 is still possible.
Finally, I had not properly considered RFC 3875 when I first created
this bug report. If I had, I would probably have decided that the
behavior is deliberate and was not expected to be fixed.
The http_response_code is confusing, since it can be set on unrelated
headers, making it difficult to track down the code that sets it since
it could be a place other than where you set the Response Line itself
(in principle, any header; practically, any Location header in addition
to the Response Line header).
Also, the HTTP Response Code that you want to set must be known at the
time you want to set the Location header, whic
