#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=49084edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49084r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49084r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49084r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49084r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49084r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49084r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49084r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49084r=needscript Try newer version: http://bugs.php.net/fix.php?id=49084r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49084r=support Expected behavior: http://bugs.php.net/fix.php?id=49084r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49084r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49084r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49084r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49084r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49084r=dst IIS Stability: http://bugs.php.net/fix.php?id=49084r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49084r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49084r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49084r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49084r=mysqlcfg
#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=49084edit=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...
?php
$table = SystemInformation;
$pdoDb = new PDO(mysql:host=localhost;dbname=eta_manybodystate,
DB_USER, DB_PWD);
$stmt = $pdoDb-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:
#49065 [Ver]: disable_functions php.ini option does not work on Zend extensions
ID: 49065 User updated by: yoram dot b at zend dot com Reported By: yoram dot b at zend dot com Status: Verified Bug Type: Scripting Engine problem Operating System: * PHP Version: 5.*, 6SVN (2009-07-26) New Comment: This is PHP code, it has nothing to do with Zend, only with zend... Previous Comments: [2009-07-26 19:06:55] j...@php.net Indeed. Maybe someone at Zend had a reason for that? Try asking around. :) [2009-07-26 15:25:44] yoram dot b at zend dot com security hole, of course...) [2009-07-26 15:23:33] yoram dot b at zend dot com Description: that is actually easy, in main.c : 1991 php_ini_register_extensions(TSRMLS_C); 1992 zend_startup_modules(TSRMLS_C); 1993 1994 /* disable certain classes and functions as requested by php.ini */ 1995 php_disable_functions(TSRMLS_C); 1996 php_disable_classes(TSRMLS_C); 1997 1998 /* start Zend extensions */ 1999 zend_startup_extensions(); As you can see, zend_extensions are started after php_disable_functions() That might be a security whole, at list when not documented. -- Edit this bug report at http://bugs.php.net/?id=49065edit=1
#42194 [Opn-Tbd]: $argc/$argv[] won't work when .php extension is assigned to php.exe
ID: 42194 Updated by: rquadl...@php.net Reported By: backbone46 at gmail dot com -Status: Open +Status: To be documented Bug Type: Scripting Engine problem Operating System: Windows XP PHP Version: 6CVS-2007-08-03 (CVS) New Comment: You have to tell windows that multiple parameters are allowed. By associating in the way that you've done, you are only going to be getting the script name assigned to the interpreter. The registry needs amending so that the handler's Run command looks more like ... C:\PHP5\PHP.EXE %1 %* So, the script name is supplied in quotes (allowing script path or file name to have spaces) followed by all the other parameters. Previous Comments: [2007-08-03 04:36:21] backbone46 at gmail dot com Description: I did a right-click-open-with-chose-program-browsed to php.exe Checked the Always use the selected program to open this kind of file OK So launched the following line in the console C:\script.php 1arg 2arg 3arg Reproduce code: --- ?php echo \nArguments:$argc\n; ? Expected result: Arguments:4 Actual result: -- Arguments:1 -- Edit this bug report at http://bugs.php.net/?id=42194edit=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:
---
?php
echo PHP_VERSION, ' ', PHP_OS, ' ', PHP_SAPI, PHP_EOL;
echo 'INI:', php_ini_loaded_file(), PHP_EOL;
// Define the descriptors.
$a_Descriptors = array(0 = 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=47918edit=1
#48894 [Opn]: Occasional crashes with Apache 1.3.41
ID: 48894
User updated by: php at anders dot fupp dot net
Reported By: php at anders dot fupp dot net
Status: Open
Bug Type: Apache related
Operating System: FreeBSD/amd64 7.2-RELEASE
PHP Version: 5.2.10
New Comment:
I just wanted to tell that I've upgraded to Apache 2.2.11 (ITK), and
since then I have not had these problems anymore. So it seems to be an
issue with Apache 1.3.
Previous Comments:
[2009-07-22 20:30:50] j...@php.net
I only pointed at the fact that there is more detailed information on
that Apache bug ticket you mentioned. I'm not pointing any fingers
anywhere, this is PHP bug for sure.
[2009-07-17 09:06:56] php at anders dot fupp dot net
Yes, the Apache ticket specifically mentions that the bug is in the
caller, which is PHP. Are you or anyone going to look at this other than
keep pointing at Apache or suggesting alternatives? I submitted this
ticket to possibly have the problem fixed, that is the only reason I
bothered to do it. It's annoying to keep have to mentioning where the
problem (probably) is, I start to wonder whether it is useful to submit
tickets at bugs.php.net at all.
[2009-07-15 12:14:47] j...@php.net
Note: There is good analysis on that Apache bug what the problem is.
Workaround: Use lighttpd + PHP-fcgi :)
[2009-07-12 20:13:03] php at anders dot fupp dot net
Someone report this as an Apache bug, which was closed in their bug
tracking system:
https://issues.apache.org/bugzilla/show_bug.cgi?id=47070
[2009-07-12 20:08:10] php at anders dot fupp dot net
Description:
Apache 1.3.41 crashes now and then due to problems in PHP 5.2.10
mod_php module:
Jul 12 18:44:59 master kernel: pid 58886 (httpd), uid 80: exited on
signal 10 (core dumped)
Jul 12 19:06:31 master kernel: pid 60864 (httpd), uid 80: exited on
signal 10 (core dumped)
Jul 12 19:08:30 master kernel: pid 61302 (httpd), uid 80: exited on
signal 11 (core dumped)
Jul 12 20:27:43 master kernel: pid 67077 (httpd), uid 80: exited on
signal 11 (core dumped)
Jul 12 20:50:14 master kernel: pid 69216 (httpd), uid 80: exited on
signal 11 (core dumped)
Jul 12 21:07:00 master kernel: pid 71457 (httpd), uid 80: exited on
signal 10 (core dumped)
Jul 12 21:10:18 master kernel: pid 70542 (httpd), uid 80: exited on
signal 11 (core dumped)
Jul 12 21:38:28 master kernel: pid 77041 (httpd), uid 80: exited on
signal 11 (core dumped)
I use these extensions:
php5-ctype-5.2.10
php5-curl-5.2.10
php5-dom-5.2.10
php5-gd-5.2.10
php5-gettext-5.2.10
php5-iconv-5.2.10
php5-imap-5.2.10
php5-mbstring-5.2.10
php5-mcrypt-5.2.10
php5-mhash-5.2.10
php5-mysql-5.2.10
php5-openssl-5.2.10
php5-pcre-5.2.10
php5-posix-5.2.10
php5-pspell-5.2.10
php5-session-5.2.10
php5-simplexml-5.2.10
php5-spl-5.2.10
php5-tokenizer-5.2.10
php5-xml-5.2.10
php5-zlib-5.2.10
Also, I have gd 2.0.35 and imap-uw 2007e installed.
Reproduce code:
---
N/A. It happens occasionally. I run one fairly big WordPress site
(http://neppe.no/) and a forum on http://motorpsycho.fix.no. But I can't
find out exactly what provokes the crash.
Actual result:
--
GDB backtrace:
(gdb) bt full
#0 0x004249e4 in ap_rflush (r=0x805d61c38) at
http_protocol.c:2823
No locals.
#1 0x000801c92efc in sapi_apache_flush
(server_context=0x805d61c38)
at /usr/ports/lang/php5/work/php-5.2.10/sapi/apache/mod_php5.c:119
No locals.
#2 0x000801bc652f in sapi_flush ()
at /usr/ports/lang/php5/work/php-5.2.10/main/SAPI.c:922
No locals.
#3 0x0008016d in php_module_shutdown ()
at /usr/ports/lang/php5/work/php-5.2.10/main/main.c:1906
module_number = 0
#4 0x00080131 in php_module_shutdown_wrapper (
sapi_globals=0x801e43c00)
at /usr/ports/lang/php5/work/php-5.2.10/main/main.c:1879
No locals.
#5 0x000801c945c0 in php_child_exit_handler (s=0x800b05060,
p=0x800b31018)
at /usr/ports/lang/php5/work/php-5.2.10/sapi/apache/mod_php5.c:928
No locals.
#6 0x004119f0 in ap_child_exit_modules (p=0x800b31018,
s=0x800b05060)
at http_config.c:1634
m = (module *) 0x801e43d20
#7 0x00419df6 in clean_child_exit (code=0) at http_main.c:542
No locals.
#8 0x0041d16a in child_main (child_num_arg=5) at
http_main.c:4633
conn_io = (BUFF *) 0x805dcb080
r = (request_rec *) 0x805d60060
clen = 16
sa_server = {sa_len = 16 '\020', sa_family = 2 '\002',
sa_data = \000PP[$\024\000\000\000\000\000\000\000}
sa_client = {sa_len = 16 '\020', sa_family = 2 '\002',
sa_data = \bÄW\232ã\027\000\000\000\000\000\000\000}
lr = (listen_rec *) 0x0
#9
#47980 [Com]: date Fatal error: Balloc() allocation exceeds list boundary
ID: 47980 Comment by: s dot aditya at teles dot com Reported By: crquan at gmail dot com Status: No Feedback Bug Type: Date/time related Operating System: PowerPC Linux Embedded PHP Version: 5.2.9 Assigned To: fb-req-jani New Comment: Reproduced on NBSD PPC embedded with PHP 5.3.1. Any suggestions on how to fix? Previous Comments: [2009-07-17 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2009-07-09 20:51:59] 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/ [2009-06-24 08:05:30] crquan at gmail dot com I have checked compiled php-5.2.10 for powerpc-linux cross compilation, the result is the bug still exists, date() function is still broken through php-5.2.9 to 5.2.10, OS is powerpc-linux embedded system. [2009-04-28 05:43:30] crquan at gmail dot com Today I noticed something maybe important: if I delete /etc/localtime, or use a UTC timezone in /etc/localtime, the phpinfo() function would display the default timezone is UTC, Default timezoneUTC and no errors, my previous timezone in using is copied from /usr/share/zoneinfo/Asia/Hong_Kong, maybe this cause the bug? [2009-04-16 04:59:07] crquan at gmail dot com that's really a fatal error on powerpc linux, please help to fix it, if you don't have that hardware, I can also help to fix it, I have greped the problem source is in Zend/zend_strtod.c, please give some hints on how to resolve, Zend/zend_strtod.c: $ grep -RsInw Balloc Zend/ Zend/zend_strtod.c:470:static Bigint * Balloc(int k) Zend/zend_strtod.c:476: zend_error(E_ERROR, Balloc() allocation exceeds list boundary); Zend/zend_strtod.c:487: zend_error(E_ERROR, Balloc() failed to allocate memory); Zend/zend_strtod.c:522: r = (int*)Balloc(k); Zend/zend_strtod.c:570: b1 = Balloc(b-k+1); Zend/zend_strtod.c:658: b = Balloc(1); Zend/zend_strtod.c:686: c = Balloc(k); Zend/zend_strtod.c:757: b = Balloc(k); Zend/zend_strtod.c:761: b = Balloc(k+1); Zend/zend_strtod.c:839: b1 = Balloc(k1); Zend/zend_strtod.c:922: c = Balloc(0); Zend/zend_strtod.c:935: c = Balloc(a-k); Zend/zend_strtod.c:1110:b = Balloc(1); Zend/zend_strtod.c:1112:b = Balloc(2); Zend/zend_strtod.c:1917:mhi = Balloc(mhi-k); Zend/zend_strtod.c:2310:bd = Balloc(bd0-k); 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/47980 -- Edit this bug report at http://bugs.php.net/?id=47980edit=1
#48965 [Asn-Bgs]: curl is not able to post a string properly from a cloned handle
ID: 48965
Updated by: il...@php.net
Reported By: sriram dot natarajan at gmail dot com
-Status: Assigned
+Status: Bogus
Bug Type: cURL related
Operating System: *
PHP Version: 5.*, 6CVS (2009-07-22)
Assigned To: srinatar
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
This is a cURL limitation..
Previous Comments:
[2009-07-25 22:15:16] j...@php.net
The reason is explained here:
http://curl.haxx.se/libcurl/c/curl_easy_duphandle.html
You can not close the original handle before doing curl_exec($copy)..
[2009-07-21 20:45:19] srina...@php.net
yes, this is an issue with HEAD, 5.2 and 5.3
- sriram
[2009-07-20 14:55:36] j...@php.net
See also bug #48774
[2009-07-20 09:42:17] j...@php.net
only PHP_5_3 and HEAD? Not PHP_5_2..?
[2009-07-18 07:10:07] sriram dot natarajan at gmail dot com
Description:
currently, within php tests, the following tests are marked as
'expected failures'
curl_copy_handle_basic_002.phpt
curl_copy_handle_basic_005.phpt
which both does some thing like
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS,
Hello=WorldFoo=BarPerson=John%20Doe);
$copy = curl_copy_handle($ch);
curl_close($ch);
$curl_content_copy = curl_exec($copy);
curl_close($copy);
var_dump( $curl_content_copy );
Expected result:
these tests should pass fine.
Actual result:
--
string(163) array(1) {
[test]=
string(7) getpost
}
--
Edit this bug report at http://bugs.php.net/?id=48965edit=1
#48569 [Asn]: Called from the global scope error on code that worked before
ID: 48569
Updated by: dmi...@php.net
Reported By: ken at smallboxsoftware dot net
Status: Assigned
Bug Type: Scripting Engine problem
Operating System: RHEL 5.3
PHP Version: 5.3.0RC3
Assigned To: dmitry
New Comment:
It's not going to be fixed. It worked before not on purpose, but
because of wired func_get_args() implementation.
Previous Comments:
[2009-06-16 17:29:44] ken at smallboxsoftware dot net
Description:
Called from the global scope error now appears in situations where it
did not previously.
for example:
?php
function foo() {
include macro_to_process_arguments.php;
}
?
?php
// macro_to_process_arguments.php
$args = func_get_args();
?
Now triggers an error.
Reproduce code:
---
Called from the global scope
Expected result:
Not to get the above error message.
--
Edit this bug report at http://bugs.php.net/?id=48569edit=1
#48569 [Asn-WFx]: Called from the global scope error on code that worked before
ID: 48569
Updated by: dmi...@php.net
Reported By: ken at smallboxsoftware dot net
-Status: Assigned
+Status: Wont fix
Bug Type: Scripting Engine problem
Operating System: RHEL 5.3
PHP Version: 5.3.0RC3
Assigned To: dmitry
Previous Comments:
[2009-07-28 12:34:32] dmi...@php.net
It's not going to be fixed. It worked before not on purpose, but
because of wired func_get_args() implementation.
[2009-06-16 17:29:44] ken at smallboxsoftware dot net
Description:
Called from the global scope error now appears in situations where it
did not previously.
for example:
?php
function foo() {
include macro_to_process_arguments.php;
}
?
?php
// macro_to_process_arguments.php
$args = func_get_args();
?
Now triggers an error.
Reproduce code:
---
Called from the global scope
Expected result:
Not to get the above error message.
--
Edit this bug report at http://bugs.php.net/?id=48569edit=1
#48912 [Asn-Csd]: Namespace causes unexpected strict behaviour with extract()
ID: 48912
Updated by: dmi...@php.net
Reported By: david at grudl dot com
-Status: Assigned
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.3.0
Assigned To: dmitry
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2009-07-28 12:36:09] s...@php.net
Automatic comment from SVN on behalf of dmitry
Revision: http://svn.php.net/viewvc/?view=revisionrevision=286453
Log: Fixed bug #48912 (Namespace causes unexpected strict behaviour
with extract())
[2009-07-28 12:35:28] s...@php.net
Automatic comment from SVN on behalf of dmitry
Revision: http://svn.php.net/viewvc/?view=revisionrevision=286452
Log: Fixed bug #48912 (Namespace causes unexpected strict behaviour
with extract())
[2009-07-15 15:48:15] vr...@php.net
extract() uses ZEND_SEND_PREFER_REF. It seems that it is not compatible
with func_get_arg() under a namespace.
[2009-07-14 08:29:36] david at grudl dot com
Description:
The namespace clause causes the PHP behaves more strictly (unexpected
behavior according to the documentation - with regard to the namespaces
or function extract).
Reproduce code:
---
?php
// namespace A;
function test()
{
extract(func_get_arg(0));
}
test(array('x' = 1));
Expected result:
--none--
Actual result:
--
When row namespace A is commented:
--none--
When row namespace A is uncommented:
Strict Standards: Only variables should be passed by reference in ...
--
Edit this bug report at http://bugs.php.net/?id=48912edit=1
#49037 [Asn-Csd]: @list( $b ) = $a; causes a crash
ID: 49037
Updated by: dmi...@php.net
Reported By: alex dot emsenhuber at bluewin dot ch
-Status: Assigned
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: Mac OS X 10.5.7
PHP Version: 6SVN-2009-07-23 (SVN)
Assigned To: dmitry
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2009-07-28 13:01:41] s...@php.net
Automatic comment from SVN on behalf of dmitry
Revision: http://svn.php.net/viewvc/?view=revisionrevision=286454
Log: Fixed bug #49037 (@list( $b ) = $a; causes a crash)
[2009-07-23 18:27:02] alex dot emsenhuber at bluewin dot ch
Description:
When using @list( $b ) = $a; on PHP 6, it seems that a new opcode is
inserted that frees a temp variable set from $a (see the Actual result
section below) and thus segfaults when using $a later. When I set
breakpoints on all lines that contains SWITCH_FREE in Zend_execute.c,
it's the one at line 1170 in function zend_do_free() that is called.
Reproduce code:
---
?php
$a = array( c );
@list( $b ) = $a;
var_dump( $a );
I also used vld to get the opcodes produced by the laguage parser.
Expected result:
array(1) {
[0]=
string(1) c
}
Analyse with vld:
$ PHP_5_3/sapi/cli/php -dvld.active=1 ~/test.php
Branch analysis from position: 0
Return found
filename: /Users/alexandre/test.php
function name: (null)
number of ops: 11
compiled vars: !0 = $a
line # op fetch ext return
operands
---
2 0 INIT_ARRAY ~0
'c'
1 ASSIGN
!0, ~0
3 2 BEGIN_SILENCE~2
3 FETCH_R local $4
'a'
4 FETCH_DIM_R $5
$4, 0
5 FETCH_W local $3
'b'
6 ASSIGN
$3, $5
7 END_SILENCE
~2
4 8 SEND_VAR
!0
9 DO_FCALL 1
'var_dump'
510 RETURN 1
Actual result:
--
Segmentation fault.
Analyse with vld:
$ PHP_6/sapi/cli/php -dvld.active=1 ~/test.php
Branch analysis from position: 0
Return found
filename: /Users/alexandre/test.php
function name: (null)
number of ops: 12
compiled vars: !0 = $a
line # op fetch ext return
operands
---
2 0 INIT_ARRAY ~0 c
1 ASSIGN
!0, ~0
3 2 BEGIN_SILENCE~2
3 FETCH_R local $4 a
4 FETCH_DIM_TMP_VAR$5
$4, 0
5 FETCH_W local $3 b
6 ASSIGN
$3, $5
7 END_SILENCE
~2
8 SWITCH_FREE
$4
4 9 SEND_VAR
!0
10 DO_FCALL 1
var_dump
511 RETURN 1
You can see the new opcode SWITCH_FREE at position 8.
--
Edit this bug report at http://bugs.php.net/?id=49037edit=1
#47664 [Asn-Fbk]: get_class returns NULL instead of FALSE.
ID: 47664 Updated by: dmi...@php.net Reported By: wiebe at wiebelt dot nl -Status: Assigned +Status: Feedback Bug Type: Class/Object related Operating System: Ubuntu 8.10 PHP Version: 5.3.0beta1 Assigned To: dmitry New Comment: I would prefer to stay the warning, as it indicates a problem in user code that probably need to be fixed. Previous Comments: [2009-06-30 12:33:05] der...@php.net I've a patch at: http://php.pastebin.com/m20d61023 [2009-06-23 11:19:37] der...@php.net This isn't fixed, the warning is still there which is a part of the problem here. [2009-03-16 09:53:50] dmi...@php.net This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2009-03-15 18:10:28] paj...@php.net hm, you are right. It should remain the same especially as it is documented. Dmitry? [2009-03-15 17:44:48] wiebe at wiebelt dot nl The documentation says it should return false. Returns the name of the class of which object is an instance. Returns FALSE if object is not an object. It's very inconsistent if in PHP 5.2 it returns false and in 5.3 null. 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/47664 -- Edit this bug report at http://bugs.php.net/?id=47664edit=1
#47664 [Fbk-Asn]: get_class returns NULL instead of FALSE.
ID: 47664 Updated by: der...@php.net Reported By: wiebe at wiebelt dot nl -Status: Feedback +Status: Assigned Bug Type: Class/Object related Operating System: Ubuntu 8.10 PHP Version: 5.3.0beta1 Assigned To: dmitry New Comment: The documentation clearly states: Returns the name of the class of which object is an instance. Returns FALSE if object is not an object. It doesn't say shows a warning when object is not an object, so this should be fixed according to what PHP 5.2.x and the manual say. Previous Comments: [2009-07-28 13:06:48] dmi...@php.net I would prefer to stay the warning, as it indicates a problem in user code that probably need to be fixed. [2009-06-30 12:33:05] der...@php.net I've a patch at: http://php.pastebin.com/m20d61023 [2009-06-23 11:19:37] der...@php.net This isn't fixed, the warning is still there which is a part of the problem here. [2009-03-16 09:53:50] dmi...@php.net This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2009-03-15 18:10:28] paj...@php.net hm, you are right. It should remain the same especially as it is documented. Dmitry? 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/47664 -- Edit this bug report at http://bugs.php.net/?id=47664edit=1
#49087 [NEW]: Session: PHP cannot serialize strings in an object that contain apostrophes
From: anis at boubaker dot ca Operating system: Linux Ubuntu PHP version: 5.3.0 PHP Bug Type: Session related Bug description: Session: PHP cannot serialize strings in an object that contain apostrophes Description: When we use session-set-save-handler to save session data in database and we want to save an object that encapsulates strings, we get the following exception if the string(s) contains an apostrophe. The exception raised is: Fatal error: Exception thrown without a stack frame in Unknown on line 0 Reproduce code: --- --- From manual page: function.session-set-save-handler --- Please find the source code (slightly more than 20 lines) at this URL: http://www.cibaxion.com/php/PHPBug-AnisBoubaker.txt Expected result: No exception raised, session's data saved into database. Actual result: -- Fatal error: Exception thrown without a stack frame in Unknown on line 0 -- Edit bug report at http://bugs.php.net/?id=49087edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49087r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49087r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49087r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49087r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49087r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49087r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49087r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49087r=needscript Try newer version: http://bugs.php.net/fix.php?id=49087r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49087r=support Expected behavior: http://bugs.php.net/fix.php?id=49087r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49087r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49087r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49087r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49087r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49087r=dst IIS Stability: http://bugs.php.net/fix.php?id=49087r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49087r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49087r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49087r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49087r=mysqlcfg
#45155 [NoF-Opn]: Constructors not called when using classmap option in SoapClient
ID: 45155
Updated by: b...@php.net
Reported By: david at globulebleu dot com
-Status: No Feedback
+Status: Open
Bug Type: SOAP related
Operating System: *
PHP Version: 5.2.6
New Comment:
changed status because this bug still exists and is reproduced
Previous Comments:
[2009-06-22 13:20:31] b...@php.net
Hi Jani,
i strumbled over this issue and have the same bug here.
tested with latest 5.2snap. Results in a not called constructor or
other magic function.
the __destructor will be called but this is too late for handling
special stuff here.
[2009-05-06 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2009-04-28 18:40:52] 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/
[2009-02-03 09:44:08] r dot swets at gmail dot com
i can imagine that instead of using the constructor, the __wakeup
method is called.
[2008-06-03 09:43:30] david at globulebleu dot com
Description:
When using classmap to map the SOAP results to a class, the constructor
of the object you've mapped to is not called.
Reproduce code:
---
$client = new SoapClient(url_to_wsdl,
array('classmap' = array('contact' = Contact));
$params = array(1);
$contact = $client-__soapCall(get_contact, $params);
Expected result:
A contact object that has properties initialized (i.e. db connections,
...).
Actual result:
--
A contact object without the properties.
--
Edit this bug report at http://bugs.php.net/?id=45155edit=1
#48668 [Asn-Ctl]: foreach with array will coredump php
ID: 48668
Updated by: d...@php.net
Reported By: dmda at yandex dot ru
-Status: Assigned
+Status: Critical
Bug Type: Reproducible crash
Operating System: Solaris
PHP Version: 5.3.0RC4
Assigned To: dsp
New Comment:
PHP is broken on Sparc (and possible every other processor that
requires memalignment) at the moment
Previous Comments:
[2009-06-26 15:42:15] d...@php.net
It looks like this is a memalign issue. PHP 5.3.0 is now build with
flags to avoid the crash. I assign the bug to me to provide a proper
fix
for the issue for 5.3.1
[2009-06-24 12:21:10] johan...@php.net
When using --enable-dbug the code works, without --enable-debug the
code fails, maybe that's the reason why I didn't see this before.
uname -a
SunOS techra46 5.8 Generic_117350-54 sun4u sparc SUNW,Sun-Fire-V210
The issue seems to be independent from the compiler but in some way
system dependent, another similar box worked for me.
[2009-06-24 06:49:42] dmda at yandex dot ru
to me it looks like bogus pointer appeared in the heap's cache first,
then it was returned by the allocator, called by ALLOC_ZVAL(). I see no
other reasons for the tmp pointer to have this strange value.
[2009-06-24 00:32:54] scott...@php.net
Don't think its endian specific, PPC chip works.
Will test with another sparc box shortly.
[2009-06-23 22:16:22] dmda at yandex dot ru
Description:
$uname -a
SunOS qu1 5.8 Generic_108528-11 sun4u sparc
SUNW,UltraSPARC-IIi-cEngine
$ sapi/cli/php ./1.php
Bus Error (core dumped)
$gdb --core core sapi/cli/php
Core was generated by `./php 1.php'.
Program terminated with signal 10, Bus error.
#0 0x002e7d80 in ZEND_FE_RESET_SPEC_TMP_HANDLER
(execute_data=0x861cc0)
at
/export/home/jvlad/php/php5.3-200906221030/Zend/zend_vm_execute.h:5371
5371INIT_PZVAL_COPY(tmp, array_ptr);
(gdb) bt
#0 0x002e7d80 in ZEND_FE_RESET_SPEC_TMP_HANDLER
(execute_data=0x861cc0)
at
/export/home/jvlad/php/php5.3-200906221030/Zend/zend_vm_execute.h:5371
#1 0x002d92a0 in execute (op_array=0x70bd90)
at
/export/home/jvlad/php/php5.3-200906221030/Zend/zend_vm_execute.h:104
#2 0x002b8d48 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /export/home/jvlad/php/php5.3-200906221030/Zend/zend.c:1188
#3 0x00266444 in php_execute_script (primary_file=0xffbefbf0)
at /export/home/jvlad/php/php5.3-200906221030/main/main.c:2196
#4 0x003447d4 in main (argc=2, argv=0xffbefcac)
at
/export/home/jvlad/php/php5.3-200906221030/sapi/cli/php_cli.c:1188
(gdb) p array_ptr
$1 = (zval *) 0x861d14
(gdb) p *array_ptr
$2 = {value = {lval = 7458416, dval = 1.5848218932638939e-306, str =
{val =
0x71ce70 ,
len = 0}, ht = 0x71ce70, obj = {handle = 7458416, handlers =
0x0}},
refcount__gc = 0,
type = 4 '\004', is_ref__gc = 0 '\0'}
(gdb) p tmp
Cannot access memory at address 0xfff0
(gdb) dump_bt executor_globals.current_execute_data
[0x00861cc0] ???
/export/home/jvlad/php/php5.3-200906221030/sapi/cli/1.php:2
Reproduce code:
---
$cat 1.php
?php
foreach (array(SPL, Reflection, Phar) as $ext) {
if (!extension_loaded($ext)) {
echo $argv[0] requires PHP extension $ext.\n;
exit(1);
}
}
?
--
Edit this bug report at http://bugs.php.net/?id=48668edit=1
#49077 [Opn-Fbk]: Partialy server response
ID: 49077
Updated by: j...@php.net
Reported By: darkside at i dot ua
-Status: Open
+Status: Feedback
Bug Type: *General Issues
Operating System: Windows XP SP3
PHP Version: 5.3.0
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2009-07-27 17:43:50] darkside at i dot ua
Description:
Browsers attempt to display a page generated by script with code below
and get only some content of phpinfo() output (approximate 17Kb). After
that request is freezing and no more data retrieving from server.
But this bug is not reproduce if small content outputs after ini_set
called.
Reproduce code:
---
ini_set('error_log', 'error.log');
phpinfo();
Expected result:
phpinfo() whole output
Actual result:
--
Partialy phpinfo() output
--
Edit this bug report at http://bugs.php.net/?id=49077edit=1
#49087 [Opn-Fbk]: Session: PHP cannot serialize strings in an object that contain apostrophes
ID: 49087 Updated by: j...@php.net Reported By: anis at boubaker dot ca -Status: Open +Status: Feedback Bug Type: Session related Operating System: Linux Ubuntu PHP Version: 5.3.0 New Comment: Can your reproduce this without PDO? Please try simplify the code to bare minimum and to not contain such requirements. Now it might be anything throwing exception, most likely PDO for inv Previous Comments: [2009-07-28 13:40:13] anis at boubaker dot ca Description: When we use session-set-save-handler to save session data in database and we want to save an object that encapsulates strings, we get the following exception if the string(s) contains an apostrophe. The exception raised is: Fatal error: Exception thrown without a stack frame in Unknown on line 0 Reproduce code: --- --- From manual page: function.session-set-save-handler --- Please find the source code (slightly more than 20 lines) at this URL: http://www.cibaxion.com/php/PHPBug-AnisBoubaker.txt Expected result: No exception raised, session's data saved into database. Actual result: -- Fatal error: Exception thrown without a stack frame in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/?id=49087edit=1
#49087 [Fbk]: Session: PHP cannot serialize strings in an object that contain apostrophes
ID: 49087 Updated by: j...@php.net Reported By: anis at boubaker dot ca Status: Feedback Bug Type: Session related Operating System: Linux Ubuntu PHP Version: 5.3.0 New Comment: Can your reproduce this without PDO? Please try simplify the code to bare minimum and to not contain such requirements. Now it might be anything throwing exception, most likely PDO for some invalid SQL.. Previous Comments: [2009-07-28 15:51:19] j...@php.net Can your reproduce this without PDO? Please try simplify the code to bare minimum and to not contain such requirements. Now it might be anything throwing exception, most likely PDO for inv [2009-07-28 13:40:13] anis at boubaker dot ca Description: When we use session-set-save-handler to save session data in database and we want to save an object that encapsulates strings, we get the following exception if the string(s) contains an apostrophe. The exception raised is: Fatal error: Exception thrown without a stack frame in Unknown on line 0 Reproduce code: --- --- From manual page: function.session-set-save-handler --- Please find the source code (slightly more than 20 lines) at this URL: http://www.cibaxion.com/php/PHPBug-AnisBoubaker.txt Expected result: No exception raised, session's data saved into database. Actual result: -- Fatal error: Exception thrown without a stack frame in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/?id=49087edit=1
#49073 [Opn-Bgs]: hanging on flock()ing the session file as
ID: 49073
Updated by: j...@php.net
Reported By: dacran at riseup dot net
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: Linux
PHP Version: 5.2.10
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
Previous Comments:
[2009-07-27 12:32:24] dacran at riseup dot net
Description:
I have the same problem as in bug:
http://bugs.php.net/bug.php?id=47640
In php 5.2.10 has not been solved
Reproduce code:
---
?php
session_start();
while (true) { $i *= 2; }
?
Expected result:
I can strace apache/php processes seeing that there is a PHP script
doing flock() on a file, the process never returns.
PHP session handler should have some timeout and/or old file locks
should be hard-broken.
Actual result:
--
Forever-Hanging php processes.
--
Edit this bug report at http://bugs.php.net/?id=49073edit=1
#49089 [NEW]: problems with ImageTTFBBox and ImageTTFText
From: fausto dot gastaldin at gmail dot com
Operating system: Linux CentOS
PHP version: 5.2.10
PHP Bug Type: *General Issues
Bug description: problems with ImageTTFBBox and ImageTTFText
Description:
After updating php to 5.2.10 (we have freetype 2.2.1 and GD 2.0.34)w e
have this problem:
http://www.fmeshop.com/fm/test/lib/heading.php?text=Felpe12345678
The text is cut, we have a wrong align.
Reproduce code:
---
Code used to generate text and align inside png image.
$dip = get_dip($font_file,$font_size) ;
$box = @ImageTTFBBox($font_size,0,$font_file,$text) ;
$image = @ImageCreate(abs($box[2]-$box[0]),abs($box[5]-$dip)) ;
ImageTTFText($image,$font_size,0,-$box[0],abs($box[5]-$box[3])-$box[1],
$font_color,$font_file,$text) ;
header('Content-type: ' . $mime_type) ;
ImagePNG($image) ;
--
Edit bug report at http://bugs.php.net/?id=49089edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49089r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49089r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49089r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49089r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49089r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49089r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49089r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49089r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49089r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49089r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49089r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49089r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49089r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49089r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49089r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49089r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49089r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49089r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49089r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49089r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49089r=mysqlcfg
#49071 [Opn-Bgs]: gmp_intval returns bad value
ID: 49071 Updated by: j...@php.net Reported By: erha at freemail dot hu -Status: Open +Status: Bogus Bug Type: GNU MP related Operating System: windows PHP Version: 5.2.10 New Comment: RTFM, http://php.net/gmp_intval Warning This function returns a useful result only if the number actually fits the PHP integer (i.e., signed long type). If you want just to print the GMP number, use gmp_strval(). Previous Comments: [2009-07-27 10:59:15] erha at freemail dot hu Description: In the following code gmp_intval returns bad results. Replace it with gmp_strval to see the difference: Reproduce code: --- $val = 19991231235958; $value = gmp_init($val); $res = gmp_div_qr($value, 0x1); $b1 = (string) gmp_intval($res[1]); $b2 = (string) gmp_intval($res[0]); echo $b1 $b2; -- Edit this bug report at http://bugs.php.net/?id=49071edit=1
#49065 [Ver]: disable_functions php.ini option does not work on Zend extensions
ID: 49065 Updated by: j...@php.net Reported By: yoram dot b at zend dot com Status: Verified Bug Type: Scripting Engine problem Operating System: * PHP Version: 5.*, 6SVN (2009-07-26) New Comment: FYI: The person who committed the code is Zeev. AFAIK, he has something to do with Zend. It's _ZEND_ extensions you're talking about.. Previous Comments: [2009-07-28 08:32:27] yoram dot b at zend dot com This is PHP code, it has nothing to do with Zend, only with zend...) [2009-07-26 19:06:55] j...@php.net Indeed. Maybe someone at Zend had a reason for that? Try asking around. :) [2009-07-26 15:25:44] yoram dot b at zend dot com security hole, of course...) [2009-07-26 15:23:33] yoram dot b at zend dot com Description: that is actually easy, in main.c : 1991 php_ini_register_extensions(TSRMLS_C); 1992 zend_startup_modules(TSRMLS_C); 1993 1994 /* disable certain classes and functions as requested by php.ini */ 1995 php_disable_functions(TSRMLS_C); 1996 php_disable_classes(TSRMLS_C); 1997 1998 /* start Zend extensions */ 1999 zend_startup_extensions(); As you can see, zend_extensions are started after php_disable_functions() That might be a security whole, at list when not documented. -- Edit this bug report at http://bugs.php.net/?id=49065edit=1
#42194 [Tbd-Csd]: $argc/$argv[] won't work when .php extension is assigned to php.exe
ID: 42194 Updated by: j...@php.net Reported By: backbone46 at gmail dot com -Status: To be documented +Status: Closed Bug Type: Scripting Engine problem Operating System: Windows XP PHP Version: 6CVS-2007-08-03 (CVS) Previous Comments: [2009-07-28 11:22:26] s...@php.net Automatic comment from SVN on behalf of rquadling Revision: http://svn.php.net/viewvc/?view=revisionrevision=286450 Log: Bug#42194 - Document how to get command line script working like BAT files without the need to supply the executable or the extension and have all parameters supplied passed to the script. [2009-07-28 09:40:11] rquadl...@php.net You have to tell windows that multiple parameters are allowed. By associating in the way that you've done, you are only going to be getting the script name assigned to the interpreter. The registry needs amending so that the handler's Run command looks more like ... C:\PHP5\PHP.EXE %1 %* So, the script name is supplied in quotes (allowing script path or file name to have spaces) followed by all the other parameters. [2007-08-03 04:36:21] backbone46 at gmail dot com Description: I did a right-click-open-with-chose-program-browsed to php.exe Checked the Always use the selected program to open this kind of file OK So launched the following line in the console C:\script.php 1arg 2arg 3arg Reproduce code: --- ?php echo \nArguments:$argc\n; ? Expected result: Arguments:4 Actual result: -- Arguments:1 -- Edit this bug report at http://bugs.php.net/?id=42194edit=1
#49012 [Opn-Fbk]: Spurious fatal error on require() statement
ID: 49012 Updated by: j...@php.net Reported By: gary dot barnes at is-networks dot co dot uk -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Linux version 2.6.10-1.766_FC3 PHP Version: 5.3.0 New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ And do not try loading any 3rd party extensions, or outdated ones either. :) Previous Comments: [2009-07-27 10:52:04] gary dot barnes at is-networks dot co dot uk Found some out of date PHP4 extensions which were failing to load (mysql and ldap). However, these aren't required and obviously failed to load with previous PHP5 versions with no detrimental affects. I can now confirm there is no problem with 5.2.10, so it seems only with 5.3.0 I get this problem.) [2009-07-22 07:04:02] ras...@php.net Any 3rd-party extensions? [2009-07-22 06:58:47] gary dot barnes at is-networks dot co dot uk Description: After installing 5.3.0 some site scripts fail with the message: PHP Fatal error: Unknown: Failed opening required filename include path in Unknown on line 0. This is only some sites, and is intermittent, and can appear after several refreshes of the web page (maybe memory/file handle related?) Versions 5.2.9, 5.2.8 work fine with the same scripts. Also appears not to be obeying error_reporting statement in php.ini -- Edit this bug report at http://bugs.php.net/?id=49012edit=1
#48706 [Opn-Csd]: SoapClient invalid wsdl crashes php with file error_log active
ID: 48706
Updated by: j...@php.net
Reported By: aigors at inbox dot lv
-Status: Open
+Status: Closed
Bug Type: SOAP related
Operating System: Windows XP
PHP Version: 5.2.10
Assigned To: jani
New Comment:
Yes, this was fixed by fixing bug #48247
Previous Comments:
[2009-07-27 07:22:23] aigors at inbox dot lv
It doesn't crash with the PHP Version 5.2.11-dev build on Jul 26 2009
23:42:23. Thank you.)
[2009-07-26 19:37:55] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-06-27 10:26:34] aigors at inbox dot lv
I generated the crash backtrace report, it's available in
http://gedrox.no-ip.org/php/CrashHang_Report__PID_5620__06272009131757156.mht.
Hope did it right.
[2009-06-27 09:59:53] aigors at inbox dot lv
Description:
SoapClient crashes the PHP when invalid wsdl_url is used and file php
log output is configured in the php.ini.
Reproduce code:
---
PHP code:
?php
new SoapClient('http://example.com');
?
php.ini-dist and php.ini changes:
--- C:/php5/php.ini-dist
+++ C:/php5/php.ini
-log_errors = Off
+log_errors = On
-;error_log = filename
+error_log = c:/php_log
-;extension=php_soap.dll
+extension=php_soap.dll
Expected result:
SoapFault Exception should be thrown.
Actual result:
--
PHP crashes with system log message Faulting application php.exe,
version 5.2.10.10, faulting module php5ts.dll, version 5.2.10.10, fault
address 0x000abc6f.
--
Edit this bug report at http://bugs.php.net/?id=48706edit=1
#49090 [NEW]: call_user_func_array modifies internal object context for custom error handler
From: doctorrock83 at gmail dot com
Operating system: Linux
PHP version: 5.2.10
PHP Bug Type: Scripting Engine problem
Bug description: call_user_func_array modifies internal object context for
custom error handler
Description:
call_user_func_array() seems to modifies the internal object context while
used with set_error_handler();
See the reproduce code.
Note: In the reproduce code, when not using call_user_func_array() (direct
function call), there is no problem and the expected behavior occurs.
Reproduce code:
---
?php
class Foo
{
public function call()
{
set_error_handler(array($this, '_errors'));
$result = call_user_func_array('ucfirst', array());
}
protected function _errors($errno, $errstr)
{
throw new Exception($errstr);
}
}
$f = new Foo;
$f-call();
Expected result:
Exception thrown with the message telling that ucfirst accept one
parameter, none given
Actual result:
--
Fatal error: Call to protected method Foo::_errors() from context '' in
/path/to/script.php on line XXX
PHP 5.3.0 returns :
Warning: Invalid callback Foo::_errors, cannot access protected method
Foo::_errors() in /path/to/script.php on line XXX
Warning: ucfirst() expects exactly 1 parameter, 0 given in
/path/to/script.php on line XXX
--
Edit bug report at http://bugs.php.net/?id=49090edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49090r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49090r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49090r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49090r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49090r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49090r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49090r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49090r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49090r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49090r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49090r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49090r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49090r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49090r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49090r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49090r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49090r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49090r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49090r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49090r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49090r=mysqlcfg
#49090 [Opn-Fbk]: call_user_func_array modifies internal object context for custom error handler
ID: 49090
Updated by: j...@php.net
Reported By: doctorrock83 at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 5.2.10
New Comment:
That's quite expected output. What exactly are you saying the bug is?
Previous Comments:
[2009-07-28 17:30:21] doctorrock83 at gmail dot com
Description:
call_user_func_array() seems to modifies the internal object context
while used with set_error_handler();
See the reproduce code.
Note: In the reproduce code, when not using call_user_func_array()
(direct function call), there is no problem and the expected behavior
occurs.
Reproduce code:
---
?php
class Foo
{
public function call()
{
set_error_handler(array($this, '_errors'));
$result = call_user_func_array('ucfirst', array());
}
protected function _errors($errno, $errstr)
{
throw new Exception($errstr);
}
}
$f = new Foo;
$f-call();
Expected result:
Exception thrown with the message telling that ucfirst accept one
parameter, none given
Actual result:
--
Fatal error: Call to protected method Foo::_errors() from context '' in
/path/to/script.php on line XXX
PHP 5.3.0 returns :
Warning: Invalid callback Foo::_errors, cannot access protected method
Foo::_errors() in /path/to/script.php on line XXX
Warning: ucfirst() expects exactly 1 parameter, 0 given in
/path/to/script.php on line XXX
--
Edit this bug report at http://bugs.php.net/?id=49090edit=1
#48922 [Opn-NoF]: session_set_save_handler() appears to cause all processing to stop
ID: 48922
Updated by: j...@php.net
Reported By: bobby at indesignfirm dot com
-Status: Open
+Status: No Feedback
Bug Type: Session related
Operating System: RedHat 2.6.9-42.0.8.EL #1
PHP Version: 5.2.10
New Comment:
Timj: Please don't hijack bugs.
Previous Comments:
[2009-07-18 22:04:39] t...@php.net
I *think* I have the same problem. Segfaults on various pages that
don't occur on 5.2.9. I have a session handler using PEAR HTTP_Session,
that saves via MDB2/mysqli to a MySQL database. The common factor seems
to be that they happen during session_save_state.
Here's 5.2.10: (crash in version_compare):
Program received signal SIGSEGV, Segmentation fault.
0x71ea4d3f in _zend_mm_free_int (heap=0x78396480,
p=0x78bb7010) at /usr/src/debug/php-5.2.10/Zend/zend_alloc.c:1978
1978if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
(gdb) bt
#0 0x71ea4d3f in _zend_mm_free_int (heap=0x78396480,
p=0x78bb7010) at /usr/src/debug/php-5.2.10/Zend/zend_alloc.c:1978
#1 0x71ea5af4 in _efree (ptr=0x78bb7010) at
/usr/src/debug/php-5.2.10/Zend/zend_alloc.c:2311
#2 0x71e3f4ff in php_version_compare (orig_ver1=0x787b7538
5.2.10, orig_ver2=0x78e41ac0 5.0) at
/usr/src/debug/php-5.2.10/ext/standard/versioning.c:202
#3 0x71e3f58b in zif_version_compare (ht=3,
return_value=0x787bc458, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1) at
/usr/src/debug/php-5.2.10/ext/standard/versioning.c:222
#4 0x71ef028d in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffac00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:200
#5 0x71ef4235 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x7fffac00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:1739
#6 0x71eefd6f in execute (op_array=0x78a028c0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#7 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffba00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#8 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffba00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#9 0x71eefd6f in execute (op_array=0x78b696e8) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#10 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffbf60) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#11 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffbf60) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#12 0x71eefd6f in execute (op_array=0x78b69588) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#13 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffc2d0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#14 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffc2d0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#15 0x71eefd6f in execute (op_array=0x78b6a728) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#16 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffd1c0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#17 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffd1c0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#18 0x71eefd6f in execute (op_array=0x78e29300) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#19 0x71eb816b in zend_call_function (fci=0x7fffd440,
fci_cache=0x0) at
/usr/src/debug/php-5.2.10/Zend/zend_execute_API.c:1032
#20 0x71eb66d4 in call_user_function_ex
(function_table=0x78396d20, object_pp=0x0,
function_name=0x78e3eea0, retval_ptr_ptr=0x7fffd4e8,
param_count=2, params=0x787b7670, no_separation=1,
symbol_table=0x0) at
/usr/src/debug/php-5.2.10/Zend/zend_execute_API.c:640
#21 0x71eb65af in call_user_function
(function_table=0x78396d20, object_pp=0x0,
function_name=0x78e3eea0, retval_ptr=0x787b7c18, param_count=2,
params=0x7fffd590)
at /usr/src/debug/php-5.2.10/Zend/zend_execute_API.c:613
#22 0x71da4785 in ps_call_handler (func=0x78e3eea0, argc=2,
argv=0x7fffd590) at
/usr/src/debug/php-5.2.10/ext/session/mod_user.c:53
#23 0x71da4c2d in ps_write_user (mod_data=0x7221db60,
key=0x78e3f7c0 59ufo7hqslet38p73jp9na8577,
val=0x78fb1e88
__HTTP_Session2_Info|i:2;__HTTP_Session2_Idle|i:3600;__HTTP_Session2_Idle_TS|i:1247951369;user_id|s:1:\6\;audit_user|N;,
vallen=119) at /usr/src/debug/php-5.2.10/ext/session/mod_user.c:141
#24 0x71d9d8ba in php_session_save_current_state () at
/usr/src/debug/php-5.2.10/ext/session/session.c:556
#25 0x71da0fbb in php_session_flush () at
#48965 [Bgs]: curl is not able to post a string properly from a cloned handle
ID: 48965 Updated by: srina...@php.net Reported By: sriram dot natarajan at gmail dot com Status: Bogus Bug Type: cURL related Operating System: * PHP Version: 5.*, 6CVS (2009-07-22) Assigned To: srinatar New Comment: should these below test cases be removed as it is doing some thing which is not supported or standard behavior ? curl_copy_handle_basic_002.phpt curl_copy_handle_basic_005.phpt just curious as to what is the practice in this case ? Previous Comments: [2009-07-28 12:19:47] il...@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 This is a cURL limitation.. [2009-07-25 22:15:16] j...@php.net The reason is explained here: http://curl.haxx.se/libcurl/c/curl_easy_duphandle.html You can not close the original handle before doing curl_exec($copy).. [2009-07-21 20:45:19] srina...@php.net yes, this is an issue with HEAD, 5.2 and 5.3 - sriram [2009-07-20 14:55:36] j...@php.net See also bug #48774 [2009-07-20 09:42:17] j...@php.net only PHP_5_3 and HEAD? Not PHP_5_2..? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/48965 -- Edit this bug report at http://bugs.php.net/?id=48965edit=1
#49090 [Fbk-Opn]: call_user_func_array modifies internal object context for custom error handler
ID: 49090
User updated by: doctorrock83 at gmail dot com
Reported By: doctorrock83 at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 5.2.10
New Comment:
Well call_user_func_array() actually generates an error which is not
trapped in the custom error handler as it should be
Previous Comments:
[2009-07-28 18:29:02] j...@php.net
That's quite expected output. What exactly are you saying the bug is?
[2009-07-28 17:30:21] doctorrock83 at gmail dot com
Description:
call_user_func_array() seems to modifies the internal object context
while used with set_error_handler();
See the reproduce code.
Note: In the reproduce code, when not using call_user_func_array()
(direct function call), there is no problem and the expected behavior
occurs.
Reproduce code:
---
?php
class Foo
{
public function call()
{
set_error_handler(array($this, '_errors'));
$result = call_user_func_array('ucfirst', array());
}
protected function _errors($errno, $errstr)
{
throw new Exception($errstr);
}
}
$f = new Foo;
$f-call();
Expected result:
Exception thrown with the message telling that ucfirst accept one
parameter, none given
Actual result:
--
Fatal error: Call to protected method Foo::_errors() from context '' in
/path/to/script.php on line XXX
PHP 5.3.0 returns :
Warning: Invalid callback Foo::_errors, cannot access protected method
Foo::_errors() in /path/to/script.php on line XXX
Warning: ucfirst() expects exactly 1 parameter, 0 given in
/path/to/script.php on line XXX
--
Edit this bug report at http://bugs.php.net/?id=49090edit=1
#49090 [Opn-Fbk]: call_user_func_array modifies internal object context for custom error handler
ID: 49090
Updated by: j...@php.net
Reported By: doctorrock83 at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 5.2.10
New Comment:
Setting the error handler fails, so why should it be used..?
Previous Comments:
[2009-07-28 19:02:27] doctorrock83 at gmail dot com
Well call_user_func_array() actually generates an error which is not
trapped in the custom error handler as it should be)
[2009-07-28 18:29:02] j...@php.net
That's quite expected output. What exactly are you saying the bug is?
[2009-07-28 17:30:21] doctorrock83 at gmail dot com
Description:
call_user_func_array() seems to modifies the internal object context
while used with set_error_handler();
See the reproduce code.
Note: In the reproduce code, when not using call_user_func_array()
(direct function call), there is no problem and the expected behavior
occurs.
Reproduce code:
---
?php
class Foo
{
public function call()
{
set_error_handler(array($this, '_errors'));
$result = call_user_func_array('ucfirst', array());
}
protected function _errors($errno, $errstr)
{
throw new Exception($errstr);
}
}
$f = new Foo;
$f-call();
Expected result:
Exception thrown with the message telling that ucfirst accept one
parameter, none given
Actual result:
--
Fatal error: Call to protected method Foo::_errors() from context '' in
/path/to/script.php on line XXX
PHP 5.3.0 returns :
Warning: Invalid callback Foo::_errors, cannot access protected method
Foo::_errors() in /path/to/script.php on line XXX
Warning: ucfirst() expects exactly 1 parameter, 0 given in
/path/to/script.php on line XXX
--
Edit this bug report at http://bugs.php.net/?id=49090edit=1
#49087 [Fbk-Csd]: Session: PHP cannot serialize strings in an object that contain apostrophes
ID: 49087 User updated by: anis at boubaker dot ca Reported By: anis at boubaker dot ca -Status: Feedback +Status: Closed Bug Type: Session related Operating System: Linux Ubuntu PHP Version: 5.3.0 New Comment: It was not related to session management but PDO throwing an exception because of an SQL error Previous Comments: [2009-07-28 15:51:35] j...@php.net Can your reproduce this without PDO? Please try simplify the code to bare minimum and to not contain such requirements. Now it might be anything throwing exception, most likely PDO for some invalid SQL.. [2009-07-28 15:51:19] j...@php.net Can your reproduce this without PDO? Please try simplify the code to bare minimum and to not contain such requirements. Now it might be anything throwing exception, most likely PDO for inv [2009-07-28 13:40:13] anis at boubaker dot ca Description: When we use session-set-save-handler to save session data in database and we want to save an object that encapsulates strings, we get the following exception if the string(s) contains an apostrophe. The exception raised is: Fatal error: Exception thrown without a stack frame in Unknown on line 0 Reproduce code: --- --- From manual page: function.session-set-save-handler --- Please find the source code (slightly more than 20 lines) at this URL: http://www.cibaxion.com/php/PHPBug-AnisBoubaker.txt Expected result: No exception raised, session's data saved into database. Actual result: -- Fatal error: Exception thrown without a stack frame in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/?id=49087edit=1
#49078 [Opn-Fbk]: Make Failed sapi/cli/php Error 1
ID: 49078 Updated by: j...@php.net Reported By: kdprice at baylou dot com -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: CentOS 5 PHP Version: 5.3SVN-2009-07-27 (snap) New Comment: We haven't released 5.3.1 even, so how could you test 5.3.2? :D Anyway, I can't reproduce this under CentOS 5, using latest SVN checkout. Please try again, this time using _clean_ sources and configure _outside_ sources: /some/dir/sources /some/dir/build # cd /some/dir/build # /some/dir/sources/configure your options here Previous Comments: [2009-07-27 18:40:29] kdprice at baylou dot com Description: Make for php5.3.2 installation failed with an Error 1 related to sapi/cli/php. Reproduce code: --- ./configure --with-apxs2=/usr/local/apache2/bin/apxs --prefix=/usr/local/php5 --with-config-file-path=/usr/local/php5/lib --disable-cgi --with-gettext --with-gdbm --with-libxml-dir=/usr/include/libxml2/libxml --with-openssl=/usr/local/ssl --with-pear --with-zlib --with-pgsql=/usr/local/pgsql Expected result: A confirmation of success prior to Make Install Actual result: -- ext/standard/.libs/dns.o: In function `php_parserr': /tmp/Software/php5.3-200907271630/ext/standard/dns.c:389: undefined reference to `__dn_expand' /tmp/Software/php5.3-200907271630/ext/standard/dns.c:439: undefined reference to `__dn_expand' /tmp/Software/php5.3-200907271630/ext/standard/dns.c:623: undefined reference to `__dn_expand' /tmp/Software/php5.3-200907271630/ext/standard/dns.c:645: undefined reference to `__dn_expand' /tmp/Software/php5.3-200907271630/ext/standard/dns.c:484: undefined reference to `__dn_expand' ext/standard/.libs/dns.o:/tmp/Software/php5.3-200907271630/ext/standard/dns.c:490: more undefined references to `__dn_expand' follow ext/standard/.libs/dns.o: In function `zif_dns_check_record': /tmp/Software/php5.3-200907271630/ext/standard/dns.c:323: undefined reference to `__res_search' ext/standard/.libs/dns.o: In function `zif_dns_get_mx': /tmp/Software/php5.3-200907271630/ext/standard/dns.c:878: undefined reference to `__res_search' /tmp/Software/php5.3-200907271630/ext/standard/dns.c:889: undefined reference to `__dn_skipname' /tmp/Software/php5.3-200907271630/ext/standard/dns.c:895: undefined reference to `__dn_skipname' /tmp/Software/php5.3-200907271630/ext/standard/dns.c:907: undefined reference to `__dn_expand' ext/standard/.libs/dns.o: In function `zif_dns_get_record': /tmp/Software/php5.3-200907271630/ext/standard/dns.c:769: undefined reference to `__res_nmkquery' /tmp/Software/php5.3-200907271630/ext/standard/dns.c:777: undefined reference to `__res_nsend' /tmp/Software/php5.3-200907271630/ext/standard/dns.c:796: undefined reference to `__dn_skipname' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 -- Edit this bug report at http://bugs.php.net/?id=49078edit=1
#48182 [Asn-Csd]: ssl handshake fails during asynchronous socket connection
ID: 48182
Updated by: srina...@php.net
Reported By: frase at cs dot wisc dot edu
-Status: Assigned
+Status: Closed
Bug Type: OpenSSL related
Operating System: *
PHP Version: 5.2.10, 5.3.0
-Assigned To: pajoye
+Assigned To: srinatar
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Committed revision 286465.
Previous Comments:
[2009-07-10 13:38:01] frase at cs dot wisc dot edu
The supplied patch does fix the problem in 5.3.0 on Linux; I have no
Windows build environment so I can't test it there but can't see why it
wouldn't also work. Since the patch was to OpenSSL I've changed the
category back.
Many thanks!
[2009-07-09 21:53:03] sriram dot natarajan at gmail dot com
better still, here is the patch (more readable format)
http://pastebin.org/805
[2009-07-09 21:47:44] sriram dot natarajan at gmail dot com
thanks for your patience.
here is a patch that should address your issue. to apply this patch,
save the above text into a file and run
--- ext/openssl/xp_ssl.c.ORIG Thu Jul 9 12:20:44 2009
+++ ext/openssl/xp_ssl.cThu Jul 9 12:29:18 2009
@@ -672,7 +672,11 @@
* we notice that the connect
has actually been established */
php_stream_socket_ops.set_option(stream, option, value, ptrparam
TSRMLS_CC);
- if (xparam-outputs.returncode
== 0 sslsock-enable_on_connect) {
+ if
((sslsock-enable_on_connect)
+
((xparam-outputs.returncode == 0) ||
+(xparam-op ==
STREAM_XPORT_OP_CONNECT_ASYNC xparam-outputs.returncode == 1
+
xparam-outputs.error_code == EINPROGRESS)))
+ {
if
(php_stream_xport_crypto_setup(stream, sslsock-method, NULL TSRMLS_CC)
0 ||
php_stream_xport_crypto_enable(stream, 1 TSRMLS_CC) 0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, Failed to enable crypto);
- download and unzip the latest php 5.3snapshot from
http://snaps.php.net
- cd php-workspace ; patch -p0 -d . filename
now, you can run make and should be able to test it.
i will wait for some one to review this patch . hopefully, should
happen before next release :-)
[2009-07-01 16:28:14] frase at cs dot wisc dot edu
This bug remains also in 5.2.10.
Let's try a new summary and changing the category to Sockets, maybe
it will get someone's attention.
[2009-06-30 14:28:01] frase at cs dot wisc dot edu
This bug remains in 5.3.0 final.
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/48182
--
Edit this bug report at http://bugs.php.net/?id=48182edit=1
#49084 [Opn-Fbk]: PSFS_FEED_ME causes stream block
ID: 49084 Updated by: j...@php.net Reported By: morrisdavidd at gmail dot com -Status: Open +Status: Feedback Bug Type: Streams related Operating System: Linux/Unix PHP Version: 5.3.0 New Comment: Why do you open the pipe as writable one when you want to read from it..? Previous Comments: [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=49084edit=1
#49049 [Opn-Fbk]: file_exists() under unprivileged user with set user ID on execution fails
ID: 49049
Updated by: j...@php.net
Reported By: rusxakep at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: Linux 2.6.29
PHP Version: 5.2.10
New Comment:
Your report is quite confusing. You talk about creating /home/user/2/3
directories (note the missing 1?) but your straces show quite different
outputs. Please, come up with _simple_ way to reproduce this. Simple
meaning ONE php (and PHP ONLY!) file.
Previous Comments:
[2009-07-27 09:19:12] rusxakep at gmail dot com
Added -D__USE_FILE_OFFSET64 to CFLAGS and re-compile all php stuff.
Example of compilation (correct?):
/bin/sh
/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/libtool
--silent --preserve-dup-deps --mode=compile i686-pc-linux-gnu-gcc
-IZend/
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/Zend/
-DPHP_ATOM_INC
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/include
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/main
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/ext/date/lib
-I/usr/include/libxml2 -I/usr/include/freetype2
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/ext/mbstring/oniguruma
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/ext/mbstring/libmbfl
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/ext/mbstring/libmbfl/mbfl
-I/usr/include/mysql
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/TSRM
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/Zend
-I/usr/include -march=pentium4 -O2 -fomit-frame-pointer -pipe
-D_GNU_SOURCE -D__USE_FILE_OFFSET64 -prefer-non-pic -c
/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/Zend/zend_objects.c
-o Zend/zend_objects.lo
/bin/sh
/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/libtool
--silent --preserve-dup-deps --mode=compile i686-pc-linux-gnu-gcc
-IZend/
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/Zend/
-DPHP_ATOM_INC
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/include
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/main
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/ext/date/lib
-I/usr/include/libxml2 -I/usr/include/freetype2
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/ext/mbstring/oniguruma
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/ext/mbstring/libmbfl
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/ext/mbstring/libmbfl/mbfl
-I/usr/include/mysql
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/TSRM
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/Zend
-I/usr/include -march=pentium4 -O2 -fomit-frame-pointer -pipe
-D_GNU_SOURCE -D__USE_FILE_OFFSET64 -prefer-non-pic -c
/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/Zend/zend_object_handlers.c
-o Zend/zend_object_handlers.lo
My problem not resolved yet :(
access(/home/1/2/3, F_OK) = -1 EACCES (Permission
denied)
stat64(/home/1/2, {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
mkdir(/home/1/2/3, 0700) = -1 EEXIST (File exists)
write(1, \nWarning: mkdir(): File exists in..., 61
Warning: mkdir(): File exists in /home/1/test.php on line 3
) = 61)
[2009-07-26 12:02:56] j...@php.net
Did you or did you not compile using the LFS flags?
[2009-07-25 20:20:52] rusxakep at gmail dot com
No, isn't LFS bug.
I'm run test php from LFS bug notes. mkdir working fine. Directory has
been created successfully.)
[2009-07-24 17:10:09] j...@php.net
Would you please just do what I asked and try compile with LFS
flags..?
I'm quite sure this is same issue as in that other bug.
[2009-07-24 16:39:57] rusxakep at gmail dot com
I'm not guru in php development, but
access(/home/1/2/3, F_OK) = -1 EACCES (Permission
denied)
stat64(/home/1/2, {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
why stat64(/home/1/2), but no stat64(/home/1/2/3)?
why permission denied placed here with using set execution bit
feature?)
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/49049
--
Edit this bug report at http://bugs.php.net/?id=49049edit=1
#49049 [Fbk-Opn]: file_exists() under unprivileged user with set user ID on execution fails
ID: 49049
User updated by: rusxakep at gmail dot com
Reported By: rusxakep at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: Linux 2.6.29
PHP Version: 5.2.10
New Comment:
Jani,
Is bug reproducing ONLY with using set execution bit!
Simple way test with strace output:
1. Temprorarly set chmod 6755 to /usr/bin/strace binary for correct
test.
2. Create simple CONSOLE test.php file and place to /home/1/ directory
(owner should be root.root):
#!/usr/bin/php -q
?php
if (!file_exists(/home/1/2/3)) mkdir(/home/1/2/3,0700,true);
?
3. Run this script under any unprivileged user with next cmd: su -
someuser -c /usr/bin/strace /home/1/test.php
First run test.php create directory /home/1/2 and /home/1/2/3
successfully with someuser owner and 0700.
Second run test.php script must be finish w/o any messages, because
directory already exists, but function file_exists() incorrectly fulfils
and produces that the directory does not exist, though it is.
Try it!
If something else is not clear, I will explain more in detail.
Previous Comments:
[2009-07-28 19:52:47] j...@php.net
Your report is quite confusing. You talk about creating /home/user/2/3
directories (note the missing 1?) but your straces show quite different
outputs. Please, come up with _simple_ way to reproduce this. Simple
meaning ONE php (and PHP ONLY!) file.
[2009-07-27 09:19:12] rusxakep at gmail dot com
Added -D__USE_FILE_OFFSET64 to CFLAGS and re-compile all php stuff.
Example of compilation (correct?):
/bin/sh
/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/libtool
--silent --preserve-dup-deps --mode=compile i686-pc-linux-gnu-gcc
-IZend/
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/Zend/
-DPHP_ATOM_INC
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/include
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/main
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/ext/date/lib
-I/usr/include/libxml2 -I/usr/include/freetype2
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/ext/mbstring/oniguruma
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/ext/mbstring/libmbfl
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/ext/mbstring/libmbfl/mbfl
-I/usr/include/mysql
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/TSRM
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/Zend
-I/usr/include -march=pentium4 -O2 -fomit-frame-pointer -pipe
-D_GNU_SOURCE -D__USE_FILE_OFFSET64 -prefer-non-pic -c
/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/Zend/zend_objects.c
-o Zend/zend_objects.lo
/bin/sh
/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/libtool
--silent --preserve-dup-deps --mode=compile i686-pc-linux-gnu-gcc
-IZend/
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/Zend/
-DPHP_ATOM_INC
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/include
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/main
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/ext/date/lib
-I/usr/include/libxml2 -I/usr/include/freetype2
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/ext/mbstring/oniguruma
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/ext/mbstring/libmbfl
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/ext/mbstring/libmbfl/mbfl
-I/usr/include/mysql
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/TSRM
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/Zend
-I/usr/include -march=pentium4 -O2 -fomit-frame-pointer -pipe
-D_GNU_SOURCE -D__USE_FILE_OFFSET64 -prefer-non-pic -c
/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/Zend/zend_object_handlers.c
-o Zend/zend_object_handlers.lo
My problem not resolved yet :(
access(/home/1/2/3, F_OK) = -1 EACCES (Permission
denied)
stat64(/home/1/2, {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
mkdir(/home/1/2/3, 0700) = -1 EEXIST (File exists)
write(1, \nWarning: mkdir(): File exists in..., 61
Warning: mkdir(): File exists in /home/1/test.php on line 3
) = 61)
[2009-07-26 12:02:56] j...@php.net
Did you or did you not compile using the LFS flags?
[2009-07-25 20:20:52] rusxakep at gmail dot com
No, isn't LFS bug.
I'm run test php from LFS bug notes. mkdir working fine. Directory has
been created successfully.)
#42434 [Asn-Csd]: ImageLine w/ antialias = 1px shorter
ID: 42434
Updated by: ka...@php.net
Reported By: wojjie at gmail dot com
-Status: Assigned
+Status: Closed
Bug Type: GD related
Operating System: *
PHP Version: 5.2.6
Assigned To: pajoye
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2009-07-28 20:35:06] s...@php.net
Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revisionrevision=286466
Log: Fixed bug #42434 (ImageLine w/ antialias = 1px shorter)
- patch by wojjie at gmail dot com
[2008-09-05 02:19:52] abc at abc dot abc
reproduced on PHP 5.2.6 / windows. problem is still there
[2007-08-27 11:04:46] j...@php.net
Assigned to the maintainer.
[2007-08-27 04:50:47] wojjie at gmail dot com
Description:
This bug looks fixed in the GD library, but for some reason the GD
included in PHP still has this.
What happens is when drawing a line with anti aliasing enabled, the
resulting line is 1 pixel shorter than it should be.
Fix (using snapshot: php5.2-200708270430.tar.gz):
--- gd.c 2007-08-26 23:44:04.0 -0500
+++ gd.c2007-08-26 23:44:28.0 -0500
@@ -1351,7 +1351,7 @@
x = x1 16;
y = y1 16;
inc = (dy * 65536) / dx;
- while ((x 16) x2) {
+ while ((x 16) = x2) {
gdImageSetAAPixelColor(im, x 16, y 16,
col, (y 8) 0xFF);
if ((y 16) + 1 im-sy) {
gdImageSetAAPixelColor(im, x 16, (y
16) + 1,col, (~y 8) 0xFF);
@@ -1373,7 +1373,7 @@
x = x1 16;
y = y1 16;
inc = (dx * 65536) / dy;
- while ((y16) y2) {
+ while ((y16) = y2) {
gdImageSetAAPixelColor(im, x 16, y 16,
col, (x 8) 0xFF);
if ((x 16) + 1 im-sx) {
gdImageSetAAPixelColor(im, (x 16) +
1, (y 16),col, (~x 8) 0xFF);
Reproduce code:
---
?php
$im=imagecreatetruecolor(30,30);
$c1=ImageColorAllocate($im,255,255,255);
$c2=ImageColorAllocate($im, 0, 0, 0);
imagefill( $im,0,0, $c1 );
imageline($im,5,5, 25,5, $c2);
imageantialias($im,true);
imageline($im,5,25, 25,25, $c2);
header(Content-type: image/png);
imagepng($im);
imagedestroy($im);
?
Expected result:
Two lines of equal length
Actual result:
--
Top line is longer than bottom line by 1 pixel.
--
Edit this bug report at http://bugs.php.net/?id=42434edit=1
#49049 [Opn-Fbk]: file_exists() under unprivileged user with set user ID on execution fails
ID: 49049
Updated by: j...@php.net
Reported By: rusxakep at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: Linux 2.6.29
PHP Version: 5.2.10
New Comment:
My /home dir isn't writable by anyone. So how could it work? And what
does setting those permissions on strace help to debug this?
Previous Comments:
[2009-07-28 20:12:08] rusxakep at gmail dot com
Jani,
Is bug reproducing ONLY with using set execution bit!
Simple way test with strace output:
1. Temprorarly set chmod 6755 to /usr/bin/strace binary for correct
test.
2. Create simple CONSOLE test.php file and place to /home/1/ directory
(owner should be root.root):
#!/usr/bin/php -q
?php
if (!file_exists(/home/1/2/3)) mkdir(/home/1/2/3,0700,true);
?
3. Run this script under any unprivileged user with next cmd: su -
someuser -c /usr/bin/strace /home/1/test.php
First run test.php create directory /home/1/2 and /home/1/2/3
successfully with someuser owner and 0700.
Second run test.php script must be finish w/o any messages, because
directory already exists, but function file_exists() incorrectly fulfils
and produces that the directory does not exist, though it is.
Try it!
If something else is not clear, I will explain more in detail.)
[2009-07-28 19:52:47] j...@php.net
Your report is quite confusing. You talk about creating /home/user/2/3
directories (note the missing 1?) but your straces show quite different
outputs. Please, come up with _simple_ way to reproduce this. Simple
meaning ONE php (and PHP ONLY!) file.
[2009-07-27 09:19:12] rusxakep at gmail dot com
Added -D__USE_FILE_OFFSET64 to CFLAGS and re-compile all php stuff.
Example of compilation (correct?):
/bin/sh
/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/libtool
--silent --preserve-dup-deps --mode=compile i686-pc-linux-gnu-gcc
-IZend/
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/Zend/
-DPHP_ATOM_INC
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/include
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/main
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/ext/date/lib
-I/usr/include/libxml2 -I/usr/include/freetype2
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/ext/mbstring/oniguruma
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/ext/mbstring/libmbfl
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/ext/mbstring/libmbfl/mbfl
-I/usr/include/mysql
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/TSRM
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/Zend
-I/usr/include -march=pentium4 -O2 -fomit-frame-pointer -pipe
-D_GNU_SOURCE -D__USE_FILE_OFFSET64 -prefer-non-pic -c
/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/Zend/zend_objects.c
-o Zend/zend_objects.lo
/bin/sh
/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/libtool
--silent --preserve-dup-deps --mode=compile i686-pc-linux-gnu-gcc
-IZend/
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/Zend/
-DPHP_ATOM_INC
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/include
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/main
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/ext/date/lib
-I/usr/include/libxml2 -I/usr/include/freetype2
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/ext/mbstring/oniguruma
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/ext/mbstring/libmbfl
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/ext/mbstring/libmbfl/mbfl
-I/usr/include/mysql
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/TSRM
-I/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/Zend
-I/usr/include -march=pentium4 -O2 -fomit-frame-pointer -pipe
-D_GNU_SOURCE -D__USE_FILE_OFFSET64 -prefer-non-pic -c
/var/tmp/portage/dev-lang/php-5.2.99/work/php5.2-200907241430/Zend/zend_object_handlers.c
-o Zend/zend_object_handlers.lo
My problem not resolved yet :(
access(/home/1/2/3, F_OK) = -1 EACCES (Permission
denied)
stat64(/home/1/2, {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
mkdir(/home/1/2/3, 0700) = -1 EEXIST (File exists)
write(1, \nWarning: mkdir(): File exists in..., 61
Warning: mkdir(): File exists in /home/1/test.php on line 3
) = 61)
[2009-07-26 12:02:56] j...@php.net
Did you or did you not compile using the LFS flags?
#48645 [Opn-Ver]: mb_convert_encoding() doesn't understand hexadecimal html-entities
ID: 48645 Updated by: j...@php.net Reported By: psc at webcraft dot ch -Status: Open +Status: Verified Bug Type: mbstring related Operating System: Debian Lenny PHP Version: 5.2.10 Previous Comments: [2009-06-22 14:47:04] psc at webcraft dot ch Description: When converting a hexadecimal html entity to UTF-8 with mb_convert_encoding, it get's converted to a broken unicode character (displayed in firefox as a small square). Reproduce code: --- $v_html = #x161;; echo $v_html; echo mb_convert_encoding($v_html, 'UTF-8', 'HTML-ENTITIES'); echo html_entity_decode($v_html, ENT_COMPAT, 'UTF-8'); Expected result: I'd expect it to output three times the same character, scaron;. At first as hexadecimal html entity, then two times in UTF-8. scaron; Actual result: -- scaron;[something broken] -- Edit this bug report at http://bugs.php.net/?id=48645edit=1
#48911 [Opn-Csd]: embed sapi misses SAPI_API
ID: 48911
Updated by: j...@php.net
Reported By: thomas at koch dot ro
-Status: Open
+Status: Closed
Bug Type: Compile Failure
Operating System: Debian Lenny
PHP Version: 5.3.0
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2009-07-28 21:07:43] s...@php.net
Automatic comment from SVN on behalf of jani
Revision: http://svn.php.net/viewvc/?view=revisionrevision=286468
Log: - Fixed bug #48911 (embed sapi misses SAPI_API)
[2009-07-14 07:16:45] thomas at koch dot ro
Description:
I try the most simple program that uses the embed sapi. Due to missing
SAPI_API macros the symbols
int php_embed_init(int argc, char **argv PTSRMLS_DC);
void php_embed_shutdown(TSRMLS_D);
extern sapi_module_struct php_embed_module;
get visibility hidden in the resulting libphp5.so.
Fix: put SAPI_API before these symbols in sapi/embed/php_embed.c.
(Also in php_embed.h ?)
Thanks to ScottMac for the hint on IRC!
Reproduce code:
---
#include sapi/embed/php_embed.h
int main(int argc, char *argv[])
{
PHP_EMBED_START_BLOCK(argc,argv)
PHP_EMBED_END_BLOCK()
return 0;
}
Expected result:
should compile without problems
Actual result:
--
gcc -c -I/usr/local/include/php/ -I/usr/local/include/php/main -
I/usr/local/include/php/Zend -I/usr/local/include/php/TSRM -Wall -g -o
worker.o worker.c
gcc -L/usr/local/lib -lphp5 -o worker worker.o
worker.o: In function `main':
/var/checkouts/gearman-php-worker/worker.c:5: undefined reference to
`php_embed_init'
/var/checkouts/gearman-php-worker/worker.c:6: undefined reference to
`php_embed_shutdown'
collect2: ld returned 1 exit status
make: *** [all] Error
--
Edit this bug report at http://bugs.php.net/?id=48911edit=1
#48971 [Opn-Csd]: Missing ZEND_NS_NAMED_FE macro
ID: 48971
Updated by: j...@php.net
Reported By: mike at mikegerwitz dot com
-Status: Open
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: GNU/Linux
PHP Version: 5.3.0
New Comment:
Added the missing ZEND_NS_NAMED_FE macro. Adding the aliases for these
_new_ macros is totally unnecessary. Having those for the old stuff was
also unnecessary and very confusing to begin with, but that's another
story..
Previous Comments:
[2009-07-28 21:12:42] s...@php.net
Automatic comment from SVN on behalf of jani
Revision: http://svn.php.net/viewvc/?view=revisionrevision=286469
Log: - Fixed bug #48971 (Missing ZEND_NS_NAMED_FE macro)
[2009-07-18 19:42:46] mike at mikegerwitz dot com
Description:
PHP 5.3 seems to have missed a few things internally (macro-wise) when
it comes to namespaces. When developing an extension for 5.3, I noticed
the following:
Zend/zend_API.h:93
#define ZEND_NS_NAMED_FE(ns, zend_name, name, arg_info)
It's blank! I do not see any options to submit patches, therefore, this
should be the definition:
#define ZEND_NS_NAMED_FE(ns, zend_name, name, arg_info) \
ZEND_NS_FENTRY(ns, zend_name, name, arg_info, 0)
In addition, PHP_NS_* aliases are missing for the ZEND_NS_* macros. For
example, PHP_FE is an alias to ZEND_FE. Therefore, the following macros
should be added:
#define PHP_NS_FE ZEND_NS_FE
#define PHP_NS_NAMED_FE ZEND_NS_NAMED_FE
#define PHP_NS_DEP_FE ZEND_NS_DEP_FE
#define PHP_NS_FALIAS ZEND_NS_FALIAS
#define PHP_NS_DEP_FALIAS ZEND_NS_DEP_FALIAS
If you could provide me with a means to submit a patch, I would be more
than happy to do it myself, as I feel this to be an important (albeit
minor) addition for extension developers in order to keep things
consistent, and less confusing.
Reproduce code:
---
zend_function_entry php_test_functions[] = {
ZEND_NS_NAMED_FE( Ns, myfunc, test_myfunc, NULL )
{ NULL, NULL, NULL }
};
---
?php var_dump( get_extension_funcs('test') ); ?
Expected result:
array(1) {
[0]=
string(16) Ns\myfunc
}
Actual result:
--
array(0) {
}
--
Edit this bug report at http://bugs.php.net/?id=48971edit=1
#48971 [Csd]: Missing ZEND_NS_NAMED_FE macro
ID: 48971
Updated by: j...@php.net
Reported By: mike at mikegerwitz dot com
Status: Closed
Bug Type: Scripting Engine problem
Operating System: GNU/Linux
PHP Version: 5.3.0
New Comment:
Short version: ALWAYS use the ZEND_* macros. :)
Previous Comments:
[2009-07-28 21:14:14] j...@php.net
Added the missing ZEND_NS_NAMED_FE macro. Adding the aliases for these
_new_ macros is totally unnecessary. Having those for the old stuff was
also unnecessary and very confusing to begin with, but that's another
story..
[2009-07-28 21:12:42] s...@php.net
Automatic comment from SVN on behalf of jani
Revision: http://svn.php.net/viewvc/?view=revisionrevision=286469
Log: - Fixed bug #48971 (Missing ZEND_NS_NAMED_FE macro)
[2009-07-18 19:42:46] mike at mikegerwitz dot com
Description:
PHP 5.3 seems to have missed a few things internally (macro-wise) when
it comes to namespaces. When developing an extension for 5.3, I noticed
the following:
Zend/zend_API.h:93
#define ZEND_NS_NAMED_FE(ns, zend_name, name, arg_info)
It's blank! I do not see any options to submit patches, therefore, this
should be the definition:
#define ZEND_NS_NAMED_FE(ns, zend_name, name, arg_info) \
ZEND_NS_FENTRY(ns, zend_name, name, arg_info, 0)
In addition, PHP_NS_* aliases are missing for the ZEND_NS_* macros. For
example, PHP_FE is an alias to ZEND_FE. Therefore, the following macros
should be added:
#define PHP_NS_FE ZEND_NS_FE
#define PHP_NS_NAMED_FE ZEND_NS_NAMED_FE
#define PHP_NS_DEP_FE ZEND_NS_DEP_FE
#define PHP_NS_FALIAS ZEND_NS_FALIAS
#define PHP_NS_DEP_FALIAS ZEND_NS_DEP_FALIAS
If you could provide me with a means to submit a patch, I would be more
than happy to do it myself, as I feel this to be an important (albeit
minor) addition for extension developers in order to keep things
consistent, and less confusing.
Reproduce code:
---
zend_function_entry php_test_functions[] = {
ZEND_NS_NAMED_FE( Ns, myfunc, test_myfunc, NULL )
{ NULL, NULL, NULL }
};
---
?php var_dump( get_extension_funcs('test') ); ?
Expected result:
array(1) {
[0]=
string(16) Ns\myfunc
}
Actual result:
--
array(0) {
}
--
Edit this bug report at http://bugs.php.net/?id=48971edit=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=49084edit=1
#49084 [Bgs]: PSFS_FEED_ME causes stream block
ID: 49084 Updated by: j...@php.net Reported By: morrisdavidd at gmail dot com Status: Bogus Bug Type: Streams related Operating System: Linux/Unix PHP Version: 5.3.0 New Comment: nevermind, I forgot the proc_open params. :) Previous Comments: [2009-07-28 21:27:14] morrisdavidd at gmail dot com 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 ); ) [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=49084edit=1
#49084 [Bgs-Opn]: PSFS_FEED_ME causes stream block
ID: 49084 Updated by: j...@php.net Reported By: morrisdavidd at gmail dot com -Status: Bogus +Status: Open Bug Type: Streams related Operating System: Linux/Unix PHP Version: 5.3.0 Previous Comments: [2009-07-28 22:06:02] j...@php.net nevermind, I forgot the proc_open params. :) [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=49084edit=1
#49091 [NEW]: preg_replace bug and potential security issue
From: nomail at example dot com Operating system: Debian Linux 5.0 Lenny PHP version: 5.2.10 PHP Bug Type: *Regular Expressions Bug description: preg_replace bug and potential security issue Description: Using the latest stable Debian's PHP 5.2.6-1+lenny3. Can't use anything newer on this production server, sorry. Note that this malfunction in regular expressions might create exploitable application vulnerabilities (for example, a forum routine to sanitize posts). So this should be treated as a security fix. // This code works as expected and outputs: ttt www.exa.com/ZZZ ttt echo preg_replace( '#([a-z\.]+)+ZZZ#', 'i', 'ttt www.exa.com/ZZZ ttt'); // The following code is the same but it will not work, even though it // should. It will produce just an empty string. The only difference // between this call and the previous call is that the text contains // a LONGER domain name (instead of exa, it contains the word // example). echo preg_replace( '#([a-z\.]+)+ZZZ#', 'i', 'ttt www.example.com/ZZZ ttt'); Note: preg_last_error() returns the bogus PREG_SET_ORDER, which should apply only to preg_match_all() and not to preg_replace(). Reproduce code: --- echo preg_replace( '#([a-z\.]+)+ZZZ#', 'i', 'ttt www.example.com/ZZZ ttt'); Expected result: ttt www.example.com/ZZZ ttt Actual result: -- Empty string -- Edit bug report at http://bugs.php.net/?id=49091edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49091r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49091r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49091r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49091r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49091r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49091r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49091r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49091r=needscript Try newer version: http://bugs.php.net/fix.php?id=49091r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49091r=support Expected behavior: http://bugs.php.net/fix.php?id=49091r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49091r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49091r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49091r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49091r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49091r=dst IIS Stability: http://bugs.php.net/fix.php?id=49091r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49091r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49091r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49091r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49091r=mysqlcfg
#49084 [Opn-Bgs]: PSFS_FEED_ME causes stream block
ID: 49084 Updated by: j...@php.net Reported By: morrisdavidd at gmail dot com -Status: Open +Status: Bogus Bug Type: Streams related Operating System: Linux/Unix PHP Version: 5.3.0 New Comment: I didn't ask for manual page, I asked why you try to read from pipe opened for writing. And when you change it to 'r' you get your expected result. No bug here. Previous Comments: [2009-07-28 21:27:14] morrisdavidd at gmail dot com 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 ); ) [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=49084edit=1
#49092 [NEW]: ReflectionFunction fails to work with functions in fully qualified namespaces
From: crystality at mail dot ru
Operating system: Windows XP SP3
PHP version: 5.3.0
PHP Bug Type: Reflection related
Bug description: ReflectionFunction fails to work with functions in fully
qualified namespaces
Description:
Just about the same bug I've reported in #47593
This time ReflectionFunction fails to work with functions with fully
qualified namespaces.
Reproduce code:
---
namespace ns;
function func(){}
//new \ReflectionFunction('ns\func'); //Works
new \ReflectionFunction('\ns\func'); //Throws exception
Expected result:
new ReflectionFunction object created
Actual result:
--
Fatal error: Uncaught exception 'ReflectionException' with message
'Function \ns\func() does not exist' in ...
--
Edit bug report at http://bugs.php.net/?id=49092edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49092r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49092r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49092r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49092r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49092r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49092r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49092r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49092r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49092r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49092r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49092r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49092r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49092r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49092r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49092r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49092r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49092r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49092r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49092r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49092r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49092r=mysqlcfg
#49093 [NEW]: ReflectionFunction fails to work with functions in fully qualified namespaces
From: crystality at mail dot ru
Operating system: Windows XP SP3
PHP version: 5.3.0
PHP Bug Type: Reflection related
Bug description: ReflectionFunction fails to work with functions in fully
qualified namespaces
Description:
Just about the same bug I've reported in #47593
This time ReflectionFunction fails to work with functions with fully
qualified namespaces.
Reproduce code:
---
namespace ns;
function func(){}
//new \ReflectionFunction('ns\func'); //Works
new \ReflectionFunction('\ns\func'); //Throws exception
Expected result:
new ReflectionFunction object created
Actual result:
--
Fatal error: Uncaught exception 'ReflectionException' with message
'Function \ns\func() does not exist' in ...
--
Edit bug report at http://bugs.php.net/?id=49093edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49093r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49093r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49093r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49093r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49093r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49093r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49093r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49093r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49093r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49093r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49093r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49093r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49093r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49093r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49093r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49093r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49093r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49093r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49093r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49093r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49093r=mysqlcfg
#49093 [Opn-Bgs]: ReflectionFunction fails to work with functions in fully qualified namespaces
ID: 49093
User updated by: crystality at mail dot ru
Reported By: crystality at mail dot ru
-Status: Open
+Status: Bogus
Bug Type: Reflection related
Operating System: Windows XP SP3
PHP Version: 5.3.0
New Comment:
Since the php.net site bugged a bit, threw Warning: Cannot modify
header information - headers already sent by (output started at
/home/Web/sites/php-bugs-web/include/auth.inc:30) in
/home/Web/sites/php-bugs-web/report.php on line 195 and sent me my own
bug-report, I've made this by mistake. Refer to 49092.
Previous Comments:
[2009-07-28 22:48:30] crystality at mail dot ru
Description:
Just about the same bug I've reported in #47593
This time ReflectionFunction fails to work with functions with fully
qualified namespaces.
Reproduce code:
---
namespace ns;
function func(){}
//new \ReflectionFunction('ns\func'); //Works
new \ReflectionFunction('\ns\func'); //Throws exception
Expected result:
new ReflectionFunction object created
Actual result:
--
Fatal error: Uncaught exception 'ReflectionException' with message
'Function \ns\func() does not exist' in ...
--
Edit this bug report at http://bugs.php.net/?id=49093edit=1
#49091 [Opn-Ana]: preg_replace bug and potential security issue
ID: 49091 Updated by: ras...@php.net Reported By: nomail at example dot com -Status: Open +Status: Analyzed Bug Type: *Regular Expressions Operating System: Debian Linux 5.0 Lenny PHP Version: 5.2.10 New Comment: PREG_SET_ORDER is not an error constant. The actual error is PREG_BACKTRACK_LIMIT_ERROR which is set when the pcre library returns a PCRE_ERROR_MATCHLIMIT Run the command-line pcre test tool and file a bug with pcre if you think this is a bug. Previous Comments: [2009-07-28 22:36:02] nomail at example dot com Description: Using the latest stable Debian's PHP 5.2.6-1+lenny3. Can't use anything newer on this production server, sorry. Note that this malfunction in regular expressions might create exploitable application vulnerabilities (for example, a forum routine to sanitize posts). So this should be treated as a security fix. // This code works as expected and outputs: ttt www.exa.com/ZZZ ttt echo preg_replace( '#([a-z\.]+)+ZZZ#', 'i', 'ttt www.exa.com/ZZZ ttt'); // The following code is the same but it will not work, even though it // should. It will produce just an empty string. The only difference // between this call and the previous call is that the text contains // a LONGER domain name (instead of exa, it contains the word // example). echo preg_replace( '#([a-z\.]+)+ZZZ#', 'i', 'ttt www.example.com/ZZZ ttt'); Note: preg_last_error() returns the bogus PREG_SET_ORDER, which should apply only to preg_match_all() and not to preg_replace(). Reproduce code: --- echo preg_replace( '#([a-z\.]+)+ZZZ#', 'i', 'ttt www.example.com/ZZZ ttt'); Expected result: ttt www.example.com/ZZZ ttt Actual result: -- Empty string -- Edit this bug report at http://bugs.php.net/?id=49091edit=1
#49091 [Ana]: preg_replace bug and potential security issue
ID: 49091 Updated by: ras...@php.net Reported By: nomail at example dot com Status: Analyzed Bug Type: *Regular Expressions Operating System: Debian Linux 5.0 Lenny PHP Version: 5.2.10 New Comment: Note also that if you crank up the backtrack limit in pcre, your second example works: pcre.backtrack_limit=100 Previous Comments: [2009-07-28 23:15:32] ras...@php.net PREG_SET_ORDER is not an error constant. The actual error is PREG_BACKTRACK_LIMIT_ERROR which is set when the pcre library returns a PCRE_ERROR_MATCHLIMIT Run the command-line pcre test tool and file a bug with pcre if you think this is a bug. [2009-07-28 22:36:02] nomail at example dot com Description: Using the latest stable Debian's PHP 5.2.6-1+lenny3. Can't use anything newer on this production server, sorry. Note that this malfunction in regular expressions might create exploitable application vulnerabilities (for example, a forum routine to sanitize posts). So this should be treated as a security fix. // This code works as expected and outputs: ttt www.exa.com/ZZZ ttt echo preg_replace( '#([a-z\.]+)+ZZZ#', 'i', 'ttt www.exa.com/ZZZ ttt'); // The following code is the same but it will not work, even though it // should. It will produce just an empty string. The only difference // between this call and the previous call is that the text contains // a LONGER domain name (instead of exa, it contains the word // example). echo preg_replace( '#([a-z\.]+)+ZZZ#', 'i', 'ttt www.example.com/ZZZ ttt'); Note: preg_last_error() returns the bogus PREG_SET_ORDER, which should apply only to preg_match_all() and not to preg_replace(). Reproduce code: --- echo preg_replace( '#([a-z\.]+)+ZZZ#', 'i', 'ttt www.example.com/ZZZ ttt'); Expected result: ttt www.example.com/ZZZ ttt Actual result: -- Empty string -- Edit this bug report at http://bugs.php.net/?id=49091edit=1
#49065 [Ver-Csd]: disable_functions php.ini option does not work on Zend extensions
ID: 49065 Updated by: s...@php.net Reported By: yoram dot b at zend dot com -Status: Verified +Status: Closed Bug Type: Scripting Engine problem Operating System: * PHP Version: 5.*, 6SVN (2009-07-26) New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. fixed, thanks Previous Comments: [2009-07-29 00:18:20] s...@php.net Automatic comment from SVN on behalf of stas Revision: http://svn.php.net/viewvc/?view=revisionrevision=286479 Log: report fix for bug #49065 [2009-07-29 00:17:10] s...@php.net Automatic comment from SVN on behalf of stas Revision: http://svn.php.net/viewvc/?view=revisionrevision=286478 Log: fix extension functions disabling (bug #49065) [2009-07-28 16:36:56] j...@php.net FYI: The person who committed the code is Zeev. AFAIK, he has something to do with Zend. It's _ZEND_ extensions you're talking about.. [2009-07-28 08:32:27] yoram dot b at zend dot com This is PHP code, it has nothing to do with Zend, only with zend...) [2009-07-26 19:06:55] j...@php.net Indeed. Maybe someone at Zend had a reason for that? Try asking around. :) 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/49065 -- Edit this bug report at http://bugs.php.net/?id=49065edit=1
#32283 [Com]: zlib.output_compression = 1 but no headers sent
ID: 32283 Comment by: apinstein at mac dot com Reported By: plasmahh at gmx dot net Status: No Feedback Bug Type: Output Control Operating System: Linux PHP Version: 5CVS-2005-03-14 New Comment: I had this same problem when I upgraded an existing install to php 5.3. Turns out that the problem is ext/zlib. When I de-activated that module it behaved as expected. Not sure if that means this is a php bug or a ext/zlib bug, but at least it's reproducible! Hope that helps someone. My config (in httpd.conf): # enable php gzip php_flag zlib.output_compression On php_value zlib.output_compression_level 9 One more thing to add, although it works when zlib is disabled, there is no compression! Previous Comments: [2005-05-02 16:05:48] matt at dis dot com I have this problem too, albeit with PHP 4.3.7. Very annoying [2005-04-20 01:00:06] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2005-04-12 08:44:22] sni...@php.net Is ext/zlib compiled as shared by any chance in your system? What was the configure line you've used? [2005-03-25 15:13:30] plasmahh at gmx dot net This is an example when I do it with mozilla, but its always the same whenever an accept encoding of gzip or deflate is present... GET / HTTP/1.1 Host: localhost User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050321 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive [2005-03-17 18:02:21] il...@php.net What headers are being sent by the browser making the request? 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/32283 -- Edit this bug report at http://bugs.php.net/?id=32283edit=1
#48994 [Com]: zlib.output_compression does not ouput HTTP headers when set to a string value
ID: 48994
Comment by: apinstein at mac dot com
Reported By: jflatnes at vt dot edu
Status: Assigned
Bug Type: Zlib Related
Operating System: Linux 2.6.29
PHP Version: 5.2.10
Assigned To: jani
New Comment:
I ran into this issue today as well... but I have more to add.
Using PHP 5.3 + zlib 1.2.3
I *cannot* get compression + headers. I can get no compression, or
compression
w/o headers, but never working compression+headers.
I have tried:
httpd.conf:
php_flag zlib.output_compression On
php_admin_flag zlib.output_compression On
- zip + no headers
php_flag zlib.output_compression true
php_admin_flag zlib.output_compression true
- not zipped
In app.php:
ini_set('zlib.output_compression', true);
ini_set('zlib.output_compression', On);
- not zipped
Previous Comments:
[2009-07-21 22:50:56] j...@php.net
There is something weird going on here, verified it now. Need to
investigate more tomorrow. To reproduce on command line:
# HTTP_ACCEPT_ENCODING=gzip gdb --arg php-cgi test.php
[2009-07-21 19:03:10] jflatnes at vt dot edu
?php var_dump(ini_set('zlib.output_compression', 'On')); ?
Results in:
string(0) (meaning I had no previous setting for
zlib.output_compression, I believe)
---
I am coming to understand that the string 'On' doesn't behave the same
way in ini_set as in an ini file, as mentioned. The issue I see here is
that there are two options for zlib compression:
zlib.output_compression = false: no compression with no headers.
zlib.output_compression = true: compression with appropriate headers.
Passing a string to ini_set (other than the string '1') causes a third,
undocumented behavior:
zlib.output_compression = 'On': compression without the headers.
Those three states describe the behavior I'm seeing, and the third
state seems like a bug. If 'On' is an invalid setting, shouldn't the
compression simply not be activated? Am I thinking about this
correctly?)
[2009-07-21 18:46:33] j...@php.net
Try this too:
?php
var_dump(ini_set('zlib.output_compression', 'On'));
?
Also note that using On or Off or such with ini_set() does NOT work
like they do when used in php.ini.
[2009-07-21 02:48:18] jflatnes at vt dot edu
Description:
When the configuration option 'zlib.output_compression' is set to a
boolean value, output is compressed and the appropriate HTTP headers are
sent. When the option is set to a string like 'true' or 'On', the
output is compressed, but no headers are sent, causing browsers to fail
to interpret the output as compressed.
Reproduce code:
---
?php
ini_set('zlib.output_compression', 'On');
echo 'hello, world';
?
Expected result:
The output hello, world to be gzip/deflate compressed as appropriate
for Accept-Encoding, and the Content-Encoding and Vary HTTP headers to
be set.
Actual result:
--
Instead, the output is indeed gzip-compressed, but the Content-Encoding
and Vary headers are not set.
The actual text that the browser prints is:
#65533;#65533;#65533;#65533;#65533;#65533;ÊHÍÉÉ×Q(Ï/ÊI#65533;#65533;#65533;ÿÿ#65533;:r«ÿ
#65533;#65533;#65533;
Note, this works correctly with the an ini_set argument of the boolean
value true. The documentation claims that ini_set should take string
arguments, though. Even if a boolean/integer is required to activate
output compression, the behavior should either be all on or all off.
--
Edit this bug report at http://bugs.php.net/?id=48994edit=1
#16155 [Com]: variables_order affects existence of php predefined variables
ID: 16155 Comment by: cly109 at 126 dot com Reported By: rlm at pricegrabber dot com Status: Open Bug Type: Feature/Change Request Operating System: all PHP Version: 4CVS New Comment: The price of Buya href=http://www.mytopchi.com;chi hair straightener/a for the two new races is as the same as the original races. Previous Comments: [2002-10-07 12:38:20] phi...@php.net feature request- php options bug [2002-07-10 20:08:46] phi...@php.net This is a feature request as it's documented and expected bahavior. Your points are valid and shared by many. It's a matter of sitting down, thinking it through, and coming up with a nice BC friendly solution. In speaking with Zeev, he tentively suggested the following: (a) Decouple variables_order from the $_* / $HTTP_*_VARS completely. (b) Make it possible to prevent $_ENV and $_SERVER from being populated. Like env_autoglobal = on and server_autoglobal = on. (c) It shouldn't be possible to prevent $_GET, $_POST, $_COOKIE, and $_FILES from being populated. This falls in line with your suggestions. The current variables_order manual entry is vague on this particular matter, yes, but it's there, and it's much clearer in the other aforementioned entries. With variables_order = GPCS and register_globals = off, the global namespace will not be polluted. Not sure what you mean there as $_GET['id'] will exist, $id will not. [2002-07-10 19:02:52] rlm at pricegrabber dot com Oops. That should be track_vars On That's all. What this implies is that if track_vars is on, variables_order shouldn't prohibit any HTTP_*_VARS variable from being set (i.e., parsing always occurs). The only utility that variables_order gives you is the ability to say with some certainty where a particular global might have originated given overlapping names in two or more sources. That is, if I have a foo in my cookies, a url that looks like http://www.blorg.com/blech.php?foo=bar, and a POST var called foo on the same page, AND if variables_order is set to CGP, I know for sure that the global $foo came from the POST if there was one, then from the Get (URL), then from the cookies. And that's it! [2002-07-10 18:57:33] rlm at pricegrabber dot com No, it won't, because that will also add the variables to the global namespace. This is not a feature request -- it's *making the system work as advertised*. There already is -- or should be, if the writers of the documentation were correct -- a way to disable global variable imports, which ought to be the configuration lines register_globals = Off variables_order = That is, - register_globals should control the registration of globals, and - variables_order should control the source(s) of and order of global variable parsing. Just like it says in the documentation: variables_order string Set the order of the EGPCS (Environment, GET, POST, Cookie, Server) variable parsing. The default setting of this directive is EGPCS. Setting this to GP, for example, will cause PHP to completely ignore environment variables, cookies and server variables, and to overwrite any GET method variables with POST-method variables of the same name. Notice how the above makes NO mention of whether track_vars is set -- but that doesn't matter, because track_vars IS ALWAYS SET ON! That implies that variable tracking in HTTP_*_VARS should ALWAYS happen. ALWAYS. The tools to do this already exists. This is not a feature but a bug -- the extant documentation describes a rationally behaving environment, but PHP no longer conforms to it. [2002-07-10 18:21:53] phi...@php.net Just set the PHP predefined variables you want in the variables_order directive. Like, GPCS or EGPCS. And turn register_globals off. This will do what you want. I'm turning this into a feature request and changing the summary. See Rasmus' post/thread for details on this request. Whoever decided that variables_order should be 'es' during your install should be informed on the matter too. 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/16155 -- Edit this bug report at http://bugs.php.net/?id=16155edit=1
#48645 [Ver-Asn]: mb_convert_encoding() doesn't understand hexadecimal html-entities
ID: 48645 Updated by: moriyo...@php.net Reported By: psc at webcraft dot ch -Status: Verified +Status: Assigned Bug Type: mbstring related Operating System: Debian Lenny PHP Version: 5.* -Assigned To: +Assigned To: moriyoshi New Comment: This isn't actually a bug, as it wasn't implemented at all. (I don't know why the original implementer doesn't take account of it.) Previous Comments: [2009-06-22 14:47:04] psc at webcraft dot ch Description: When converting a hexadecimal html entity to UTF-8 with mb_convert_encoding, it get's converted to a broken unicode character (displayed in firefox as a small square). Reproduce code: --- $v_html = #x161;; echo $v_html; echo mb_convert_encoding($v_html, 'UTF-8', 'HTML-ENTITIES'); echo html_entity_decode($v_html, ENT_COMPAT, 'UTF-8'); Expected result: I'd expect it to output three times the same character, scaron;. At first as hexadecimal html entity, then two times in UTF-8. scaron; Actual result: -- scaron;[something broken] -- Edit this bug report at http://bugs.php.net/?id=48645edit=1
#48645 [Asn-Csd]: mb_convert_encoding() doesn't understand hexadecimal html-entities
ID: 48645 Updated by: moriyo...@php.net Reported By: psc at webcraft dot ch -Status: Assigned +Status: Closed Bug Type: mbstring related Operating System: Debian Lenny PHP Version: 5.* Assigned To: moriyoshi New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2009-07-29 04:44:08] s...@php.net Automatic comment from SVN on behalf of moriyoshi Revision: http://svn.php.net/viewvc/?view=revisionrevision=286483 Log: * Fix bug #48645 (mb_convert_encoding() doesn't understand hexadecimal html-entities) [2009-07-29 03:00:17] moriyo...@php.net This isn't actually a bug, as it wasn't implemented at all. (I don't know why the original implementer doesn't take account of it.) [2009-06-22 14:47:04] psc at webcraft dot ch Description: When converting a hexadecimal html entity to UTF-8 with mb_convert_encoding, it get's converted to a broken unicode character (displayed in firefox as a small square). Reproduce code: --- $v_html = #x161;; echo $v_html; echo mb_convert_encoding($v_html, 'UTF-8', 'HTML-ENTITIES'); echo html_entity_decode($v_html, ENT_COMPAT, 'UTF-8'); Expected result: I'd expect it to output three times the same character, scaron;. At first as hexadecimal html entity, then two times in UTF-8. scaron; Actual result: -- scaron;[something broken] -- Edit this bug report at http://bugs.php.net/?id=48645edit=1
