#49084 [Bgs]: PSFS_FEED_ME causes stream block
ID: 49084 User updated by: morrisdavidd at gmail dot com Reported By: morrisdavidd at gmail dot com Status: Bogus Bug Type: Streams related Operating System: Linux/Unix PHP Version: 5.3.0 New Comment: My code was not intended to be "real world", it was intended to accent a bug. However, here's a slightly rewritten bug demonstration: http://capricorn.physics.fsu.edu/~ddm05/bug_demo2.txt With non-blocking I/O, I expect to see ~4 "Loop!" statements for each timestamp, since "Loop!" echos every .5 sec and the timestamp echos every 2 seconds. P.S. The output should be the same as when the filter is removed. Previous Comments: [2009-07-31 16:57:43] j...@php.net Well, your test is inherently buggy. You never return PSFS_PASS_ON from the filter to begin with. And yes, to get this really working you HAVE to use fread(). ---- [2009-07-30 02:42:09] morrisdavidd at gmail dot com Yes, that is what I expect to see. To restate: I do not expect to see an infinite number of "x"es on any non-block read like you see in "bug_demo". I expect the non-block read to return immediately resulting in another "Loop!" statement. i.e. I expect the output of "bug_demo" with the "badFilter" to be the same as with the "goodFilter" and the number of "x"es to be similar to the number of "Loop!"s.) [2009-07-29 23:15:16] j...@php.net We must have different idea of "working" or this is what you expect: $ sapi/cli/php -n working_demo.txt bool(true) Loop! xLoop! x Now, what should this output? [2009-07-29 19:00:30] morrisdavidd at gmail dot com See: http://capricorn.physics.fsu.edu/~ddm05/working_demo.txt Or were you asking for something else? The whole fgets vs fread thing shouldn't matter for this bug, I've came across plenty of "you should use fgets instead of fread when not blocking" statements before I submitted this code. So I did test fread which had no changes with respect to the bug except more overhead to extract separate lines.) [2009-07-29 13:50:54] j...@php.net Can you please provide reproducing scripts that actually give the expected output with the "goodFilter" ?? And fyi, with non-blocking you should use fread() instead of fgets().. 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/49084 -- Edit this bug report at http://bugs.php.net/?id=49084&edit=1
#49084 [Fbk->Opn]: PSFS_FEED_ME causes stream block
ID: 49084 User updated by: morrisdavidd at gmail dot com Reported By: morrisdavidd at gmail dot com -Status: Feedback +Status: Open Bug Type: Streams related Operating System: Linux/Unix PHP Version: 5.3.0 New Comment: Yes, that is what I expect to see. To restate: I do not expect to see an infinite number of "x"es on any non-block read like you see in "bug_demo". I expect the non-block read to return immediately resulting in another "Loop!" statement. i.e. I expect the output of "bug_demo" with the "badFilter" to be the same as with the "goodFilter" and the number of "x"es to be similar to the number of "Loop!"s. Previous Comments: [2009-07-29 23:15:16] j...@php.net We must have different idea of "working" or this is what you expect: $ sapi/cli/php -n working_demo.txt bool(true) Loop! xLoop! x Now, what should this output? ---------------- [2009-07-29 19:00:30] morrisdavidd at gmail dot com See: http://capricorn.physics.fsu.edu/~ddm05/working_demo.txt Or were you asking for something else? The whole fgets vs fread thing shouldn't matter for this bug, I've came across plenty of "you should use fgets instead of fread when not blocking" statements before I submitted this code. So I did test fread which had no changes with respect to the bug except more overhead to extract separate lines.) [2009-07-29 13:50:54] j...@php.net Can you please provide reproducing scripts that actually give the expected output with the "goodFilter" ?? And fyi, with non-blocking you should use fread() instead of fgets().. -------- [2009-07-28 06:08:58] morrisdavidd at gmail dot com Actual result is when leaving "badFilter".) [2009-07-28 06:07:22] morrisdavidd at gmail dot com Description: According to: http://us3.php.net/manual/en/function.stream-filter-register.php The return value of PSFS_FEED_ME for the method filter of extended classes of php_user_filter means: "Filter processed successfully, however no data was available to return. More data is required from the stream or prior filter." However, using the return value of PSFS_FEED_ME also inadvertently causes a block on stream read requests that should not be blocked (and an infinite poll for data?). Reproduce code: --- bug_demo.php: http://capricorn.physics.fsu.edu/~ddm05/bug_demo.txt test2.php: http://capricorn.physics.fsu.edu/~ddm05/test2.txt Expected result: When replacing the phrase "badFilter" with "goodFilter" in line 44: bool(true) Loop! xLoop! xxtest2: 1248760722 Loop! xLoop! xLoop! xLoop! xxtest2: 1248760724 Loop! xLoop! xLoop! xLoop! xxtest2: 1248760726 Loop! ... Actual result: -- bool(true) Loop! xxx... -- Edit this bug report at http://bugs.php.net/?id=49084&edit=1
#49084 [Fbk->Opn]: PSFS_FEED_ME causes stream block
ID: 49084 User updated by: morrisdavidd at gmail dot com Reported By: morrisdavidd at gmail dot com -Status: Feedback +Status: Open Bug Type: Streams related Operating System: Linux/Unix PHP Version: 5.3.0 New Comment: See: http://capricorn.physics.fsu.edu/~ddm05/working_demo.txt Or were you asking for something else? The whole fgets vs fread thing shouldn't matter for this bug, I've came across plenty of "you should use fgets instead of fread when not blocking" statements before I submitted this code. So I did test fread which had no changes with respect to the bug except more overhead to extract separate lines. Previous Comments: [2009-07-29 13:50:54] j...@php.net Can you please provide reproducing scripts that actually give the expected output with the "goodFilter" ?? And fyi, with non-blocking you should use fread() instead of fgets().. ---- [2009-07-28 06:08:58] morrisdavidd at gmail dot com Actual result is when leaving "badFilter".) ---- [2009-07-28 06:07:22] morrisdavidd at gmail dot com Description: According to: http://us3.php.net/manual/en/function.stream-filter-register.php The return value of PSFS_FEED_ME for the method filter of extended classes of php_user_filter means: "Filter processed successfully, however no data was available to return. More data is required from the stream or prior filter." However, using the return value of PSFS_FEED_ME also inadvertently causes a block on stream read requests that should not be blocked (and an infinite poll for data?). Reproduce code: --- bug_demo.php: http://capricorn.physics.fsu.edu/~ddm05/bug_demo.txt test2.php: http://capricorn.physics.fsu.edu/~ddm05/test2.txt Expected result: When replacing the phrase "badFilter" with "goodFilter" in line 44: bool(true) Loop! xLoop! xxtest2: 1248760722 Loop! xLoop! xLoop! xLoop! xxtest2: 1248760724 Loop! xLoop! xLoop! xLoop! xxtest2: 1248760726 Loop! ... Actual result: -- bool(true) Loop! xxx... -- Edit this bug report at http://bugs.php.net/?id=49084&edit=1
#49084 [Fbk->Opn]: PSFS_FEED_ME causes stream block
ID: 49084
User updated by: morrisdavidd at gmail dot com
Reported By: morrisdavidd at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Streams related
Operating System: Linux/Unix
PHP Version: 5.3.0
New Comment:
According to:
http://us2.php.net/manual/en/function.proc-open.php
... descriptorspec ... "An array describing the pipe to pass to the
process. The first element is the descriptor type and the second element
is an option for the given type. Valid types are pipe (the second
element is either r to pass the read end of the pipe to the process, or
w to pass the write end) "
So I open "w" because I want to pass the write end to the process that
I've opened so the process can write to it (and I can read from it).
On same page, see Example 1:
"
$descriptorspec = array(
0 => array("pipe", "r"), // stdin is a pipe that the child will
read from
1 => array("pipe", "w"), // stdout is a pipe that the child will
write to
2 => array("file", "/tmp/error-output.txt", "a") // stderr is a file
to write to
);
"
Previous Comments:
[2009-07-28 19:45:40] j...@php.net
Why do you open the pipe as writable one when you want to read from
it..?
------------
[2009-07-28 06:08:58] morrisdavidd at gmail dot com
Actual result is when leaving "badFilter".)
----
[2009-07-28 06:07:22] morrisdavidd at gmail dot com
Description:
According to:
http://us3.php.net/manual/en/function.stream-filter-register.php
The return value of PSFS_FEED_ME for the method filter of extended
classes of php_user_filter means: "Filter processed successfully,
however no data was available to return. More data is required from the
stream or prior filter."
However, using the return value of PSFS_FEED_ME also inadvertently
causes a block on stream read requests that should not be blocked (and
an infinite poll for data?).
Reproduce code:
---
bug_demo.php:
http://capricorn.physics.fsu.edu/~ddm05/bug_demo.txt
test2.php:
http://capricorn.physics.fsu.edu/~ddm05/test2.txt
Expected result:
When replacing the phrase "badFilter" with "goodFilter" in line 44:
bool(true)
Loop!
xLoop!
xxtest2: 1248760722
Loop!
xLoop!
xLoop!
xLoop!
xxtest2: 1248760724
Loop!
xLoop!
xLoop!
xLoop!
xxtest2: 1248760726
Loop!
...
Actual result:
--
bool(true)
Loop!
xxx...
--
Edit this bug report at http://bugs.php.net/?id=49084&edit=1
#47918 [Com]: stream_set_blocking() does not work with pipes opened with proc_open()
ID: 47918
Comment by: morrisdavidd at gmail dot com
Reported By: RQuadling at GMail dot com
Status: Open
Bug Type: Streams related
Operating System: Windows
PHP Version: 5.*, 6CVS (2009-06-19
New Comment:
I tested this on PHP 5.3 (on Linux) and duplicated the error that the
print_r command shows blocking as true. HOWEVER, the stream does not
block when actually tested... a simple test script can be created by
adding a line and slightly modifying the scripts found at:
http://bugs.php.net/bug.php?id=49084
Previous Comments:
[2009-06-19 11:12:34] j...@php.net
If it exists below 5.3, the version must state it! Do NOT touch it
again.
[2009-06-19 09:31:34] RQuadling at GMail dot com
Only worry about 5.3+
[2009-05-08 09:58:57] RQuadling at GMail dot com
I also tried opening the pipes descriptors like ...
$a_Descriptors = array(0 => array('pipe', 'rn'), 1 => array('pipe',
'wn'), 2 => array('pipe', 'wn'));
but no change.
[2009-04-07 21:50:45] RQuadling at GMail dot com
I tried both 0 and False to set non blocking mode. In all cases the
function returns false and the meta data reports that the pipe is
still in blocking mode.
I've just tried it with PHP 5.2.8 (cli) (built: Dec 8 2008 19:31:23)
(on Windows XP SP3) on my home laptop and the same problem.
[2009-04-07 12:31:33] RQuadling at GMail dot com
Description:
I'm trying to set non-blocking mode on pipes attached to a process
opened using proc_open.
The documentation and the user notes suggest that what I am doing
should work.
Running this with php -n to remove my ini file settings.
Reproduce code:
---
array('pipe', 'r'), 1 => array('pipe',
'w'), 2 => array('pipe', 'w'));
// Provide a place for the pipes.
$a_Pipes = array();
// Create the thread.
$r_Thread = proc_open("dir c:\\ /b", $a_Descriptors, $a_Pipes, Null,
$_ENV);
// Display the current STDOUT meta data.
print_r(stream_get_meta_data($a_Pipes[1]));
// Try to change the blocking mode to non-blocking.
echo (stream_set_blocking($a_Pipes[1], False) ? 'Successfully' :
'Failed'), ' to set blocking mode to non-blocking', PHP_EOL;
// Display the current STDOUT meta data.
print_r(stream_get_meta_data($a_Pipes[1]));
Expected result:
5.3.0RC2-dev WINNT cli
INI:
Array
(
[stream_type] => STDIO
[mode] => r
[unread_bytes] => 0
[seekable] =>
[timed_out] =>
[blocked] => 1
[eof] =>
)
Successfully set blocking mode to non-blocking
Array
(
[stream_type] => STDIO
[mode] => r
[unread_bytes] => 0
[seekable] =>
[timed_out] =>
[blocked] =>
[eof] =>
)
Actual result:
--
5.3.0RC2-dev WINNT cli
INI:
Array
(
[stream_type] => STDIO
[mode] => r
[unread_bytes] => 0
[seekable] =>
[timed_out] =>
[blocked] => 1
[eof] =>
)
Failed to set blocking mode to non-blocking
Array
(
[stream_type] => STDIO
[mode] => r
[unread_bytes] => 0
[seekable] =>
[timed_out] =>
[blocked] => 1
[eof] =>
)
--
Edit this bug report at http://bugs.php.net/?id=47918&edit=1
#45120 [NoF->Opn]: PDOStatement->execute() returns true then false for same statement
ID: 45120
User updated by: morrisdavidd at gmail dot com
Reported By: morrisdavidd at gmail dot com
-Status: No Feedback
+Status: Open
Bug Type: PDO related
Operating System: Linux
-PHP Version: 5.2.6
+PHP Version: 5.3
New Comment:
Sorry for the late reply,
I just duplicated this bug in PHP 5.3
Cheers,
David
Previous Comments:
[2009-05-03 01:00:13] 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-04-25 15:03:12] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2008-10-14 13:06:53] fel...@php.net
I can't reproduce it.
[2008-07-03 13:32:37] u...@php.net
On the first look this seems to be a PDO not a PDO_MYSQL (or any other
driver) bug.
>From pdo_stmt.c, static PHP_METHOD(PDOStatement, execute), around line
450:
if (PDO_PLACEHOLDER_NONE == stmt->supports_placeholders) {
/* handle the emulated parameter binding,
* stmt->active_query_string holds the query with binds
expanded and
* quoted.
*/
ret = pdo_parse_params(stmt, stmt->query_string,
stmt->query_stringlen,
&stmt->active_query_string,
&stmt->active_query_stringlen
TSRMLS_CC);
[...]
}
For some drivers, PDO assigns the return value of its
pdo_parse_params() function to ret. And then the code flow continues and
eventually the driver gets called to execute the statement (depending on
the driver features):
if (stmt->methods->executer(stmt TSRMLS_CC)) {
if (stmt->active_query_string && stmt->active_query_string !=
stmt->query_string) {
efree(stmt->active_query_string);
}
stmt->active_query_string = NULL;
if (!stmt->executed) {
/* this is the first execute */
if (stmt->dbh->alloc_own_columns && !stmt->columns) {
/* for "big boy" drivers, we need to allocate
memory to fetch
* the results into, so lets do that now */
ret = pdo_stmt_describe_columns(stmt TSRMLS_CC);
}
stmt->executed = 1;
}
if (ret && !dispatch_param_event(stmt, PDO_PARAM_EVT_EXEC_POST
TSRMLS_CC)) {
RETURN_FALSE;
}
RETURN_BOOL(ret);
}
ret (returned ny pdo_parse_params()) will be overwritten only on the
first execution. Upon subsequent executions the driver cannot set ret.
You get a bool(false) because pdo_parse_params() has returned 0 (=
success) and the return value of PDO_MYSQL has been ignored.
Maybe it should read like this:
if (ret = stmt->methods->executer(stmt TSRMLS_CC)) {
--------
[2008-05-28 20:53:59] morrisdavidd at gmail dot com
Description:
The query is the exact same every time the statement is called. There
are no parameters being bound. However, the function only returns true
the first time the PDO->execute() is called.
As per:
http://us3.php.net/manual/en/pdostatement.execute.php
"Return Values
Returns TRUE on success or FALSE on failure."
I've run a test where I had it sleep after the first $stmt->execute()
long enough for me to change the value of the data being selected from
the database (And I output the data being selected to make sure it was
retrieved in its changed form the second time around). It still returned
FALSE.
However, the documentation for the function states: "Execute the
prepared statement." ... "Returns TRUE on success or FALSE on failure."
So, the function returns FALSE when it executed the prepared statement
successfully.
Reproduce code:
---
Obviously You'll have to change the database name, user, pass,
table...
prepare("SELECT * FROM `".$table."` LIMIT 1;");
$foo = $stmt->execute();
$stmt->closeCursor();
echo "foo: ";
var_dump($foo);
$bar = $stmt->execute();
$stmt->closeCursor();
echo "bar: ";
var_dump($bar);
$foo2 = $stmt->execute();
$stmt->closeCursor();
#49084 [Opn]: PSFS_FEED_ME causes stream block
ID: 49084 User updated by: morrisdavidd at gmail dot com Reported By: morrisdavidd at gmail dot com Status: Open Bug Type: Streams related Operating System: Linux/Unix PHP Version: 5.3.0 New Comment: Actual result is when leaving "badFilter". Previous Comments: [2009-07-28 06:07:22] morrisdavidd at gmail dot com Description: According to: http://us3.php.net/manual/en/function.stream-filter-register.php The return value of PSFS_FEED_ME for the method filter of extended classes of php_user_filter means: "Filter processed successfully, however no data was available to return. More data is required from the stream or prior filter." However, using the return value of PSFS_FEED_ME also inadvertently causes a block on stream read requests that should not be blocked (and an infinite poll for data?). Reproduce code: --- bug_demo.php: http://capricorn.physics.fsu.edu/~ddm05/bug_demo.txt test2.php: http://capricorn.physics.fsu.edu/~ddm05/test2.txt Expected result: When replacing the phrase "badFilter" with "goodFilter" in line 44: bool(true) Loop! xLoop! xxtest2: 1248760722 Loop! xLoop! xLoop! xLoop! xxtest2: 1248760724 Loop! xLoop! xLoop! xLoop! xxtest2: 1248760726 Loop! ... Actual result: -- bool(true) Loop! xxx... -- Edit this bug report at http://bugs.php.net/?id=49084&edit=1
#49084 [NEW]: PSFS_FEED_ME causes stream block
From: morrisdavidd at gmail dot com Operating system: Linux/Unix PHP version: 5.3.0 PHP Bug Type: Streams related Bug description: PSFS_FEED_ME causes stream block Description: According to: http://us3.php.net/manual/en/function.stream-filter-register.php The return value of PSFS_FEED_ME for the method filter of extended classes of php_user_filter means: "Filter processed successfully, however no data was available to return. More data is required from the stream or prior filter." However, using the return value of PSFS_FEED_ME also inadvertently causes a block on stream read requests that should not be blocked (and an infinite poll for data?). Reproduce code: --- bug_demo.php: http://capricorn.physics.fsu.edu/~ddm05/bug_demo.txt test2.php: http://capricorn.physics.fsu.edu/~ddm05/test2.txt Expected result: When replacing the phrase "badFilter" with "goodFilter" in line 44: bool(true) Loop! xLoop! xxtest2: 1248760722 Loop! xLoop! xLoop! xLoop! xxtest2: 1248760724 Loop! xLoop! xLoop! xLoop! xxtest2: 1248760726 Loop! ... Actual result: -- bool(true) Loop! xxx... -- Edit bug report at http://bugs.php.net/?id=49084&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49084&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49084&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49084&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49084&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49084&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49084&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49084&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49084&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49084&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49084&r=support Expected behavior: http://bugs.php.net/fix.php?id=49084&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49084&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49084&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49084&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49084&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49084&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49084&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49084&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49084&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49084&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49084&r=mysqlcfg
#45120 [NEW]: PDOStatement->execute() returns true then false for same statement
From: morrisdavidd at gmail dot com
Operating system: Linux
PHP version: 5.2.6
PHP Bug Type: PDO related
Bug description: PDOStatement->execute() returns true then false for same
statement
Description:
The query is the exact same every time the statement is called. There are
no parameters being bound. However, the function only returns true the
first time the PDO->execute() is called.
As per:
http://us3.php.net/manual/en/pdostatement.execute.php
"Return Values
Returns TRUE on success or FALSE on failure."
I've run a test where I had it sleep after the first $stmt->execute() long
enough for me to change the value of the data being selected from the
database (And I output the data being selected to make sure it was
retrieved in its changed form the second time around). It still returned
FALSE.
However, the documentation for the function states: "Execute the prepared
statement." ... "Returns TRUE on success or FALSE on failure."
So, the function returns FALSE when it executed the prepared statement
successfully.
Reproduce code:
---
Obviously You'll have to change the database name, user, pass, table...
prepare("SELECT * FROM `".$table."` LIMIT 1;");
$foo = $stmt->execute();
$stmt->closeCursor();
echo "foo: ";
var_dump($foo);
$bar = $stmt->execute();
$stmt->closeCursor();
echo "bar: ";
var_dump($bar);
$foo2 = $stmt->execute();
$stmt->closeCursor();
echo "foo2: ";
var_dump($foo2);
$bar2 = $stmt->execute();
$stmt->closeCursor();
echo "bar2: ";
var_dump($bar2);
?>
Expected result:
foo: bool(true)
bar: bool(true)
foo2: bool(true)
bar2: bool(true)
Actual result:
--
foo: bool(true)
bar: bool(false)
foo2: bool(false)
bar2: bool(false)
--
Edit bug report at http://bugs.php.net/?id=45120&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45120&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45120&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45120&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45120&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45120&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45120&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45120&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45120&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45120&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45120&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45120&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45120&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45120&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45120&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45120&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45120&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45120&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45120&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45120&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45120&r=mysqlcfg
