Bug #60697 [Opn->Bgs]: gettype() cann't distinguish object and function?
Edit report at https://bugs.php.net/bug.php?id=60697&edit=1
ID: 60697
Updated by: cataphr...@php.net
Reported by:hfcorriez at gmail dot com
Summary:gettype() cann't distinguish object and function?
-Status: Open
+Status: Bogus
Type: Bug
Package:Scripting Engine problem
Operating System: all
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
"function" is not a type. See http://php.net/manual/en/language.types.php
Previous Comments:
[2012-01-10 05:25:13] hfcorriez at gmail dot com
Description:
I create a lambda function with a variable, then check it type with gettype ,
it's
return "object", It think it's not good in here.
Test script:
---
$a = function(){};
$b = new stdClass();
echo gettype($a) . '|' . gettype($b); // echo 'object|object'
--
Edit this bug report at https://bugs.php.net/bug.php?id=60697&edit=1
Bug #60697 [Bgs]: gettype() cann't distinguish object and function?
Edit report at https://bugs.php.net/bug.php?id=60697&edit=1
ID: 60697
User updated by:hfcorriez at gmail dot com
Reported by:hfcorriez at gmail dot com
Summary:gettype() cann't distinguish object and function?
Status: Bogus
Type: Bug
Package:Scripting Engine problem
Operating System: all
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
I think it's not good for use
When I want to check function and call witch $a(), I must check it's a object
and
the class name is "Closure"
Previous Comments:
[2012-01-10 08:20:50] cataphr...@php.net
"function" is not a type. See http://php.net/manual/en/language.types.php
[2012-01-10 05:25:13] hfcorriez at gmail dot com
Description:
I create a lambda function with a variable, then check it type with gettype ,
it's
return "object", It think it's not good in here.
Test script:
---
$a = function(){};
$b = new stdClass();
echo gettype($a) . '|' . gettype($b); // echo 'object|object'
--
Edit this bug report at https://bugs.php.net/bug.php?id=60697&edit=1
Bug #60694 [Com]: print() results in bad logic
Edit report at https://bugs.php.net/bug.php?id=60694&edit=1
ID: 60694
Comment by: phpmpan at mpan dot pl
Reported by:MarkAndrewSlade at gmail dot com
Summary:print() results in bad logic
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: CentOS release 5.4 (Final)
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Invalid interpretation of the code caused by misleading parenthenses.
1. false && print ('')
-> false && (print (''))
-> false && 1
-> false
2. print('') && false
-> (print (('') && false))
-> (print false)
-> 1
-> true
3. print('') && false && false
-> (print ((('') && false) && false))
-> (print false)
-> 1
-> true
4. (print('') && false) && true
-> ( print (('') && false) ) && true
-> (print false) && true
-> 1 && true
-> true
5. (print('') && false) && false
-> (print (('') && false) && false
-> (print false) && false
-> 1 && false
-> false
I believe that documentation for all language constructs (`echo`, `include`,
`print`, ...) should explicitly discourage use of parenthenses around
arguments. They're very misleading.
Previous Comments:
[2012-01-10 02:26:21] MarkAndrewSlade at gmail dot com
Description:
Unlike echo, the print construct is allowed inside logic clauses. If it is
reached (not short-circuited), it will cause the rest of that clause to be
true.
Tested with 5.3.8 and PHP 5.3.9RC5-dev, both with default configure.
Test script:
---
Expected result:
The word "Pass" five times.
Actual result:
--
The middle three fail. The first and last pass, and are included to
demonstrate
the limits of the bug.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60694&edit=1
Req #38917 [Com]: OpenSSL: signing function for spkac
Edit report at https://bugs.php.net/bug.php?id=38917&edit=1
ID: 38917
Comment by: jason dot gerfen at gmail dot com
Reported by:zeph at purotesto dot it
Summary:OpenSSL: signing function for spkac
Status: Feedback
Type: Feature/Change Request
Package:OpenSSL related
Operating System: Irrilevant
PHP Version:trunk
Block user comment: N
Private report: N
New Comment:
I have added the requested test case and it is included in the patch
as 026.phpt. I have also performed the required testing against the
Openssl 0.9.8x and 1.0.0x. It is attached to the original bug report
#38917. In addition to attaching the proposed patch I have created a
github repo to make maintenance on the patch simple for myself. The
URL is https://github.com/jas-/SPKAC-PHP-OpenSSL.
Previous Comments:
[2011-12-21 10:49:08] jason dot gerfen at gmail dot com
Once again, please disregard the last message. After researching the
documentation I found that where I had been using NULL with the
openssl_csr_sign() function allows for a CA option as well as the SPKAC
addition to the configargs optional array.
The patch was updated last night to include the 026.phpt test script, as well
as the five new functions to work with the SPKI provided by keygen tags.
How do patch inclusions work besides posting them to the php internals list?
[2011-12-14 22:10:52] jason dot gerfen at gmail dot com
Please disregard my previous comment. I did a little more digging and am under
the impression that adding the following to php_openssl_make_REQ() function
should allow me to create a self signed certificate using the SPKAC NID like so?
if (strcmp(strindex, "SPKAC") == 0) {
if (!X509_NAME_add_entry_by_txt(subj, strindex, MBSTRING_ASC, (unsigned
char*)Z_STRVAL_PP(item), -1, -1, 0)){
php_error_docref(NULL TSRMLS_CC, E_WARNING, "dn: add_entry_by_txt %s -> %s
(failed)", strindex, Z_STRVAL_PP(item));
return FAILURE;
}
}
Would you recommend another method? Please advise.
[2011-12-14 19:40:20] jason dot gerfen at gmail dot com
One other question about using SPKAC's when creating a x509. It seems the
current method using openssl_csr_new() which in turn calls the
php_openssl_make_REQ() to assign the specified DN attributes has no method of
adding the SPKAC field.
After digging around it seems logical to use the OBJ_create() and OBJ_* family
of functions to add NID. Please forgive me if I am way off here but any
direction you could point me in using the existing functions to output and sign
a certificate similar to the following command?
openssl ca -config /path/to/openssl.conf -days 180 -notext -batch \
-spkac /path/to/cert.pem -out /path/to/signed.pem -passin pass:'random'
My assumption is that I will need to create one specifically for this purpose
but would like your insight.
[2011-12-14 13:51:42] jason dot gerfen at gmail dot com
This will test all five new functions unless you would like one test case per
function?
--TEST--
openssl_spki_new(), openssl_spki_verify(), openssl_spki_export(),
openssl_spki_export_challenge(), openssl_spki_details()
--SKIPIF--
--FILE--
--EXPECT--
Creating private key
Creating new SPKAC
Verifying SPKAC
Exporting challenge
Exporting public key from SPKAC
Generating details of SPKAC structure
OK!
[2011-12-14 12:02:35] paj...@php.net
Please see the phpt files in ext/openssl/tests/
this is how tests should be written.
Further explanations are available here: http://qa.php.net/
Thanks!
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
https://bugs.php.net/bug.php?id=38917
--
Edit this bug report at https://bugs.php.net/bug.php?id=38917&edit=1
[PHP-BUG] Bug #60699 [NEW]: mysqli_init() crashes under high concurrency
From: Operating system: Windows 7 PHP version: 5.4.0RC5 Package: MySQLi related Bug Type: Bug Bug description:mysqli_init() crashes under high concurrency Description: Calling purely mysqli_init() crashes PHP under high concurrency. Using VC9 x86 Thread Safe (2012-Jan-06 02:06:02) build of PHP 5.4.0RC5. Using Apache HTTPd 2.2.21.0. Using ab (apache benchmark) tool to simulate high loads: "ab -c 30 -n 2000 http://localhost:8080/index.php";. PHP installed as module. Test script: --- mysqli_init(); Expected result: No crash Actual result: -- Crash -- Edit bug report at https://bugs.php.net/bug.php?id=60699&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60699&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60699&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60699&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60699&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60699&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60699&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60699&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60699&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60699&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60699&r=support Expected behavior: https://bugs.php.net/fix.php?id=60699&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60699&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60699&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60699&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60699&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60699&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60699&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60699&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60699&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60699&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60699&r=mysqlcfg
Bug #60695 [Opn]: bind_param 'd' appends a 0
Edit report at https://bugs.php.net/bug.php?id=60695&edit=1
ID: 60695
User updated by:nbari at dalmp dot com
Reported by:nbari at dalmp dot com
Summary:bind_param 'd' appends a 0
Status: Open
Type: Bug
Package:MySQLi related
Operating System: FreeBSD
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
The type of column 'name' is text()
After inserting the data, I query via mysql console directly on a terminal and
notice the 0, so i can confirm it is not an issue with a software displaying or
formatting numbers with 2 decimal places.
I made the same test using 'i' (for integer) and instead of 99.3 the stored
value
was just 99 (no 0 appended), when using 's' is is working but I start noticing
this strange behaivor when the search string was an double.
my search query/code is like this:
$sql = 'select id from test where name=?';
$param = $_POST['name'];
if (is_numeric($param)) {
$param = !strcmp(intval($param), $param) ? (int)$param :
(!strcmp(floatval($param), $param) ? (float)$param : $param);
}
$type = is_int($param) ? 'i' : (is_float($param) ? 'd' : (is_string($param) ?
's' : 'b'));
$stmt->bind_param($type,$param);
$stmt->execute();
$stmt->close();
Initially I though that the 'sanitation' made was affecting the results but
later manually I specified the types and notice that only with doubles 'd' this
was happening.
Previous Comments:
[2012-01-10 05:44:34] anon at anon dot anon
What is the type of the column 'name'?
If it's a string, then bind it as 's' instead of 'd'. If it's a double, there's
no problem; it's the same number and the internal bits of a double do not have
a way to represent "93.3" and "93.30" differently -- the bits are identical, so
the issue is the program or code you're using for *displaying* the number is
formatting it with 2 decimal places on purpose.
[2012-01-10 02:51:01] nbari at dalmp dot com
Description:
---
>From manual page: http://www.php.net/mysqli-stmt.bind-param#refsect1-mysqli-
stmt.bind-param-parameters
---
When inserting a 'double' using prepared statements
d corresponding variable has type double
if the number is on the format n.y example:1.3, or 99.3, an '0' is appended to
the number, storing something like 1.30, or 99.30 instead of just 1.3 or 99.3
Test script:
---
$mysqli = new mysqli('localhost','dalmp','test','test');
/* check connection */
if (mysqli_connect_errno()) {
printf("Connect failed: %s\n", mysqli_connect_error());
exit();
}
$name = 99.3;
if ($stmt = $mysqli->prepare('INSERT INTO test set name=?')) {
$stmt->bind_param('d',$name);
$stmt->execute();
$stmt->close();
}
$mysqli->close();
#this will store 99.30 instead of just 99.3
Expected result:
do not alter/append the input with a 0 when selecting 'd' as the bind_parameter
--
Edit this bug report at https://bugs.php.net/bug.php?id=60695&edit=1
Bug #60666 [Opn]: scandir doesn''t return entries on GlusterFS (redHat's) file system
Edit report at https://bugs.php.net/bug.php?id=60666&edit=1
ID: 60666
User updated by:hunter at yessoftware dot com
Reported by:hunter at yessoftware dot com
Summary:scandir doesn''t return entries on GlusterFS
(redHat's) file system
Status: Open
Type: Bug
Package:Directory function related
Operating System: CentOS 5.7
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
I solved it by rebuilding php with
export CPPFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
./configure
Previous Comments:
[2012-01-07 12:36:17] hunter at yessoftware dot com
PHP strace:
10458 open("/sites/cache", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
10458 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
10458 getdents(3, 0x9d0640c, 32768) = -1 EINVAL (Invalid argument)
10458 close(3) = 0
10458 write(1, "0\r\n", 3) = 3
10458 open("/nonglustered/dir", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
10458 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
10458 getdents(3, 0x9d0640c, 32768) = 120
10458 getdents(3, 0x9d0640c, 32768) = 0
10458 close(3) = 0
10458 write(1, "3\r\n", 3) = 3
10458 close(0) = 0
Perl strace
open("/sites/other", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
brk(0x8608000) = 0x8608000
getdents64(3, /* 24 entries */, 32768) = 1352
write(1, "12548855754ef9fb85723261.9149936"..., 38) = 38
So goal is to use getdents64 instead of getdents.
The original Linux getdents() system call did not handle large file systems and
large file offsets. Consequently, Linux 2.4 added getdents64(), with wider
types for the d_ino and d_off fields employed in the linux_dirent structure.
[2012-01-05 22:13:27] hunter at yessoftware dot com
Description:
When I'm trying to scandir or opendir/readdir on GlusterFS Distributed volumes
(mounted to some folder) I got something but not I'm expecting to obtainan:
empty array even without . and .. entries, only . entry, 2-3 entries instead of
>100 and so on.
Other ways (bash ls or perl opendir) works correctly.
for example:
distributed GlusterFS volume mounted to /sites/blog folder.
scandir("/sites/blog");
array(0) {
}
distributed GlusterFS volume mounted to /sites/other folder:
scandir("/sites/other");
array(1) {
[0]=>
string(1) "."
}
scandir("/sites/other/old");
array(3) {
[0]=>
string(1) "."
[1]=>
string(11) "1.2.0.2540"
[2]=>
string(11) "1.5.0.2559"
}
Test script:
---
--
Edit this bug report at https://bugs.php.net/bug.php?id=60666&edit=1
Bug #60671 [Bgs->Opn]: fread does not fail when operating on a write only stream
Edit report at https://bugs.php.net/bug.php?id=60671&edit=1
ID: 60671
Updated by: cataphr...@php.net
Reported by:james dot turner dot phpninja at gmail dot com
Summary:fread does not fail when operating on a write only
stream
-Status: Bogus
+Status: Open
Type: Bug
Package:Streams related
Operating System: Ubuntu 11.04
PHP Version:5.3.8
-Assigned To:
+Assigned To:cataphract
Block user comment: N
Private report: N
New Comment:
All right, I'll give a bit more thought to this.
Previous Comments:
[2012-01-08 21:45:18] phpmpan at mpan dot pl
You are right: no one should try to read from write-only stream. Also no one
should try to divide by 0 and no one should pass something other than stream to
`fread`. But people do it all the time and that's why errors, warnings,
exceptions and status codes exist. Using an invalid type of a stream is an
error too and should be reported.
If returning `FALSE` from `fread` breaks something, than I agree: `fread`
bahaviour should not be changed. However a warning does not break anything, so
it can be emitted. Since `php_stream` stores `fopen` flags in `mode`, I believe
this can be done easily:
--- BEGIN DIFF ---
diff php5.3-201201041830/ext/standard/file.c
php5.3-201201041830-modified/ext/standard/file.c
1893a1894,1898
>
> if (strpbrk(stream->mode, "+r") == NULL) { /* r or any + mode is fine */
> php_error_docref(NULL TSRMLS_CC, E_WARNING,
> "Reading from a write-only stream");
> }
END DIFF
After this modification some of ext/standard/tests/file/007* tests will fail,
but this is expected.
I agree that this case is a feature request.
[2012-01-08 09:29:07] james dot turner dot phpninja at gmail dot com
I feel I should say that just because the behaviour is analogous to the way the
underlying C works does not make it correct nor useful.
While I concur that one should not really attempt to read from a write-only
stream, I DO feel that any attempt to perform such an action should warrant an
exception/warning/error of some sort. This is currently not the case and as a
result can lead to potential indefinite loops given recommended usage in the
PHP documentation.
Perhaps this should be a feature/change request?
[2012-01-08 02:51:16] phpmpan at mpan dot pl
Let me change your code just a bit:
---
#include
int main(void)
{
FILE *f = fopen("/tmp/foobaz", "w");
printf("feof: %d\n", feof(f));
printf("ferror: %d\n", ferror(f)); // <- HERE
printf("read: %zd\n", fread((char[100]) {}, 1, 100, f));
printf("feof: %d\n", feof(f));
printf("ferror: %d\n", ferror(f)); // <- AND HERE
return 0;
}
gcc --std=c99 h.c && ./a.out
feof: 0
ferror: 0
read: 0
feof: 0
ferror: 1
---
In PHP there is no `ferror`. `feof` does work of both stdio's `feof` and
`ferror`, as described in the documentation [1]: "Returns TRUE if the file
pointer is at EOF or an error occurs".
Therefore, if we use analogy to stdio, `feof` should return `TRUE` in this case.
[1] http://pl.php.net/manual/en/function.feof.php
[2012-01-06 21:17:49] cataphr...@php.net
This is not a bug. fread only returns false if given invalid arguments. The bug
is that you try to read from a stream that's write-only.
This C program has analogous behavior:
#include
int main(void)
{
FILE *f = fopen("/tmp/foobaz", "w");
printf("feof: %d\n", feof(f));
printf("read: %zd\n", fread((char[100]) {}, 1, 100, f));
printf("feof: %d\n", feof(f));
return 0;
}
gcc --std=c99 h.c && ./a.out
feof: 0
read: 0
feof: 0
[2012-01-06 16:01:07] phpmpan at mpan dot pl
CONFIRMED for both 5.3.8 and 5.3.7 on Arch64, and for 5.3.4 on an unknown Linux.
Note however, that the test script provided by OP is wrong. It should be:
BEGIN CODE
$tmp = tempnam(sys_get_temp_dir(), 'test_');
$stream = fopen($tmp, 'w');
$data = "";
while(!feof($stream)){
if(false === ($data = fread($stream, 8192))){
break; // ^ no dot here
};
}
- END CODE -
OP's code will fail regardless of the bug, because .= always produces a string.
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
https://bugs.php.net/bug.php?i
Bug #40574 [Com]: file_put_contents fails with ftp wrapper
Edit report at https://bugs.php.net/bug.php?id=40574&edit=1
ID: 40574
Comment by: simonsimcity at gmail dot com
Reported by:arn...@php.net
Summary:file_put_contents fails with ftp wrapper
Status: No Feedback
Type: Bug
Package:Streams related
PHP Version:5.2.1
Block user comment: N
Private report: N
New Comment:
I think I have the same issue reproduced in a slightly different way:
In one script I tried to upload a file using WebDAV. Therefore I used the
PHP-Library HTTP_WebDAV_Client_Stream.
This library registers the streams webdav:// and webdavs://
When I try to save into that stream using file_put_contents() it fails
returning "Only 0 of 160 bytes written, possibly out of free disk space" .. but
the work-arround (using fopen, fwrite and fclose) works.
Here's the code:
http://pastebin.com/8tDqyg4K
Previous Comments:
[2007-05-30 00:49:33] lc at nospam dot com
I am also getting the same behavior mat describes using 5.2.2 The only
way to get a successfull upload using file_put_contents using a ftp
stream is when the file being uploaded does not exist on the server.
Subsequent uploads with the stream_context of overwrite being true
result in a zero-byte file
[2007-03-28 14:34:44] mat at actiondb dot com
The example:
array("overwrite"=>true)));
var_dump(file_put_contents("ftp://localhost/upload/data.txt";, "data", 0, $c));
?>
Will output int(4), but if you check the FTP server, the file will probably be
0 bytes.
I have been trying to resolve this problem myself, and it seems that if the
file is greater than around 30K-35K (maybe it's 32K?), the upload works.
I'm using PHP 5.2.1 on Apache 2.2.4 installed on Win2k3
[2007-03-14 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2007-03-06 11:55:08] tony2...@php.net
Can't reproduce using vsftpd.
[2007-03-05 13:48:52] arn...@php.net
Using proftpd with authentication fails
php > $c = stream_context_create(array("ftp" => array("overwrite"=>true)));
php > var_dump(file_put_contents("ftp://xx:xx@localhost/data.txt";, "data", 0,
$c));
Warning: file_put_contents(): Only 0 of 4 bytes written, possibly out of free
disk space in php shell code on line 1
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
https://bugs.php.net/bug.php?id=40574
--
Edit this bug report at https://bugs.php.net/bug.php?id=40574&edit=1
Bug #40574 [Com]: file_put_contents fails with ftp wrapper
Edit report at https://bugs.php.net/bug.php?id=40574&edit=1
ID: 40574
Comment by: simonsimcity at gmail dot com
Reported by:arn...@php.net
Summary:file_put_contents fails with ftp wrapper
Status: No Feedback
Type: Bug
Package:Streams related
PHP Version:5.2.1
Block user comment: N
Private report: N
New Comment:
Please ignore/delete my last comment. I was not seriously checking the script I
run.
The PEAR-library seem to have an error here because I do not get an error on
using fopen, frwite and fclose, but the file is not written.
Previous Comments:
[2012-01-10 15:17:09] simonsimcity at gmail dot com
I think I have the same issue reproduced in a slightly different way:
In one script I tried to upload a file using WebDAV. Therefore I used the
PHP-Library HTTP_WebDAV_Client_Stream.
This library registers the streams webdav:// and webdavs://
When I try to save into that stream using file_put_contents() it fails
returning "Only 0 of 160 bytes written, possibly out of free disk space" .. but
the work-arround (using fopen, fwrite and fclose) works.
Here's the code:
http://pastebin.com/8tDqyg4K
[2007-05-30 00:49:33] lc at nospam dot com
I am also getting the same behavior mat describes using 5.2.2 The only
way to get a successfull upload using file_put_contents using a ftp
stream is when the file being uploaded does not exist on the server.
Subsequent uploads with the stream_context of overwrite being true
result in a zero-byte file
[2007-03-28 14:34:44] mat at actiondb dot com
The example:
array("overwrite"=>true)));
var_dump(file_put_contents("ftp://localhost/upload/data.txt";, "data", 0, $c));
?>
Will output int(4), but if you check the FTP server, the file will probably be
0 bytes.
I have been trying to resolve this problem myself, and it seems that if the
file is greater than around 30K-35K (maybe it's 32K?), the upload works.
I'm using PHP 5.2.1 on Apache 2.2.4 installed on Win2k3
[2007-03-14 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2007-03-06 11:55:08] tony2...@php.net
Can't reproduce using vsftpd.
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
https://bugs.php.net/bug.php?id=40574
--
Edit this bug report at https://bugs.php.net/bug.php?id=40574&edit=1
Bug #60689 [Com]: Return $this double quoted __toString
Edit report at https://bugs.php.net/bug.php?id=60689&edit=1
ID: 60689
Comment by: phpmpan at mpan dot pl
Reported by:valentiny510 at yahoo dot es
Summary:Return $this double quoted __toString
Status: Open
Type: Bug
Package:Class/Object related
Operating System: windows xp
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Confirmed for 5.3.8 and for 2011/01/04 snapshots of 5.3, 5.4 and trunk, on
Arch64.
Inifnite recursion causing SIGSEGV. Partial backtrace:
--- BEGIN BACKTRACE ---
#0 0x005d853e in zend_mm_search_large_block (heap=
Cannot access memory at address 0x7f7fefc0
) at src-trunk/Zend/zend_alloc.c:1804
#1 0x005d8a50 in _zend_mm_alloc_int (heap=0xad72b0, size=32,
__zend_filename=0x86c908 "src-trunk/Zend/zend.c",
__zend_lineno=264, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at src-trunk/Zend/zend_alloc.c:1934
#2 0x005da624 in _emalloc (size=32,
__zend_filename=0x86c908 "src-trunk/Zend/zend.c",
__zend_lineno=264, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at src-trunk/Zend/zend_alloc.c:2425
#3 0x0060dfd9 in zend_make_printable_zval (expr=0x76777618,
expr_copy=0x7f7ff220, use_copy=0x7f7ff21c)
at src-trunk/Zend/zend.c:264
#4 0x00712d75 in ZEND_ADD_VAR_SPEC_UNUSED_CV_HANDLER (
execute_data=0x76710510)
at src-trunk/Zend/zend_vm_execute.h:25868
#5 0x0064e123 in execute (op_array=0x77fcbf68)
at src-trunk/Zend/zend_vm_execute.h:410
#6 0x005fd1de in zend_call_function (fci=0x7f7ff6e0,
fci_cache=0x7f7ff670)
at src-trunk/Zend/zend_execute_API.c:958
#7 0x0062edc1 in zend_call_method (object_pp=0x7f7ff798,
obj_ce=0x77fcab98, fn_proxy=0x77fcad00, function_name=0x872790
"__tostring",
function_name_len=10, retval_ptr_ptr=0x7f7ff7a8, param_count=0,
arg1=0x0,
arg2=0x0) at src-trunk/Zend/zend_interfaces.c:97
#8 0x006462e8 in zend_std_cast_object_tostring
(readobj=0x76777618,
writeobj=0x7f7ff960, type=6)
at src-trunk/Zend/zend_object_handlers.c:1494
#9 0x0060e0b4 in zend_make_printable_zval (expr=0x76801598,
expr_copy=0x7f7ff960, use_copy=0x7f7ff95c)
at src-trunk/Zend/zend.c:267
#10 0x00712d75 in ZEND_ADD_VAR_SPEC_UNUSED_CV_HANDLER (
execute_data=0x76710428)
at src-trunk/Zend/zend_vm_execute.h:25868
#11 0x0064e123 in execute (op_array=0x77fcbf68)
at src-trunk/Zend/zend_vm_execute.h:410
#12 0x005fd1de in zend_call_function (fci=0x7f7ffe20,
fci_cache=0x7f7ffdb0)
at src-trunk/Zend/zend_execute_API.c:958
(#7-#12 repeats)
END BACKTRACE
Previous Comments:
[2012-01-09 06:16:37] valentiny510 at yahoo dot es
Description:
If you try to return $this double quoted in __toString break all the system and
does not even throw any exception or log anything.
my php.ini have
error_reporting = E_ALL | E_STRICT
display_errors = On
display_startup_errors = On
log_errors = On
report_memleaks = On
report_zend_debug = 1
Test script:
---
class test
{
public function __toString ( )
{
return "$this";
}
}
$test = new test;
echo $test;
Expected result:
the string "$this" or the error exception
Actual result:
--
The server break completely and does not output nothing, not even the error log.
The browser say "The connection has been reset".
(The apache server is still logging the requests)
--
Edit this bug report at https://bugs.php.net/bug.php?id=60689&edit=1
Req #52761 [Com]: include backtrace in web server log on fatal error
Edit report at https://bugs.php.net/bug.php?id=52761&edit=1 ID: 52761 Comment by: walovaton at yahoo dot com dot mx Reported by:freeman3 at centrum dot cz Summary:include backtrace in web server log on fatal error Status: Bogus Type: Feature/Change Request Package:Apache2 related Operating System: opensuse PHP Version:5.3.3 Block user comment: N Private report: N New Comment: If you install xdebug you will get exactly what you want although it will make the execution somewhat slower (acceptable in development but maybe not in production). What I would like to see is a way to get a backtrace of the current point of execution in the PHP code in a similar way you get it from Java when you kill -3 the process ID. It doesn't die, instead it gives you a backtrace of what it's doing at that moment. Is there any way to do this?? I guess I should file a new enhancement request. Previous Comments: [2011-02-20 21:31:04] freeman3 at centrum dot cz I totally agree with robin, i still don't get why it's marked as bogus. How do you trace fatal errors? I you use a framework and an error occurs in a framework code file (like modelAbstract.php, which almost every other file uses), the error message like fatal error occured in modelAbstract.php is totally useless [2010-11-04 20:11:23] robin at robindaugherty dot net "if you want you can implement your error logger in user space" I don't believe it's possible to implement an error logger for fatal errors in user space. I see this as a huge problem. I develop and run a large site using PHP. I have a user-space handler for all other errors, notices, etc., but fatal errors are uncatchable and the log entry is usually missing enough information to track down the problem. For example: Fatal error: ob_start(): Cannot use output buffering in output buffering display handlers in [...]/ErrorHandler.php on line 785 I've tried to find a way to detect this, and having the backtrace would help. This particular code is called to render hundreds of variable on the page before the fatal one (which is apparently a non-fatal error or notice occurring inside of ob_gzhandler). I just need the call stack that exists when the error occurs. This is especially true of production sites, where I try to get enough information to at least reproduce issues. I get backtraces and context information for non-fatal errors, but the fatal errors are more important. [2010-09-01 22:52:15] freeman3 at centrum dot cz I know it's not a bug. That's why I marked it as feature request (where else should I post feature request?!?). And I didn't find such option in php manual. I wanted only extend the error message in the log, I don't want to install xdebug on production server... I still think it would be a good idea. [2010-09-01 21:30:41] johan...@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 You can install xdebug on your development server to get this feature. http://xdebug.org [2010-09-01 19:01:23] freeman3 at centrum dot cz Too long? I mean log only for fatal error and such. I happens only when developing application usually, few times a day. It would be few extra lines only. Access log has several GB usually so I think few lines doesn't matter. I think many developers would be grateful because this can save much time. I have tried something with shutdown handler but it didn't work for me. If you have a code that returns backtrace when fatal error occurs, I would be grateful. 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 https://bugs.php.net/bug.php?id=52761 -- Edit this bug report at https://bugs.php.net/bug.php?id=52761&edit=1
Req #38489 [Opn->Csd]: DOMNodeList should implement Traversable
Edit report at https://bugs.php.net/bug.php?id=38489&edit=1
ID: 38489
Updated by: jpa...@php.net
Reported by:mmcintyre at squiz dot net
Summary:DOMNodeList should implement Traversable
-Status: Open
+Status: Closed
Type: Feature/Change Request
Package:DOM XML related
Operating System: *
PHP Version:5.1.5
-Assigned To:
+Assigned To:jpauli
Block user comment: N
Private report: N
New Comment:
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
DomNodeListe implements Traversable. You can convert a Traversable object to an
Iterator using the IteratorIterator
class.
';
$doc = new DOMDocument;
$doc->loadXML($xml);
$queries = $doc->getElementsByTagName('queries');
$nodes = iterator_to_array(new IteratorIterator($queries));
?>
Previous Comments:
[2007-01-17 15:11:55] jules_papillon_fh at yahoo dot de
This bug exists further reproducibly on PHP5.2
[2007-01-17 15:09:11] jules_papillon_fh at yahoo dot de
Another Code to reproduce the Bug:
--
$dom = new DOMDocument('1.0', 'ISO-8859-1');
$dom->load('file.xml');
$iterator = new RecursiveIteratorIterator($dom->childNodes,
RecursiveIteratorIterator::SELF_FIRST);
foreach($iterator as $name => $element) {
print $name . "\n";
}
Expected result:
A recursive List of all Elements
Actual result:
--
"Catchable fatal error: Argument 1 passed to
RecursiveIteratorIterator::__construct() must implement interface Traversable,
instance of DOMNodeList given, called in [
] and defined in [
]"
[2006-08-18 06:37:22] mmcintyre at squiz dot net
Description:
Currently, a DOMNodeList object can be traversed using a foreach loop, but it
cannot be converted to an array using iterator_to_array(), as it produces an
error "Warning: iterator_to_array() expects parameter 1 to be Traversable,
object given"
Reproduce code:
---
$xml = '';
$doc = new DOMDocument;
$doc->loadXML($xml);
$queries = $doc->getElementsByTagName('queries');
$nodes = iterator_to_array($queries);
Expected result:
The nodes in the NodeList are returned as an array.
Actual result:
--
"Warning: iterator_to_array() expects parameter 1 to be Traversable, object
given"
--
Edit this bug report at https://bugs.php.net/bug.php?id=38489&edit=1
[PHP-BUG] Bug #60701 [NEW]: __toString() which stores $this reference triggers segfault
From:
Operating system: CentOS
PHP version: 5.3.8
Package: Class/Object related
Bug Type: Bug
Bug description:__toString() which stores $this reference triggers segfault
Description:
A simple object construction where a __toString() stores $this, will
trigger a
segfault during garbage collection at the end of the request.
Probably related bug: https://bugs.php.net/bug.php?id=60598
Is a distilled version of this bug: https://bugs.php.net/bug.php?id=60457
Test script:
---
object = new StringableObject();
return $this->object;
}
// This destructor is required to exist to trigger the segfault
public function __destruct()
{
}
}
class StringableObject
{
public function __toString()
{
$this->test = $this;
return '';
}
}
$container = new Container();
$object = $container->getObject();
// Any kind of function which triggers a 'to string' object conversion
// Casting $object with (string) will circumvent the problem
echo trim($object);
// Another call is required to corrupt heap
echo trim('test');
Expected result:
test
Actual result:
--
Segfault
gdb backtrace (with commandline PHP with build tag ZEND_DEBUG_OBJECTS)
[Thread debugging using libthread_db enabled]
Allocated object id #1
Allocated object id #2
Increased refcount of object id #2
Decreased refcount of object id #2
testIncreased refcount of object id #1
Decreased refcount of object id #1
Deallocated object id #1
Program received signal SIGSEGV, Segmentation fault.
0x006d4c69 in gc_zval_possible_root (zv=0x1023e40) at
/home/sjon/php-
debug/php-5.3.8/Zend/zend_gc.c:143
143GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv);
(gdb) bt
#0 0x006d4c69 in gc_zval_possible_root (zv=0x1023e40) at
/home/sjon/php-debug/php-5.3.8/Zend/zend_gc.c:143
#1 0x006c4ad8 in zend_hash_destroy (ht=0x10266d0) at
/home/sjon/php-
debug/php-5.3.8/Zend/zend_hash.c:529
#2 0x006d6009 in zend_object_std_dtor (object=0x1023dc8) at
/home/sjon/php-debug/php-5.3.8/Zend/zend_objects.c:45
#3 0x006d6029 in zend_objects_free_object_storage
(object=0x1023dc8) at
/home/sjon/php-debug/php-5.3.8/Zend/zend_objects.c:126
#4 0x006da037 in zend_objects_store_del_ref_by_handle_ex
(handle=2,
handlers=) at /home/sjon/php-debug/php-
5.3.8/Zend/zend_objects_API.c:220
#5 0x006da053 in zend_objects_store_del_ref (zobject=0x1022350) at
/home/sjon/php-debug/php-5.3.8/Zend/zend_objects_API.c:172
#6 0x006a9571 in _zval_dtor (zvalue=0x1022350) at /home/sjon/php-
debug/php-5.3.8/Zend/zend_variables.h:35
#7 _zval_ptr_dtor (zval_ptr=) at /home/sjon/php-debug/php-
5.3.8/Zend/zend_execute_API.c:447
#8 0x006c3645 in zend_hash_apply_deleter (ht=0xe33188,
p=0x1026728) at
/home/sjon/php-debug/php-5.3.8/Zend/zend_hash.c:612
#9 0x006c4f81 in zend_hash_reverse_apply (ht=0xe33188,
apply_func=0x6a9430 ) at /home/sjon/php-debug/php-
5.3.8/Zend/zend_hash.c:762
#10 0x006a9921 in shutdown_destructors () at
/home/sjon/php-debug/php-
5.3.8/Zend/zend_execute_API.c:226
#11 0x006b7747 in zend_call_destructors () at
/home/sjon/php-debug/php-
5.3.8/Zend/zend.c:875
#12 0x006651fd in php_request_shutdown (dummy=) at
/home/sjon/php-debug/php-5.3.8/main/main.c:1594
#13 0x0042d105 in main (argc=2, argv=0x7fffebb8) at
/home/sjon/php-
debug/php-5.3.8/sapi/cli/php_cli.c:1363
(gdb) frame 2
#2 0x006d6009 in zend_object_std_dtor (object=0x1023dc8) at
/home/sjon/php-debug/php-5.3.8/Zend/zend_objects.c:45
45zend_hash_destroy(object->properties);
(gdb) print object->ce->name
$1 = 0x1025af0 "StringableObject"
(gdb) frame 1
#1 0x006c4ad8 in zend_hash_destroy (ht=0x10266d0) at
/home/sjon/php-
debug/php-5.3.8/Zend/zend_hash.c:529
529ht->pDestructor(q->pData);
(gdb) print_ht ht
[0x010266d0] {
"test\0" => [0x01023e40] (refcount=-1) object
Program received signal SIGSEGV, Segmentation fault.
0x006da0a4 in zend_object_store_get_object (zobject=0x1023e40) at
/home/sjon/php-debug/php-5.3.8/Zend/zend_objects_API.c:272
272return
EG(objects_store).object_buckets[handle].bucket.obj.object;
The program being debugged was signaled while in a function called from
GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(zend_objects_get_address) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb)
--
Edit bug report at https://bugs.php.net/bug.php?id=60701&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60701&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60701&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60701&r=
Bug #60689 [Com]: Return $this double quoted __toString
Edit report at https://bugs.php.net/bug.php?id=60689&edit=1
ID: 60689
Comment by: valentiny510 at yahoo dot es
Reported by:valentiny510 at yahoo dot es
Summary:Return $this double quoted __toString
Status: Open
Type: Bug
Package:Class/Object related
Operating System: windows xp
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Looking into the source (zend_object_handlers.c) you don´t need the debugger:
ZEND_API int zend_std_cast_object_tostring(zval *readobj, zval *writeobj, int
type TSRMLS_DC) /* {{{ */
{
zval *retval;
zend_class_entry *ce;
switch (type) {
case IS_STRING:
ce = Z_OBJCE_P(readobj);
if (ce->__tostring &&
(zend_call_method_with_0_params(&readobj, ce, &ce->__tostring,
"__tostring", &retval) || EG(exception))) {
if (EG(exception)) {
if (retval) {
zval_ptr_dtor(&retval);
}
zend_error(E_ERROR, "Method %s::__toString() must not throw
an exception", ce->name);
return FAILURE;
}
if (Z_TYPE_P(retval) == IS_STRING) {
INIT_PZVAL(writeobj);
if (readobj == writeobj) {
zval_dtor(readobj);
}
ZVAL_ZVAL(writeobj, retval, 1, 1);
if (Z_TYPE_P(writeobj) != type) {
convert_to_explicit_type(writeobj, type);
}
return SUCCESS;
} else {
zval_ptr_dtor(&retval);
INIT_PZVAL(writeobj);
if (readobj == writeobj) {
zval_dtor(readobj);
}
ZVAL_EMPTY_STRING(writeobj);
zend_error(E_RECOVERABLE_ERROR, "Method %s::__toString()
must return a string value", ce->name);
return SUCCESS;
}
}
return FAILURE;
case IS_BOOL:
INIT_PZVAL(writeobj);
ZVAL_BOOL(writeobj, 1);
return SUCCESS;
case IS_LONG:
ce = Z_OBJCE_P(readobj);
zend_error(E_NOTICE, "Object of class %s could not be converted to
int", ce->name);
INIT_PZVAL(writeobj);
if (readobj == writeobj) {
zval_dtor(readobj);
}
ZVAL_LONG(writeobj, 1);
return SUCCESS;
case IS_DOUBLE:
ce = Z_OBJCE_P(readobj);
zend_error(E_NOTICE, "Object of class %s could not be converted to
double", ce->name);
INIT_PZVAL(writeobj);
if (readobj == writeobj) {
zval_dtor(readobj);
}
ZVAL_DOUBLE(writeobj, 1);
return SUCCESS;
default:
INIT_PZVAL(writeobj);
Z_TYPE_P(writeobj) = IS_NULL;
break;
}
return FAILURE;
}
Previous Comments:
[2012-01-10 15:25:37] phpmpan at mpan dot pl
Confirmed for 5.3.8 and for 2011/01/04 snapshots of 5.3, 5.4 and trunk, on
Arch64.
Inifnite recursion causing SIGSEGV. Partial backtrace:
--- BEGIN BACKTRACE ---
#0 0x005d853e in zend_mm_search_large_block (heap=
Cannot access memory at address 0x7f7fefc0
) at src-trunk/Zend/zend_alloc.c:1804
#1 0x005d8a50 in _zend_mm_alloc_int (heap=0xad72b0, size=32,
__zend_filename=0x86c908 "src-trunk/Zend/zend.c",
__zend_lineno=264, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at src-trunk/Zend/zend_alloc.c:1934
#2 0x005da624 in _emalloc (size=32,
__zend_filename=0x86c908 "src-trunk/Zend/zend.c",
__zend_lineno=264, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at src-trunk/Zend/zend_alloc.c:2425
#3 0x0060dfd9 in zend_make_printable_zval (expr=0x76777618,
expr_copy=0x7f7ff220, use_copy=0x7f7ff21c)
at src-trunk/Zend/zend.c:264
#4 0x00712d75 in ZEND_ADD_VAR_SPEC_UNUSED_CV_HANDLER (
execute_data=0x76710510)
at src-trunk/Zend/zend_vm_execute.h:25868
#5 0x0064e123 in execute (op_array=0x77fcbf68)
at src-trunk/Zend/zend_vm_execute.h:410
#6 0x005fd1de in zend_call_function (fci=0x7f7ff6e0,
fci_cache=0x7f7ff670)
at src-trunk/Zend/zend_execute_API.c:958
#7 0x0062edc1 in zend_call_method (object_pp=0x7f7ff798,
obj_ce=0x77fcab98, fn_proxy=0x77fcad00, function_name=0x872790
"__tostring",
function_name_len=10, retval_ptr_ptr=0x7f7ff7a8, param_count=0,
arg1=0x0,
arg2=0x0) at src-trunk/Zend/zend_interfaces.c:97
#8 0x006462e8 in zend_std_cast_object_tostring
(readobj=0x76777618,
writeobj=0x7f7ff960, type=6)
Req #52761 [Bgs]: include backtrace in web server log on fatal error
Edit report at https://bugs.php.net/bug.php?id=52761&edit=1 ID: 52761 User updated by:freeman3 at centrum dot cz Reported by:freeman3 at centrum dot cz Summary:include backtrace in web server log on fatal error Status: Bogus Type: Feature/Change Request Package:Apache2 related Operating System: opensuse PHP Version:5.3.3 Block user comment: N Private report: N New Comment: Still no response? this feature would be very useful. I can't use xdebug in production environment... is this some zend server only feature? Previous Comments: [2012-01-10 16:19:00] walovaton at yahoo dot com dot mx If you install xdebug you will get exactly what you want although it will make the execution somewhat slower (acceptable in development but maybe not in production). What I would like to see is a way to get a backtrace of the current point of execution in the PHP code in a similar way you get it from Java when you kill -3 the process ID. It doesn't die, instead it gives you a backtrace of what it's doing at that moment. Is there any way to do this?? I guess I should file a new enhancement request. [2011-02-20 21:31:04] freeman3 at centrum dot cz I totally agree with robin, i still don't get why it's marked as bogus. How do you trace fatal errors? I you use a framework and an error occurs in a framework code file (like modelAbstract.php, which almost every other file uses), the error message like fatal error occured in modelAbstract.php is totally useless [2010-11-04 20:11:23] robin at robindaugherty dot net "if you want you can implement your error logger in user space" I don't believe it's possible to implement an error logger for fatal errors in user space. I see this as a huge problem. I develop and run a large site using PHP. I have a user-space handler for all other errors, notices, etc., but fatal errors are uncatchable and the log entry is usually missing enough information to track down the problem. For example: Fatal error: ob_start(): Cannot use output buffering in output buffering display handlers in [...]/ErrorHandler.php on line 785 I've tried to find a way to detect this, and having the backtrace would help. This particular code is called to render hundreds of variable on the page before the fatal one (which is apparently a non-fatal error or notice occurring inside of ob_gzhandler). I just need the call stack that exists when the error occurs. This is especially true of production sites, where I try to get enough information to at least reproduce issues. I get backtraces and context information for non-fatal errors, but the fatal errors are more important. [2010-09-01 22:52:15] freeman3 at centrum dot cz I know it's not a bug. That's why I marked it as feature request (where else should I post feature request?!?). And I didn't find such option in php manual. I wanted only extend the error message in the log, I don't want to install xdebug on production server... I still think it would be a good idea. [2010-09-01 21:30:41] johan...@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 You can install xdebug on your development server to get this feature. http://xdebug.org 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 https://bugs.php.net/bug.php?id=52761 -- Edit this bug report at https://bugs.php.net/bug.php?id=52761&edit=1
Bug #60701 [Com]: __toString() which stores $this reference triggers segfault
Edit report at https://bugs.php.net/bug.php?id=60701&edit=1
ID: 60701
Comment by: sjon at hortensius dot net
Reported by:daan at react dot com
Summary:__toString() which stores $this reference triggers
segfault
Status: Open
Type: Bug
Package:Class/Object related
Operating System: CentOS
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
This bug is not reproducible when php is compiled with enable-debug. It is
however reproducible in other PHP versions, such as 5.3.7/5.3.6/5.3.5
Previous Comments:
[2012-01-10 16:43:17] daan at react dot com
Description:
A simple object construction where a __toString() stores $this, will trigger a
segfault during garbage collection at the end of the request.
Probably related bug: https://bugs.php.net/bug.php?id=60598
Is a distilled version of this bug: https://bugs.php.net/bug.php?id=60457
Test script:
---
object = new StringableObject();
return $this->object;
}
// This destructor is required to exist to trigger the segfault
public function __destruct()
{
}
}
class StringableObject
{
public function __toString()
{
$this->test = $this;
return '';
}
}
$container = new Container();
$object = $container->getObject();
// Any kind of function which triggers a 'to string' object conversion
// Casting $object with (string) will circumvent the problem
echo trim($object);
// Another call is required to corrupt heap
echo trim('test');
Expected result:
test
Actual result:
--
Segfault
gdb backtrace (with commandline PHP with build tag ZEND_DEBUG_OBJECTS)
[Thread debugging using libthread_db enabled]
Allocated object id #1
Allocated object id #2
Increased refcount of object id #2
Decreased refcount of object id #2
testIncreased refcount of object id #1
Decreased refcount of object id #1
Deallocated object id #1
Program received signal SIGSEGV, Segmentation fault.
0x006d4c69 in gc_zval_possible_root (zv=0x1023e40) at /home/sjon/php-
debug/php-5.3.8/Zend/zend_gc.c:143
143GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv);
(gdb) bt
#0 0x006d4c69 in gc_zval_possible_root (zv=0x1023e40) at
/home/sjon/php-debug/php-5.3.8/Zend/zend_gc.c:143
#1 0x006c4ad8 in zend_hash_destroy (ht=0x10266d0) at /home/sjon/php-
debug/php-5.3.8/Zend/zend_hash.c:529
#2 0x006d6009 in zend_object_std_dtor (object=0x1023dc8) at
/home/sjon/php-debug/php-5.3.8/Zend/zend_objects.c:45
#3 0x006d6029 in zend_objects_free_object_storage (object=0x1023dc8)
at
/home/sjon/php-debug/php-5.3.8/Zend/zend_objects.c:126
#4 0x006da037 in zend_objects_store_del_ref_by_handle_ex (handle=2,
handlers=) at /home/sjon/php-debug/php-
5.3.8/Zend/zend_objects_API.c:220
#5 0x006da053 in zend_objects_store_del_ref (zobject=0x1022350) at
/home/sjon/php-debug/php-5.3.8/Zend/zend_objects_API.c:172
#6 0x006a9571 in _zval_dtor (zvalue=0x1022350) at /home/sjon/php-
debug/php-5.3.8/Zend/zend_variables.h:35
#7 _zval_ptr_dtor (zval_ptr=) at /home/sjon/php-debug/php-
5.3.8/Zend/zend_execute_API.c:447
#8 0x006c3645 in zend_hash_apply_deleter (ht=0xe33188, p=0x1026728) at
/home/sjon/php-debug/php-5.3.8/Zend/zend_hash.c:612
#9 0x006c4f81 in zend_hash_reverse_apply (ht=0xe33188,
apply_func=0x6a9430 ) at /home/sjon/php-debug/php-
5.3.8/Zend/zend_hash.c:762
#10 0x006a9921 in shutdown_destructors () at /home/sjon/php-debug/php-
5.3.8/Zend/zend_execute_API.c:226
#11 0x006b7747 in zend_call_destructors () at /home/sjon/php-debug/php-
5.3.8/Zend/zend.c:875
#12 0x006651fd in php_request_shutdown (dummy=) at
/home/sjon/php-debug/php-5.3.8/main/main.c:1594
#13 0x0042d105 in main (argc=2, argv=0x7fffebb8) at /home/sjon/php-
debug/php-5.3.8/sapi/cli/php_cli.c:1363
(gdb) frame 2
#2 0x006d6009 in zend_object_std_dtor (object=0x1023dc8) at
/home/sjon/php-debug/php-5.3.8/Zend/zend_objects.c:45
45zend_hash_destroy(object->properties);
(gdb) print object->ce->name
$1 = 0x1025af0 "StringableObject"
(gdb) frame 1
#1 0x006c4ad8 in zend_hash_destroy (ht=0x10266d0) at /home/sjon/php-
debug/php-5.3.8/Zend/zend_hash.c:529
529ht->pDestructor(q->pData);
(gdb) print_ht ht
[0x010266d0] {
"test\0" => [0x01023e40] (refcount=-1) object
Program received signal SIGSEGV, Segmentation fault.
0x006da0a4 in zend_object_store_get_object (zobject=0x1023e40) at
/home/sjon/php-debug/php-5.3.8/Zend/zend_objects_API.c:272
272return EG(objects_store).object_buckets[handle].bucket.obj.object;
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal
[PHP-BUG] Req #60703 [NEW]: support for reference cursors on pdo_oci
From:
Operating system: Linux
PHP version: 5.3.8
Package: PDO related
Bug Type: Feature/Change Request
Bug description:support for reference cursors on pdo_oci
Description:
PDO_OCI doesn't yet allow fetching ref cursors with oracle (or any other
database).
This patch adds support for fetching reference cursors on pdo_oci on both
SELECT's as well CALL's to stored procedures (see the example below).
Test script:
---
$dbh = new PDO('oci:dbname=//localhost/XE', 'user', 'pass');
$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
$sql = "select cursor(select table_name, owner from all_tables where rownum
<= 1) as cursor from dual";
$sth = $dbh->prepare($sql);
$sth->execute();
$row = $sth->fetch(PDO::FETCH_ASSOC);
var_dump($row);
if (is_a($row['CURSOR'],'PDOStatement')) {
$sthc = $row['CURSOR'];
while ($rr = $sthc->fetch(PDO::FETCH_ASSOC)) {
var_dump($rr);
}
}
$sql = "begin OPEN :c FOR 'SELECT table_name FROM all_TABLES WHERE ROWNUM
<= 1'; END;";
$sthc = '';
$sth = $dbh->prepare($sql);
$sth->bindParam(":c", $sthc, PDO::PARAM_STMT|PDO::PARAM_INPUT_OUTPUT);
$sth->execute();
if ($sthc && is_a($sthc,'PDOStatement'))
while ($rr = $sthc->fetch(PDO::FETCH_ASSOC)) {
var_dump($rr);
}
Expected result:
array(1) {
["CURSOR"]=>
object(PDOStatement)#3 (1) {
["queryString"]=>
NULL
}
}
array(2) {
["TABLE_NAME"]=>
string(5) "ICOL$"
["OWNER"]=>
string(3) "SYS"
}
array(1) {
["TABLE_NAME"]=>
string(5) "ICOL$"
}
Actual result:
--
PHP Warning: PDOStatement::fetch(): SQLSTATE[HY000]: General error: 932
OCIStmtFetch: ORA-00932: inconsistent datatypes: expected CHAR got DTYCWD
Warning: PDOStatement::fetch(): SQLSTATE[HY000]: General error: 932
OCIStmtFetch: ORA-00932: inconsistent datatypes: expected CHAR got DTYCWD
bool(false)
PHP Warning: PDOStatement::execute(): SQLSTATE[HY000]: General error: 1008
OCIStmtExecute: ORA-01008: not all variables bound
Warning: PDOStatement::execute(): SQLSTATE[HY000]: General error: 1008
OCIStmtExecute: ORA-01008: not all variables bound
--
Edit bug report at https://bugs.php.net/bug.php?id=60703&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60703&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60703&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60703&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60703&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60703&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60703&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60703&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60703&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60703&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60703&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60703&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60703&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60703&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60703&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60703&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60703&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60703&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60703&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60703&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60703&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60703&r=mysqlcfg
[PHP-BUG] Bug #60704 [NEW]: unlink() bug with some files path
From:
Operating system: Linux 3.0.0-14-generic #23-Ubunt
PHP version: 5.3.8
Package: Filesystem function related
Bug Type: Bug
Bug description:unlink() bug with some files path
Description:
unlink() function truncates the file path name argument in some cases.
This bug appears also with the rename() function in the same cases.
The given source code use link() to duplicate a file, then unlink() to
remove the
source file. link() function works and unlink() bugs.
Test script:
---
#!/usr/local/bin/php
Expected result:
unlink() should remove the "/mnt/M://BRASIL/Carlinhos
Brown/Alfagamabetizado -
Angel's Robot List.mp3" file
Actual result:
--
root@djavanubu:/# ./b.php
Warning: unlink(BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot
List.mp3): No such file or directory in /b.php on line 8
###
below trace shows the truncated file path given to unlink() syscall:
[...]
lstat("/mnt/M://BRASIL", {st_mode=S_IFDIR|0755, st_size=69632, ...}) = 0
link("/mnt/M://BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot
List.mp3", "/mnt/M:/NEWBASE/BRASIL/Carlinhos Brown/Alfagamabetizado -
Angel's
Robot List.1.2.mp3") = 0
unlink("BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot List.mp3")
= -1
ENOENT (No such file or directory)
write(1, "\nWarning: unlink(BRASIL/Carlinho"..., 130
Warning: unlink(BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot
List.mp3): No such file or directory in /b.php on line 8
) = 130
[...]
--
Edit bug report at https://bugs.php.net/bug.php?id=60704&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60704&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60704&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60704&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60704&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60704&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60704&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60704&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60704&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60704&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60704&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60704&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60704&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60704&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60704&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60704&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60704&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60704&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60704&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60704&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60704&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60704&r=mysqlcfg
Bug #60694 [Opn]: print() results in bad logic
Edit report at https://bugs.php.net/bug.php?id=60694&edit=1
ID: 60694
User updated by:MarkAndrewSlade at gmail dot com
Reported by:MarkAndrewSlade at gmail dot com
Summary:print() results in bad logic
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: CentOS release 5.4 (Final)
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Oh, I see what happened. I agree with your recommendation. The documentation
says they are "not required" (implying optional), and they are used in the
actual example. I normally use echo, and without parens, so I just kinda
randomly came across this.
I'm not sure if you were saying the parser's interpretation was invalid or
mine,
but in case the latter and this is considered correct parsing, the
documentation
should be updated to reflect that it's "print ", without parens.
Developers can deduce for themselves that "print ('foo')" is allowed, but the
semantics will be clearer.
Previous Comments:
[2012-01-10 10:24:08] phpmpan at mpan dot pl
Invalid interpretation of the code caused by misleading parenthenses.
1. false && print ('')
-> false && (print (''))
-> false && 1
-> false
2. print('') && false
-> (print (('') && false))
-> (print false)
-> 1
-> true
3. print('') && false && false
-> (print ((('') && false) && false))
-> (print false)
-> 1
-> true
4. (print('') && false) && true
-> ( print (('') && false) ) && true
-> (print false) && true
-> 1 && true
-> true
5. (print('') && false) && false
-> (print (('') && false) && false
-> (print false) && false
-> 1 && false
-> false
I believe that documentation for all language constructs (`echo`, `include`,
`print`, ...) should explicitly discourage use of parenthenses around
arguments. They're very misleading.
[2012-01-10 02:26:21] MarkAndrewSlade at gmail dot com
Description:
Unlike echo, the print construct is allowed inside logic clauses. If it is
reached (not short-circuited), it will cause the rest of that clause to be
true.
Tested with 5.3.8 and PHP 5.3.9RC5-dev, both with default configure.
Test script:
---
Expected result:
The word "Pass" five times.
Actual result:
--
The middle three fail. The first and last pass, and are included to
demonstrate
the limits of the bug.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60694&edit=1
[PHP-BUG] Bug #60705 [NEW]: rijndael iv problem
From: Operating system: linux/windows PHP version: 5.3.8 Package: mcrypt related Bug Type: Bug Bug description:rijndael iv problem Description: Cryptography basics: IV is always the same as the block size, which is 16 bytes (128 bits) in case of AES(Rijndael). However, when you use RIJNDAEL_192 or RIJNDAEL_256 with an IV of 16 bytes in CBC mode, you got a warning "mcrypt_generic_init() [function.mcrypt-generic-init]: Iv size incorrect; supplied length: 16, needed: 32". This is bullshit. This way if you try to decrypt data encrypted by a 32 byte (256 bit) key with 16 byte (128 bit) IV with RIJNDAEL_256 in CBC mode, the decrypted data is WRONG. Even worse, if you modify the constant to RIJNDAEL_128, it decrypts the ciphertext correctly. This is a major failure. Tested with PHP 5.3.4 Win32 and 5.3.8 Linux. Test script: --- http://pastebin.com/X1S7bUXV Expected result: decrypted : hello world decrypted : *garbage* Actual result: -- Warning: mcrypt_generic_init() [function.mcrypt-generic-init]: Iv size incorrect; supplied length: 16, needed: 32 in ... decrypted : Ñ2âв ÐÐ/(Ñвy7YÐÆ0z=/оÑ|µ8â0У decrypted : hello world -- Edit bug report at https://bugs.php.net/bug.php?id=60705&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60705&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60705&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60705&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60705&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60705&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60705&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60705&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60705&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60705&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60705&r=support Expected behavior: https://bugs.php.net/fix.php?id=60705&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60705&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60705&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60705&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60705&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60705&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60705&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60705&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60705&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60705&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60705&r=mysqlcfg
Bug #60695 [Com]: bind_param 'd' appends a 0
Edit report at https://bugs.php.net/bug.php?id=60695&edit=1
ID: 60695
Comment by: anon at anon dot anon
Reported by:nbari at dalmp dot com
Summary:bind_param 'd' appends a 0
Status: Open
Type: Bug
Package:MySQLi related
Operating System: FreeBSD
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
>The type of column 'name' is text()
Then bind it as 's'.
Previous Comments:
[2012-01-10 12:08:47] nbari at dalmp dot com
The type of column 'name' is text()
After inserting the data, I query via mysql console directly on a terminal and
notice the 0, so i can confirm it is not an issue with a software displaying or
formatting numbers with 2 decimal places.
I made the same test using 'i' (for integer) and instead of 99.3 the stored
value
was just 99 (no 0 appended), when using 's' is is working but I start noticing
this strange behaivor when the search string was an double.
my search query/code is like this:
$sql = 'select id from test where name=?';
$param = $_POST['name'];
if (is_numeric($param)) {
$param = !strcmp(intval($param), $param) ? (int)$param :
(!strcmp(floatval($param), $param) ? (float)$param : $param);
}
$type = is_int($param) ? 'i' : (is_float($param) ? 'd' : (is_string($param) ?
's' : 'b'));
$stmt->bind_param($type,$param);
$stmt->execute();
$stmt->close();
Initially I though that the 'sanitation' made was affecting the results but
later manually I specified the types and notice that only with doubles 'd' this
was happening.
[2012-01-10 05:44:34] anon at anon dot anon
What is the type of the column 'name'?
If it's a string, then bind it as 's' instead of 'd'. If it's a double, there's
no problem; it's the same number and the internal bits of a double do not have
a way to represent "93.3" and "93.30" differently -- the bits are identical, so
the issue is the program or code you're using for *displaying* the number is
formatting it with 2 decimal places on purpose.
[2012-01-10 02:51:01] nbari at dalmp dot com
Description:
---
>From manual page: http://www.php.net/mysqli-stmt.bind-param#refsect1-mysqli-
stmt.bind-param-parameters
---
When inserting a 'double' using prepared statements
d corresponding variable has type double
if the number is on the format n.y example:1.3, or 99.3, an '0' is appended to
the number, storing something like 1.30, or 99.30 instead of just 1.3 or 99.3
Test script:
---
$mysqli = new mysqli('localhost','dalmp','test','test');
/* check connection */
if (mysqli_connect_errno()) {
printf("Connect failed: %s\n", mysqli_connect_error());
exit();
}
$name = 99.3;
if ($stmt = $mysqli->prepare('INSERT INTO test set name=?')) {
$stmt->bind_param('d',$name);
$stmt->execute();
$stmt->close();
}
$mysqli->close();
#this will store 99.30 instead of just 99.3
Expected result:
do not alter/append the input with a 0 when selecting 'd' as the bind_parameter
--
Edit this bug report at https://bugs.php.net/bug.php?id=60695&edit=1
Bug #60695 [Opn]: bind_param 'd' appends a 0
Edit report at https://bugs.php.net/bug.php?id=60695&edit=1
ID: 60695
User updated by:nbari at dalmp dot com
Reported by:nbari at dalmp dot com
Summary:bind_param 'd' appends a 0
Status: Open
Type: Bug
Package:MySQLi related
Operating System: FreeBSD
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
The point is that when using 'd' a 0 shouldn't be appended to the inputed value.
Using 's' works but the 'posible' bug report is related that to the 'd'
When using 'i' the stored value is like the expected, example 99.3 will store
only 99 and remove the .3 .
But when using 'd' the stored value instead of been or continue to be like the
input, in some cases an 0 is appended.
example:
99.3 is stored like 99.30
99.31 is stored like 99.31
1.1 is stored like 1.10
1.31 is stored like 1.31
for an unknown reason only doubles with 1 decimal are stored or reformatted to
be
have 2 decimals
Previous Comments:
[2012-01-10 23:13:35] anon at anon dot anon
>The type of column 'name' is text()
Then bind it as 's'.
[2012-01-10 12:08:47] nbari at dalmp dot com
The type of column 'name' is text()
After inserting the data, I query via mysql console directly on a terminal and
notice the 0, so i can confirm it is not an issue with a software displaying or
formatting numbers with 2 decimal places.
I made the same test using 'i' (for integer) and instead of 99.3 the stored
value
was just 99 (no 0 appended), when using 's' is is working but I start noticing
this strange behaivor when the search string was an double.
my search query/code is like this:
$sql = 'select id from test where name=?';
$param = $_POST['name'];
if (is_numeric($param)) {
$param = !strcmp(intval($param), $param) ? (int)$param :
(!strcmp(floatval($param), $param) ? (float)$param : $param);
}
$type = is_int($param) ? 'i' : (is_float($param) ? 'd' : (is_string($param) ?
's' : 'b'));
$stmt->bind_param($type,$param);
$stmt->execute();
$stmt->close();
Initially I though that the 'sanitation' made was affecting the results but
later manually I specified the types and notice that only with doubles 'd' this
was happening.
[2012-01-10 05:44:34] anon at anon dot anon
What is the type of the column 'name'?
If it's a string, then bind it as 's' instead of 'd'. If it's a double, there's
no problem; it's the same number and the internal bits of a double do not have
a way to represent "93.3" and "93.30" differently -- the bits are identical, so
the issue is the program or code you're using for *displaying* the number is
formatting it with 2 decimal places on purpose.
[2012-01-10 02:51:01] nbari at dalmp dot com
Description:
---
>From manual page: http://www.php.net/mysqli-stmt.bind-param#refsect1-mysqli-
stmt.bind-param-parameters
---
When inserting a 'double' using prepared statements
d corresponding variable has type double
if the number is on the format n.y example:1.3, or 99.3, an '0' is appended to
the number, storing something like 1.30, or 99.30 instead of just 1.3 or 99.3
Test script:
---
$mysqli = new mysqli('localhost','dalmp','test','test');
/* check connection */
if (mysqli_connect_errno()) {
printf("Connect failed: %s\n", mysqli_connect_error());
exit();
}
$name = 99.3;
if ($stmt = $mysqli->prepare('INSERT INTO test set name=?')) {
$stmt->bind_param('d',$name);
$stmt->execute();
$stmt->close();
}
$mysqli->close();
#this will store 99.30 instead of just 99.3
Expected result:
do not alter/append the input with a 0 when selecting 'd' as the bind_parameter
--
Edit this bug report at https://bugs.php.net/bug.php?id=60695&edit=1
[PHP-BUG] Bug #60706 [NEW]: Unable to compile pdo_mysql with mysqlnd
From: Operating system: Debian PHP version: 5.4.0RC5 Package: PDO related Bug Type: Bug Bug description:Unable to compile pdo_mysql with mysqlnd Description: Initially I was getting: /usr/local/src/php-5.4.0RC4/ext/pdo_mysql/php_pdo_mysql_int.h:27:34: fatal error: ext/mysqlnd/mysqlnd.h: No such file or directory so I did a mkdir ext && cp -r ../mysqlnd ./ext to fix the path issue. # php -v PHP 5.4.0RC4 (cli) (built: Jan 3 2012 12:00:03) # phpize -v Configuring for: PHP Api Version: 20100412 Zend Module Api No: 20100525 Zend Extension Api No: 220100525 Test script: --- phpize && ./configure && make && make install Expected result: Successful compilation Actual result: -- In file included from /usr/local/src/php- 5.4.0RC4/ext/pdo_mysql/ext/mysqlnd/mysqlnd.h:60:0, from /usr/local/src/php- 5.4.0RC4/ext/pdo_mysql/php_pdo_mysql_int.h:27, from /usr/local/src/php-5.4.0RC4/ext/pdo_mysql/pdo_mysql.c:32: /usr/local/src/php- 5.4.0RC4/ext/pdo_mysql/ext/mysqlnd/mysqlnd_portability.h:40:46: fatal error: ext/mysqlnd/php_mysqlnd_config.h: No such file or directory sure enough: total 804 drwxr-xr-x 2 root root 4096 Jan 10 18:27 . drwxr-xr-x 3 root root 4096 Jan 10 18:33 .. -rw-r--r-- 1 root root 2230 Jan 10 18:27 config9.m4 -rw-r--r-- 1 root root 1172 Jan 10 18:27 config.w32 -rw-r--r-- 1 root root 3312 Jan 10 18:27 config-win.h -rw-r--r-- 1 root root50 Jan 10 18:27 CREDITS -rw-r--r-- 1 root root 20160 Jan 10 18:27 mysqlnd_alloc.c -rw-r--r-- 1 root root 5934 Jan 10 18:27 mysqlnd_alloc.h -rw-r--r-- 1 root root 16643 Jan 10 18:27 mysqlnd_auth.c -rw-r--r-- 1 root root 5955 Jan 10 18:27 mysqlnd_block_alloc.c -rw-r--r-- 1 root root 1750 Jan 10 18:27 mysqlnd_block_alloc.h -rw-r--r-- 1 root root 14026 Jan 10 18:27 mysqlnd_bt.c -rw-r--r-- 1 root root 85349 Jan 10 18:27 mysqlnd.c -rw-r--r-- 1 root root 28599 Jan 10 18:27 mysqlnd_charset.c -rw-r--r-- 1 root root 2450 Jan 10 18:27 mysqlnd_charset.h -rw-r--r-- 1 root root 24722 Jan 10 18:27 mysqlnd_debug.c -rw-r--r-- 1 root root 7552 Jan 10 18:27 mysqlnd_debug.h -rw-r--r-- 1 root root 9753 Jan 10 18:27 mysqlnd_driver.c -rw-r--r-- 1 root root 17588 Jan 10 18:27 mysqlnd_enum_n_def.h -rw-r--r-- 1 root root 6530 Jan 10 18:27 mysqlnd_ext_plugin.c -rw-r--r-- 1 root root 3941 Jan 10 18:27 mysqlnd_ext_plugin.h -rw-r--r-- 1 root root 17025 Jan 10 18:27 mysqlnd.h -rw-r--r-- 1 root root 7534 Jan 10 18:27 mysqlnd_libmysql_compat.h -rw-r--r-- 1 root root 7651 Jan 10 18:27 mysqlnd_loaddata.c -rw-r--r-- 1 root root 36242 Jan 10 18:27 mysqlnd_net.c -rw-r--r-- 1 root root 1812 Jan 10 18:27 mysqlnd_net.h -rw-r--r-- 1 root root 5660 Jan 10 18:27 mysqlnd_plugin.c -rw-r--r-- 1 root root 19302 Jan 10 18:27 mysqlnd_portability.h -rw-r--r-- 1 root root 8949 Jan 10 18:27 mysqlnd_priv.h -rw-r--r-- 1 root root 73074 Jan 10 18:27 mysqlnd_ps.c -rw-r--r-- 1 root root 30964 Jan 10 18:27 mysqlnd_ps_codec.c -rw-r--r-- 1 root root 55262 Jan 10 18:27 mysqlnd_result.c -rw-r--r-- 1 root root 1780 Jan 10 18:27 mysqlnd_result.h -rw-r--r-- 1 root root 15375 Jan 10 18:27 mysqlnd_result_meta.c -rw-r--r-- 1 root root 1917 Jan 10 18:27 mysqlnd_result_meta.h -rw-r--r-- 1 root root 2845 Jan 10 18:27 mysqlnd_reverse_api.c -rw-r--r-- 1 root root 2019 Jan 10 18:27 mysqlnd_reverse_api.h -rw-r--r-- 1 root root 12464 Jan 10 18:27 mysqlnd_statistics.c -rw-r--r-- 1 root root 7945 Jan 10 18:27 mysqlnd_statistics.h -rw-r--r-- 1 root root 49400 Jan 10 18:27 mysqlnd_structs.h -rw-r--r-- 1 root root 77671 Jan 10 18:27 mysqlnd_wireprotocol.c -rw-r--r-- 1 root root 9884 Jan 10 18:27 mysqlnd_wireprotocol.h -rw-r--r-- 1 root root 12009 Jan 10 18:27 php_mysqlnd.c -rw-r--r-- 1 root root 1648 Jan 10 18:27 php_mysqlnd.h That file doesn't exist. -- Edit bug report at https://bugs.php.net/bug.php?id=60706&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60706&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60706&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60706&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60706&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60706&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60706&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60706&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60706&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60706&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60706&r=support Expected behavior: https://bugs.php.net/fix.php?id=60706&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60706&r=notenoughinf
Bug #48591 [Com]: Internal classes registered in extensions can cause PHP crash
Edit report at https://bugs.php.net/bug.php?id=48591&edit=1 ID: 48591 Comment by: register at cjsoft dot org Reported by:pforsub at gmail dot com Summary:Internal classes registered in extensions can cause PHP crash Status: Wont fix Type: Bug Package:Scripting Engine problem Operating System: Windows 2008 PHP Version:5.2.9 Assigned To:pajoye Block user comment: N Private report: N New Comment: The simpliest way to solve this bug without rebuild php itself (the binary distribution for windows servers!): INIT_CLASS_ENTRY(ce, "your_class", php_your_class_methods); #ifdef WIN32 char *cn = (char*) emalloc(strlen(ce.name)+1); strcpy(cn,ce.name); free(ce.name); ce.name = cn; #endif unix distribution don't need that path Previous Comments: [2009-06-18 15:52:27] paj...@php.net We do not support VC8 (2005) or VC9 (2008) for php 5.2 but VC6 SP6 with the platform SDK 2003/02. PHP 5.3 and later support VC9 SP1 (2008) with the SDK 6.1A. [2009-06-18 15:25:42] johan...@php.net Without checking: I assume his code crates a memleak, and I think you will have other issues when mixing different CRTs, Pierre, please confirm [2009-06-18 02:32:21] pforsub at gmail dot com Description: Custom PHP extension compiled in Visual Studio 2005. (which means it is compiled with CRT library msvcr80.dll) Extension declares internal class for exception. PHP cause crash (0xc005 Access denied) during shutdown of execution. Problem is that extension allocates string in its own CRT. This string used then by php5ts without copying content of string (just using pointer). During shutdown procedure extension is already unloaded, but php5ts tries to free memory allocated in extension and cause crash. Reproduce code: --- Declaring exception in ZEND_MINIT_FUNCTION(myownextension): zend_class_entry ce, *pce; INIT_CLASS_ENTRY(ce, "MyOwnException", NULL); pce = zend_register_internal_class_ex(&ce, zend_exception_get_default(TSRMLS_C), NULL TSRMLS_CC); Expected result: Expected: No crash. Proposed fix is: --- Zend/zend_API.c Fri Mar 07 00:28:47 2008 +++ Zend/zend_API.c Thu Jun 18 08:40:53 2009 @@ -1992,6 +1992,7 @@ zend_class_entry *class_entry = malloc(sizeof(zend_class_entry)); char *lowercase_name = malloc(orig_class_entry->name_length + 1); *class_entry = *orig_class_entry; + class_entry->name = strdup(orig_class_entry->name); class_entry->type = ZEND_INTERNAL_CLASS; zend_initialize_class_data(class_entry, 0 TSRMLS_CC); Probably you should change also logic of INIT_CLASS_ENTRY macros to avoid memory leak. Actual result: -- Crash occurs at the following call stack: # ZEND_API void destroy_zend_class(zend_class_entry **pce) # zend_hash_destroy(compiler_globals->class_table); # static void compiler_globals_dtor(zend_compiler_globals *compiler_globals TSRMLS_DC) Line that cause exception is zend_opcode.c (200): free(ce->name); -- Edit this bug report at https://bugs.php.net/bug.php?id=48591&edit=1
Bug #60694 [Com]: print() results in bad logic
Edit report at https://bugs.php.net/bug.php?id=60694&edit=1
ID: 60694
Comment by: phpmpan at mpan dot pl
Reported by:MarkAndrewSlade at gmail dot com
Summary:print() results in bad logic
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: CentOS release 5.4 (Final)
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Your interpretation was invalid. This is a common pitfall. The documentation is
very misleading, since it states that parenthenses are optional. This suggests
that they're a part of the language construct itself and work like parenthenses
in a function call. Unfortunely they aren't. They're interpreted as a part of
an expression that is later passed to `print` (`echo`, `include` and similar).
They have nothing to do with "function" itself. A nice example that shows this
issue is the following snippet:
print(string) TRUE;
I have posted a request (#60698) to change documentation.
Previous Comments:
[2012-01-10 22:00:46] MarkAndrewSlade at gmail dot com
Oh, I see what happened. I agree with your recommendation. The documentation
says they are "not required" (implying optional), and they are used in the
actual example. I normally use echo, and without parens, so I just kinda
randomly came across this.
I'm not sure if you were saying the parser's interpretation was invalid or
mine,
but in case the latter and this is considered correct parsing, the
documentation
should be updated to reflect that it's "print ", without parens.
Developers can deduce for themselves that "print ('foo')" is allowed, but the
semantics will be clearer.
[2012-01-10 10:24:08] phpmpan at mpan dot pl
Invalid interpretation of the code caused by misleading parenthenses.
1. false && print ('')
-> false && (print (''))
-> false && 1
-> false
2. print('') && false
-> (print (('') && false))
-> (print false)
-> 1
-> true
3. print('') && false && false
-> (print ((('') && false) && false))
-> (print false)
-> 1
-> true
4. (print('') && false) && true
-> ( print (('') && false) ) && true
-> (print false) && true
-> 1 && true
-> true
5. (print('') && false) && false
-> (print (('') && false) && false
-> (print false) && false
-> 1 && false
-> false
I believe that documentation for all language constructs (`echo`, `include`,
`print`, ...) should explicitly discourage use of parenthenses around
arguments. They're very misleading.
[2012-01-10 02:26:21] MarkAndrewSlade at gmail dot com
Description:
Unlike echo, the print construct is allowed inside logic clauses. If it is
reached (not short-circuited), it will cause the rest of that clause to be
true.
Tested with 5.3.8 and PHP 5.3.9RC5-dev, both with default configure.
Test script:
---
Expected result:
The word "Pass" five times.
Actual result:
--
The middle three fail. The first and last pass, and are included to
demonstrate
the limits of the bug.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60694&edit=1
[PHP-BUG] Bug #60707 [NEW]: max_input_vars allows one extra var
From: vrana Operating system: Irrelevant PHP version: 5.3.9 Package: Variables related Bug Type: Bug Bug description:max_input_vars allows one extra var Description: Setting max_input_vars to N allows N+1 variables. Test script: --- \n"; } var_dump($max_input_vars); var_dump(count($_POST)); ?> Expected result: string(4) "1000" int(1000) Actual result: -- string(4) "1000" int(1001) -- Edit bug report at https://bugs.php.net/bug.php?id=60707&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60707&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60707&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60707&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60707&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60707&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60707&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60707&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60707&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60707&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60707&r=support Expected behavior: https://bugs.php.net/fix.php?id=60707&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60707&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60707&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60707&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60707&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60707&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60707&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60707&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60707&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60707&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60707&r=mysqlcfg
[PHP-BUG] Bug #60708 [NEW]: segmentation fault, use max_input_vars
From: Operating system: x86_64 GNU/Linux PHP version: 5.3.9 Package: *General Issues Bug Type: Bug Bug description:segmentation fault, use max_input_vars Description: segmentation fault, use max_input_vars $ gdb /tmp/php-5.3.9/sapi/cgi/php-cgi (gdb) run -d max_input_vars=1 /tmp/cgitest.php a[]=1 v[]=2 Starting program: /tmp/php-5.3.9/sapi/cgi/php-cgi -d max_input_vars=1 /tmp/cgitest.php a[]=1 v[]=2 warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2aaab000 [Thread debugging using libthread_db enabled] Unknown(0) : Warning - Unknown: Input variables exceeded 1. To increase the limit change max_input_vars in php.ini. Unknown(0) : Warning - Unknown: Input variables exceeded 1. To increase the limit change max_input_vars in php.ini. Unknown(0) : Warning - Unknown: Input variables exceeded 1. To increase the limit change max_input_vars in php.ini. Program received signal SIGSEGV, Segmentation fault. 0x0077ba65 in php_register_variable_ex (var_name=0xfe6618 "v[]", val=0x7fffc100, track_vars_array=0xfe5eb8) at /tmp/php-5.3.9/main/php_variables.c:207 207 symtable1 = Z_ARRVAL_PP(gpc_element_p); (gdb) bt #0 0x0077ba65 in php_register_variable_ex (var_name=0xfe6618 "v[]", val=0x7fffc100, track_vars_array=0xfe5eb8) at /tmp/php-5.3.9/main/php_variables.c:207 #1 0x005886d9 in php_sapi_filter (arg=1, var=0xfe6618 "v[]", val=0x7fffc1c0, val_len=1, new_val_len=0x7fffc1b4) at /tmp/php-5.3.9/ext/filter/filter.c:461 #2 0x0077c6ca in php_default_treat_data (arg=1, str=0x0, destArray=0x0) at /tmp/php-5.3.9/main/php_variables.c:408 #3 0x0077d5b0 in php_hash_environment () at /tmp/php- 5.3.9/main/php_variables.c:716 #4 0x00769448 in php_request_startup () at /tmp/php- 5.3.9/main/main.c:1468 #5 0x008d0438 in main (argc=6, argv=0x7fffe928) at /tmp/php- 5.3.9/sapi/cgi/cgi_main.c:2035 Test script: --- https://bugs.php.net/bug.php?id=60708&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60708&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60708&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60708&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60708&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60708&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60708&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60708&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60708&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60708&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60708&r=support Expected behavior: https://bugs.php.net/fix.php?id=60708&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60708&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60708&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60708&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60708&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60708&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60708&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60708&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60708&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60708&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60708&r=mysqlcfg
Bug #44420 [Com]: upload_tmp_dir directive in php.ini ignored for file uploads
Edit report at https://bugs.php.net/bug.php?id=44420&edit=1 ID: 44420 Comment by: bushkonst at gmail dot com Reported by:jturner at paycomonline dot com Summary:upload_tmp_dir directive in php.ini ignored for file uploads Status: No Feedback Type: Bug Package:IIS related Operating System: Windows Server 2003 PHP Version:5.2.5 Block user comment: N Private report: N New Comment: I had a same problem: Win2008R2, PHP 5.2.12, and (upload_tmp_dir != tmp_name) when uploading. I had list the "upload_tmp_dir" on c:\ and in it was 65535(!) files php1.tmp - php.tmp. After truncatig folder, PHP become upload files corectly to "upload_tmp_dir" Previous Comments: [2010-04-20 04:55:18] f dot moretti at diciannove dot net I'm using php from debian package, PHP 5.2.13-0.dotdeb.0, that come with suhosin-patch 0.9.7, and i've written in my vhost configuration file this directive: php_admin_value open_basedir /home/data/mysite.org/:/usr/lib/php php_admin_value upload_tmp_dir/home/data/mysite.org/tmp/ but when i try to upload a file i receive this error: PHP Warning: file(): open_basedir restriction in effect. File(/tmp/phpCtsVNF) is not within the allowed path(s): (/home/data/mysite.org/:/usr/lib/php) in /home/data/mysite.org/file3.php on line 85 PHP Warning: file(/tmp/phpCtsVNF): failed to open stream: Operation not permitted in /home/data/mysite.org/file3.php on line 85 php is ignoring my directive, any workaround? [2009-08-29 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-08-21 19:36:31] paj...@php.net "/var/tmp/phpiXsjk3"? That's a linux path. Which php version do you use and on which platform? [2009-08-21 18:42:28] adam at ingenesis-ca dot com Experiencing exactly the same thing... I ran phpinfo() and it properly reflects the new php.ini setting in local and master, but the script keeps throwing an error saying "/var/tmp/phpiXsjk3" doesn't exist (the original path that i don't want to use). What the F. [2009-03-01 01:22:37] ka...@php.net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. 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 https://bugs.php.net/bug.php?id=44420 -- Edit this bug report at https://bugs.php.net/bug.php?id=44420&edit=1
[PHP-BUG] Bug #60709 [NEW]: Any php file of size 8192 bytes crashes Apache and PHP
From:
Operating system: Win All
PHP version: 5.4.0RC5
Package: Reproducible crash
Bug Type: Bug
Bug description:Any php file of size 8192 bytes crashes Apache and PHP
Description:
1. use Test script to generate crash.php, size 8192 bytes
2. now let crash php engine crash.php
3. Any php file of size 8192 bytes crashes Apache and PHP!
4. Tested with Apache 2.2.21 V9 apache longue, PHP 5.4.0 RC5 or RC6 dev on
three other machines, Win 7 x86 or Win 7 x64.
Test script:
---
testcase php file generator:
';
file_put_contents('crash.php',$out);
print('1. testcase file generated: crash.php, size '.strlen($out).'
bytes');
print('2. now let crash php engine crash.php');
print('3. Any php file of size 8192 bytes crashes
Apache and PHP!');
print('4. Tested with Apache 2.2.21 V9 apache longue, PHP 5.4.0 RC5 or RC6
dev on three other machines, Win 7 x86 or Win 7 x64.');
?>
Expected result:
NO crash
Actual result:
--
CRASH
--
Edit bug report at https://bugs.php.net/bug.php?id=60709&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60709&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60709&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60709&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60709&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60709&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60709&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60709&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60709&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60709&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60709&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60709&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60709&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60709&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60709&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60709&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60709&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60709&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60709&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60709&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60709&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60709&r=mysqlcfg
Bug #60709 [Com]: Any php file of size 8192 bytes crashes Apache and PHP
Edit report at https://bugs.php.net/bug.php?id=60709&edit=1
ID: 60709
Comment by: bugzilla33 at gmail dot com
Reported by:bugzilla33 at gmail dot com
Summary:Any php file of size 8192 bytes crashes Apache and
PHP
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Win All
PHP Version:5.4.0RC5
Block user comment: N
Private report: N
New Comment:
Apache error.log:
[Wed Jan 11 08:39:51 2012] [notice] Parent: child process exited with status
255 -- Restarting.
Previous Comments:
[2012-01-11 07:51:23] bugzilla33 at gmail dot com
Description:
1. use Test script to generate crash.php, size 8192 bytes
2. now let crash php engine crash.php
3. Any php file of size 8192 bytes crashes Apache and PHP!
4. Tested with Apache 2.2.21 V9 apache longue, PHP 5.4.0 RC5 or RC6 dev on
three other machines, Win 7 x86 or Win 7 x64.
Test script:
---
testcase php file generator:
';
file_put_contents('crash.php',$out);
print('1. testcase file generated: crash.php, size '.strlen($out).'
bytes');
print('2. now let crash php engine crash.php');
print('3. Any php file of size 8192 bytes crashes Apache
and PHP!');
print('4. Tested with Apache 2.2.21 V9 apache longue, PHP 5.4.0 RC5 or RC6 dev
on three other machines, Win 7 x86 or Win 7 x64.');
?>
Expected result:
NO crash
Actual result:
--
CRASH
--
Edit this bug report at https://bugs.php.net/bug.php?id=60709&edit=1
