#41492 [NEW]: open_basedir bypass via readfile()
From: bugs dot php dot net at chsc dot dk Operating system: Linux PHP version: 5.2.2 PHP Bug Type: Safe Mode/open_basedir Bug description: open_basedir bypass via readfile() Description: file_exists() etc. does not allow checking the existence of files outside the directories specified in open_basedir. Appearently readfile() does *not* have this restriction and thus allows checking the existence of files anywhere in the filesystem. If realpath($filename) returns a string (i.e. not false), the file exists. This is a circumvention of the open_basedir restriction in file_exists() etc. Reproduce code: --- The following should always be true, but it isn't when $dir is outside the directories specified in open_basedir: var_dump(file_exists($dir) === (bool) realpath($dir)); -- Edit bug report at http://bugs.php.net/?id=41492edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41492r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41492r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41492r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41492r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41492r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41492r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41492r=needscript Try newer version:http://bugs.php.net/fix.php?id=41492r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41492r=support Expected behavior:http://bugs.php.net/fix.php?id=41492r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41492r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41492r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41492r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41492r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41492r=dst IIS Stability:http://bugs.php.net/fix.php?id=41492r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41492r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41492r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41492r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41492r=mysqlcfg
#40009 [NEW]: http_build_query(array()) returns NULL, not empty string
From: bugs dot php dot net at chsc dot dk Operating system: Windows PHP version: 5.2.0 PHP Bug Type: URL related Bug description: http_build_query(array()) returns NULL, not empty string Description: http_build_query(array()) returns NULL. According to the documentation, the return type of http_build_query is string. This can be considered a documentation problem, but I think it would be better to change the function so that it always returns a string. Reproduce code: --- ./php.exe -r echo gettype(http_build_query(array())); Expected result: string Actual result: -- NULL -- Edit bug report at http://bugs.php.net/?id=40009edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40009r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40009r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40009r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40009r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40009r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40009r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40009r=needscript Try newer version:http://bugs.php.net/fix.php?id=40009r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40009r=support Expected behavior:http://bugs.php.net/fix.php?id=40009r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40009r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40009r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40009r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40009r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40009r=dst IIS Stability:http://bugs.php.net/fix.php?id=40009r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40009r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40009r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40009r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40009r=mysqlcfg
#35326 [Opn]: Concurrency issue with recursive mkdir
ID: 35326
User updated by: bugs dot php dot net at chsc dot dk
Reported By: bugs dot php dot net at chsc dot dk
Status: Open
Bug Type: Feature/Change Request
Operating System: Linux
-PHP Version: 5.0.5
+PHP Version: 5.1.6
New Comment:
Problem still exists in PHP 5.1.6.
Previous Comments:
[2005-11-22 13:52:24] bugs dot php dot net at chsc dot dk
Yes, it also occurs with the CVS snapshot (this time I tried with the
CGI version).
AFAICS the problem is in php_plain_files_mkdir in
main/streams/plain_wrapper.c. If php_mkdir() or VCWD_MKDIR() returns
false, the method gives up instead of checking whether directory exists
anyway, i.e. if it was created by another thread.
[2005-11-22 12:13:10] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-11-22 11:32:49] bugs dot php dot net at chsc dot dk
Description:
There appears to be a concurrency issue when mkdir is called on two
separate threads with the following parameters:
Thread 1:
mkdir('/tmp/foo/bar/1', 0777, true);
Thread 2:
mkdir('/tmp/foo/bar/2', 0777, true);
Sometimes one of the threads (e.g. thread 2) two fails with Warning:
mkdir(): File exists and the directory /tmp/foo/bar/2 does not exist
afterwards.
What I think is happening in thread 2 is is this:
PHP looks for /tmp/foo/bar/2 and sees that it does not exist. Neither
does /tmp/foo/bar and /tmp/foo. So it tries to create /tmp/foo, but
that directory was just created a millisecond second ago by another
thread, so mkdir gives instead of just moving on to create /tmp/foo/bar
and /tmp/foo/bar/2.
Reproduce code:
---
This code reproduces the problem in about every second attempt. It
consists of two files, index.php and iframe.php.
index.php:
?php
$fire = time() + 2;
?
h1Nr. 1/h1
iframe src=iframe.php?fire=?= $fire ?amp;no=1/iframe
h1Nr. 2/h1
iframe src=iframe.php?fire=?= $fire ?amp;no=2/iframe
iframe.php:
?php
$fire = $_GET['fire'];
$no = $_GET['no'];
// synchronize the two threads
while ($fire time());
$dir = '/tmp/' . $fire . '/foo/bar/foo/bar/' . $no;
//sleep($no);
var_dump(is_dir($dir));
echo Making $dir ;
mkdir($dir, 0777, true);
var_dump(is_dir($dir));
?
Expected result:
Thread 2 should output this:
bool(false) Making /tmp/1132653651/foo/bar/foo/bar/2 bool(true)
Actual result:
--
Thread 2 sometimes outputs this:
bool(false) Making /tmp/1132655181/foo/bar/foo/bar/2 Warning: mkdir():
File exists in /home/chsc/public_html/mkdir/iframe.php on line 10
bool(false)
Notice that the directory does not exist afterwards.
If I uncomment the sleep() call above, there are no problems.
A workaround:
$ok = mkdir($dir, 0777, true);
if (!$ok !is_dir($dir)) {
sleep(1);
mkdir($dir, 0777, true);
}
In other words, it works if I try again. I hope that mkdir() can be
changed so that it only returns false if the directory cannot be
created at all (e.g. because of lack of permissions or because it
already exists).
--
Edit this bug report at http://bugs.php.net/?id=35326edit=1
#35326 [NEW]: Concurrency issue with recursive mkdir
From: bugs dot php dot net at chsc dot dk
Operating system: Linux
PHP version: 5.0.5
PHP Bug Type: Directory function related
Bug description: Concurrency issue with recursive mkdir
Description:
There appears to be a concurrency issue when mkdir is called on two
separate threads with the following parameters:
Thread 1:
mkdir('/tmp/foo/bar/1', 0777, true);
Thread 2:
mkdir('/tmp/foo/bar/2', 0777, true);
Sometimes one of the threads (e.g. thread 2) two fails with Warning:
mkdir(): File exists and the directory /tmp/foo/bar/2 does not exist
afterwards.
What I think is happening in thread 2 is is this:
PHP looks for /tmp/foo/bar/2 and sees that it does not exist. Neither does
/tmp/foo/bar and /tmp/foo. So it tries to create /tmp/foo, but that
directory was just created a millisecond second ago by another thread, so
mkdir gives instead of just moving on to create /tmp/foo/bar and
/tmp/foo/bar/2.
Reproduce code:
---
This code reproduces the problem in about every second attempt. It
consists of two files, index.php and iframe.php.
index.php:
?php
$fire = time() + 2;
?
h1Nr. 1/h1
iframe src=iframe.php?fire=?= $fire ?amp;no=1/iframe
h1Nr. 2/h1
iframe src=iframe.php?fire=?= $fire ?amp;no=2/iframe
iframe.php:
?php
$fire = $_GET['fire'];
$no = $_GET['no'];
// synchronize the two threads
while ($fire time());
$dir = '/tmp/' . $fire . '/foo/bar/foo/bar/' . $no;
//sleep($no);
var_dump(is_dir($dir));
echo Making $dir ;
mkdir($dir, 0777, true);
var_dump(is_dir($dir));
?
Expected result:
Thread 2 should output this:
bool(false) Making /tmp/1132653651/foo/bar/foo/bar/2 bool(true)
Actual result:
--
Thread 2 sometimes outputs this:
bool(false) Making /tmp/1132655181/foo/bar/foo/bar/2 Warning: mkdir():
File exists in /home/chsc/public_html/mkdir/iframe.php on line 10
bool(false)
Notice that the directory does not exist afterwards.
If I uncomment the sleep() call above, there are no problems.
A workaround:
$ok = mkdir($dir, 0777, true);
if (!$ok !is_dir($dir)) {
sleep(1);
mkdir($dir, 0777, true);
}
In other words, it works if I try again. I hope that mkdir() can be
changed so that it only returns false if the directory cannot be created
at all (e.g. because of lack of permissions or because it already
exists).
--
Edit bug report at http://bugs.php.net/?id=35326edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35326r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=35326r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=35326r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=35326r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=35326r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35326r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=35326r=needscript
Try newer version: http://bugs.php.net/fix.php?id=35326r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35326r=support
Expected behavior: http://bugs.php.net/fix.php?id=35326r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35326r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35326r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=35326r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35326r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=35326r=dst
IIS Stability: http://bugs.php.net/fix.php?id=35326r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35326r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35326r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35326r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=35326r=mysqlcfg
#35326 [Fbk-Opn]: Concurrency issue with recursive mkdir
ID: 35326
User updated by: bugs dot php dot net at chsc dot dk
Reported By: bugs dot php dot net at chsc dot dk
-Status: Feedback
+Status: Open
Bug Type: Directory function related
Operating System: Linux
PHP Version: 5.0.5
New Comment:
Yes, it also occurs with the CVS snapshot (this time I tried with the
CGI version).
AFAICS the problem is in php_plain_files_mkdir in
main/streams/plain_wrapper.c. If php_mkdir() or VCWD_MKDIR() returns
false, the method gives up instead of checking whether directory exists
anyway, i.e. if it was created by another thread.
Previous Comments:
[2005-11-22 12:13:10] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-11-22 11:32:49] bugs dot php dot net at chsc dot dk
Description:
There appears to be a concurrency issue when mkdir is called on two
separate threads with the following parameters:
Thread 1:
mkdir('/tmp/foo/bar/1', 0777, true);
Thread 2:
mkdir('/tmp/foo/bar/2', 0777, true);
Sometimes one of the threads (e.g. thread 2) two fails with Warning:
mkdir(): File exists and the directory /tmp/foo/bar/2 does not exist
afterwards.
What I think is happening in thread 2 is is this:
PHP looks for /tmp/foo/bar/2 and sees that it does not exist. Neither
does /tmp/foo/bar and /tmp/foo. So it tries to create /tmp/foo, but
that directory was just created a millisecond second ago by another
thread, so mkdir gives instead of just moving on to create /tmp/foo/bar
and /tmp/foo/bar/2.
Reproduce code:
---
This code reproduces the problem in about every second attempt. It
consists of two files, index.php and iframe.php.
index.php:
?php
$fire = time() + 2;
?
h1Nr. 1/h1
iframe src=iframe.php?fire=?= $fire ?amp;no=1/iframe
h1Nr. 2/h1
iframe src=iframe.php?fire=?= $fire ?amp;no=2/iframe
iframe.php:
?php
$fire = $_GET['fire'];
$no = $_GET['no'];
// synchronize the two threads
while ($fire time());
$dir = '/tmp/' . $fire . '/foo/bar/foo/bar/' . $no;
//sleep($no);
var_dump(is_dir($dir));
echo Making $dir ;
mkdir($dir, 0777, true);
var_dump(is_dir($dir));
?
Expected result:
Thread 2 should output this:
bool(false) Making /tmp/1132653651/foo/bar/foo/bar/2 bool(true)
Actual result:
--
Thread 2 sometimes outputs this:
bool(false) Making /tmp/1132655181/foo/bar/foo/bar/2 Warning: mkdir():
File exists in /home/chsc/public_html/mkdir/iframe.php on line 10
bool(false)
Notice that the directory does not exist afterwards.
If I uncomment the sleep() call above, there are no problems.
A workaround:
$ok = mkdir($dir, 0777, true);
if (!$ok !is_dir($dir)) {
sleep(1);
mkdir($dir, 0777, true);
}
In other words, it works if I try again. I hope that mkdir() can be
changed so that it only returns false if the directory cannot be
created at all (e.g. because of lack of permissions or because it
already exists).
--
Edit this bug report at http://bugs.php.net/?id=35326edit=1
#33468 [Com]: preg_match on long strings fails
ID: 33468
Comment by: bugs dot php dot net at chsc dot dk
Reported By: mjsherman at chartermi dot net
Status: Assigned
Bug Type: PCRE related
Operating System: *
PHP Version: 5CVS, 4CVS (2005-08-09)
Assigned To: andrei
New Comment:
An even simpler testcase:
$data = str_repeat('a', );
preg_match('/(?:[a])*/', $data, $reg);
Notice that the parenthesis is non-capturing, i.e. we don't even put a
lot of elements in the $reg array.
Previous Comments:
[2005-08-09 10:36:28] [EMAIL PROTECTED]
Happens also with the new PCRE 6.2 lib which was bundled in PHP CVS
today.
[2005-06-24 19:30:06] [EMAIL PROTECTED]
Andrei, could you check it plz.
As far as I understand, this is something not related to PHP, but just
another PCRE limitation.
[2005-06-24 19:21:22] mjsherman at chartermi dot net
Just tested with 5.1.0beta2
Same problem.
[2005-06-24 18:28:01] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-06-24 18:24:34] mjsherman at chartermi dot net
Description:
preg_match, if passed a long subject string, fails unexpectedly.
I have read through the PCRE limitations, and can't see that this is
one of them. I have tried increasing memory limit (to increase the
stack) with the same results.
Cutoff and examples are below:
Reproduce code:
---
$subject = str_repeat('a',100);
$subject .= str_repeat('b', 4370);
$subject .= str_repeat('a', 100);
if (preg_match('/(.*).*?\1/',$subject)) {
echo OK\n;
}
Expected result:
OK to be printed after matching 100 as.
If 4370 is changed to 4369, then OK is printed.
Actual result:
--
With 4370 'b's, nothing is printed (failed preg_match)
With 4369 'b's, OK is printed (worked).
--
Edit this bug report at http://bugs.php.net/?id=33468edit=1
#31349 [NEW]: Segmentation fault in mysql_query()
From: bugs dot php dot net at chsc dot dk Operating system: Linux PHP version: 5.0.3 PHP Bug Type: MySQL related Bug description: Segmentation fault in mysql_query() Description: I have a rather complex script that dumps core every time mysql_query() is called for the 7th time (through PEAR's DB_mysql). The script uses Smarty, PEAR_DB and a bunch of other classes. I have not been able to make a simple testcase. Doing the seven SQL queries alone without Smarty and all the other code does not trigger this bug. I hope that a stack trace will point in the right direction though. The problem occurs with two different MySQL versions: mysql Ver 12.22 Distrib 4.0.20, for pc-linux (i686) mysql Ver 14.7 Distrib 4.1.8, for pc-linux (i686) The problem can be reproduced on two different machines. I am using PHP 5.0.3. The problem wasn't there with PHP 5.0.2. PHP was configured like this: './configure' '--with-mysql=/usr/local/mysql' '--with-apache=../apache' '--enable-track-vars' '--with-gettext' '--with-dom' '--with-mcrypt' '--with-gd' '--with-jpeg-dir' '--with-png-dir' '--with-zlib-dir' '--with-freetype-dir' '--with-pear' '--enable-mbstring' '--with-iconv' '--disable-debug' '--enable-soap' This is a stacktrace of the failure: # gdb /usr/local/apache/bin/httpd GNU gdb 2002-04-01-cvs Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-linux...(no debugging symbols found)... (gdb) run -X Starting program: /usr/local/apache/bin/httpd -X (no debugging symbols found)...[New Thread 1024 (LWP 31535)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 31535)] 0x403d61b7 in memcpy () from /lib/libc.so.6 (gdb) bt #0 0x403d61b7 in memcpy () from /lib/libc.so.6 #1 0x0829a104 in cli_read_rows () #2 0x0829b942 in mysql_close () #3 0x0829ba50 in mysql_real_query () #4 0x0817446e in zif_mysql_client_encoding () #5 0x0817460c in zif_mysql_client_encoding () #6 0x08174630 in zif_mysql_query () #7 0x08113a5a in zend_do_fcall_common_helper () #8 0x08114091 in zend_do_fcall_handler () #9 0x080fc375 in execute () #10 0x08113b42 in zend_do_fcall_common_helper () #11 0x08113e99 in zend_do_fcall_by_name_handler () #12 0x080fc375 in execute () #13 0x08113b42 in zend_do_fcall_common_helper () #14 0x08113e99 in zend_do_fcall_by_name_handler () #15 0x080fc375 in execute () #16 0x08113b42 in zend_do_fcall_common_helper () #17 0x08113e99 in zend_do_fcall_by_name_handler () #18 0x080fc375 in execute () #19 0x08113b42 in zend_do_fcall_common_helper () #20 0x08113e99 in zend_do_fcall_by_name_handler () #21 0x080fc375 in execute () #22 0x08113b42 in zend_do_fcall_common_helper () ---Type return to continue, or q return to quit--- #23 0x08113e99 in zend_do_fcall_by_name_handler () #24 0x080fc375 in execute () #25 0x08113b42 in zend_do_fcall_common_helper () #26 0x08113e99 in zend_do_fcall_by_name_handler () #27 0x080fc375 in execute () #28 0x08113b42 in zend_do_fcall_common_helper () #29 0x08113e99 in zend_do_fcall_by_name_handler () #30 0x080fc375 in execute () #31 0x08113b42 in zend_do_fcall_common_helper () #32 0x08113e99 in zend_do_fcall_by_name_handler () #33 0x080fc375 in execute () #34 0x08113b42 in zend_do_fcall_common_helper () #35 0x08113e99 in zend_do_fcall_by_name_handler () #36 0x080fc375 in execute () #37 0x08118cd6 in zend_include_or_eval_handler () #38 0x080fc375 in execute () #39 0x08113b42 in zend_do_fcall_common_helper () #40 0x08113e99 in zend_do_fcall_by_name_handler () #41 0x080fc375 in execute () #42 0x08118cd6 in zend_include_or_eval_handler () #43 0x080fc375 in execute () #44 0x08113b42 in zend_do_fcall_common_helper () #45 0x08113e99 in zend_do_fcall_by_name_handler () ---Type return to continue, or q return to quit--- #46 0x080fc375 in execute () #47 0x08113b42 in zend_do_fcall_common_helper () #48 0x08113e99 in zend_do_fcall_by_name_handler () #49 0x080fc375 in execute () #50 0x08113b42 in zend_do_fcall_common_helper () #51 0x08113e99 in zend_do_fcall_by_name_handler () #52 0x080fc375 in execute () #53 0x08113b42 in zend_do_fcall_common_helper () #54 0x08113e99 in zend_do_fcall_by_name_handler () #55 0x080fc375 in execute () #56 0x080e1a68 in zend_execute_scripts () #57 0x080b98da in php_execute_script () #58 0x0811b712 in apache_php_module_main () #59 0x080b22f2 in ssl_expr_yyinput () #60 0x080b2341 in ssl_expr_yyinput () #61 0x0825b364 in ap_invoke_handler () #62 0x0826b74c in ap_some_auth_required () #63 0x0826ba50 in ap_internal_redirect () #64 0x08096c6c in ap_get_server_built () #65 0x0825b364 in ap_invoke_handler () #66 0x0826b74c in ap_some_auth_required () #67 0x0826b7a8 in ap_process_request () #68 0x08264d57 in ap_child_terminate
#31349 [Opn]: Segmentation fault in mysql_query()
ID: 31349 User updated by: bugs dot php dot net at chsc dot dk Reported By: bugs dot php dot net at chsc dot dk Status: Open Bug Type: MySQL related Operating System: Linux PHP Version: 5.0.3 New Comment: I appears that if I change the queries slightly, e.g. add a /* comment */ to the end of the SQL string, or remove additional whitespace outsite strings, everything works as expected. It may be related to this bug: http://bugs.mysql.com/bug.php?id=5607 Previous Comments: [2004-12-30 11:56:20] bugs dot php dot net at chsc dot dk Description: I have a rather complex script that dumps core every time mysql_query() is called for the 7th time (through PEAR's DB_mysql). The script uses Smarty, PEAR_DB and a bunch of other classes. I have not been able to make a simple testcase. Doing the seven SQL queries alone without Smarty and all the other code does not trigger this bug. I hope that a stack trace will point in the right direction though. The problem occurs with two different MySQL versions: mysql Ver 12.22 Distrib 4.0.20, for pc-linux (i686) mysql Ver 14.7 Distrib 4.1.8, for pc-linux (i686) The problem can be reproduced on two different machines. I am using PHP 5.0.3. The problem wasn't there with PHP 5.0.2. PHP was configured like this: './configure' '--with-mysql=/usr/local/mysql' '--with-apache=../apache' '--enable-track-vars' '--with-gettext' '--with-dom' '--with-mcrypt' '--with-gd' '--with-jpeg-dir' '--with-png-dir' '--with-zlib-dir' '--with-freetype-dir' '--with-pear' '--enable-mbstring' '--with-iconv' '--disable-debug' '--enable-soap' This is a stacktrace of the failure: # gdb /usr/local/apache/bin/httpd GNU gdb 2002-04-01-cvs Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-linux...(no debugging symbols found)... (gdb) run -X Starting program: /usr/local/apache/bin/httpd -X (no debugging symbols found)...[New Thread 1024 (LWP 31535)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 31535)] 0x403d61b7 in memcpy () from /lib/libc.so.6 (gdb) bt #0 0x403d61b7 in memcpy () from /lib/libc.so.6 #1 0x0829a104 in cli_read_rows () #2 0x0829b942 in mysql_close () #3 0x0829ba50 in mysql_real_query () #4 0x0817446e in zif_mysql_client_encoding () #5 0x0817460c in zif_mysql_client_encoding () #6 0x08174630 in zif_mysql_query () #7 0x08113a5a in zend_do_fcall_common_helper () #8 0x08114091 in zend_do_fcall_handler () #9 0x080fc375 in execute () #10 0x08113b42 in zend_do_fcall_common_helper () #11 0x08113e99 in zend_do_fcall_by_name_handler () #12 0x080fc375 in execute () #13 0x08113b42 in zend_do_fcall_common_helper () #14 0x08113e99 in zend_do_fcall_by_name_handler () #15 0x080fc375 in execute () #16 0x08113b42 in zend_do_fcall_common_helper () #17 0x08113e99 in zend_do_fcall_by_name_handler () #18 0x080fc375 in execute () #19 0x08113b42 in zend_do_fcall_common_helper () #20 0x08113e99 in zend_do_fcall_by_name_handler () #21 0x080fc375 in execute () #22 0x08113b42 in zend_do_fcall_common_helper () ---Type return to continue, or q return to quit--- #23 0x08113e99 in zend_do_fcall_by_name_handler () #24 0x080fc375 in execute () #25 0x08113b42 in zend_do_fcall_common_helper () #26 0x08113e99 in zend_do_fcall_by_name_handler () #27 0x080fc375 in execute () #28 0x08113b42 in zend_do_fcall_common_helper () #29 0x08113e99 in zend_do_fcall_by_name_handler () #30 0x080fc375 in execute () #31 0x08113b42 in zend_do_fcall_common_helper () #32 0x08113e99 in zend_do_fcall_by_name_handler () #33 0x080fc375 in execute () #34 0x08113b42 in zend_do_fcall_common_helper () #35 0x08113e99 in zend_do_fcall_by_name_handler () #36 0x080fc375 in execute () #37 0x08118cd6 in zend_include_or_eval_handler () #38 0x080fc375 in execute () #39 0x08113b42 in zend_do_fcall_common_helper () #40 0x08113e99 in zend_do_fcall_by_name_handler () #41 0x080fc375 in execute () #42 0x08118cd6 in zend_include_or_eval_handler () #43 0x080fc375 in execute () #44 0x08113b42 in zend_do_fcall_common_helper () #45 0x08113e99 in zend_do_fcall_by_name_handler () ---Type return to continue, or q return to quit--- #46 0x080fc375 in execute () #47 0x08113b42 in zend_do_fcall_common_helper () #48 0x08113e99 in zend_do_fcall_by_name_handler () #49 0x080fc375 in execute () #50 0x08113b42 in zend_do_fcall_common_helper () #51 0x08113e99 in zend_do_fcall_by_name_handler () #52 0x080fc375 in execute () #53 0x08113b42 in zend_do_fcall_common_helper () #54 0x08113e99 in zend_do_fcall_by_name_handler () #55 0x080fc375 in execute () #56 0x080e1a68 in zend_execute_scripts () #57 0x080b98da
#29923 [Fbk-Opn]: Assignment operations inside class methods not working
ID: 29923
User updated by: bugs dot php dot net at chsc dot dk
Reported By: bugs dot php dot net at chsc dot dk
-Status: Feedback
+Status: Open
Bug Type: Zend Engine 2 problem
Operating System: Linux
PHP Version: 5.0.1
New Comment:
Sorry, it's not a bug in PHP but in the Zend Optimizer.
Changing zend_optimizer.optimization_level from 15 to 0 in php.ini
fixes the problem. We'll report this to Zend.
Previous Comments:
[2004-09-01 08:39:24] [EMAIL PROTECTED]
Extra note: this works fine for me.
[2004-09-01 08:39:09] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
[2004-08-31 19:24:44] bugs dot php dot net at chsc dot dk
Description:
When called from inside a class method, $this-foo += 2 does not
increment the variable.
$this-foo = $this-foo + 2 appears to work, though.
This looks related to bug 27798.
Reproduce code:
---
?php
class foo {
var $bar = 1;
function baz() {
$this-bar += 2;
var_dump($this-bar);
var_dump(get_object_vars($this));
}
}
$f = new foo();
$f-baz();
$f-bar += 4;
var_dump($f-bar);
?
Expected result:
int(3)
array(1) {
[bar]=
int(3)
}
int(7)
Actual result:
--
int(1)
array(2) {
[bar]=
int(1)
[0]=
int(2)
}
int(5)
--
Edit this bug report at http://bugs.php.net/?id=29923edit=1
#29923 [Opn-Bgs]: Assignment operations inside class methods not working
ID: 29923
User updated by: bugs dot php dot net at chsc dot dk
Reported By: bugs dot php dot net at chsc dot dk
-Status: Open
+Status: Bogus
Bug Type: Zend Engine 2 problem
Operating System: Linux
PHP Version: 5.0.1
New Comment:
Marking Bogus
Previous Comments:
[2004-09-01 09:29:18] bugs dot php dot net at chsc dot dk
Sorry, it's not a bug in PHP but in the Zend Optimizer.
Changing zend_optimizer.optimization_level from 15 to 0 in php.ini
fixes the problem. We'll report this to Zend.
[2004-09-01 08:39:24] [EMAIL PROTECTED]
Extra note: this works fine for me.
[2004-09-01 08:39:09] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
[2004-08-31 19:24:44] bugs dot php dot net at chsc dot dk
Description:
When called from inside a class method, $this-foo += 2 does not
increment the variable.
$this-foo = $this-foo + 2 appears to work, though.
This looks related to bug 27798.
Reproduce code:
---
?php
class foo {
var $bar = 1;
function baz() {
$this-bar += 2;
var_dump($this-bar);
var_dump(get_object_vars($this));
}
}
$f = new foo();
$f-baz();
$f-bar += 4;
var_dump($f-bar);
?
Expected result:
int(3)
array(1) {
[bar]=
int(3)
}
int(7)
Actual result:
--
int(1)
array(2) {
[bar]=
int(1)
[0]=
int(2)
}
int(5)
--
Edit this bug report at http://bugs.php.net/?id=29923edit=1
#29923 [NEW]: Assignment operations inside class methods not working
From: bugs dot php dot net at chsc dot dk
Operating system: Linux
PHP version: 5.0.1
PHP Bug Type: Zend Engine 2 problem
Bug description: Assignment operations inside class methods not working
Description:
When called from inside a class method, $this-foo += 2 does not increment
the variable.
$this-foo = $this-foo + 2 appears to work, though.
This looks related to bug 27798.
Reproduce code:
---
?php
class foo {
var $bar = 1;
function baz() {
$this-bar += 2;
var_dump($this-bar);
var_dump(get_object_vars($this));
}
}
$f = new foo();
$f-baz();
$f-bar += 4;
var_dump($f-bar);
?
Expected result:
int(3)
array(1) {
[bar]=
int(3)
}
int(7)
Actual result:
--
int(1)
array(2) {
[bar]=
int(1)
[0]=
int(2)
}
int(5)
--
Edit bug report at http://bugs.php.net/?id=29923edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29923r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=29923r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=29923r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=29923r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=29923r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29923r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29923r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29923r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=29923r=support
Expected behavior: http://bugs.php.net/fix.php?id=29923r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=29923r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=29923r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=29923r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29923r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=29923r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29923r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=29923r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29923r=float
#29049 [NEW]: usort() does not trigger an error when callback does not exist
From: bugs dot php dot net at chsc dot dk
Operating system: Linux
PHP version: 4.3.7
PHP Bug Type: Arrays related
Bug description: usort() does not trigger an error when callback does not exist
Description:
When the second argument to usort() is not a valid callback, no error is
triggered, and the return value is true.
This makes debugging tricky.
When invoked with an invalid callback, usort() for some reason rearranges
the values in the array anyway.
Reproduce code:
---
?php
error_reporting(E_ALL);
$array = array(1, 7, 3, 2);
var_dump(usort($array, 'not a function name'));
var_dump($array);
var_dump(usort($array, ));
var_dump($array);
var_dump(usort($array, array('foo', 'bar')));
var_dump($array);
?
Expected result:
The output should be three error messages, three times bool(false) and
three times the original array.
Actual result:
--
bool(true)
array(4) {
[0]=
int(2)
[1]=
int(3)
[2]=
int(7)
[3]=
int(1)
}
bool(true)
array(4) {
[0]=
int(1)
[1]=
int(7)
[2]=
int(3)
[3]=
int(2)
}
bool(true)
array(4) {
[0]=
int(2)
[1]=
int(3)
[2]=
int(7)
[3]=
int(1)
}
--
Edit bug report at http://bugs.php.net/?id=29049edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29049r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29049r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=29049r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=29049r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29049r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29049r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29049r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=29049r=support
Expected behavior: http://bugs.php.net/fix.php?id=29049r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=29049r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=29049r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=29049r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29049r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=29049r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29049r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=29049r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29049r=float
