#42038 [Opn->Fbk]: realpath does not resolve symbolic link
ID: 42038 Updated by: [EMAIL PROTECTED] Reported By: kraghuba at in dot ibm dot com -Status: Open +Status: Feedback Bug Type: Filesystem function related Operating System: MacOSX, FreeBSD PHP Version: 5CVS-2007-07-18 (snap) -Assigned To: +Assigned To: fb-req-jani New Comment: I'm guessing this should be fixed in PHP_5_3 and HEAD by the commit by Dmitry? Previous Comments: [2007-07-19 03:21:44] kraghuba at in dot ibm dot com The reference to testcase symlink_link_linkinfo_is_link_variation6.phpt is wrong. The write testcases to check are : ext/standard/tests/file/readlink_realpath_basic1.phpt ext/standard/tests/file/readlink_realpath_variation1.phpt ext/standard/tests/file/readlink_realpath_variation2.phpt The similar failure is also noticed on FreeBSD. (FreeBSD - FreeBSD lindsay.php.is 6.2-STABLE FreeBSD 6.2-STABLE #1: Thu Jun 28 22:12:54 CEST 2007 ) MACOSX details: Darwin - Darwin thought 8.10.1 Darwin Kernel Version 8.10.1: Wed May 23 16:33:00 PDT 2007; root:xnu-792.22.5~1/RELEASE_I386 i386 [2007-07-18 17:16:51] kraghuba at in dot ibm dot com Description: realpath() doesn't resolve symlink and returns the link file name when input path is a link path. As per the documentation at http://in.php.net/manual/en/function.realpath.php, The resulting path will have no symbolic link, '/./' or '/../' components. Applicable to php5.2.4 only on MacOS X. Please check testcase symlink_link_linkinfo_is_link_variation6.phpt. Reproduce code: --- Expected result: string(%d) "%s/file.tmp" Actual result: -- string(%d) "%s/link.tmp" -- Edit this bug report at http://bugs.php.net/?id=42038&edit=1
#45044 [Ctl->Fbk]: relative paths not resolved correctly
ID: 45044 Updated by: [EMAIL PROTECTED] Reported By: felipensp at gmail dot com -Status: Critical +Status: Feedback Bug Type: Scripting Engine problem Operating System: FreeBSD 6.3 PHP Version: 5.3CVS-2008-05-20 (CVS) -Assigned To: dmitry +Assigned To: fb-req-jani New Comment: Isn't this fixed now by Dmitry's commit..? Previous Comments: [2008-08-06 15:33:54] [EMAIL PROTECTED] Dmitry, could you take a look at this, plz? [2008-08-06 15:33:28] [EMAIL PROTECTED] I can verify this on OS X 10.4 with this reproducable script http://trash.chregu.tv/include-bug.php.txt [2008-07-24 19:27:21] [EMAIL PROTECTED] virtual_file_ex() assume that if realpath() does not return NULL the file exists. The problem is that FreeBSD's realpath() will not return NULL if all components *but the last* exist. So php_resolve_path()/tsrm_realpath() will pass /usr/home/felipe/foo.php to virtual_file_ex() and assume it exists. [2008-05-30 20:19:00] [EMAIL PROTECTED] status->verified [2008-05-20 02:44:43] [EMAIL PROTECTED] [EMAIL PROTECTED]:/home$ cd felipe [EMAIL PROTECTED]:/home/felipe$ mkdir test [EMAIL PROTECTED]:/home/felipe$ cd test [EMAIL PROTECTED]:/home/felipe/test$ echo "" >> test.php [EMAIL PROTECTED]:/home/felipe/test$ echo "foobar" >> foo.php [EMAIL PROTECTED]:/home/felipe/test$ cd .. [EMAIL PROTECTED]:/home/felipe$ ../cellog/workspace/php5/sapi/cli/php test/test.php foobar I am on linux. I suspect zend_resolve_path is broken on FreeBSD and this is part of the segfault you described in phar on IRC. Can we find another FreeBSDer to confirm this? 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/45044 -- Edit this bug report at http://bugs.php.net/?id=45044&edit=1
#44271 [Opn->Fbk]: open_basedir resolves links on link-specific operations
ID: 44271 Updated by: [EMAIL PROTECTED] Reported By: tautolog at gmail dot com -Status: Open +Status: Feedback Bug Type: Safe Mode/open_basedir Operating System: DragonFly BSD PHP Version: 5.2.5 -Assigned To: +Assigned To: fb-req-jani New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz There are some fixes done in PHP_5_3 which most likely fix this problem. Note: Those fixes will NOT be backported to 5.2 branch! Previous Comments: [2008-02-27 20:17:16] tautolog at gmail dot com Description: This is not a security issue. It is just a functionality issue. open_basedir resolves links on link-specific operations, getting in the way of expected behavior. I don't think that the ability to read a link target (the target itself, not the file the target resolves to) within the basedir is a security concern because it is no different than the ability to read a config file which refers to a file outside of the basedir. In my thinking about this issue, I am viewing a symbolic link as just an alternate way to associate data with a file that just happens to have common support for treating the data as a target. See my reproduce code. Clearly, "/tmp/testlink" is in the allowed path of "home/ben/public_html:/tmp", but since it resolves to "/test", it is not being allowed. The following system calls (and therefore PHP functions) do not follow symlinks, according to symlink(7) on my BSD system: lchown() lstat() readlink() rename() rmdir() unlink() remove() (just an alias to unlink which is not in PHP) I tested all of them. All of them have this issue. rmdir() is an odd one. According to the manual, if you use it on a symbolic link, it should return ENOTDIR. $ mkdir /tmp/link_target $ ln -s /tmp/link_target /tmp/testlink $ rmdir /tmp/testlink rmdir: /tmp/testlink: Not a directory I have been using symbolic links to back a fast, simple, global, atomic, persistent hash, where the link filename is the key and the link value is the value. I have been running the application with open_basedir set to try to find compatibility problems with it, and found this issue. To work around it, I prefix all values with "./" now. However, there are other cases that cannot be worked around. For example, a php file manager would not even be able to tell whether the file were a link, let alone read its value or delete it. I have some interest in working on a patch. If you agree that it is desirable for open_basedir to not resolve links in some cases, I may be able to provide a patch. Just in case, I also tested the case where a link is outside open_basedir, but it resolves within open_basedir, and it blocked that, which I agree should be the expected behavior. Reproduce code: --- Add /tmp to open_basedir $ ln -s /test /tmp/testlink Expected result: 1 Actual result: -- Warning: is_link(): open_basedir restriction in effect. File(/tmp/testlink) is not within the allowed path(s): (/home/ben/public_html:/tmp) in /home/ben/public_html/cvs/app-modernbill-admin/include/lib-action/migrate/- on line 1 -- Edit this bug report at http://bugs.php.net/?id=44271&edit=1
#44608 [Opn->Fbk]: Use of rmdir() and relative directory scope / open_basedir restriction
ID: 44608 Updated by: [EMAIL PROTECTED] Reported By: adrian dot stannard at icps2007 dot org -Status: Open +Status: Feedback Bug Type: Safe Mode/open_basedir Operating System: FreeBSD PHP Version: 5.2.5 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz There are some fixes done in PHP_5_3 which most likely fix this problem. Note: Those fixes will NOT be backported to 5.2 branch! Previous Comments: [2008-04-02 12:15:00] adrian dot stannard at icps2007 dot org Description: Use of rmdir() and relative directory scope / open_basedir restriction. I cannot find mention of this anywhere, but the following is observed if you are on a server with open_basedir restriction and you use relative links in your script, for e.g. you define a root directory as $root='./'; If you use rmdir($dir), where $dir is some dir relative to your $root, rmdir removes this directory successfully, but later if you perform another file calling function dependent relative to $root - for example if you do a file include you get the following error: open_basedir restriction in effect File(./includes/page_header.php) is not within the allowed path(s): /home/[account_name]:/usr/lib/php:/usr/local/lib/php:/tmp the $root variable itself is unchanged (I've checked this), but its scope changes. So far I've only seen this happen immediately after using rmdir. The only way around this seems to be to drop relative assignments and redefine the root as something like: $root=$_SERVER['DOCUMENT_ROOT']. dirname($_SERVER["PHP_SELF"]).'/'; **Note on server configuration: SAFE MODE is off, but open_basedir restriction has been set ** Reproduce code: --- $selected_dir='some_user_created_directory'; rmdir($root.$selected_dir); include($root.'some_file.php'); Expected result: $selected_dir is deleted. Would then expect to see some_file.php included. Actual result: -- open_basedir restriction in effect File(./includes/page_header.php) is not within the allowed path(s): /home/[account_name]:/usr/lib/php:/usr/local/lib/php:/tmp -- Edit this bug report at http://bugs.php.net/?id=44608&edit=1
#45049 [Opn->Fbk]: spawn-fcgi sometimes cannot resolve symlinks
ID: 45049
Updated by: [EMAIL PROTECTED]
Reported By: szoftos at freemail dot hu
-Status: Open
+Status: Feedback
Bug Type: CGI related
Operating System: FreeBSD
PHP Version: 5.2.6
-Assigned To:
+Assigned To: fb-req-jani
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
There are some fixes done in PHP_5_3 which most likely fix this
problem. Note: Those fixes will NOT be backported to 5.2 branch!
Previous Comments:
[2008-05-22 14:10:54] szoftos at freemail dot hu
Hello,
original configuration snippet follows:
$HTTP["host"] =~ "^crxforum\.flix\.hu$|^crxforum\.localhost$" {
server.document-root =
"/var/www/crxforum.flix.hu/crxforum.flix.hu"
fastcgi.server= ( ".php" =>
((
"socket" => "/tmp/crxforum.flix.hu.php.sock",
"broken-scriptfilename" => "enable",
))
)
accesslog.filename =
"/var/log/lighttpd/crxforum.flix.hu-access.log"
server.errorlog = "/var/log/lighttpd/crxforum.flix.hu-error.log"
server.error-handler-404 = "/404.php"
$HTTP["url"] =~ "^(/images/|/skins/|/js/)" {
expire.url = ( "" => "access 1 years" )
}
}
[2008-05-22 08:42:34] [EMAIL PROTECTED]
Please provide the actual fastcgi.server part of your lighttpd.conf.
Also, how did you compile/configure PHP itself? (OTOH, *bsd has lot of
problems dealing with symlinks, just search this bug db..:)
[2008-05-20 09:37:40] szoftos at freemail dot hu
Description:
Hello,
recently i changed my operating system from linux to freebsd, which has
its default documentroot in /usr/local/www, and linux had it in
/var/www. i moved my files to /usr/local/www, but i made a symlink into
/var:
'cd /var'
'ln -s ../usr/local/www www'
lighttpd has its old configs, locating files in /var/www, but this
shouldn't be a problem with the symlink.
php got its settings locating files in /usr/local/www, and i got
sometimes a mystical response from the fcgi-php: 'No input file
specified.'
i lowered the spawned processes to 2 (sadly i couldn't lower it to 1),
and traced one of the two processes. one of them was the faulty, and i
had luck: i have seen that lighttpd passed /var/www (normally) to
php-fcgi, and somehow php-fcgi couldn't really resolve the symlink.
the problem solved when i changed /var/www to /usr/local/www in
lighty's configuration.
this looks like a problem to me, and it is not unique. i had this
situation with one of my other virtualhosts too. the spawned processes
are resolving that symlink good in most of the time, but then one
process stops resolving it right, and produces the message, as i have
written.
this should be a problem.
i have gone to lighttpd developers, and they told me its a php problem.
the original bugreport is here:
http://trac.lighttpd.net/trac/ticket/1668
Reproduce code:
---
You can reproduce if you use the same settings as i mentioned above.
--
Edit this bug report at http://bugs.php.net/?id=45049&edit=1
#43817 [Asn->Csd]: opendir() fails on Windows directories with parent directory unaccessible
ID: 43817
Updated by: [EMAIL PROTECTED]
Reported By: losd at mail dot dk
-Status: Assigned
+Status: Closed
Bug Type: Directory function related
Operating System: Windows Server 2003
PHP Version: 5.2.5
Assigned To: dmitry
New Comment:
Fixed in CVS HEAD and PHP_5_3.
Previous Comments:
[2008-03-01 09:09:15] losd at mail dot dk
Doh, sorry, thought I could edit the original text. Just delete that
comment.
But yes, as Daniel correctly points out, it's all Windows permission
handling (As my reproduce code also shows), not just related to network
shares... I experienced it in one at first, I guess that's why it stuck
in my brain.
[2008-03-01 09:02:02] losd at mail dot dk
Description:
If the parent directory of a Windows directory is not accessible,
you are still able to access subdirectories if given explicit
permission.
However, PHP has trouble with the first accessible directory below an
inaccessible directory. This is not a problem for the accessible dir's
subdirs, though.
Scenario:
C:/Test/NoAccess/ -- Not accessible
Access/-- Accesible from here
yyy.txt
Subdir/
xxx.txt
The problem has been found with opendir(), is_dir() and is_readable().
All directory functions are probably affected.
No workarounds has been found so far (suggestions appreciated).
Reproduce code:
---
";
while (false !== ($file = readdir($handle)))
echo"File: $file";
closedir($handle);
} else {
echo "H, can't open directory, is it accessible?";
}
echo "";
if ($handle = opendir("C:/Test/NoAccess/Access")) {
echo "Opened directory C:/Test/NoAccess/Access";
while (false !== ($file = readdir($handle)))
echo"File: $file";
closedir($handle);
} else {
echo "H, can't open directory, is it accessible?";
}
?>
Expected result:
Opened dir C:/Test/NoAccess/Access/Subdir
File: .
File: ..
File: xxx.txt
Opened dir C:/Test/NoAccess/Access
File: .
File: ..
File: yyy.txt
File: Subdir
Actual result:
--
Opened dir C:/Test/NoAccess/Access/Subdir
File: .
File: ..
File: xxx.txt
Warning: opendir(C:/Test/NoAccess/Access) [function.opendir]: failed to
open dir: No such file or directory in
C:\Inetpub\wwwroot\pm2\opendir.php on line 13
H, can't open directory, is it accessible?
[2008-03-01 01:10:46] [EMAIL PROTECTED]
I am experiencing this issue as well, but on local directories, not
network shares. My OS is Windows XP Pro. The opendir() functionality
works correctly in release 5.2.1. The functionality is broken in
releases 5.2.2 through 5.2.5, plus the 526-php5.2-win32-200802292130 and
php5.3-win32-200802201330 snapshots.
[2008-01-11 13:36:50] losd at mail dot dk
Temporary workaround found, but only if there is a known subdirectory
inside the top accessible directory:
opendir("C:/Test/NoAccess/Access/Subdir/..");
[2008-01-11 12:23:54] losd at mail dot dk
Description:
If the parent directory of a Windows network share is not accessible,
you are still able to access subdirectories if given explicit
permission.
However, PHP has trouble with the first accessible directory below an
inaccessible directory. This is not a problem for the accessible dir's
subdirs, though.
Scenario:
C:/Test/NoAccess/ -- Not accessible
Access/-- Accesible from here
yyy.txt
Subdir/
xxx.txt
The problem has been found with opendir(), is_dir() and is_readable().
All directory functions are probably affected.
No workarounds has been found so far (suggestions appreciated).
Reproduce code:
---
";
while (false !== ($file = readdir($handle)))
echo"File: $file";
closedir($handle);
} else {
echo "H, can't open directory, is it accessible?";
}
echo "";
if ($handle = opendir("C:/Test/NoAccess/Access")) {
echo "Opened directory C:/Test/NoAccess/Access";
while (false !== ($file = readdir($handle)))
echo"File: $file";
closedir($handle);
} else {
echo "H, can't open directory, is it accessible?";
}
?>
Expected result:
Opened dir C:/Test/NoAccess/Access/Subdir
File: .
File: ..
File: xxx.txt
Opened dir C:/Test/NoAccess/Access
File: .
File: ..
File: yyy.txt
File: Subdir
Actual result:
--
Opened dir C:/Test/NoAccess/Access/Subdir
File: .
File: ..
File: xxx.txt
Warning: opendir(C:/Test/NoAccess/Access) [function.opendir]: failed to
open dir: No
#45044 [Fbk->Csd]: relative paths not resolved correctly
ID: 45044 Updated by: [EMAIL PROTECTED] Reported By: felipensp at gmail dot com -Status: Feedback +Status: Closed Bug Type: Scripting Engine problem Operating System: FreeBSD 6.3 PHP Version: 5.3CVS-2008-05-20 (CVS) -Assigned To: fb-req-jani +Assigned To: dmitry New Comment: Fixed in CVS HEAD and PHP_5_3. Previous Comments: [2008-08-12 08:55:49] [EMAIL PROTECTED] Isn't this fixed now by Dmitry's commit..? [2008-08-06 15:33:54] [EMAIL PROTECTED] Dmitry, could you take a look at this, plz? [2008-08-06 15:33:28] [EMAIL PROTECTED] I can verify this on OS X 10.4 with this reproducable script http://trash.chregu.tv/include-bug.php.txt [2008-07-24 19:27:21] [EMAIL PROTECTED] virtual_file_ex() assume that if realpath() does not return NULL the file exists. The problem is that FreeBSD's realpath() will not return NULL if all components *but the last* exist. So php_resolve_path()/tsrm_realpath() will pass /usr/home/felipe/foo.php to virtual_file_ex() and assume it exists. [2008-05-30 20:19:00] [EMAIL PROTECTED] status->verified 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/45044 -- Edit this bug report at http://bugs.php.net/?id=45044&edit=1
#45797 [NEW]: PDO closes connection too early when combined with pcntl_fork()
From: jketterl at chipxonio dot de
Operating system: linux (debian)
PHP version: 5.2.6
PHP Bug Type: MySQL related
Bug description: PDO closes connection too early when combined with
pcntl_fork()
Description:
When forking a php skript using pcntl_fork, the PDO connections to a MySQL
server are lost as soon as one of the processes exits (parent or child,
which ever exits first) and the remaining process can't continue to execute
queries (or, even worse, is interrupted during an active query).
the code to reproduce is a CLI script as the application i'm working on is
one too. you will need to replace username & password. also, I had to
change the file extension in order to make it downloadable.
Reproduce code:
---
http://www.djmacgyver.net/files/test2.php.txt
Expected result:
before fork
records returned: 1
child
records returned: 1
parent
records returned: 1
after fork
records returned: 1
end
Actual result:
--
before fork
records returned: 1
child
records returned: 1
parent
records returned: 1
after fork
SQLSTATE[HY000]: General error: 2006 MySQL server has gone away
#0 /home/jketterl/public_html/me/application/import/test2.php(5):
PDO->query('select * from p...')
#1 /home/jketterl/public_html/me/application/import/test2.php(41):
doQuery(Object(PDO))
#2 {main}
end
--
Edit bug report at http://bugs.php.net/?id=45797&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45797&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45797&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45797&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45797&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45797&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45797&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45797&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45797&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45797&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45797&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45797&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45797&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45797&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45797&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45797&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45797&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45797&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45797&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45797&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45797&r=mysqlcfg
#45798 [NEW]: sqlite3 doesn't notice if variable was bound
From: [EMAIL PROTECTED]
Operating system: OSX
PHP version: 5.3.0alpha1
PHP Bug Type: SQLite related
Bug description: sqlite3 doesn't notice if variable was bound
Description:
If a prepared statement is executed while the bound variable doesn't
exist, or is NULL, PHP freeze and wait.
I tweaked the test also to use SQLITE3_NULL instead of SQLITE3_TEXT, and
NULL or !isset($foo) also froze PHP.
Reproduce code:
---
exec('CREATE TABLE test (time INTEGER, id STRING)');
$db->exec("INSERT INTO test (time, id) VALUES (" . time() . ", 'a')");
$db->exec("INSERT INTO test (time, id) VALUES (" . time() . ", 'b')");
$stmt = $db->prepare("SELECT * FROM test WHERE id = ? ORDER BY id ASC");
//$foo = 'a'; works OK
//$foo = NULL; also freeze
$stmt->bindParam(1, $foo, SQLITE3_TEXT);
$results = $stmt->execute();
while ($result = $results->fetchArray(SQLITE3_NUM))
{
var_dump($result);
}
$results->finalize();
$db->close();
?>
Expected result:
I would expect PHP to return from execute with an error.
Actual result:
--
PHP freeze, doing nothing.
--
Edit bug report at http://bugs.php.net/?id=45798&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45798&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45798&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45798&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45798&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45798&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45798&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45798&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45798&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45798&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45798&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45798&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45798&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45798&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45798&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45798&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45798&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45798&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45798&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45798&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45798&r=mysqlcfg
#45613 [NoF->Asn]: Segfault when using is_file() on Apache-2.2.8
ID: 45613 Updated by: [EMAIL PROTECTED] Reported By: crocodile2u at yandex dot ru -Status: No Feedback +Status: Assigned Bug Type: Apache2 related Operating System: Ununtu 8.04 PHP Version: 5.3CVS-2008-07-24 (CVS) -Assigned To: +Assigned To: tony2001 Previous Comments: [2008-08-05 11:15:54] crocodile2u at yandex dot ru The problem is still here with PHP-5.3.0alpha [2008-08-01 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". [2008-07-28 08:58:51] crocodile2u at yandex dot ru I've just installed the latest snapshot of PHP-5.3 and the problem persists. The dump: #0 0x in ?? () #1 0xb71feef8 in phar_is_file (ht=1, return_value=0x83db0b8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0, tsrm_ls=0x83c5a70) at /home/vbolshov/src/php/php5.3-200807280630/ext/phar/func_interceptors.c:956 #2 0xb73f3828 in zend_do_fcall_common_helper_SPEC (execute_data=0x84a0a70, tsrm_ls=0x83c5a70) at /home/vbolshov/src/php/php5.3-200807280630/Zend/zend_vm_execute.h:313 #3 0xb73e00b5 in execute (op_array=0x83dac2c, tsrm_ls=0x83c5a70) at /home/vbolshov/src/php/php5.3-200807280630/Zend/zend_vm_execute.h:104 #4 0xb73bad2f in zend_execute_scripts (type=8, tsrm_ls=0x83c5a70, retval=0x0, file_count=3) at /home/vbolshov/src/php/php5.3-200807280630/Zend/zend.c:1199 #5 0xb73617d5 in php_execute_script (primary_file=0xb44c41f0, tsrm_ls=0x83c5a70) at /home/vbolshov/src/php/php5.3-200807280630/main/main.c:2088 #6 0xb744fa48 in php_handler (r=0x83cac20) at /home/vbolshov/src/php/php5.3-200807280630/sapi/apache2handler/sapi_apache2.c:630 #7 0x08079639 in ap_run_handler () #8 0x0807ca47 in ap_invoke_handler () #9 0x08089d60 in ap_process_request () #10 0x0808706b in ?? () #11 0x083cac20 in ?? () #12 0x0004 in ?? () #13 0x083cac20 in ?? () #14 0x in ?? () Source code for the script was: http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. 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/45613 -- Edit this bug report at http://bugs.php.net/?id=45613&edit=1
#45799 [NEW]: imagepng() crashes on empty image
From: amelek32 at gmail dot com Operating system: Windows XP Pro x64 PHP version: 5.2.6 PHP Bug Type: GD related Bug description: imagepng() crashes on empty image Description: imagepng *crashes* when no color was alocated. I see no point in rendering blank images, but this functions behavior is buggy. All other functions (imagejpeg, imagegif) AND imagepng on true scale images return black image. This is most likely expected result. Instead, this function flushes some part of header and then crashes with warnings when trying to convert non existing color palette. GD Version bundled (2.0.34 compatible) Reproduce code: --- Expected result: blank black image (like other image* functions) or E_WARNING without junk. Actual result: -- PNG IHDRôôñMÉ Warning: imagepng() [function.imagepng]: gd-png: fatal libpng error: Invalid number of colors in palette in C:\usr\apache\httpd\html\draw.php on line 21 Warning: imagepng() [function.imagepng]: gd-png error: setjmp returns error condition in C:\usr\apache\httpd\html\draw.php on line 21 -- Edit bug report at http://bugs.php.net/?id=45799&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45799&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45799&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45799&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45799&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45799&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45799&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45799&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45799&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45799&r=support Expected behavior:http://bugs.php.net/fix.php?id=45799&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45799&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45799&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45799&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45799&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45799&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45799&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45799&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45799&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45799&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45799&r=mysqlcfg
#45797 [Opn->Bgs]: PDO closes connection too early when combined with pcntl_fork()
ID: 45797
Updated by: [EMAIL PROTECTED]
Reported By: jketterl at chipxonio dot de
-Status: Open
+Status: Bogus
Bug Type: MySQL related
Operating System: linux (debian)
PHP Version: 5.2.6
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
That's due to the architecture of PHP, you should use different
connections in different processes else you get all different kinds of
random results, and connecting to a MySQL daemon is a quite cheap
operation.
Previous Comments:
[2008-08-12 11:46:21] jketterl at chipxonio dot de
Description:
When forking a php skript using pcntl_fork, the PDO connections to a
MySQL server are lost as soon as one of the processes exits (parent or
child, which ever exits first) and the remaining process can't continue
to execute queries (or, even worse, is interrupted during an active
query).
the code to reproduce is a CLI script as the application i'm working on
is one too. you will need to replace username & password. also, I had to
change the file extension in order to make it downloadable.
Reproduce code:
---
http://www.djmacgyver.net/files/test2.php.txt
Expected result:
before fork
records returned: 1
child
records returned: 1
parent
records returned: 1
after fork
records returned: 1
end
Actual result:
--
before fork
records returned: 1
child
records returned: 1
parent
records returned: 1
after fork
SQLSTATE[HY000]: General error: 2006 MySQL server has gone away
#0 /home/jketterl/public_html/me/application/import/test2.php(5):
PDO->query('select * from p...')
#1 /home/jketterl/public_html/me/application/import/test2.php(41):
doQuery(Object(PDO))
#2 {main}
end
--
Edit this bug report at http://bugs.php.net/?id=45797&edit=1
#45798 [Opn->Asn]: sqlite3 doesn't notice if variable was bound
ID: 45798
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Assigned
Bug Type: SQLite related
Operating System: OSX
PHP Version: 5.3.0alpha1
-Assigned To:
+Assigned To: scottmac
New Comment:
Assign to maintainer
Previous Comments:
[2008-08-12 13:11:17] [EMAIL PROTECTED]
Description:
If a prepared statement is executed while the bound variable doesn't
exist, or is NULL, PHP freeze and wait.
I tweaked the test also to use SQLITE3_NULL instead of SQLITE3_TEXT,
and
NULL or !isset($foo) also froze PHP.
Reproduce code:
---
exec('CREATE TABLE test (time INTEGER, id STRING)');
$db->exec("INSERT INTO test (time, id) VALUES (" . time() . ", 'a')");
$db->exec("INSERT INTO test (time, id) VALUES (" . time() . ", 'b')");
$stmt = $db->prepare("SELECT * FROM test WHERE id = ? ORDER BY id
ASC");
//$foo = 'a'; works OK
//$foo = NULL; also freeze
$stmt->bindParam(1, $foo, SQLITE3_TEXT);
$results = $stmt->execute();
while ($result = $results->fetchArray(SQLITE3_NUM))
{
var_dump($result);
}
$results->finalize();
$db->close();
?>
Expected result:
I would expect PHP to return from execute with an error.
Actual result:
--
PHP freeze, doing nothing.
--
Edit this bug report at http://bugs.php.net/?id=45798&edit=1
#45794 [Opn->Bgs]: HTTP headers rendered differently in PHP than Apache rewrite mod likes them
ID: 45794 Updated by: [EMAIL PROTECTED] Reported By: tarag956 at gmail dot com -Status: Open +Status: Bogus Bug Type: *Web Server problem Operating System: nix PHP Version: 5.2.6 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 HTTP headers and other variables follows the CGI specification: http://hoohoo.ncsa.uiuc.edu/cgi/env.html Previous Comments: [2008-08-12 06:08:40] tarag956 at gmail dot com Description: HTTP headers rendered differently in PHP than Apache rewrite mod likes them For instance... PHP renders a header this way (from the $_SERVER associated array): HTTP_X_MOZ But apache rewrite mod likes it: HTTP:X-MOZ I couldn't find any previous reports on this. But basically, PHP needs some way for its HTTP headers to end up looking the same way that Apache's mod-rewrite likes them. Other examples... Apache likes them like: HTTP:X-FORWARDED-FOR REMOTE_ADDR HTTP:CLIENT-IP REQUEST_METHOD But PHP usually converts all "-" to "_" and converts all ":" to "_" and sometimes adds "HTTP_" in front of things. Maybe this is a feature request, but it would be nice if PHP's HTTP header variables could go be the exact names that HTTP's rewrite mod like them as. Reproduce code: --- .. Expected result: .. Actual result: -- .. -- Edit this bug report at http://bugs.php.net/?id=45794&edit=1
#45798 [Asn->Csd]: sqlite3 doesn't notice if variable was bound
ID: 45798
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Assigned
+Status: Closed
Bug Type: SQLite related
Operating System: OSX
PHP Version: 5.3.0alpha1
Assigned To: scottmac
New Comment:
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.
I'm not the maintainer, but as it's a simple fix, I commited it, ok
Scott? :)
Previous Comments:
[2008-08-12 13:31:33] [EMAIL PROTECTED]
Assign to maintainer
[2008-08-12 13:11:17] [EMAIL PROTECTED]
Description:
If a prepared statement is executed while the bound variable doesn't
exist, or is NULL, PHP freeze and wait.
I tweaked the test also to use SQLITE3_NULL instead of SQLITE3_TEXT,
and
NULL or !isset($foo) also froze PHP.
Reproduce code:
---
exec('CREATE TABLE test (time INTEGER, id STRING)');
$db->exec("INSERT INTO test (time, id) VALUES (" . time() . ", 'a')");
$db->exec("INSERT INTO test (time, id) VALUES (" . time() . ", 'b')");
$stmt = $db->prepare("SELECT * FROM test WHERE id = ? ORDER BY id
ASC");
//$foo = 'a'; works OK
//$foo = NULL; also freeze
$stmt->bindParam(1, $foo, SQLITE3_TEXT);
$results = $stmt->execute();
while ($result = $results->fetchArray(SQLITE3_NUM))
{
var_dump($result);
}
$results->finalize();
$db->close();
?>
Expected result:
I would expect PHP to return from execute with an error.
Actual result:
--
PHP freeze, doing nothing.
--
Edit this bug report at http://bugs.php.net/?id=45798&edit=1
#45799 [Opn->Bgs]: imagepng() crashes on empty image
ID: 45799 Updated by: [EMAIL PROTECTED] Reported By: amelek32 at gmail dot com -Status: Open +Status: Bogus Bug Type: GD related Operating System: Windows XP Pro x64 PHP Version: 5.2.6 New Comment: That's libpng behaviors. A PNG palette image must have colors to be saved. By the way, warnings are not crashes. Previous Comments: [2008-08-12 13:29:36] amelek32 at gmail dot com Description: imagepng *crashes* when no color was alocated. I see no point in rendering blank images, but this functions behavior is buggy. All other functions (imagejpeg, imagegif) AND imagepng on true scale images return black image. This is most likely expected result. Instead, this function flushes some part of header and then crashes with warnings when trying to convert non existing color palette. GD Version bundled (2.0.34 compatible) Reproduce code: --- Expected result: blank black image (like other image* functions) or E_WARNING without junk. Actual result: -- PNG IHDRôôñMÉ Warning: imagepng() [function.imagepng]: gd-png: fatal libpng error: Invalid number of colors in palette in C:\usr\apache\httpd\html\draw.php on line 21 Warning: imagepng() [function.imagepng]: gd-png error: setjmp returns error condition in C:\usr\apache\httpd\html\draw.php on line 21 -- Edit this bug report at http://bugs.php.net/?id=45799&edit=1
#45800 [NEW]: cannot compile PHP with http on osx
From: [EMAIL PROTECTED] Operating system: osx 10.4 PHP version: 5.3.0alpha1 PHP Bug Type: HTTP related Bug description: cannot compile PHP with http on osx Description: When compiling PHP with --enable-http, I get this error : In file included from /Users/macbook/bin/php5.3- 200808111430/ext/http/http.c:26: /Users/macbook/bin/php5.3-200808111430/ext/http/php_http_api.h: In function '_zval_copy': /Users/macbook/bin/php5.3-200808111430/ext/http/php_http_api.h:299: error: 'struct _zval_struct' has no member named 'refcount' /Users/macbook/bin/php5.3-200808111430/ext/http/php_http_api.h:300: error: 'struct _zval_struct' has no member named 'is_ref' make: *** [ext/http/http.lo] Error 1 Reproduce code: --- ./configure --enable-http & make Expected result: PHP compile correctly with the http extension. Actual result: -- Compilation fails. -- Edit bug report at http://bugs.php.net/?id=45800&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45800&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45800&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45800&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45800&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45800&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45800&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45800&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45800&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45800&r=support Expected behavior:http://bugs.php.net/fix.php?id=45800&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45800&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45800&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45800&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45800&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45800&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45800&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45800&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45800&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45800&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45800&r=mysqlcfg
#45799 [Bgs]: imagepng() crashes on empty image
ID: 45799 User updated by: amelek32 at gmail dot com Reported By: amelek32 at gmail dot com Status: Bogus Bug Type: GD related Operating System: Windows XP Pro x64 PHP Version: 5.2.6 New Comment: shouldn't it return warning without putting part of header to output? Previous Comments: [2008-08-12 13:37:02] [EMAIL PROTECTED] That's libpng behaviors. A PNG palette image must have colors to be saved. By the way, warnings are not crashes. [2008-08-12 13:29:36] amelek32 at gmail dot com Description: imagepng *crashes* when no color was alocated. I see no point in rendering blank images, but this functions behavior is buggy. All other functions (imagejpeg, imagegif) AND imagepng on true scale images return black image. This is most likely expected result. Instead, this function flushes some part of header and then crashes with warnings when trying to convert non existing color palette. GD Version bundled (2.0.34 compatible) Reproduce code: --- Expected result: blank black image (like other image* functions) or E_WARNING without junk. Actual result: -- PNG IHDRôôñMÉ Warning: imagepng() [function.imagepng]: gd-png: fatal libpng error: Invalid number of colors in palette in C:\usr\apache\httpd\html\draw.php on line 21 Warning: imagepng() [function.imagepng]: gd-png error: setjmp returns error condition in C:\usr\apache\httpd\html\draw.php on line 21 -- Edit this bug report at http://bugs.php.net/?id=45799&edit=1
#45800 [Opn->Bgs]: cannot compile PHP with http on osx
ID: 45800 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: HTTP related Operating System: osx 10.4 PHP Version: 5.3.0alpha1 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. You are trying to compile ext/http from PECL and you encountered a bug related to pecl-http and not to PHP itself. Please report a bug on http://pecl.php.net/bugs/ Previous Comments: [2008-08-12 13:43:23] [EMAIL PROTECTED] Description: When compiling PHP with --enable-http, I get this error : In file included from /Users/macbook/bin/php5.3- 200808111430/ext/http/http.c:26: /Users/macbook/bin/php5.3-200808111430/ext/http/php_http_api.h: In function '_zval_copy': /Users/macbook/bin/php5.3-200808111430/ext/http/php_http_api.h:299: error: 'struct _zval_struct' has no member named 'refcount' /Users/macbook/bin/php5.3-200808111430/ext/http/php_http_api.h:300: error: 'struct _zval_struct' has no member named 'is_ref' make: *** [ext/http/http.lo] Error 1 Reproduce code: --- ./configure --enable-http & make Expected result: PHP compile correctly with the http extension. Actual result: -- Compilation fails. -- Edit this bug report at http://bugs.php.net/?id=45800&edit=1
#45793 [Opn->Fbk]: conflicting types for `utf8_mime2text'
ID: 45793 Updated by: [EMAIL PROTECTED] Reported By: amiheev at st-host dot ru -Status: Open +Status: Feedback -Bug Type: Compile Failure +Bug Type: IMAP related Operating System: Linux glibc-2.3.3-27 gcc-3.3.3 PHP Version: 5.2.6 New Comment: 1. What is the exact c-client version you compile with? 2. Check your config.log for the relevant output for the check of utf8_mime2text() signature and paste here. Previous Comments: [2008-08-12 06:02:09] amiheev at st-host dot ru Description: This bug have been opened many times for a variety of php versions (up to 5.2.0), but most of them were closed due to no feedback. Hopefully, this report would be the final one. As in previous reports, the problem occurs while trying to build PHP over a newer c-client version with new utf8_mime2text signature. This is caused by undefined HAVE_NEW_MIME2TEXT. configure script detects new c-client correctly and comments out the '#undef HAVE_NEW_MIME2TEXT' line, but this is not enough. The following changes to main/php_config.h after running ./configure solve the problem: /* Whether utf8_mime2text() has new signature * -/* #undef HAVE_NEW_MIME2TEXT */ +#define HAVE_NEW_MIME2TEXT Reproduce code: --- ./configure --with-imap=/usr/local && make Expected result: Compile without errors. Actual result: -- Compilation fails with the following output /chr/src/php-5.2.6/ext/imap/php_imap.c:82: error: conflicting types for `utf8_mime2text' /usr/local/include/utf8aux.h:37: error: previous declaration of `utf8_mime2text' -- Edit this bug report at http://bugs.php.net/?id=45793&edit=1
#45788 [Opn->Bgs]: fgetcsv retuns NULL on warning instead of false
ID: 45788 Updated by: [EMAIL PROTECTED] Reported By: steven at realestatewebmasters dot com -Status: Open +Status: Bogus Bug Type: Filesystem function related Operating System: Linux PHP Version: 5.2.6 New Comment: Invalid parameter does not cause fatal error in any PHP function. And when an invalid parameter is passed, all functions using the new (more consistent) parameter parsing also return NULL. No bug here. Previous Comments: [2008-08-11 18:36:49] steven at realestatewebmasters dot com Description: fgetcsv returns null if passed false as the handle. This should cause and error instead of a warning and cause the function to return false. Reproduce code: --- Expected result: Warning: fopen(foo): failed to open stream: No such file or directory in /home/sbarre85/test.php on line 3 Warning: fgetcsv() expects parameter 1 to be resource, boolean given in /home/sbarre85/test.php on line 5 bool(false) Error: fgetcsv() expects parameter 1 to be resource, boolean given in /home/sbarre85/test.php on line 7 Actual result: -- Warning: fopen(foo): failed to open stream: No such file or directory in /home/sbarre85/test.php on line 3 Warning: fgetcsv() expects parameter 1 to be resource, boolean given in /home/sbarre85/test.php on line 5 NULL Warning: fgetcsv() expects parameter 1 to be resource, boolean given in /home/sbarre85/test.php on line 7 test .. looping infinitly -- Edit this bug report at http://bugs.php.net/?id=45788&edit=1
#45799 [Bgs->Asn]: imagepng() crashes on empty image
ID: 45799 Updated by: [EMAIL PROTECTED] Reported By: amelek32 at gmail dot com -Status: Bogus +Status: Assigned Bug Type: GD related Operating System: Windows XP Pro x64 PHP Version: 5.2.6 -Assigned To: +Assigned To: pajoye New Comment: > shouldn't it return warning without putting part of header to output? Hm, good point. I may add a check before calling the png function and avoid to much troubles later. I will do it for 5.3+ Previous Comments: [2008-08-12 13:45:49] amelek32 at gmail dot com shouldn't it return warning without putting part of header to output? [2008-08-12 13:37:02] [EMAIL PROTECTED] That's libpng behaviors. A PNG palette image must have colors to be saved. By the way, warnings are not crashes. [2008-08-12 13:29:36] amelek32 at gmail dot com Description: imagepng *crashes* when no color was alocated. I see no point in rendering blank images, but this functions behavior is buggy. All other functions (imagejpeg, imagegif) AND imagepng on true scale images return black image. This is most likely expected result. Instead, this function flushes some part of header and then crashes with warnings when trying to convert non existing color palette. GD Version bundled (2.0.34 compatible) Reproduce code: --- Expected result: blank black image (like other image* functions) or E_WARNING without junk. Actual result: -- PNG IHDRôôñMÉ Warning: imagepng() [function.imagepng]: gd-png: fatal libpng error: Invalid number of colors in palette in C:\usr\apache\httpd\html\draw.php on line 21 Warning: imagepng() [function.imagepng]: gd-png error: setjmp returns error condition in C:\usr\apache\httpd\html\draw.php on line 21 -- Edit this bug report at http://bugs.php.net/?id=45799&edit=1
#45786 [Opn->Fbk]: FastCGI process exited unexpectedly
ID: 45786 Updated by: [EMAIL PROTECTED] Reported By: karelevzen at gmail dot com -Status: Open +Status: Feedback Bug Type: IIS related Operating System: Windows Vista Ultimate x64 SP1 PHP Version: 5.3CVS-2008-08-10 (CVS) -Assigned To: +Assigned To: fb-req-jani New Comment: You're propably loading some shared extensions in your php.ini? Disable all of them and try again. Then enable them one by one to find out the error causing one. Then check that the extension in question isn't compiled in the PHP core binary. (php -m output!) Previous Comments: [2008-08-11 16:49:18] karelevzen at gmail dot com may be related to bug 45630 [2008-08-11 13:48:32] karelevzen at gmail dot com Description: When you run PHP as a FastCGI module under IIS 7.0 (Windows Vista Ultimate x64) you get an error "FastCGI process exited unexpectedly" every time you visit a PHP page. The page contents loads OK, but after a second or so you get this error (a GUI message). Until you receive the message, the browser seems to be loading something (this could mean that the request wasn't handled well). Also, I've noticed that I have Configuration File (php.ini) set to C:\Windows, while the file is correctly loaded from C:\bin32\php\php.ini Everything works OK with the 2.5.6 nts build. Reproduce code: --- Expected result: No error message. Actual result: -- Faulting module name: php-cgi.exe Exception code: c005 Exception offset: 5604 -- Edit this bug report at http://bugs.php.net/?id=45786&edit=1
#45779 [Opn->Asn]: regression with shebang lines processing
ID: 45779 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: Scripting Engine problem Operating System: Windows PHP Version: 5.3CVS-2008-08-10 -Assigned To: +Assigned To: dmitry New Comment: Dmitry, please check this out. Previous Comments: [2008-08-10 14:31:08] [EMAIL PROTECTED] Description: tests\lang\comments.php fails. There is a regression between 5.2.x and 5.3 on how the shebang line is processed. 5.2.x ignores only the first line, 5.3.x ignores the first two lines. Reproduce code: --- See tests\lang\comments.php -- Edit this bug report at http://bugs.php.net/?id=45779&edit=1
#45793 [Fbk->Opn]: conflicting types for `utf8_mime2text'
ID: 45793 User updated by: amiheev at st-host dot ru Reported By: amiheev at st-host dot ru -Status: Feedback +Status: Open Bug Type: IMAP related Operating System: Linux glibc-2.3.3-27 gcc-3.3.3 PHP Version: 5.2.6 Assigned To: fb-req-jani New Comment: 1. imap-2007b 2. Not too much: configure:46967: checking for IMAP support configure:47014: checking for IMAP Kerberos support configure:47040: checking for IMAP SSL support configure:47456: checking for utf8_mime2text signature configure:47503: checking for U8T_CANONICAL And a bit later: configure:49236: checking whether build with IMAP works configure:49274: gcc -o conftest -I/usr/local/include -g -O2 -L/usr/local/lib -Wl,-rpath,/usr/local/lib -L/usr/local/lib conftest.c -lc-client -lcrypt -lpam -liconv -lfreetype -lpng -lz -ljpeg -lcurl -lz -lresolv -lm -ldl -lnsl -lxml2 -lz -liconv -lm -lcurl -lxml2 -lz -liconv -lm 1>&5 /usr/local/lib/libc-client.a(osdep.o)(.text+0x8b0b): In function `ssl_onceonlyin it': /chr/src/imap/imap-2007b/c-client/osdep.c:353: warning: the use of `tmpnam' is dangerous, better use `mkstemp' Previous Comments: [2008-08-12 14:21:36] [EMAIL PROTECTED] 1. What is the exact c-client version you compile with? 2. Check your config.log for the relevant output for the check of utf8_mime2text() signature and paste here. [2008-08-12 06:02:09] amiheev at st-host dot ru Description: This bug have been opened many times for a variety of php versions (up to 5.2.0), but most of them were closed due to no feedback. Hopefully, this report would be the final one. As in previous reports, the problem occurs while trying to build PHP over a newer c-client version with new utf8_mime2text signature. This is caused by undefined HAVE_NEW_MIME2TEXT. configure script detects new c-client correctly and comments out the '#undef HAVE_NEW_MIME2TEXT' line, but this is not enough. The following changes to main/php_config.h after running ./configure solve the problem: /* Whether utf8_mime2text() has new signature * -/* #undef HAVE_NEW_MIME2TEXT */ +#define HAVE_NEW_MIME2TEXT Reproduce code: --- ./configure --with-imap=/usr/local && make Expected result: Compile without errors. Actual result: -- Compilation fails with the following output /chr/src/php-5.2.6/ext/imap/php_imap.c:82: error: conflicting types for `utf8_mime2text' /usr/local/include/utf8aux.h:37: error: previous declaration of `utf8_mime2text' -- Edit this bug report at http://bugs.php.net/?id=45793&edit=1
#45761 [Opn->Fbk]: make test & make install failure
ID: 45761
Updated by: [EMAIL PROTECTED]
Reported By: a dot sanders at manchester dot ac dot uk
-Status: Open
+Status: Feedback
Bug Type: Compile Failure
Operating System: Solaris 9
PHP Version: 5.2CVS-2008-08-11
Assigned To: fb-req-jani
New Comment:
Add the output of '(gdb) bt' here of the crash. Compile using this
configure line:
# ./configure --disable-all --enable-debug
Also, when you generate the backtrace, make sure you're not loading any
php.ini file using the '-n' parameter. f.e.
# USE_ZEND_ALLOC=0 gdb sapi/cli/php -n run-tests.php
Previous Comments:
[2008-08-11 09:45:59] a dot sanders at manchester dot ac dot uk
I downloaded the latest this morning and did
./configure --disable-all
make test
I compiles okay and then still seg faults when it
gets to the test part of make test:
...
Build complete.
Don't forget to run 'make test'.
Segmentation Fault - core dumped
make: [test] Error 139 (ignored)
Same stuff as before from gdb:
#0 0x0010003c in _zval_ptr_dtor (zval_ptr=0x23f1e0)
at /home/copacw/php5.2-200808110830/Zend/zend_execute_API.c:412
412 (*zval_ptr)->refcount--;
(gdb) print *zval_ptr
$1 = (zval *) 0x1
(gdb)
I recompiled again with the DEBUG_ZEND=2 flag and got the following
result:
Build complete.
Don't forget to run 'make test'.
+---+
| ! ERROR ! |
| The test-suite requires that you have pcre extension |
| enabled. To enable this extension either compile your PHP |
| with --with-pcre-regex or if you've compiled pcre as a|
| shared module load it via php.ini.|
+---+
So reconfigured and recompiled again with --disbale-all
--with-pcre_regex. This time it compiled and got to test 3519 when
it again tried to spawn thousands of child processes. It
was in danger of consuming all available memory, so I killed
it at that point.
TEST 3519/3546 [sapi/cgi/tests/001.phpt]
[2008-08-08 18:12:01] [EMAIL PROTECTED]
s/options/patches/ :)
[2008-08-08 18:11:35] [EMAIL PROTECTED]
Get this:
http://snaps.php.net/php5.2-latest.tar.gz
And do not apply any 3rd party options. And do (exactly) this:
# ./configure --disable-all && make test
[2008-08-08 11:59:04] a dot sanders at manchester dot ac dot uk
Description:
'make test' fails immediately with a segmentation fault. Re-compiling
with compiler flag DEBUG_ZEND=2 allows 'make test' to get to test
4399 before spawning several thousand php-cgi children and consuming
all
the system memory.
Actual result:
--
Initial configure command was:
env LDFLAGS="-R/copac/gcc-4/lib" ./configure --prefix=~/apache-
2_2/ --with-mysql=/home/copacw/mysql5/mysql --with-libxml-
dir=/home/copacw/apache-2_2
A 'make test' from the above results in this:
huntly copacw/php-5.2.6 $ make test
Build complete.
Don't forget to run 'make test'.
Segmentation Fault - core dumped
make: [test] Error 139 (ignored)
A backtrace of the core file from the above:
#0 0x00220130 in _zval_ptr_dtor (zval_ptr=0x39d8a8)
at /home/copacw/php-5.2.6/Zend?/zend_execute_API.c:412
412 (*zval_ptr)->refcount--;
(gdb) list
407 ZEND_API void _zval_ptr_dtor(zval **zval_ptr
ZEND_FILE_LINE_DC)
408 {
409 #if DEBUG_ZEND>=2
410 printf("Reducing refcount for %x (%x): %d->%d\n",
*zval_ptr, zval_ptr, (*zval_ptr)->refcount, (*zval_ptr)-
>refcount-1);
411 #endif
412 (*zval_ptr)->refcount--;
413 if ((*zval_ptr)->refcount==0) {
414 zval_dtor(*zval_ptr);
415 safe_free_zval_ptr_rel(*zval_ptr
ZEND_FILE_LINE_RELAY_CC ZEND_FILE_LINE_CC);
416 } else if ((*zval_ptr)->refcount == 1) {
(gdb) print *zval_ptr
$1 = (zval *) 0x1
I reconfigured by adding CFLAGS="-DDEBUG_ZEND=2" to the start of the
configure command, did a 'make clean', then 'make', then
'make test'.
This time the 'make test' gets to test 4399 and then fails as below:
PASS XMLWriter: libxml2 XML Writer DTD Element & Attlist
[ext/xmlwriter/tests/OO_008.phpt]
PASS XMLWriter: PI, Comment, CDATA [ext/xmlwriter/tests/OO_009.phpt]
PASS Bug #39504 (xmlwriter_write_dtd_entity() creates Attlist tag,
not enity) [ext/xmlwriter/tests/bug39504.phpt]
PASS Bug #41287 (Namespace functions don't allow xmlns defintion to
be optional) [ext/xmlwriter/tests/bug41287.phpt]
PASS Bug #41287 (Writing empty tags with Xmlwriter::WriteElement?
[ns]) [ext/xmlwriter/tests/bug41326.phpt]
TEST
#45793 [Opn->Fbk]: conflicting types for `utf8_mime2text'
ID: 45793 Updated by: [EMAIL PROTECTED] Reported By: amiheev at st-host dot ru -Status: Open +Status: Feedback Bug Type: IMAP related Operating System: Linux glibc-2.3.3-27 gcc-3.3.3 PHP Version: 5.2.6 Assigned To: fb-req-jani New Comment: Are you sure you don't have some old c-client header files in your system, for example in /usr/include or other header path included in the make? Previous Comments: [2008-08-12 14:29:30] amiheev at st-host dot ru 1. imap-2007b 2. Not too much: configure:46967: checking for IMAP support configure:47014: checking for IMAP Kerberos support configure:47040: checking for IMAP SSL support configure:47456: checking for utf8_mime2text signature configure:47503: checking for U8T_CANONICAL And a bit later: configure:49236: checking whether build with IMAP works configure:49274: gcc -o conftest -I/usr/local/include -g -O2 -L/usr/local/lib -Wl,-rpath,/usr/local/lib -L/usr/local/lib conftest.c -lc-client -lcrypt -lpam -liconv -lfreetype -lpng -lz -ljpeg -lcurl -lz -lresolv -lm -ldl -lnsl -lxml2 -lz -liconv -lm -lcurl -lxml2 -lz -liconv -lm 1>&5 /usr/local/lib/libc-client.a(osdep.o)(.text+0x8b0b): In function `ssl_onceonlyin it': /chr/src/imap/imap-2007b/c-client/osdep.c:353: warning: the use of `tmpnam' is dangerous, better use `mkstemp' [2008-08-12 14:21:36] [EMAIL PROTECTED] 1. What is the exact c-client version you compile with? 2. Check your config.log for the relevant output for the check of utf8_mime2text() signature and paste here. [2008-08-12 06:02:09] amiheev at st-host dot ru Description: This bug have been opened many times for a variety of php versions (up to 5.2.0), but most of them were closed due to no feedback. Hopefully, this report would be the final one. As in previous reports, the problem occurs while trying to build PHP over a newer c-client version with new utf8_mime2text signature. This is caused by undefined HAVE_NEW_MIME2TEXT. configure script detects new c-client correctly and comments out the '#undef HAVE_NEW_MIME2TEXT' line, but this is not enough. The following changes to main/php_config.h after running ./configure solve the problem: /* Whether utf8_mime2text() has new signature * -/* #undef HAVE_NEW_MIME2TEXT */ +#define HAVE_NEW_MIME2TEXT Reproduce code: --- ./configure --with-imap=/usr/local && make Expected result: Compile without errors. Actual result: -- Compilation fails with the following output /chr/src/php-5.2.6/ext/imap/php_imap.c:82: error: conflicting types for `utf8_mime2text' /usr/local/include/utf8aux.h:37: error: previous declaration of `utf8_mime2text' -- Edit this bug report at http://bugs.php.net/?id=45793&edit=1
#45755 [Opn]: can't use pipes to deliver script via PATH_TRANSLATED
ID: 45755 Updated by: [EMAIL PROTECTED] Reported By: louis at steelbytes dot com Status: Open -Bug Type: CGI related +Bug Type: Feature/Change Request Operating System: Vista SP1 x64 PHP Version: 5.2.6 New Comment: Reclassified. This most likely will never be implemented. You really should be using the FastCGI interface anyways. Previous Comments: [2008-08-12 01:16:17] louis at steelbytes dot com more notes: * using php.exe -f \\.\pipe\test also does not work * also using \\mypc\pipe\test does not work [2008-08-11 11:08:53] louis at steelbytes dot com using a trivial pipes experiment available from http://louis.steelbytes.com/temp/fileAsPipe.zip shell1: fileAsPipe c:\path\test.php \\.\pipe\test shell2: set GATEWAY_INTERFACE=CGI/1.1 set REQUEST_METHOD=GET set PATH_TRANSLATED=\\.\pipe\test set SCRIPT_NAME=test.php php-cgi.exe shell2.output: Status: 404 Not Found X-Powered-By: PHP/5.2.6 Content-type: text/html No input file specified. note: this is arguably not a bug, but really a feature request :) [2008-08-08 07:52:18] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. It's read by a human, we need a script or C code or at least something we can test with. [2008-08-08 06:30:53] louis at steelbytes dot com Description: I'm trying to call php-cgi.exe from inside my app, and I wanted to supply the script via a pipe. so I set the pipe name \\.\pipe\testpipe in PATH_TRANSLATED, but php-cgi.exe won't read from there. it failes in virtual_file_ex() being confused thinking it's a unc path, and skipping the . component, and trying to use FindFirstFile to test if valid. Reproduce code: --- see above Expected result: see above Actual result: -- see above -- Edit this bug report at http://bugs.php.net/?id=45755&edit=1
#45756 [Opn->Fbk]: Query is executed on wrong server (resource). Bug with global resource scope?
ID: 45756
Updated by: [EMAIL PROTECTED]
Reported By: jochem dot blok at fasterforward dot nl
-Status: Open
+Status: Feedback
Bug Type: MSSQL related
Operating System: Debian
PHP Version: 5.2.6
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
Previous Comments:
[2008-08-08 07:20:10] jochem dot blok at fasterforward dot nl
Btw. FreeTDS is used described in the manual:
http://nl2.php.net/manual/en/mssql.setup.php
[2008-08-08 07:18:08] jochem dot blok at fasterforward dot nl
Description:
See reproduce code. The query is executed 2 times on resource $r2.
Reproduce code:
---
$r1 = mssql_connect('my_server', 'my_user', 'my_pass');
mssql_select_db('database_1', $r1);
$r2 = mssql_connect('my_server', 'my_user', 'my_pass');
mssql_select_db('database_2', $r2);
$sSql = 'select count(*) as total from my_table';
$rRes1 = mssql_query($sSql, $r1);
$oRow1 = mssql_fetch_object($rRes1);
echo '1: '.$oRow1->total.'';
$rRes2 = mssql_query($sSql, $r2);
$oRow2 = mssql_fetch_object($rRes2);
echo '2: '.$oRow2->total.'';
Expected result:
Different total.
Actual result:
--
Same total.
--
Edit this bug report at http://bugs.php.net/?id=45756&edit=1
#45786 [Fbk->Opn]: FastCGI process exited unexpectedly
ID: 45786 User updated by: karelevzen at gmail dot com Reported By: karelevzen at gmail dot com -Status: Feedback +Status: Open Bug Type: IIS related Operating System: Windows Vista Ultimate x64 SP1 PHP Version: 5.3CVS-2008-08-10 (CVS) Assigned To: fb-req-jani New Comment: I am not loading any extensions. It's a fresh install with recommended php.ini and only these changes: cgi.force_redirect = 0 cgi.fix_pathinfo=1 fastcgi.impersonate = 1 and correct extension_dir As I said, I've got all the extensions commented out. Previous Comments: [2008-08-12 14:26:13] [EMAIL PROTECTED] You're propably loading some shared extensions in your php.ini? Disable all of them and try again. Then enable them one by one to find out the error causing one. Then check that the extension in question isn't compiled in the PHP core binary. (php -m output!) [2008-08-11 16:49:18] karelevzen at gmail dot com may be related to bug 45630 [2008-08-11 13:48:32] karelevzen at gmail dot com Description: When you run PHP as a FastCGI module under IIS 7.0 (Windows Vista Ultimate x64) you get an error "FastCGI process exited unexpectedly" every time you visit a PHP page. The page contents loads OK, but after a second or so you get this error (a GUI message). Until you receive the message, the browser seems to be loading something (this could mean that the request wasn't handled well). Also, I've noticed that I have Configuration File (php.ini) set to C:\Windows, while the file is correctly loaded from C:\bin32\php\php.ini Everything works OK with the 2.5.6 nts build. Reproduce code: --- Expected result: No error message. Actual result: -- Faulting module name: php-cgi.exe Exception code: c005 Exception offset: 5604 -- Edit this bug report at http://bugs.php.net/?id=45786&edit=1
#45697 [Opn->Bgs]: ISAPI mode header() doesnt send any headers
ID: 45697 Updated by: [EMAIL PROTECTED] Reported By: beezlebob666 at yahoo dot com -Status: Open +Status: Bogus Bug Type: IIS related Operating System: XP Pro PHP Version: 5.2.6 New Comment: >From the manual page for header(): "Note: The HTTP status header line will always be the first sent to the client, regardless of the actual header() call being the first or not. The status may be overridden by calling header() with a new status line at any time unless the HTTP headers have already been sent." The correct way to send such headers: Previous Comments: [2008-08-06 05:44:54] beezlebob666 at yahoo dot com Oh and for the record, I have tried setting php.ini with the following: ; if cgi.nph is enabled it will force cgi to always sent Status: 200 with ; every request. cgi.nph = 0 cgi.rfc2616_headers = 0 Although its not in cgi mode,its ISAPI mode so, despite my inexperience, makes sense to try, but it didnt resolve the issue. I have also run a header scanner on my server also, and even though I dont see it, its as if the server is sending a Status: 200 OK before sending Status: 404 [2008-08-06 00:18:08] japan at email dot de This sounds like a comparable Sympom of my error message Bug # 45615 of the 2008-07-24 [2008-08-03 11:01:06] beezlebob666 at yahoo dot com Description: In ISAPI mode on IIS on XP, header() does not send anything to the browser. Pear not installed, zend not installed, all .dll files unloaded, default php.ini-dist used. Uninstalled and reinstalled as a CGI mode and it appears to work fine. Reproduce code: --- Expected result: Expected to redirect to any 404 page. Actual result: -- Blank page with no content. -- Edit this bug report at http://bugs.php.net/?id=45697&edit=1
#45697 [Bgs]: ISAPI mode header() doesnt send any headers
ID: 45697 Updated by: [EMAIL PROTECTED] Reported By: beezlebob666 at yahoo dot com Status: Bogus Bug Type: IIS related Operating System: XP Pro PHP Version: 5.2.6 New Comment: Also note: Running PHP as ISAPI module is not really supported. Even Microsoft suggests using FastCGI. Previous Comments: [2008-08-12 14:43:29] [EMAIL PROTECTED] >From the manual page for header(): "Note: The HTTP status header line will always be the first sent to the client, regardless of the actual header() call being the first or not. The status may be overridden by calling header() with a new status line at any time unless the HTTP headers have already been sent." The correct way to send such headers: [2008-08-06 05:44:54] beezlebob666 at yahoo dot com Oh and for the record, I have tried setting php.ini with the following: ; if cgi.nph is enabled it will force cgi to always sent Status: 200 with ; every request. cgi.nph = 0 cgi.rfc2616_headers = 0 Although its not in cgi mode,its ISAPI mode so, despite my inexperience, makes sense to try, but it didnt resolve the issue. I have also run a header scanner on my server also, and even though I dont see it, its as if the server is sending a Status: 200 OK before sending Status: 404 [2008-08-06 00:18:08] japan at email dot de This sounds like a comparable Sympom of my error message Bug # 45615 of the 2008-07-24 [2008-08-03 11:01:06] beezlebob666 at yahoo dot com Description: In ISAPI mode on IIS on XP, header() does not send anything to the browser. Pear not installed, zend not installed, all .dll files unloaded, default php.ini-dist used. Uninstalled and reinstalled as a CGI mode and it appears to work fine. Reproduce code: --- Expected result: Expected to redirect to any 404 page. Actual result: -- Blank page with no content. -- Edit this bug report at http://bugs.php.net/?id=45697&edit=1
#45786 [Opn->Fbk]: FastCGI process exited unexpectedly
ID: 45786 Updated by: [EMAIL PROTECTED] Reported By: karelevzen at gmail dot com -Status: Open +Status: Feedback Bug Type: IIS related Operating System: Windows Vista Ultimate x64 SP1 PHP Version: 5.3CVS-2008-08-10 (CVS) Assigned To: fb-req-jani New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Previous Comments: [2008-08-12 14:41:54] karelevzen at gmail dot com I am not loading any extensions. It's a fresh install with recommended php.ini and only these changes: cgi.force_redirect = 0 cgi.fix_pathinfo=1 fastcgi.impersonate = 1 and correct extension_dir As I said, I've got all the extensions commented out. [2008-08-12 14:26:13] [EMAIL PROTECTED] You're propably loading some shared extensions in your php.ini? Disable all of them and try again. Then enable them one by one to find out the error causing one. Then check that the extension in question isn't compiled in the PHP core binary. (php -m output!) [2008-08-11 16:49:18] karelevzen at gmail dot com may be related to bug 45630 [2008-08-11 13:48:32] karelevzen at gmail dot com Description: When you run PHP as a FastCGI module under IIS 7.0 (Windows Vista Ultimate x64) you get an error "FastCGI process exited unexpectedly" every time you visit a PHP page. The page contents loads OK, but after a second or so you get this error (a GUI message). Until you receive the message, the browser seems to be loading something (this could mean that the request wasn't handled well). Also, I've noticed that I have Configuration File (php.ini) set to C:\Windows, while the file is correctly loaded from C:\bin32\php\php.ini Everything works OK with the 2.5.6 nts build. Reproduce code: --- Expected result: No error message. Actual result: -- Faulting module name: php-cgi.exe Exception code: c005 Exception offset: 5604 -- Edit this bug report at http://bugs.php.net/?id=45786&edit=1
#45613 [Asn->Fbk]: Segfault when using is_file() on Apache-2.2.8
ID: 45613 Updated by: [EMAIL PROTECTED] Reported By: crocodile2u at yandex dot ru -Status: Assigned +Status: Feedback Bug Type: Apache2 related -Operating System: Ununtu 8.04 +Operating System: * PHP Version: 5.3CVS-2008-07-24 (CVS) Assigned To: tony2001 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.3-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.3-win32-installer-latest.msi Previous Comments: [2008-08-05 11:15:54] crocodile2u at yandex dot ru The problem is still here with PHP-5.3.0alpha [2008-08-01 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". [2008-07-28 08:58:51] crocodile2u at yandex dot ru I've just installed the latest snapshot of PHP-5.3 and the problem persists. The dump: #0 0x in ?? () #1 0xb71feef8 in phar_is_file (ht=1, return_value=0x83db0b8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0, tsrm_ls=0x83c5a70) at /home/vbolshov/src/php/php5.3-200807280630/ext/phar/func_interceptors.c:956 #2 0xb73f3828 in zend_do_fcall_common_helper_SPEC (execute_data=0x84a0a70, tsrm_ls=0x83c5a70) at /home/vbolshov/src/php/php5.3-200807280630/Zend/zend_vm_execute.h:313 #3 0xb73e00b5 in execute (op_array=0x83dac2c, tsrm_ls=0x83c5a70) at /home/vbolshov/src/php/php5.3-200807280630/Zend/zend_vm_execute.h:104 #4 0xb73bad2f in zend_execute_scripts (type=8, tsrm_ls=0x83c5a70, retval=0x0, file_count=3) at /home/vbolshov/src/php/php5.3-200807280630/Zend/zend.c:1199 #5 0xb73617d5 in php_execute_script (primary_file=0xb44c41f0, tsrm_ls=0x83c5a70) at /home/vbolshov/src/php/php5.3-200807280630/main/main.c:2088 #6 0xb744fa48 in php_handler (r=0x83cac20) at /home/vbolshov/src/php/php5.3-200807280630/sapi/apache2handler/sapi_apache2.c:630 #7 0x08079639 in ap_run_handler () #8 0x0807ca47 in ap_invoke_handler () #9 0x08089d60 in ap_process_request () #10 0x0808706b in ?? () #11 0x083cac20 in ?? () #12 0x0004 in ?? () #13 0x083cac20 in ?? () #14 0x in ?? () Source code for the script was: http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. 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/45613 -- Edit this bug report at http://bugs.php.net/?id=45613&edit=1
#45613 [Fbk->Asn]: Segfault when using is_file() on Apache-2.2.8
ID: 45613 Updated by: [EMAIL PROTECTED] Reported By: crocodile2u at yandex dot ru -Status: Feedback +Status: Assigned Bug Type: Apache2 related Operating System: * PHP Version: 5.3CVS-2008-07-24 (CVS) Assigned To: tony2001 New Comment: Apparently it's not fixed, so no need for feedback. Previous Comments: [2008-08-12 14:59:57] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.3-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.3-win32-installer-latest.msi [2008-08-05 11:15:54] crocodile2u at yandex dot ru The problem is still here with PHP-5.3.0alpha [2008-08-01 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". [2008-07-28 08:58:51] crocodile2u at yandex dot ru I've just installed the latest snapshot of PHP-5.3 and the problem persists. The dump: #0 0x in ?? () #1 0xb71feef8 in phar_is_file (ht=1, return_value=0x83db0b8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0, tsrm_ls=0x83c5a70) at /home/vbolshov/src/php/php5.3-200807280630/ext/phar/func_interceptors.c:956 #2 0xb73f3828 in zend_do_fcall_common_helper_SPEC (execute_data=0x84a0a70, tsrm_ls=0x83c5a70) at /home/vbolshov/src/php/php5.3-200807280630/Zend/zend_vm_execute.h:313 #3 0xb73e00b5 in execute (op_array=0x83dac2c, tsrm_ls=0x83c5a70) at /home/vbolshov/src/php/php5.3-200807280630/Zend/zend_vm_execute.h:104 #4 0xb73bad2f in zend_execute_scripts (type=8, tsrm_ls=0x83c5a70, retval=0x0, file_count=3) at /home/vbolshov/src/php/php5.3-200807280630/Zend/zend.c:1199 #5 0xb73617d5 in php_execute_script (primary_file=0xb44c41f0, tsrm_ls=0x83c5a70) at /home/vbolshov/src/php/php5.3-200807280630/main/main.c:2088 #6 0xb744fa48 in php_handler (r=0x83cac20) at /home/vbolshov/src/php/php5.3-200807280630/sapi/apache2handler/sapi_apache2.c:630 #7 0x08079639 in ap_run_handler () #8 0x0807ca47 in ap_invoke_handler () #9 0x08089d60 in ap_process_request () #10 0x0808706b in ?? () #11 0x083cac20 in ?? () #12 0x0004 in ?? () #13 0x083cac20 in ?? () #14 0x in ?? () Source code for the script was: http://bugs.php.net/45613 -- Edit this bug report at http://bugs.php.net/?id=45613&edit=1
#45761 [Fbk->Opn]: make test & make install failure
ID: 45761
User updated by: a dot sanders at manchester dot ac dot uk
Reported By: a dot sanders at manchester dot ac dot uk
-Status: Feedback
+Status: Open
Bug Type: Compile Failure
Operating System: Solaris 9
PHP Version: 5.2CVS-2008-08-11
Assigned To: fb-req-jani
New Comment:
When I compiled with
./configure --disable-all --enable-debug --with-pcre-regex
I can do a make test and it gets to the same place as before
(the cgi test) without core dumping. I then have to kill it
before it consumes the system memory.
You told me to run gdb as follows:
USE_ZEND_ALLOC=0 gdb sapi/cli/php -n run-tests.php
gdb wont accept such a command line, so I entered
run -n run-tests.php
from the gdb prompt and I then get the message:
Starting program: /home/copacw/php5.2-200808110830/sapi/cli/php -n
run-tests.php
ERROR: environment variable TEST_PHP_EXECUTABLE must be set to specify
PHP executable!
Program exited with code 01.
I've tried setting a TEST_PHP_EXECUTABLE environment variable to point
to the php executable, but I still get the same message.
Previous Comments:
[2008-08-12 14:32:08] [EMAIL PROTECTED]
Add the output of '(gdb) bt' here of the crash. Compile using this
configure line:
# ./configure --disable-all --enable-debug
Also, when you generate the backtrace, make sure you're not loading any
php.ini file using the '-n' parameter. f.e.
# USE_ZEND_ALLOC=0 gdb sapi/cli/php -n run-tests.php
[2008-08-11 09:45:59] a dot sanders at manchester dot ac dot uk
I downloaded the latest this morning and did
./configure --disable-all
make test
I compiles okay and then still seg faults when it
gets to the test part of make test:
...
Build complete.
Don't forget to run 'make test'.
Segmentation Fault - core dumped
make: [test] Error 139 (ignored)
Same stuff as before from gdb:
#0 0x0010003c in _zval_ptr_dtor (zval_ptr=0x23f1e0)
at /home/copacw/php5.2-200808110830/Zend/zend_execute_API.c:412
412 (*zval_ptr)->refcount--;
(gdb) print *zval_ptr
$1 = (zval *) 0x1
(gdb)
I recompiled again with the DEBUG_ZEND=2 flag and got the following
result:
Build complete.
Don't forget to run 'make test'.
+---+
| ! ERROR ! |
| The test-suite requires that you have pcre extension |
| enabled. To enable this extension either compile your PHP |
| with --with-pcre-regex or if you've compiled pcre as a|
| shared module load it via php.ini.|
+---+
So reconfigured and recompiled again with --disbale-all
--with-pcre_regex. This time it compiled and got to test 3519 when
it again tried to spawn thousands of child processes. It
was in danger of consuming all available memory, so I killed
it at that point.
TEST 3519/3546 [sapi/cgi/tests/001.phpt]
[2008-08-08 18:12:01] [EMAIL PROTECTED]
s/options/patches/ :)
[2008-08-08 18:11:35] [EMAIL PROTECTED]
Get this:
http://snaps.php.net/php5.2-latest.tar.gz
And do not apply any 3rd party options. And do (exactly) this:
# ./configure --disable-all && make test
[2008-08-08 11:59:04] a dot sanders at manchester dot ac dot uk
Description:
'make test' fails immediately with a segmentation fault. Re-compiling
with compiler flag DEBUG_ZEND=2 allows 'make test' to get to test
4399 before spawning several thousand php-cgi children and consuming
all
the system memory.
Actual result:
--
Initial configure command was:
env LDFLAGS="-R/copac/gcc-4/lib" ./configure --prefix=~/apache-
2_2/ --with-mysql=/home/copacw/mysql5/mysql --with-libxml-
dir=/home/copacw/apache-2_2
A 'make test' from the above results in this:
huntly copacw/php-5.2.6 $ make test
Build complete.
Don't forget to run 'make test'.
Segmentation Fault - core dumped
make: [test] Error 139 (ignored)
A backtrace of the core file from the above:
#0 0x00220130 in _zval_ptr_dtor (zval_ptr=0x39d8a8)
at /home/copacw/php-5.2.6/Zend?/zend_execute_API.c:412
412 (*zval_ptr)->refcount--;
(gdb) list
407 ZEND_API void _zval_ptr_dtor(zval **zval_ptr
ZEND_FILE_LINE_DC)
408 {
409 #if DEBUG_ZEND>=2
410 printf("Reducing refcount for %x (%x): %d->%d\n",
*zval_ptr, zval_ptr, (*zval_ptr)->refcount, (*zval_ptr)-
>refcount-1);
411 #endif
412 (*zval_ptr)->refcount--;
413 if ((*zval_ptr)->refcount==0) {
414 zval_dtor(*zval_ptr);
415
#45794 [Bgs]: HTTP headers rendered differently in PHP than Apache rewrite mod likes them
ID: 45794 User updated by: tarag956 at gmail dot com Reported By: tarag956 at gmail dot com Status: Bogus Bug Type: *Web Server problem Operating System: nix PHP Version: 5.2.6 New Comment: Those links you gave were worthless and unrelated to the issue. I've already read through the manual fully. Are you claiming that somewhere hidden PHP actually can get the same exact style of headers ad mod-rewrite? I have checked fully and there is no such thing. Or are you claiming this is something PHP knows about and "won't fix"? You never explicitly stated your reason for decaring the bug "bogus". Previous Comments: [2008-08-12 13:32:22] [EMAIL PROTECTED] 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 HTTP headers and other variables follows the CGI specification: http://hoohoo.ncsa.uiuc.edu/cgi/env.html [2008-08-12 06:08:40] tarag956 at gmail dot com Description: HTTP headers rendered differently in PHP than Apache rewrite mod likes them For instance... PHP renders a header this way (from the $_SERVER associated array): HTTP_X_MOZ But apache rewrite mod likes it: HTTP:X-MOZ I couldn't find any previous reports on this. But basically, PHP needs some way for its HTTP headers to end up looking the same way that Apache's mod-rewrite likes them. Other examples... Apache likes them like: HTTP:X-FORWARDED-FOR REMOTE_ADDR HTTP:CLIENT-IP REQUEST_METHOD But PHP usually converts all "-" to "_" and converts all ":" to "_" and sometimes adds "HTTP_" in front of things. Maybe this is a feature request, but it would be nice if PHP's HTTP header variables could go be the exact names that HTTP's rewrite mod like them as. Reproduce code: --- .. Expected result: .. Actual result: -- .. -- Edit this bug report at http://bugs.php.net/?id=45794&edit=1
#45794 [Bgs]: HTTP headers rendered differently in PHP than Apache rewrite mod likes them
ID: 45794 User updated by: tarag956 at gmail dot com Reported By: tarag956 at gmail dot com Status: Bogus Bug Type: *Web Server problem Operating System: nix PHP Version: 5.2.6 New Comment: Also your first paragraph was an obvious form letter, and your second paragraph was unrelated so I'm no even sure if you understood what I initially said. Also as for flagging bugs bogus, here's a screenshot unrelated to this bug report but related to falsely flagging bugs a bogus: http://images.encyclopediadramatica.com/images/c/c9/Why_PHP_remains_slow.png Previous Comments: [2008-08-12 15:17:24] tarag956 at gmail dot com Those links you gave were worthless and unrelated to the issue. I've already read through the manual fully. Are you claiming that somewhere hidden PHP actually can get the same exact style of headers ad mod-rewrite? I have checked fully and there is no such thing. Or are you claiming this is something PHP knows about and "won't fix"? You never explicitly stated your reason for decaring the bug "bogus". [2008-08-12 13:32:22] [EMAIL PROTECTED] 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 HTTP headers and other variables follows the CGI specification: http://hoohoo.ncsa.uiuc.edu/cgi/env.html [2008-08-12 06:08:40] tarag956 at gmail dot com Description: HTTP headers rendered differently in PHP than Apache rewrite mod likes them For instance... PHP renders a header this way (from the $_SERVER associated array): HTTP_X_MOZ But apache rewrite mod likes it: HTTP:X-MOZ I couldn't find any previous reports on this. But basically, PHP needs some way for its HTTP headers to end up looking the same way that Apache's mod-rewrite likes them. Other examples... Apache likes them like: HTTP:X-FORWARDED-FOR REMOTE_ADDR HTTP:CLIENT-IP REQUEST_METHOD But PHP usually converts all "-" to "_" and converts all ":" to "_" and sometimes adds "HTTP_" in front of things. Maybe this is a feature request, but it would be nice if PHP's HTTP header variables could go be the exact names that HTTP's rewrite mod like them as. Reproduce code: --- .. Expected result: .. Actual result: -- .. -- Edit this bug report at http://bugs.php.net/?id=45794&edit=1
#45794 [Bgs]: HTTP headers rendered differently in PHP than Apache rewrite mod likes them
ID: 45794 User updated by: tarag956 at gmail dot com Reported By: tarag956 at gmail dot com Status: Bogus Bug Type: *Web Server problem Operating System: nix PHP Version: 5.2.6 New Comment: The form cut off the URL of the screenshot then made a link out of the decapitated URL. It needs to be all on one line to be viewed. Previous Comments: [2008-08-12 15:20:27] tarag956 at gmail dot com Also your first paragraph was an obvious form letter, and your second paragraph was unrelated so I'm no even sure if you understood what I initially said. Also as for flagging bugs bogus, here's a screenshot unrelated to this bug report but related to falsely flagging bugs a bogus: http://images.encyclopediadramatica.com/images/c/c9/Why_PHP_remains_slow.png [2008-08-12 15:17:24] tarag956 at gmail dot com Those links you gave were worthless and unrelated to the issue. I've already read through the manual fully. Are you claiming that somewhere hidden PHP actually can get the same exact style of headers ad mod-rewrite? I have checked fully and there is no such thing. Or are you claiming this is something PHP knows about and "won't fix"? You never explicitly stated your reason for decaring the bug "bogus". [2008-08-12 13:32:22] [EMAIL PROTECTED] 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 HTTP headers and other variables follows the CGI specification: http://hoohoo.ncsa.uiuc.edu/cgi/env.html [2008-08-12 06:08:40] tarag956 at gmail dot com Description: HTTP headers rendered differently in PHP than Apache rewrite mod likes them For instance... PHP renders a header this way (from the $_SERVER associated array): HTTP_X_MOZ But apache rewrite mod likes it: HTTP:X-MOZ I couldn't find any previous reports on this. But basically, PHP needs some way for its HTTP headers to end up looking the same way that Apache's mod-rewrite likes them. Other examples... Apache likes them like: HTTP:X-FORWARDED-FOR REMOTE_ADDR HTTP:CLIENT-IP REQUEST_METHOD But PHP usually converts all "-" to "_" and converts all ":" to "_" and sometimes adds "HTTP_" in front of things. Maybe this is a feature request, but it would be nice if PHP's HTTP header variables could go be the exact names that HTTP's rewrite mod like them as. Reproduce code: --- .. Expected result: .. Actual result: -- .. -- Edit this bug report at http://bugs.php.net/?id=45794&edit=1
#45793 [Fbk->Opn]: conflicting types for `utf8_mime2text'
ID: 45793 User updated by: amiheev at st-host dot ru Reported By: amiheev at st-host dot ru -Status: Feedback +Status: Open Bug Type: IMAP related Operating System: Linux glibc-2.3.3-27 gcc-3.3.3 PHP Version: 5.2.6 Assigned To: fb-req-jani New Comment: Yes. Actually, I had the problem (quite different) with old version first, so I replaced old c-client files. So I did ensure I only have one instance of both c-client.h and utf8aux.h in this system. Probably, the problems with different c-client versions could be relevant. I had "old" c-client in /usr/local and a "new" one in /usr/local/imap-2007b and failed to compile php over the new one, although I explicitly specified a "new" directory when ran configure. If it could relevant, I could try to reproduce, I have another box which still has old setup. Previous Comments: [2008-08-12 14:35:33] [EMAIL PROTECTED] Are you sure you don't have some old c-client header files in your system, for example in /usr/include or other header path included in the make? [2008-08-12 14:29:30] amiheev at st-host dot ru 1. imap-2007b 2. Not too much: configure:46967: checking for IMAP support configure:47014: checking for IMAP Kerberos support configure:47040: checking for IMAP SSL support configure:47456: checking for utf8_mime2text signature configure:47503: checking for U8T_CANONICAL And a bit later: configure:49236: checking whether build with IMAP works configure:49274: gcc -o conftest -I/usr/local/include -g -O2 -L/usr/local/lib -Wl,-rpath,/usr/local/lib -L/usr/local/lib conftest.c -lc-client -lcrypt -lpam -liconv -lfreetype -lpng -lz -ljpeg -lcurl -lz -lresolv -lm -ldl -lnsl -lxml2 -lz -liconv -lm -lcurl -lxml2 -lz -liconv -lm 1>&5 /usr/local/lib/libc-client.a(osdep.o)(.text+0x8b0b): In function `ssl_onceonlyin it': /chr/src/imap/imap-2007b/c-client/osdep.c:353: warning: the use of `tmpnam' is dangerous, better use `mkstemp' [2008-08-12 14:21:36] [EMAIL PROTECTED] 1. What is the exact c-client version you compile with? 2. Check your config.log for the relevant output for the check of utf8_mime2text() signature and paste here. [2008-08-12 06:02:09] amiheev at st-host dot ru Description: This bug have been opened many times for a variety of php versions (up to 5.2.0), but most of them were closed due to no feedback. Hopefully, this report would be the final one. As in previous reports, the problem occurs while trying to build PHP over a newer c-client version with new utf8_mime2text signature. This is caused by undefined HAVE_NEW_MIME2TEXT. configure script detects new c-client correctly and comments out the '#undef HAVE_NEW_MIME2TEXT' line, but this is not enough. The following changes to main/php_config.h after running ./configure solve the problem: /* Whether utf8_mime2text() has new signature * -/* #undef HAVE_NEW_MIME2TEXT */ +#define HAVE_NEW_MIME2TEXT Reproduce code: --- ./configure --with-imap=/usr/local && make Expected result: Compile without errors. Actual result: -- Compilation fails with the following output /chr/src/php-5.2.6/ext/imap/php_imap.c:82: error: conflicting types for `utf8_mime2text' /usr/local/include/utf8aux.h:37: error: previous declaration of `utf8_mime2text' -- Edit this bug report at http://bugs.php.net/?id=45793&edit=1
#45793 [Opn->Fbk]: conflicting types for `utf8_mime2text'
ID: 45793 Updated by: [EMAIL PROTECTED] Reported By: amiheev at st-host dot ru -Status: Open +Status: Feedback Bug Type: IMAP related Operating System: Linux glibc-2.3.3-27 gcc-3.3.3 PHP Version: 5.2.6 Assigned To: fb-req-jani New Comment: You really should have only one version per system. Mixing them, even in different directories while other has header files under common (f.e. /usr/include or /usr/local/include) will never work properly. Previous Comments: [2008-08-12 15:21:35] amiheev at st-host dot ru Yes. Actually, I had the problem (quite different) with old version first, so I replaced old c-client files. So I did ensure I only have one instance of both c-client.h and utf8aux.h in this system. Probably, the problems with different c-client versions could be relevant. I had "old" c-client in /usr/local and a "new" one in /usr/local/imap-2007b and failed to compile php over the new one, although I explicitly specified a "new" directory when ran configure. If it could relevant, I could try to reproduce, I have another box which still has old setup. [2008-08-12 14:35:33] [EMAIL PROTECTED] Are you sure you don't have some old c-client header files in your system, for example in /usr/include or other header path included in the make? [2008-08-12 14:29:30] amiheev at st-host dot ru 1. imap-2007b 2. Not too much: configure:46967: checking for IMAP support configure:47014: checking for IMAP Kerberos support configure:47040: checking for IMAP SSL support configure:47456: checking for utf8_mime2text signature configure:47503: checking for U8T_CANONICAL And a bit later: configure:49236: checking whether build with IMAP works configure:49274: gcc -o conftest -I/usr/local/include -g -O2 -L/usr/local/lib -Wl,-rpath,/usr/local/lib -L/usr/local/lib conftest.c -lc-client -lcrypt -lpam -liconv -lfreetype -lpng -lz -ljpeg -lcurl -lz -lresolv -lm -ldl -lnsl -lxml2 -lz -liconv -lm -lcurl -lxml2 -lz -liconv -lm 1>&5 /usr/local/lib/libc-client.a(osdep.o)(.text+0x8b0b): In function `ssl_onceonlyin it': /chr/src/imap/imap-2007b/c-client/osdep.c:353: warning: the use of `tmpnam' is dangerous, better use `mkstemp' [2008-08-12 14:21:36] [EMAIL PROTECTED] 1. What is the exact c-client version you compile with? 2. Check your config.log for the relevant output for the check of utf8_mime2text() signature and paste here. [2008-08-12 06:02:09] amiheev at st-host dot ru Description: This bug have been opened many times for a variety of php versions (up to 5.2.0), but most of them were closed due to no feedback. Hopefully, this report would be the final one. As in previous reports, the problem occurs while trying to build PHP over a newer c-client version with new utf8_mime2text signature. This is caused by undefined HAVE_NEW_MIME2TEXT. configure script detects new c-client correctly and comments out the '#undef HAVE_NEW_MIME2TEXT' line, but this is not enough. The following changes to main/php_config.h after running ./configure solve the problem: /* Whether utf8_mime2text() has new signature * -/* #undef HAVE_NEW_MIME2TEXT */ +#define HAVE_NEW_MIME2TEXT Reproduce code: --- ./configure --with-imap=/usr/local && make Expected result: Compile without errors. Actual result: -- Compilation fails with the following output /chr/src/php-5.2.6/ext/imap/php_imap.c:82: error: conflicting types for `utf8_mime2text' /usr/local/include/utf8aux.h:37: error: previous declaration of `utf8_mime2text' -- Edit this bug report at http://bugs.php.net/?id=45793&edit=1
#45761 [Opn->Fbk]: make test & make install failure
ID: 45761 Updated by: [EMAIL PROTECTED] Reported By: a dot sanders at manchester dot ac dot uk -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Solaris 9 PHP Version: 5.2CVS-2008-08-11 Assigned To: fb-req-jani New Comment: This should work: # USE_ZEND_ALLOC=0 TEST_PHP_EXECUTABLE=/full/path/to/php \ gdb --arg /full/path/to/php -n /full/path/to/php \ run-tests.php -n /full/path/to/php/src/ Previous Comments: [2008-08-12 15:13:20] a dot sanders at manchester dot ac dot uk When I compiled with ./configure --disable-all --enable-debug --with-pcre-regex I can do a make test and it gets to the same place as before (the cgi test) without core dumping. I then have to kill it before it consumes the system memory. You told me to run gdb as follows: USE_ZEND_ALLOC=0 gdb sapi/cli/php -n run-tests.php gdb wont accept such a command line, so I entered run -n run-tests.php from the gdb prompt and I then get the message: Starting program: /home/copacw/php5.2-200808110830/sapi/cli/php -n run-tests.php ERROR: environment variable TEST_PHP_EXECUTABLE must be set to specify PHP executable! Program exited with code 01. I've tried setting a TEST_PHP_EXECUTABLE environment variable to point to the php executable, but I still get the same message. [2008-08-12 14:32:08] [EMAIL PROTECTED] Add the output of '(gdb) bt' here of the crash. Compile using this configure line: # ./configure --disable-all --enable-debug Also, when you generate the backtrace, make sure you're not loading any php.ini file using the '-n' parameter. f.e. # USE_ZEND_ALLOC=0 gdb sapi/cli/php -n run-tests.php [2008-08-11 09:45:59] a dot sanders at manchester dot ac dot uk I downloaded the latest this morning and did ./configure --disable-all make test I compiles okay and then still seg faults when it gets to the test part of make test: ... Build complete. Don't forget to run 'make test'. Segmentation Fault - core dumped make: [test] Error 139 (ignored) Same stuff as before from gdb: #0 0x0010003c in _zval_ptr_dtor (zval_ptr=0x23f1e0) at /home/copacw/php5.2-200808110830/Zend/zend_execute_API.c:412 412 (*zval_ptr)->refcount--; (gdb) print *zval_ptr $1 = (zval *) 0x1 (gdb) I recompiled again with the DEBUG_ZEND=2 flag and got the following result: Build complete. Don't forget to run 'make test'. +---+ | ! ERROR ! | | The test-suite requires that you have pcre extension | | enabled. To enable this extension either compile your PHP | | with --with-pcre-regex or if you've compiled pcre as a| | shared module load it via php.ini.| +---+ So reconfigured and recompiled again with --disbale-all --with-pcre_regex. This time it compiled and got to test 3519 when it again tried to spawn thousands of child processes. It was in danger of consuming all available memory, so I killed it at that point. TEST 3519/3546 [sapi/cgi/tests/001.phpt] [2008-08-08 18:12:01] [EMAIL PROTECTED] s/options/patches/ :) [2008-08-08 18:11:35] [EMAIL PROTECTED] Get this: http://snaps.php.net/php5.2-latest.tar.gz And do not apply any 3rd party options. And do (exactly) this: # ./configure --disable-all && make test 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/45761 -- Edit this bug report at http://bugs.php.net/?id=45761&edit=1
#45788 [Bgs]: fgetcsv retuns NULL on warning instead of false
ID: 45788
User updated by: steven at realestatewebmasters dot com
Reported By: steven at realestatewebmasters dot com
Status: Bogus
Bug Type: Filesystem function related
Operating System: Linux
PHP Version: 5.2.6
New Comment:
I accept that it should not throw an error.
I do think it should act like all the other file functions (like
fgetc() ) that will return false on invalid parameters.
At the very least could the documentation for this function be updated?
The current example:
$handle = fopen("test.csv", "r");
while (($data = fgetcsv($handle, 1000, ",")) !== FALSE) {
will cause an infinite loop if you fail to open the file.
Previous Comments:
[2008-08-12 14:24:14] [EMAIL PROTECTED]
Invalid parameter does not cause fatal error in any PHP function. And
when an invalid parameter is passed, all functions using the new (more
consistent) parameter parsing also return NULL. No bug here.
[2008-08-11 18:36:49] steven at realestatewebmasters dot com
Description:
fgetcsv returns null if passed false as the handle. This should cause
and error instead of a warning and cause the function to return false.
Reproduce code:
---
Expected result:
Warning: fopen(foo): failed to open stream: No such file or directory
in /home/sbarre85/test.php on line 3
Warning: fgetcsv() expects parameter 1 to be resource, boolean given in
/home/sbarre85/test.php on line 5
bool(false)
Error: fgetcsv() expects parameter 1 to be resource, boolean given in
/home/sbarre85/test.php on line 7
Actual result:
--
Warning: fopen(foo): failed to open stream: No such file or directory
in /home/sbarre85/test.php on line 3
Warning: fgetcsv() expects parameter 1 to be resource, boolean given in
/home/sbarre85/test.php on line 5
NULL
Warning: fgetcsv() expects parameter 1 to be resource, boolean given in
/home/sbarre85/test.php on line 7
test
.. looping infinitly
--
Edit this bug report at http://bugs.php.net/?id=45788&edit=1
#45084 [Opn->Fbk]: SoapServer Don't Work at Windows Vista
ID: 45084
Updated by: [EMAIL PROTECTED]
Reported By: neumann at ntech dot com dot br
-Status: Open
+Status: Feedback
Bug Type: SOAP related
Operating System: Windows Vista
PHP Version: 5.2.6
Previous Comments:
[2008-06-02 12:08:32] albert at insad dot nl
Did you check your firewall rules?
To me it looks like Vista is blocking you :)
[2008-06-02 06:42:35] [EMAIL PROTECTED]
Have you checked your error log for any errors? When I try to run the
reproduce script I get a maximum execution error, I've seen on some
setups that PHP errors mixed with output buffering may cause HTTP 500
errors.
[02-Jun-2008 08:37:56] PHP Fatal error: Maximum execution time of 30
seconds exceeded in C:\webserver\www\HelloClient.php on line 9
[2008-05-24 00:59:42] neumann at ntech dot com dot br
Description:
If I execute HelloClient.php with the HelloServer.php at windows vista,
don't work(error 500). If I Copy the same HelloServer.php to another
server, and execute the same HelloClient.php at Windows Vista, it work
well...
PS:. Remember to change the param location in HelloClient.php, point it
to the HelloServer.php location URL.
Reproduce code:
---
"http://localhost/soap/HelloServer.php";,
'uri' => "http://localhost/";,
'trace'=> 1 ));
$return = $client->__soapCall("hello",array("world"));
echo $return;
?>
*
"http://localhost/";));
$server->addFunction("hello");
$server->handle();
?>
Expected result:
display the text: Hello world!
Actual result:
--
http server error 500
--
Edit this bug report at http://bugs.php.net/?id=45084&edit=1
#44989 [Opn->Asn]: 64bit Oracle RPMs still not supported by pdo-oci
ID: 44989 Updated by: [EMAIL PROTECTED] Reported By: stevec at engr dot oregonstate dot edu -Status: Open +Status: Assigned Bug Type: PDO related Operating System: Linux PHP Version: 5.2.6 Assigned To: sixd Previous Comments: [2008-07-22 08:03:42] noel dot rambaud at free dot fr Create a link client-> client64 in directory /usr/include/oracle/version_instantclientoracle idem in /usr/lib/oracle/version_instantclientoracle [2008-05-13 23:50:10] stevec at engr dot oregonstate dot edu Description: Bug #41941 addressed 64bit support for the --with-oci8 configure option, but not the --with-pdo-oci option. It still can't find the include files. Reproduce code: --- Using the Oracle provided 64bit InstantClient RPMs (currently using 11.1.0.1-1): ./configure --with-pdo-oci=instantclient,/usr/include,11.1.0 ... Produces: checking Oracle OCI support for PDO... yes checking Oracle Install-Dir... instantclient,/usr/include,11.1.0 checking if that is sane... yes checking for oci.h... configure: error: I'm too dumb to figure out where the include dir is in your Instant Client install Expected result: Should pass that part and find the client64 libraries. I've tried all sorts of paths (/usr to /usr/include/oracle/11.1.0.1/client64) with no luck. -- Edit this bug report at http://bugs.php.net/?id=44989&edit=1
#45794 [Bgs]: HTTP headers rendered differently in PHP than Apache rewrite mod likes them
ID: 45794 Updated by: [EMAIL PROTECTED] Reported By: tarag956 at gmail dot com Status: Bogus Bug Type: *Web Server problem Operating System: nix PHP Version: 5.2.6 New Comment: > Or are you claiming this is something PHP knows about and "won't fix"? Yes, this is known and expected. The X-Moz header or any header can be retrieved by making it upper case and by replacing "-" by "_". The advantage is that it allows only one representation of an header (X-Moz, X-MOZ or x-moz will all be available with HTTP_X_MOZ). Previous Comments: [2008-08-12 15:21:31] tarag956 at gmail dot com The form cut off the URL of the screenshot then made a link out of the decapitated URL. It needs to be all on one line to be viewed. [2008-08-12 15:20:27] tarag956 at gmail dot com Also your first paragraph was an obvious form letter, and your second paragraph was unrelated so I'm no even sure if you understood what I initially said. Also as for flagging bugs bogus, here's a screenshot unrelated to this bug report but related to falsely flagging bugs a bogus: http://images.encyclopediadramatica.com/images/c/c9/Why_PHP_remains_slow.png [2008-08-12 15:17:24] tarag956 at gmail dot com Those links you gave were worthless and unrelated to the issue. I've already read through the manual fully. Are you claiming that somewhere hidden PHP actually can get the same exact style of headers ad mod-rewrite? I have checked fully and there is no such thing. Or are you claiming this is something PHP knows about and "won't fix"? You never explicitly stated your reason for decaring the bug "bogus". [2008-08-12 13:32:22] [EMAIL PROTECTED] 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 HTTP headers and other variables follows the CGI specification: http://hoohoo.ncsa.uiuc.edu/cgi/env.html [2008-08-12 06:08:40] tarag956 at gmail dot com Description: HTTP headers rendered differently in PHP than Apache rewrite mod likes them For instance... PHP renders a header this way (from the $_SERVER associated array): HTTP_X_MOZ But apache rewrite mod likes it: HTTP:X-MOZ I couldn't find any previous reports on this. But basically, PHP needs some way for its HTTP headers to end up looking the same way that Apache's mod-rewrite likes them. Other examples... Apache likes them like: HTTP:X-FORWARDED-FOR REMOTE_ADDR HTTP:CLIENT-IP REQUEST_METHOD But PHP usually converts all "-" to "_" and converts all ":" to "_" and sometimes adds "HTTP_" in front of things. Maybe this is a feature request, but it would be nice if PHP's HTTP header variables could go be the exact names that HTTP's rewrite mod like them as. Reproduce code: --- .. Expected result: .. Actual result: -- .. -- Edit this bug report at http://bugs.php.net/?id=45794&edit=1
#44706 [Opn->Fbk]: Segfault after sending PayPal SOAP request
ID: 44706 Updated by: [EMAIL PROTECTED] Reported By: test1 at boxaroo dot com -Status: Open +Status: Feedback Bug Type: SOAP related Operating System: at least Linux and Mac PHP Version: 5.2.5 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi Previous Comments: [2008-05-26 08:39:38] jasper at flyingfish dot nl Hi, We are experiencing the same problem on PHP 5.2.6 on Gentoo. This is a real problem for us. Regards, Jasper [2008-04-12 00:52:09] test1 at boxaroo dot com Description: I get a segault when talking to PayPal via SOAP. It seems like the segfault happens AFTER the Soap call has happened, because I can usually dump the results to the screen just before the crash. This happens on a Mac system with PHP 5.2.4 and a Linux system with 5.2.5. I have tried 3 different ways of talking to PayPal; one using their SDK, one using straight SOAP code I wrote, and one using a SOAP wrapper library I found. All crash the same way. I use SOAP for tons of other things (eBay, for instance) without issues. Reproduce code: --- http://img1.boxaroo.com/images/php_soap_segv.txt And, BTW, you do *not* need to put in your PayPal info (I have mine replaced with '---'). It still crashes in the same way whether it accepts your creds or not. Expected result: Should just be a dump of the return; instead you should see the segfault. Actual result: -- Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x2a26b9e5 0x0028ef3e in zend_objects_store_del_ref_by_handle () (gdb) bt #0 0x0028ef3e in zend_objects_store_del_ref_by_handle () #1 0x0028f0b1 in zend_objects_store_del_ref () #2 0x00264ce7 in _zval_ptr_dtor () #3 0x0027bf90 in zend_hash_destroy () #4 0x0028bb22 in zend_object_std_dtor () #5 0x0028bb4a in zend_objects_free_object_storage () #6 0x0028f097 in zend_objects_store_del_ref_by_handle () #7 0x0028f0b1 in zend_objects_store_del_ref () #8 0x00264ce7 in _zval_ptr_dtor () #9 0x0027bf90 in zend_hash_destroy () #10 0x0028bb22 in zend_object_std_dtor () #11 0x0028bb4a in zend_objects_free_object_storage () #12 0x0028f097 in zend_objects_store_del_ref_by_handle () #13 0x0028f0b1 in zend_objects_store_del_ref () #14 0x00264ce7 in _zval_ptr_dtor () #15 0x0027c12a in zend_hash_apply_deleter () #16 0x0027c47c in zend_hash_reverse_apply () #17 0x00263fba in shutdown_destructors () #18 0x00272541 in zend_call_destructors () #19 0x0022dee3 in php_request_shutdown () #20 0x0030243a in main () -- Edit this bug report at http://bugs.php.net/?id=44706&edit=1
#31323 [Com]: session file permissions differ randomly
ID: 31323
Comment by: linus dot norton at assertis dot co dot uk
Reported By: julien dot mathieu at gmail dot com
Status: No Feedback
Bug Type: Session related
Operating System: Linux
PHP Version: 5.1.2, 4.3.9
New Comment:
I have also encountered this twice on redhat running apache 2.2.6 and
php 5.2.6.
Why has this been closed, no feedback was requested then the ticket is
just closed saying no feedback has been given.
Previous Comments:
[2006-11-09 14:44:35] mg at iceni dot pl
I can confirm this bug happening on php 4.4.2 build as apache 2 (with
prefork) module. It's extremaly difficult to reproduce, but with little
research it seems to be somehow umask related.
The following is from strace running on a apache process that creates
the files with wrong permissions
open("/tmp/sess_5b2929b94cf141335d0b2d1e5a38fc29", O_RDWR|O_CREAT,
0600) = 186
fstat64(186, {st_mode=S_IFREG|0400, st_size=0, ...}) = 0
So php creates file with 600 permissions but it has only 400 in final.
Note that's happening very rarely, normally file is created with 600.
I didn't have luck tracing how and when umask is changing during
request processing (probably something is changing it prior to the
request, so possibly it's not even php related), but I tried to make the
following very dirty workaround in ext/session/mod_files.c:
@@ -138,6 +138,7 @@
static void ps_files_open(ps_files *data, const char *key TSRMLS_DC)
{
char buf[MAXPATHLEN];
+ mode_t orig_mask;
if (data->fd < 0 || !data->lastkey || strcmp(key,
data->lastkey)) {
if (data->lastkey) {
@@ -156,8 +157,10 @@
data->lastkey = estrdup(key);
+ orig_mask = umask(0);
data->fd = VCWD_OPEN_MODE(buf, O_CREAT | O_RDWR |
O_BINARY, 0600);
-
+ umask(orig_mask);
+
No matter how ugly it is - it seems to do the job and session files
with wrong permissions are no longer created (this workaround is
probably bad idea on threaded severs though).
[2006-11-05 00:16:32] bclaydon at volved dot com
To provide further details, I am also using Debian (Sarge) with the
latest 4.3.10-16 PHP4 package.
My /var/liv/php4 looks exactly as 'pieter at q-go dot com' mentioned:
drwx-wx-wt 2 root root 4.0K 2006-11-04 18:58 ./
drwxr-xr-x 35 root root 4.0K 2006-09-08 19:11 ../
-rw--- 1 www-data www-data 77 2006-11-04 18:58
sess_7b8da94a2febce75775d9082cd20d58d
-rw--- 1 www-data www-data 116 2006-11-04 19:05
sess_856401c969cc1d4e68b6ffd75457c743
-rw--- 1 www-data www-data 116 2006-11-04 18:58
sess_b5419618a3586b7e3b940a0eaf137fb9
-rw--- 1 www-data www-data 116 2006-11-04 19:09
sess_f7d957b726ff923b4b1f6178f8db489f
I am seeing this issue fairly frequently during usage of CakePHP
framework which has fairly detailed usage of session functions.
I hope this is resolved at some point, especially if it is still open
as of 5.2.0
[2006-05-22 09:20:29] pieter at q-go dot com
We have similar problems on Debian with PHP 5.1.2 and 5.1.4.
Sessions are all created with correct permissions, but we get the same
permission denied error in 5% of the cases.
drwx-wx-wt 2 root root 4096 May 22 11:03 .
drwxr-xr-x 27 root root 4096 May 18 13:44 ..
-rw--- 1 www-data www-data0 May 22 11:03
sess_11f06ca5b4701f4be8be30b275e4e51e
-rw--- 1 www-data www-data 1569 May 22 11:00
sess_1856e3c4630f074a1b0490c4792c3e53
-rw--- 1 www-data www-data0 May 22 10:21
sess_d110fb48e440d1ec4ac610243e897c69
-rw--- 1 www-data www-data 1717 May 22 11:05
sess_f9668179e8a92714f4d9553504bdcd93
Changing the default Debian permissions on /var/lib/php5 from
drwx-wx-wt to drwxrwxrwt seems to help.
I am putting this here because if the two cases are related, the
problem might be more general.
[2006-03-28 13:15:10] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2006-03-21 19:02:31] jd at godaddy dot com
I should note that after we cleaned all of the sess_* files in /tmp,
the problem seems to have gone away (at least for the moment). Why are
future PHP session file permissions being corrupted by preexisting
session files? Is there possibly a buffer overflow possible in the
session
#27792 [Asn->Ctl]: Functions fail on large files (filesize,is_file,is_dir,readdir)
ID: 27792 Updated by: [EMAIL PROTECTED] Reported By: kode at kodekrash dot com -Status: Assigned +Status: Critical Bug Type: Filesystem function related Operating System: * (LFS) -PHP Version: 6CVS, *CVS +PHP Version: 5CVS, 6CVS (2008-08-11) Assigned To: wez Previous Comments: [2008-03-22 22:20:51] xpuctu4 at abv dot bg php -v PHP 5.2.3-1ubuntu6.3 (cli) (built: Jan 10 2008 09:38:41) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies I do not know if the ubuntu version have any patches but my PHP works fine. I created a large file with dd if=/dev/urandom and this is my results: // print_r($foo) Array ( [size] => 4805357568 // filesize() [isfile] => 1 // is_file() [isreadable] => 1 // is_readable() [islink] => //is_link() empty maybe because it is not link ) // Now I read 1st 32 bytes // fopen(), fread(), fseek($filesize - 32), fread(), fclose() // strlen($data) 1st read: 32 bytes 2nd read: 32 bytes [2008-03-15 21:59:15] sawo at war3z dot org Does anybody knows if this is fixed in 6.0 ? [2008-01-29 14:45:08] elevator at thebrainhotel dot com All indications are that this is *not* fixed in PHP 5.2.x, the one comment above notwithstanding. There's another conflicting comment re: PHP 5.2.x, and there's also a patch provided for PHP 5.3 -- if a patch is needed for PHP 5.3, it would certainly appear to *not* be fixed in PHP 5.2.x And then there's my personal experience with PHP 5.2.4 (from the Xampp distro for Windows), where I'm actually experiencing the problem when trying to use move_uploaded_file; likewise on 3 deployments of PHP 5.1.x I've tried [2008-01-18 12:01:27] radon8472 at hotmail dot com file_get_contents() has also Problems with files over 2 GB Border. Doea anybody know when there will be released an php version with lage File Support (4GB an larger) ? [2007-10-14 22:17:19] [EMAIL PROTECTED] You might like to try the following patch: http://news.php.net/php.internals/32767 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/27792 -- Edit this bug report at http://bugs.php.net/?id=27792&edit=1
#45801 [NEW]: PHPUnit testcase crashes (segfault)
From: jtaal at eljakim dot nl Operating system: Linux & Windows PHP version: 5.2.6 PHP Bug Type: Reproducible crash Bug description: PHPUnit testcase crashes (segfault) Description: I'm getting a segmentation fault when running a very simple PHPUnit testcase. I'm using the latest pear package from pear.phpunit.de. The testcase is issuing an E_STRICT. I think deep inside PHPUnit something happens that causes this to happen. However, since PHPUnit is "just" a bunch of PHP classes, I dare say this is a bug inside the PHP interpreter. I've been able to run and crash this on both Linux (debian lenny) and Windows XP SP3 (both using PHP 5.2.6). Reproduce code: --- getX(); } } Actual result: -- $ phpunit MyTest.php Strict Standards: Only variables should be assigned by reference in /home/jtaal/public_html/MyTest.php on line 18 PHPUnit 3.2.21 by Sebastian Bergmann. Segmentation fault -- Edit bug report at http://bugs.php.net/?id=45801&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45801&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45801&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45801&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45801&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45801&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45801&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45801&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45801&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45801&r=support Expected behavior:http://bugs.php.net/fix.php?id=45801&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45801&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45801&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45801&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45801&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45801&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45801&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45801&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45801&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45801&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45801&r=mysqlcfg
#39171 [Asn->Opn]: pdo_mysql configure script sets empty default socket
ID: 39171 Updated by: [EMAIL PROTECTED] Reported By: spam02 at pornel dot net -Status: Assigned +Status: Open -Bug Type: PDO related +Bug Type: MySQL related -Operating System: OS X +Operating System: * -PHP Version: 6CVS-2006-10-16 (snap) +PHP Version: 5CVS, 6CVS (2008-08-11) Assigned To: wez Previous Comments: [2006-10-16 20:37:42] spam02 at pornel dot net Sorry, I've given wrong bug # in my report. The orignal issue was that PDO fails with: "Can't connect to local MySQL server through socket '' (2)" [2006-10-16 20:31:26] spam02 at pornel dot net Description: I've ran onto problem described in bug #34988 I aknowledge that there is workaround by setting appropriate socket in DSN, however the root cause is that PHP defaults to socket='', which certainly won't work. If proper socket can't be found, it would be wiser to fall back to built-in default or fail configure script and require user to supply socket via something like --with-pdo-mysql-socket. Requirement to use unix_socket in DSN ties code with machine-dependent configuration and AFAIK it's not possible to find that PDO has empty string for default socket without connection attempt - that makes it imperfect workaround. -- Edit this bug report at http://bugs.php.net/?id=39171&edit=1
#39171 [Opn->Asn]: pdo_mysql configure script sets empty default socket
ID: 39171 Updated by: [EMAIL PROTECTED] Reported By: spam02 at pornel dot net -Status: Open +Status: Assigned Bug Type: MySQL related Operating System: * PHP Version: 5CVS, 6CVS (2008-08-11) -Assigned To: +Assigned To: andrey New Comment: Assigned to the maintainer. Previous Comments: [2006-10-16 20:37:42] spam02 at pornel dot net Sorry, I've given wrong bug # in my report. The orignal issue was that PDO fails with: "Can't connect to local MySQL server through socket '' (2)" [2006-10-16 20:31:26] spam02 at pornel dot net Description: I've ran onto problem described in bug #34988 I aknowledge that there is workaround by setting appropriate socket in DSN, however the root cause is that PHP defaults to socket='', which certainly won't work. If proper socket can't be found, it would be wiser to fall back to built-in default or fail configure script and require user to supply socket via something like --with-pdo-mysql-socket. Requirement to use unix_socket in DSN ties code with machine-dependent configuration and AFAIK it's not possible to find that PDO has empty string for default socket without connection attempt - that makes it imperfect workaround. -- Edit this bug report at http://bugs.php.net/?id=39171&edit=1
#39992 [Opn->Fbk]: proc_terminate() leaves children of child running
ID: 39992 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Program Execution Operating System: linux PHP Version: 6CVS-2006-12-30 (CVS) New Comment: Nuno, is this still valid bug? I can't reproduce it even with PHP 5.2.6.. Previous Comments: [2006-12-30 15:54:27] [EMAIL PROTECTED] Ah I forgot: removing the "2>&1" part everything works fine. [2006-12-30 15:52:20] [EMAIL PROTECTED] Description: With the short reproduce code below, PHP fork()s a new process (sh), that itself forks a new one (php). proc_terminate() kill()s the sh process, but the php one doesn't get killed. I'm not really sure what is causing this problem, but it is breaking run-tests.php on timeout. Reproduce code: --- &1'; $proc = proc_open($cmd, array(), $pipes); var_dump(proc_terminate($proc)); ?> -- Edit this bug report at http://bugs.php.net/?id=39992&edit=1
#42606 [Opn->Fbk]: unicode/constants.c relies on ICU draft api
ID: 42606 Updated by: [EMAIL PROTECTED] Reported By: spam02 at pornel dot net -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: OS X PHP Version: 6CVS-2007-09-09 (snap) New Comment: What ICU version this happens with? Previous Comments: [2007-09-09 19:33:37] spam02 at pornel dot net Description: Compile fails with: ext/unicode/constants.c: In function ‘php_register_property_constants’: ext/unicode/constants.c:81: error: ‘UCHAR_POSIX_ALNUM’ undeclared The definition of it is in ICU's uchar.h hidden in #ifndef U_HIDE_DRAFT_API Expected result: constants.c should check whether stable or draft ICU API is available or just not rely on these constants. If it couldn't possibly work without draft API, configure should fail instead. -- Edit this bug report at http://bugs.php.net/?id=42606&edit=1
#44923 [Opn]: ereg functions are not unicode aware: provide wrapper functions in PCRE
ID: 44923
Updated by: [EMAIL PROTECTED]
-Summary: ereg works differently in PHP 6.0 unicode.semantics=on
Reported By: tokul at users dot sourceforge dot net
Status: Open
-Bug Type: *Regular Expressions
+Bug Type: PCRE related
Operating System: Linux Debian Etch
PHP Version: 6CVS-2008-05-06 (snap)
New Comment:
For unicode aware regexps use PCRE. The old ereg stuff should be
provided as wrapper functions which uses PCRE underneath though.
Previous Comments:
[2008-05-06 12:06:03] [EMAIL PROTECTED]
This is expected, the code isn't prepared to works with unicode
strings.
Actually it only use REG_EXTENDED with binary strings, and convert the
unicode string to normal string.
[2008-05-06 03:59:56] tokul at users dot sourceforge dot net
Description:
expressions that work in older versions fail on PHP6
unicode.semantics=on
Compared 5.2-dev, 5.3-dev and 6.0-dev snapshots
Reproduce code:
---
$line = "* 469 EXISTS\r\n";
if (ereg("[^ ]+ +([^ ]+) +EXISTS", $line, $match)) {
var_dump($match[1]);
} else {
var_dump(false);
}
$line = "* 469 FETCH (UID 508 BODY[1]<0> {154}\r\n";
if (ereg('\\{([^\\}]*)\\}', $line, $match)) {
var_dump($match[1]);
} else {
var_dump(false);
}
Expected result:
string(3) "469"
string(3) "154"
Actual result:
--
bool(false)
Warning: ereg(): REG_BADRPT in
/home/tomas/testbeds/test/php60/bin/ereg.php on line 10
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=44923&edit=1
#45248 [Opn->Fbk]: Shfift_JIS encoded characters in PHP script cause an error.
ID: 45248 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Unicode Engine related Operating System: Windows Vista PHP Version: 6CVS-2008-06-12 (CVS) New Comment: See also bug #45087 (submitted twice..? :) Previous Comments: [2008-06-12 15:21:52] [EMAIL PROTECTED] Description: Shift_JIS encoded characters in PHP script cause an error. A tiny script causes the problem. It is based on php6/tests/unicode/enc-SJIS.phpt. For UTF-8 or EUC-JP encoded script, it works fine. Reproduce code: --- enc-SJIS.php enc-SJIS.inc Expected result: тест - ok Actual result: -- Warning: Illegal or truncated character in input: offset 0, state=0 in C:\php6\enc-SJIS.inc on line 2 Parse error: syntax error, unexpected $end, expecting T_STRING in C:\php6\enc-SJIS.inc on line 2 -- Edit this bug report at http://bugs.php.net/?id=45248&edit=1
#45779 [Asn->Csd]: regression with shebang lines processing
ID: 45779 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: Scripting Engine problem Operating System: Windows PHP Version: 5.3CVS-2008-08-10 Assigned To: dmitry New Comment: 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. Previous Comments: [2008-08-12 14:26:50] [EMAIL PROTECTED] Dmitry, please check this out. [2008-08-10 14:31:08] [EMAIL PROTECTED] Description: tests\lang\comments.php fails. There is a regression between 5.2.x and 5.3 on how the shebang line is processed. 5.2.x ignores only the first line, 5.3.x ignores the first two lines. Reproduce code: --- See tests\lang\comments.php -- Edit this bug report at http://bugs.php.net/?id=45779&edit=1
#32220 [Asn->Fbk]: [PATCH] thread_resources for thread not getting freed when apache kills thread
ID: 32220 Updated by: [EMAIL PROTECTED] Reported By: kameshj at fastmail dot fm -Status: Assigned +Status: Feedback Bug Type: Apache2 related Operating System: * PHP Version: 5CVS, 4CVS (2005-03-25) Assigned To: dmitry New Comment: The patch is no longer available..? Previous Comments: [2005-12-05 09:03:14] kameshj at fastmail dot fm Yes you are correct that only IIS sapi is making use of ts_free_thread. But If you look at my patch you can see that I am registering this ts_free_thread function to pthread_push_cleanup to make sure the pthread subsystem to do the cleanup for us as soon as the thread is getting killed not to wait for the main thread to free the full thread_resources. [2005-12-01 15:51:41] [EMAIL PROTECTED] I confirm that PHP doesn't call ts_free_thread() if Web Server (except IIS) kills some thread. As a result all thread resources are not freed before server shutdown. The proposed patch is invalid and even cannot be compiled on Linux. [2005-11-10 18:36:39] [EMAIL PROTECTED] Yes, but did you check out the patch..? [2005-11-08 09:50:11] [EMAIL PROTECTED] I am not able to reproduce this. Seems like a mess in report. Apache2 worker MPM doesn't support StartThreads and MaxThreads directives. [2005-03-07 15:06:48] kameshj at fastmail dot fm Description: Run apache2 in a worker thread model with the following settings StartThreads 3 MaxSpareThreads 4 MaxThreads 10 Loadtests on a very simple php scripts like the one that calls phpinfo() at regular intervals of 5 minutes causes a memory leak(Not really a leak but huge unused memory that gets freed at tsrm_shutdown) This causes the memory consumed by the apache2 procsss to shoot up. ---Investigation Apache2 to handle the concurrent requests increases the number of child threads to max of MaxThreads when no more request to server it kills the threads till the number of threads comes to MaxSpareThreads. In the case of setting given above after the load test of 10 simultaneous requests, Apache kills 6 threads (As MaxThreads-MaxSpareThreads = 10-4 = 6). The thread_resources momory associated with these 6 threads still not freed as soon as the corresponding thread is killed. These kind of spurt loads at regular intervals causes lots of such thread_resources memory to get accumulated not being used for any real purpose. Only when the sapi module comes down it calls tsrm_shutdown then these thread_resources are getting freed. Attaching the patch to fix the issue is available at http://puggy.symonds.net/~kameshj/TSRM.c.patch This patch has a few clean up to existing ts_free_thread. This patch registers ts_free_thread as thread cleanup routine. Reproduce code: --- Run apache2 in a worker thread model with the following settings StartThreads 3 MaxSpareThreads 4 MaxThreads 10 write a simple test.php Run a load test with ab ab -n 40 -c 10 Wait for 5 minutes ab -n 40 -c 10 Wait for 5 minutes ab -n 40 -c 10 Wait for 5 minutes ab -n 40 -c 10 Expected result: In the case of setting given above after the load test of 10 simultaneous requests, Apache kills 6 threads (As MaxThreads-MaxSpareThreads = 10-4 = 6). The thread_resources momory associated with these 6 threads still not freed as soon as the corresponding thread is killed. These kind of spurt loads at regular intervals causes lots of such thread_resources memory to get accumulated not being used for any real purpose. Only when the sapi module comes down it calls tsrm_shutdown then these thread_resources are getting freed. Actual result: -- thread_resources of a thread that gets killed should get freed as soon as it dies rather than waiting till the tsrm_shutdown -- Edit this bug report at http://bugs.php.net/?id=32220&edit=1
#44271 [Fbk->Opn]: open_basedir resolves links on link-specific operations
ID: 44271 User updated by: tautolog at gmail dot com Reported By: tautolog at gmail dot com -Status: Feedback +Status: Open Bug Type: Safe Mode/open_basedir Operating System: DragonFly BSD PHP Version: 5.2.5 Assigned To: fb-req-jani New Comment: Hi, Thank you for your time and attention on this issue. I tested all of the functions at issue using the snapshot build php5.3-200808121630. I get the same result as before: the same warning, and it returns failure. Should I try again at a later date? Would you like me to take a shot at fixing it? I recognize that it is in a fairly sensitive area of the code, and you might rather just do it yourself, or not bother with changes there. I am not bothered about backporting. The workaround for my case was simple enough, and I am now at a different job that doesn't involve PHP. Thanks, Ben Previous Comments: [2008-08-12 08:58:22] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz There are some fixes done in PHP_5_3 which most likely fix this problem. Note: Those fixes will NOT be backported to 5.2 branch! [2008-02-27 20:17:16] tautolog at gmail dot com Description: This is not a security issue. It is just a functionality issue. open_basedir resolves links on link-specific operations, getting in the way of expected behavior. I don't think that the ability to read a link target (the target itself, not the file the target resolves to) within the basedir is a security concern because it is no different than the ability to read a config file which refers to a file outside of the basedir. In my thinking about this issue, I am viewing a symbolic link as just an alternate way to associate data with a file that just happens to have common support for treating the data as a target. See my reproduce code. Clearly, "/tmp/testlink" is in the allowed path of "home/ben/public_html:/tmp", but since it resolves to "/test", it is not being allowed. The following system calls (and therefore PHP functions) do not follow symlinks, according to symlink(7) on my BSD system: lchown() lstat() readlink() rename() rmdir() unlink() remove() (just an alias to unlink which is not in PHP) I tested all of them. All of them have this issue. rmdir() is an odd one. According to the manual, if you use it on a symbolic link, it should return ENOTDIR. $ mkdir /tmp/link_target $ ln -s /tmp/link_target /tmp/testlink $ rmdir /tmp/testlink rmdir: /tmp/testlink: Not a directory I have been using symbolic links to back a fast, simple, global, atomic, persistent hash, where the link filename is the key and the link value is the value. I have been running the application with open_basedir set to try to find compatibility problems with it, and found this issue. To work around it, I prefix all values with "./" now. However, there are other cases that cannot be worked around. For example, a php file manager would not even be able to tell whether the file were a link, let alone read its value or delete it. I have some interest in working on a patch. If you agree that it is desirable for open_basedir to not resolve links in some cases, I may be able to provide a patch. Just in case, I also tested the case where a link is outside open_basedir, but it resolves within open_basedir, and it blocked that, which I agree should be the expected behavior. Reproduce code: --- Add /tmp to open_basedir $ ln -s /test /tmp/testlink Expected result: 1 Actual result: -- Warning: is_link(): open_basedir restriction in effect. File(/tmp/testlink) is not within the allowed path(s): (/home/ben/public_html:/tmp) in /home/ben/public_html/cvs/app-modernbill-admin/include/lib-action/migrate/- on line 1 -- Edit this bug report at http://bugs.php.net/?id=44271&edit=1
#45802 [NEW]: Funny behaviour AddHandler
From: cees at connectcase dot nl
Operating system: Linux
PHP version: 5.2CVS-2008-08-12 (CVS)
PHP Bug Type: *Configuration Issues
Bug description: Funny behaviour AddHandler
Description:
Adding the following to your .htaccess file:
"AddHandler application/x-httpd-php .php"
parses all php files correctly regarding "slash-involved" functions like
addslashes, mysql_real_escape_string etc.:
addslashes("O'Brien") results in "O\'Brien" (as it should be?)
Adding the 5 to the PHP handler to your .htaccess file :
"AddHandler application/x-httpd-php5 .htm .html .php"
results in 2 extra slashes.
addslashes("O'Brien") results in "O\\\'Brien".
I have searched for bugreports AND all over the Internet for an
explanation (or at least someone who experienced the same). No such luck.
--
Edit bug report at http://bugs.php.net/?id=45802&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45802&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45802&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45802&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45802&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45802&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45802&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45802&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45802&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45802&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45802&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45802&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45802&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45802&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45802&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45802&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45802&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45802&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45802&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45802&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45802&r=mysqlcfg
#45802 [Opn->Bgs]: Funny behaviour AddHandler
ID: 45802
Updated by: [EMAIL PROTECTED]
Reported By: cees at connectcase dot nl
-Status: Open
+Status: Bogus
Bug Type: *Configuration Issues
Operating System: Linux
PHP Version: 5.2CVS-2008-08-12 (CVS)
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
look for magic_quotes_gpc
Previous Comments:
[2008-08-12 19:30:32] cees at connectcase dot nl
Description:
Adding the following to your .htaccess file:
"AddHandler application/x-httpd-php .php"
parses all php files correctly regarding "slash-involved" functions
like addslashes, mysql_real_escape_string etc.:
addslashes("O'Brien") results in "O\'Brien" (as it should be?)
Adding the 5 to the PHP handler to your .htaccess file :
"AddHandler application/x-httpd-php5 .htm .html .php"
results in 2 extra slashes.
addslashes("O'Brien") results in "O\\\'Brien".
I have searched for bugreports AND all over the Internet for an
explanation (or at least someone who experienced the same). No such
luck.
--
Edit this bug report at http://bugs.php.net/?id=45802&edit=1
#45114 [Opn->Asn]: Option to change --with-config-file-scan-dir runtime
ID: 45114 Updated by: [EMAIL PROTECTED] Reported By: jani dot ollikainen at pronetko dot fi -Status: Open +Status: Assigned Bug Type: Feature/Change Request Operating System: Linux PHP Version: 5.2.6 -Assigned To: +Assigned To: jani New Comment: Quite closely related to bug #42604 which kinda requires such option/env/something to exist to be fixable. Previous Comments: [2008-05-28 08:37:39] jani dot ollikainen at pronetko dot fi Description: There should be option to change it runtime. Possible ways are: - Command line parameter - php.ini directive (there's many ways to change php.ini's location) - Enviromental variable. Pick your poison as long as there is a way. Reason why this is needed is: Think about situation that's default in most distros, extension loading is done with that setting. Then you want to make a CLI program that makes a lot of fork() and you want keep it's memory footprint to be as low as possible. You cannot with acceptable way to change cli program not loading those extensions from scan dir. Just edit the files in scan dir? They are needed for normal WWW php operation. Just make two different php.ini's that have the extensions? And that will break distros extension loading style. Just use the -n and put all the settings in file with ini_set() and dl() functions? Uhoh, Not nice. And there seems to be patches around the net for this problem, but nothing in PHP itself. http://alt.linux.kiev.ua/srpm/php/patches/20 http://www.opendogs.org/pub/php-5_2_3-config-file-scan-dir.patch http://pronetko.fi/~bestis/php-5.1.6-scandir.patch (my env version) Expected result: There should be a way to change it runtime. Actual result: -- No way to change it runtime. It can only be disabled with -n parameter but then there's no php.ini. -- Edit this bug report at http://bugs.php.net/?id=45114&edit=1
#45786 [Fbk->Opn]: FastCGI process exited unexpectedly
ID: 45786 User updated by: karelevzen at gmail dot com Reported By: karelevzen at gmail dot com -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Windows Vista Ultimate x64 SP1 PHP Version: 5.3CVS-2008-08-10 (CVS) Assigned To: fb-req-jani New Comment: It tells me that it was not able to locate debug symbols, so I hope you find everything you need in this report. (I run it twice with the same results.) Entry point php_cgi+5ed6 Create time 12.8.2008 22:45:19 Time spent in user mode 0 Days 0:0:0.15 Time spent in kernel mode 0 Days 0:0:0.31 Function Arg 1 Arg 2 Arg 3 Source php_cgi+5604 01452638 00c0ddcc php5ts!zend_hash_destroy+27 PHP_CGI+5604WARNING - DebugDiag was not able to locate debug symbols for php-cgi.exe, so the information below may be incomplete. In php-cgi__PID__5468__Date__08_12_2008__Time_10_45_29PM__791__Second_Chance_Exception_C005.dmp the assembly instruction at php_cgi+5604 in C:\Program Files (x86)\php\php-cgi.exe from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x on thread 0 Previous Comments: [2008-08-12 14:46:42] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2008-08-12 14:41:54] karelevzen at gmail dot com I am not loading any extensions. It's a fresh install with recommended php.ini and only these changes: cgi.force_redirect = 0 cgi.fix_pathinfo=1 fastcgi.impersonate = 1 and correct extension_dir As I said, I've got all the extensions commented out. [2008-08-12 14:26:13] [EMAIL PROTECTED] You're propably loading some shared extensions in your php.ini? Disable all of them and try again. Then enable them one by one to find out the error causing one. Then check that the extension in question isn't compiled in the PHP core binary. (php -m output!) [2008-08-11 16:49:18] karelevzen at gmail dot com may be related to bug 45630 [2008-08-11 13:48:32] karelevzen at gmail dot com Description: When you run PHP as a FastCGI module under IIS 7.0 (Windows Vista Ultimate x64) you get an error "FastCGI process exited unexpectedly" every time you visit a PHP page. The page contents loads OK, but after a second or so you get this error (a GUI message). Until you receive the message, the browser seems to be loading something (this could mean that the request wasn't handled well). Also, I've noticed that I have Configuration File (php.ini) set to C:\Windows, while the file is correctly loaded from C:\bin32\php\php.ini Everything works OK with the 2.5.6 nts build. Reproduce code: --- Expected result: No error message. Actual result: -- Faulting module name: php-cgi.exe Exception code: c005 Exception offset: 5604 -- Edit this bug report at http://bugs.php.net/?id=45786&edit=1
#39992 [Fbk->Opn]: proc_terminate() leaves children of child running
ID: 39992 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Program Execution Operating System: linux PHP Version: 6CVS-2006-12-30 (CVS) New Comment: Yes, I'm still able to reproduce it. In some systems you may need higher proviledges in order to reproduce this bug. Previous Comments: [2008-08-12 16:28:58] [EMAIL PROTECTED] Nuno, is this still valid bug? I can't reproduce it even with PHP 5.2.6.. [2006-12-30 15:54:27] [EMAIL PROTECTED] Ah I forgot: removing the "2>&1" part everything works fine. [2006-12-30 15:52:20] [EMAIL PROTECTED] Description: With the short reproduce code below, PHP fork()s a new process (sh), that itself forks a new one (php). proc_terminate() kill()s the sh process, but the php one doesn't get killed. I'm not really sure what is causing this problem, but it is breaking run-tests.php on timeout. Reproduce code: --- &1'; $proc = proc_open($cmd, array(), $pipes); var_dump(proc_terminate($proc)); ?> -- Edit this bug report at http://bugs.php.net/?id=39992&edit=1
#45802 [Bgs]: Funny behaviour AddHandler
ID: 45802
User updated by: cees at connectcase dot nl
Reported By: cees at connectcase dot nl
Status: Bogus
Bug Type: *Configuration Issues
Operating System: Linux
PHP Version: 5.2CVS-2008-08-12 (CVS)
New Comment:
Johannes,
magic quotes are OFF in both cases (no way of changing that: shared
hosting). Believe me, I have consulted the manual and the section on
magic_quotes_gpc. Could not find any connection with the AddHandler.
In other words, this behaviour is by default and not a bug?
Previous Comments:
[2008-08-12 19:42:53] [EMAIL PROTECTED]
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
look for magic_quotes_gpc
[2008-08-12 19:30:32] cees at connectcase dot nl
Description:
Adding the following to your .htaccess file:
"AddHandler application/x-httpd-php .php"
parses all php files correctly regarding "slash-involved" functions
like addslashes, mysql_real_escape_string etc.:
addslashes("O'Brien") results in "O\'Brien" (as it should be?)
Adding the 5 to the PHP handler to your .htaccess file :
"AddHandler application/x-httpd-php5 .htm .html .php"
results in 2 extra slashes.
addslashes("O'Brien") results in "O\\\'Brien".
I have searched for bugreports AND all over the Internet for an
explanation (or at least someone who experienced the same). No such
luck.
--
Edit this bug report at http://bugs.php.net/?id=45802&edit=1
#45084 [Fbk->Opn]: SoapServer Don't Work at Windows Vista
ID: 45084
User updated by: neumann at ntech dot com dot br
Reported By: neumann at ntech dot com dot br
-Status: Feedback
+Status: Open
Bug Type: SOAP related
Operating System: Windows Vista
PHP Version: 5.2.6
New Comment:
the error returned is: PHP Fatal error: Maximum execution time of 30
seconds exceeded in C:\\wwwroot\\soap\\HelloClient.php The error
don't occurs with the same script running at XP or Linux. I turn off the
firewall, was increased the PHP parameter 'max_execution_time' but
allways return the same error.
Previous Comments:
[2008-06-02 12:08:32] albert at insad dot nl
Did you check your firewall rules?
To me it looks like Vista is blocking you :)
[2008-06-02 06:42:35] [EMAIL PROTECTED]
Have you checked your error log for any errors? When I try to run the
reproduce script I get a maximum execution error, I've seen on some
setups that PHP errors mixed with output buffering may cause HTTP 500
errors.
[02-Jun-2008 08:37:56] PHP Fatal error: Maximum execution time of 30
seconds exceeded in C:\webserver\www\HelloClient.php on line 9
[2008-05-24 00:59:42] neumann at ntech dot com dot br
Description:
If I execute HelloClient.php with the HelloServer.php at windows vista,
don't work(error 500). If I Copy the same HelloServer.php to another
server, and execute the same HelloClient.php at Windows Vista, it work
well...
PS:. Remember to change the param location in HelloClient.php, point it
to the HelloServer.php location URL.
Reproduce code:
---
"http://localhost/soap/HelloServer.php";,
'uri' => "http://localhost/";,
'trace'=> 1 ));
$return = $client->__soapCall("hello",array("world"));
echo $return;
?>
*
"http://localhost/";));
$server->addFunction("hello");
$server->handle();
?>
Expected result:
display the text: Hello world!
Actual result:
--
http server error 500
--
Edit this bug report at http://bugs.php.net/?id=45084&edit=1
#44994 [Com]: exec() produces zombie processes on Windows, hangs Apache
ID: 44994
Comment by: jkflash at gmail dot com
Reported By: dbarrett at vistaprint dot com
Status: Assigned
Bug Type: Program Execution
Operating System: Windows 2003 Server, 64-bit
PHP Version: 5.2.6
Assigned To: pajoye
New Comment:
I am experiencing this same problem with PHP 5.2.1 running on IIS as an
ISAPI module on Windows Server 2003 R2 SP2. Intermitently (a handful of
times in a hundred) a process started with exec() will appear to
complete ok but remain running in a zombie state. The IIS worker process
that created the process will not respond to any further requests. I
need to either open a new client browser or kill the worker process.
I get the same result with system, passthru, p_open and proc_open.
Previous Comments:
[2008-07-29 15:03:40] nobody at dontsendmespam dot com
i can reproduce this problem on a debian server with apache2 and
php5.2.6 running as fcgi
[2008-07-23 02:02:29] efesar at gmail dot com
I just upgraded from PHP 5.1.2 to 5.2.6, and this exact problem happens
to me. The exec and shell_exec used to work, and now they don't. They
hang the php process, and every subsequent call to exec produces a lost
cmd.exe ...
Incidentally passthru() causes the same behavior.
Maybe it has something to do with the rotatelogs.exe ... somebody
earlier mentioned that it was waiting on c:\Apache2\logs\error.log ...
So, basically, we can't run any system calls whatsoever via PHP. I
don't want to use a COM object, because I like portable code ... but
that might be the best step until this bug is fixed.
[2008-07-07 18:57:12] stephen dot cuppett at sas dot com
I am also experiencing this problem. I have been able to recreate it
with system() as well as proc_open(). With proc_open() it doesn't seem
to matter if I set bypass_shell or not, just determines whether I have a
dangling cmd.exe process or not...
cmd.exe seems to stop at Wait:UserReq, but that probably doesn't mean
much.
I am able to reproduce it with XAMPP 1.6.6a (PHP 5.2.5) on Windows XP
or Windows Server 2003 (32-bit).
I don't have much to add in terms of documentation as I don't get
anything in the httpd logs, but using the following code snippet:
protected function runSAS($filename) {
$this->log("Requested to run SAS file:
" . $filename, LOG_DEBUG);
$toRun = "\"" . SAS . "\"";
$toRun .= " -sysin '" . $filename .
"'";
$toRun .= " -CONFIG '" . SASV9CFG .
"'";
$toRun .= " -PRINT '" . TEMP_DIR . "/"
. basename($filename) . ".lst'";
$toRun .= " -LOG '" . TEMP_DIR . "/" .
basename($filename) . ".log'";
$toRun .= " -NOSPLASH";
$this->log("SAS command to run: " .
$toRun, LOG_DEBUG);
$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("pipe", "w")
// stderr is a file to write to
);
$res = proc_open($toRun,
$descriptorspec, $pipes, null, null, array(/*"bypass_shell" =>
true*/));
if (is_resource($res)) {
//fwrite($pipes[0],
"exit\n");
//fflush($pipes[0]);
fclose($pipes[0]);
fclose($pipes[1]);
fclose($pipes[2]);
$return_value =
proc_close($res);
$this->log("Return
value from SAS: " . $return_value, LOG_DEBUG);
}
}
When it does seem to complete, I'll get this in my log:
2008-06-26 20:23:55 Debug: Return value from SAS: 1
Nothing should come out on the pipes at all and when I set it up to
read those and it completes, there is no data read. However, in a hang
case, PHP blocks reading STDOUT instead of on proc_close never getting
any data... even if I set the stream to be non-blocki
#42604 [Asn->Csd]: "make test" fails with --with-config-file-scan-dir=/some/path
ID: 42604 Updated by: [EMAIL PROTECTED] Reported By: list at jth dot net -Status: Assigned +Status: Closed Bug Type: Compile Failure Operating System: Linux Fedora 64 bit PHP Version: 5.2.6 Assigned To: jani New Comment: 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. Previous Comments: [2007-09-09 17:51:53] list at jth dot net Description: The new feature of adding $(PHP_TEST_SHARED_EXTENSIONS) breaks "make test", when upgrading from an existing installation (in this case 5.2.3), where all the ini-files contain the modules included. In Makefile: CC="$(CC)" \ $(top_builddir)/$(SAPI_CLI_PATH) $(PHP_TEST_SETTINGS) $(top_srcdir)/run-tests.php -c $(top_builddir)/tmp-php.ini -U -d extension_dir=$(top_builddir)/modules/ $(PHP_TEST_SHARED_EXTENSIONS) $(TESTS); \ Reproduce code: --- make test Expected result: No 'already loaded' messages and PASSed tests Actual result: -- Extract: .. Warning: Module 'xsl' already loaded in Unknown on line 0 Warning: Module 'zip' already loaded in Unknown on line 0 = CWD : /usr/src/other/php/php-5.2.4 PHP : /usr/src/other/php/php-5.2.4/sapi/cli/php PHP_SAPI: cli PHP_VERSION : 5.2.4 ZEND_VERSION: 2.2.0 PHP_OS : Linux - Linux vennely.jth.net 2.6.20-1-2933-FC6j #1 SMP Sun Mar 25 01:54:58 CET 2007 x86_64 INI actual : /usr/src/other/php/php-5.2.4/tmp-php.ini More .INIs : /etc/php.d/bcmath.ini,/etc/php.d/dba.ini,/etc/php.d/dom.ini,/etc/php.d/ftp.ini,/etc/php.d/gd.ini,/etc/php.d/imap.ini,/etc/php.d/ldap.ini,/etc/php.d/mbstring.ini,/etc/php.d/mysql.ini,/etc/php.d/mysqli.ini,/etc/php.d/ncurses.ini,/etc/php.d/soap.ini,/etc/php.d/xmlreader.ini,/etc/php.d/xmlrpc.ini,/etc/php.d/xmlwriter.ini,/etc/php.d/xsl.ini,/etc/php.d/zip.ini Extra dirs : = TIME START 2007-09-09 19:48:23 = FAIL EXPECT [tests/run-test/test001.phpt] FAIL EXPECTF [tests/run-test/test002.phpt] FAIL EXPECTREGEX [tests/run-test/test003.phpt] FAIL INI section allows '=' [tests/run-test/test004.phpt] -- Edit this bug report at http://bugs.php.net/?id=42604&edit=1
#45114 [Csd]: Option to change --with-config-file-scan-dir runtime
ID: 45114 Updated by: [EMAIL PROTECTED] Reported By: jani dot ollikainen at pronetko dot fi Status: Closed Bug Type: Feature/Change Request Operating System: Linux PHP Version: 5.2.6 Assigned To: jani New Comment: I added 2 ways to do this. Now you can either use both -n and -c in command line options (-n disables every ini loading, -c enables loading the specified file / from specified path) or set PHP_INI_SCAN_DIR environment variable to empty (disables scanning) or to point to some other directory. Previous Comments: [2008-08-13 01:01:41] [EMAIL PROTECTED] 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. [2008-08-12 20:04:33] [EMAIL PROTECTED] Quite closely related to bug #42604 which kinda requires such option/env/something to exist to be fixable. [2008-05-28 08:37:39] jani dot ollikainen at pronetko dot fi Description: There should be option to change it runtime. Possible ways are: - Command line parameter - php.ini directive (there's many ways to change php.ini's location) - Enviromental variable. Pick your poison as long as there is a way. Reason why this is needed is: Think about situation that's default in most distros, extension loading is done with that setting. Then you want to make a CLI program that makes a lot of fork() and you want keep it's memory footprint to be as low as possible. You cannot with acceptable way to change cli program not loading those extensions from scan dir. Just edit the files in scan dir? They are needed for normal WWW php operation. Just make two different php.ini's that have the extensions? And that will break distros extension loading style. Just use the -n and put all the settings in file with ini_set() and dl() functions? Uhoh, Not nice. And there seems to be patches around the net for this problem, but nothing in PHP itself. http://alt.linux.kiev.ua/srpm/php/patches/20 http://www.opendogs.org/pub/php-5_2_3-config-file-scan-dir.patch http://pronetko.fi/~bestis/php-5.1.6-scandir.patch (my env version) Expected result: There should be a way to change it runtime. Actual result: -- No way to change it runtime. It can only be disabled with -n parameter but then there's no php.ini. -- Edit this bug report at http://bugs.php.net/?id=45114&edit=1
#44994 [Com]: exec() produces zombie processes on Windows, hangs Apache
ID: 44994
Comment by: jkflash at gmail dot com
Reported By: dbarrett at vistaprint dot com
Status: Assigned
Bug Type: Program Execution
Operating System: Windows 2003 Server, 64-bit
PHP Version: 5.2.6
Assigned To: pajoye
New Comment:
PS: shell_exec() DOES seem to work without hanging on my setup, but
none of the others.
Previous Comments:
[2008-08-12 23:50:58] jkflash at gmail dot com
I am experiencing this same problem with PHP 5.2.1 running on IIS as an
ISAPI module on Windows Server 2003 R2 SP2. Intermitently (a handful of
times in a hundred) a process started with exec() will appear to
complete ok but remain running in a zombie state. The IIS worker process
that created the process will not respond to any further requests. I
need to either open a new client browser or kill the worker process.
I get the same result with system, passthru, p_open and proc_open.
[2008-07-29 15:03:40] nobody at dontsendmespam dot com
i can reproduce this problem on a debian server with apache2 and
php5.2.6 running as fcgi
[2008-07-23 02:02:29] efesar at gmail dot com
I just upgraded from PHP 5.1.2 to 5.2.6, and this exact problem happens
to me. The exec and shell_exec used to work, and now they don't. They
hang the php process, and every subsequent call to exec produces a lost
cmd.exe ...
Incidentally passthru() causes the same behavior.
Maybe it has something to do with the rotatelogs.exe ... somebody
earlier mentioned that it was waiting on c:\Apache2\logs\error.log ...
So, basically, we can't run any system calls whatsoever via PHP. I
don't want to use a COM object, because I like portable code ... but
that might be the best step until this bug is fixed.
[2008-07-07 18:57:12] stephen dot cuppett at sas dot com
I am also experiencing this problem. I have been able to recreate it
with system() as well as proc_open(). With proc_open() it doesn't seem
to matter if I set bypass_shell or not, just determines whether I have a
dangling cmd.exe process or not...
cmd.exe seems to stop at Wait:UserReq, but that probably doesn't mean
much.
I am able to reproduce it with XAMPP 1.6.6a (PHP 5.2.5) on Windows XP
or Windows Server 2003 (32-bit).
I don't have much to add in terms of documentation as I don't get
anything in the httpd logs, but using the following code snippet:
protected function runSAS($filename) {
$this->log("Requested to run SAS file:
" . $filename, LOG_DEBUG);
$toRun = "\"" . SAS . "\"";
$toRun .= " -sysin '" . $filename .
"'";
$toRun .= " -CONFIG '" . SASV9CFG .
"'";
$toRun .= " -PRINT '" . TEMP_DIR . "/"
. basename($filename) . ".lst'";
$toRun .= " -LOG '" . TEMP_DIR . "/" .
basename($filename) . ".log'";
$toRun .= " -NOSPLASH";
$this->log("SAS command to run: " .
$toRun, LOG_DEBUG);
$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("pipe", "w")
// stderr is a file to write to
);
$res = proc_open($toRun,
$descriptorspec, $pipes, null, null, array(/*"bypass_shell" =>
true*/));
if (is_resource($res)) {
//fwrite($pipes[0],
"exit\n");
//fflush($pipes[0]);
fclose($pipes[0]);
fclose($pipes[1]);
fclose($pipes[2]);
$return_value =
proc_close($res);
$this->log("Return
value from SAS: " . $return_value, LOG_DEBUG);
}
}
When it does seem to complete, I'll get this in my log:
2008-06-26 20:23:55 Debug: Return value from SAS: 1
Nothing should come out on the pipes at all and when
#45801 [Opn->Fbk]: PHPUnit testcase crashes (segfault)
ID: 45801 Updated by: [EMAIL PROTECTED] Reported By: jtaal at eljakim dot nl -Status: Open +Status: Feedback Bug Type: Reproducible crash -Operating System: Linux & Windows +Operating System: * PHP Version: 5.2.6 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi Previous Comments: [2008-08-12 16:22:27] jtaal at eljakim dot nl Description: I'm getting a segmentation fault when running a very simple PHPUnit testcase. I'm using the latest pear package from pear.phpunit.de. The testcase is issuing an E_STRICT. I think deep inside PHPUnit something happens that causes this to happen. However, since PHPUnit is "just" a bunch of PHP classes, I dare say this is a bug inside the PHP interpreter. I've been able to run and crash this on both Linux (debian lenny) and Windows XP SP3 (both using PHP 5.2.6). Reproduce code: --- getX(); } } Actual result: -- $ phpunit MyTest.php Strict Standards: Only variables should be assigned by reference in /home/jtaal/public_html/MyTest.php on line 18 PHPUnit 3.2.21 by Sebastian Bergmann. Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=45801&edit=1
#45786 [Opn->Fbk]: FastCGI process exited unexpectedly
ID: 45786 Updated by: [EMAIL PROTECTED] Reported By: karelevzen at gmail dot com -Status: Open +Status: Feedback Bug Type: CGI related Operating System: Windows Vista Ultimate x64 SP1 PHP Version: 5.3CVS-2008-08-10 (CVS) Assigned To: fb-req-jani New Comment: Well, you propably should install the debug symbols then? They can be found at same place as the snapshots.. Previous Comments: [2008-08-12 20:51:42] karelevzen at gmail dot com It tells me that it was not able to locate debug symbols, so I hope you find everything you need in this report. (I run it twice with the same results.) Entry point php_cgi+5ed6 Create time 12.8.2008 22:45:19 Time spent in user mode 0 Days 0:0:0.15 Time spent in kernel mode 0 Days 0:0:0.31 Function Arg 1 Arg 2 Arg 3 Source php_cgi+5604 01452638 00c0ddcc php5ts!zend_hash_destroy+27 PHP_CGI+5604WARNING - DebugDiag was not able to locate debug symbols for php-cgi.exe, so the information below may be incomplete. In php-cgi__PID__5468__Date__08_12_2008__Time_10_45_29PM__791__Second_Chance_Exception_C005.dmp the assembly instruction at php_cgi+5604 in C:\Program Files (x86)\php\php-cgi.exe from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x on thread 0 [2008-08-12 14:46:42] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2008-08-12 14:41:54] karelevzen at gmail dot com I am not loading any extensions. It's a fresh install with recommended php.ini and only these changes: cgi.force_redirect = 0 cgi.fix_pathinfo=1 fastcgi.impersonate = 1 and correct extension_dir As I said, I've got all the extensions commented out. [2008-08-12 14:26:13] [EMAIL PROTECTED] You're propably loading some shared extensions in your php.ini? Disable all of them and try again. Then enable them one by one to find out the error causing one. Then check that the extension in question isn't compiled in the PHP core binary. (php -m output!) [2008-08-11 16:49:18] karelevzen at gmail dot com may be related to bug 45630 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/45786 -- Edit this bug report at http://bugs.php.net/?id=45786&edit=1
#45114 [Asn->Csd]: Option to change --with-config-file-scan-dir runtime
ID: 45114 Updated by: [EMAIL PROTECTED] Reported By: jani dot ollikainen at pronetko dot fi -Status: Assigned +Status: Closed Bug Type: Feature/Change Request Operating System: Linux PHP Version: 5.2.6 Assigned To: jani New Comment: 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. Previous Comments: [2008-08-12 20:04:33] [EMAIL PROTECTED] Quite closely related to bug #42604 which kinda requires such option/env/something to exist to be fixable. [2008-05-28 08:37:39] jani dot ollikainen at pronetko dot fi Description: There should be option to change it runtime. Possible ways are: - Command line parameter - php.ini directive (there's many ways to change php.ini's location) - Enviromental variable. Pick your poison as long as there is a way. Reason why this is needed is: Think about situation that's default in most distros, extension loading is done with that setting. Then you want to make a CLI program that makes a lot of fork() and you want keep it's memory footprint to be as low as possible. You cannot with acceptable way to change cli program not loading those extensions from scan dir. Just edit the files in scan dir? They are needed for normal WWW php operation. Just make two different php.ini's that have the extensions? And that will break distros extension loading style. Just use the -n and put all the settings in file with ini_set() and dl() functions? Uhoh, Not nice. And there seems to be patches around the net for this problem, but nothing in PHP itself. http://alt.linux.kiev.ua/srpm/php/patches/20 http://www.opendogs.org/pub/php-5_2_3-config-file-scan-dir.patch http://pronetko.fi/~bestis/php-5.1.6-scandir.patch (my env version) Expected result: There should be a way to change it runtime. Actual result: -- No way to change it runtime. It can only be disabled with -n parameter but then there's no php.ini. -- Edit this bug report at http://bugs.php.net/?id=45114&edit=1
#45803 [NEW]: Fatal error: Allowed memory size of 134217728 bytes exhausted
From: abhijitkolas at hotmail dot com Operating system: Windows XP, 2003 PHP version: 5.2.6 PHP Bug Type: Arrays related Bug description: Fatal error: Allowed memory size of 134217728 bytes exhausted Description: The following error is encountered: Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 16 bytes) in F:\jtweb\a.php on line 1 Reproduce code: --- Expected result: 'a' should be output. Actual result: -- Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 16 bytes) in F:\jtweb\a.php on line 1 -- Edit bug report at http://bugs.php.net/?id=45803&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45803&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45803&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45803&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45803&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45803&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45803&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45803&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45803&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45803&r=support Expected behavior:http://bugs.php.net/fix.php?id=45803&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45803&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45803&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45803&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45803&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45803&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45803&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45803&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45803&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45803&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45803&r=mysqlcfg
#45803 [Opn->Bgs]: Fatal error: Allowed memory size of 134217728 bytes exhausted
ID: 45803 Updated by: [EMAIL PROTECTED] Reported By: abhijitkolas at hotmail dot com -Status: Open +Status: Bogus Bug Type: Arrays related Operating System: Windows XP, 2003 PHP Version: 5.2.6 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 See http://www.php.net/manual/en/ini.core.php#ini.memory-limit Previous Comments: [2008-08-13 01:34:10] abhijitkolas at hotmail dot com Description: The following error is encountered: Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 16 bytes) in F:\jtweb\a.php on line 1 Reproduce code: --- Expected result: 'a' should be output. Actual result: -- Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 16 bytes) in F:\jtweb\a.php on line 1 -- Edit this bug report at http://bugs.php.net/?id=45803&edit=1
#45794 [Bgs]: HTTP headers rendered differently in PHP than Apache rewrite mod likes them
ID: 45794 User updated by: tarag956 at gmail dot com Reported By: tarag956 at gmail dot com Status: Bogus Bug Type: *Web Server problem Operating System: nix PHP Version: 5.2.6 New Comment: So can you reclassify it as a feature request to view the actual raw headers how they were written that the browser sends in PHP? Previous Comments: [2008-08-12 16:17:23] [EMAIL PROTECTED] > Or are you claiming this is something PHP knows about and "won't fix"? Yes, this is known and expected. The X-Moz header or any header can be retrieved by making it upper case and by replacing "-" by "_". The advantage is that it allows only one representation of an header (X-Moz, X-MOZ or x-moz will all be available with HTTP_X_MOZ). [2008-08-12 15:21:31] tarag956 at gmail dot com The form cut off the URL of the screenshot then made a link out of the decapitated URL. It needs to be all on one line to be viewed. [2008-08-12 15:20:27] tarag956 at gmail dot com Also your first paragraph was an obvious form letter, and your second paragraph was unrelated so I'm no even sure if you understood what I initially said. Also as for flagging bugs bogus, here's a screenshot unrelated to this bug report but related to falsely flagging bugs a bogus: http://images.encyclopediadramatica.com/images/c/c9/Why_PHP_remains_slow.png [2008-08-12 15:17:24] tarag956 at gmail dot com Those links you gave were worthless and unrelated to the issue. I've already read through the manual fully. Are you claiming that somewhere hidden PHP actually can get the same exact style of headers ad mod-rewrite? I have checked fully and there is no such thing. Or are you claiming this is something PHP knows about and "won't fix"? You never explicitly stated your reason for decaring the bug "bogus". [2008-08-12 13:32:22] [EMAIL PROTECTED] 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 HTTP headers and other variables follows the CGI specification: http://hoohoo.ncsa.uiuc.edu/cgi/env.html 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/45794 -- Edit this bug report at http://bugs.php.net/?id=45794&edit=1
#45804 [NEW]: cgi crashes when using -n and -z ZendOptimizer 3.3.0
From: louis at steelbytes dot com Operating system: Vista SP1 x64 PHP version: 5.2.6 PHP Bug Type: CGI related Bug description: cgi crashes when using -n and -z ZendOptimizer 3.3.0 Description: php 5.2.6 win32 zend optimizer 3.3.0 crashes. not 100% sure if this is zendopt of php's fault. so bug reporting to both :-) Reproduce code: --- crash: php-cgi.exe -n -z "C:\pathblah\php-5.2.x\ZendOptimizer.dll" no crash: php.exe -n -z "C:\pathblah\php-5.2.x\ZendOptimizer.dll" crash: php-cgi.exe -n -z "C:\pathblah\php-5.2.x\ZendOptimizer.dll" -i no crash: php-cgi.exe -n -i -z "C:\pathblah\php-5.2.x\ZendOptimizer.dll" -i go figure. Expected result: no crash Actual result: -- Faulting application php-cgi.exe, version 5.2.6.6, time stamp 0x481b8f5f, faulting module ZendOptimizer.dll, version 0.0.0.0, time stamp 0x4782498a, exception code 0xc005, fault offset 0x000180fb, process id 0x16fc, application start time 0x01c8fd067056e080. -- Edit bug report at http://bugs.php.net/?id=45804&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45804&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45804&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45804&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45804&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45804&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45804&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45804&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45804&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45804&r=support Expected behavior:http://bugs.php.net/fix.php?id=45804&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45804&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45804&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45804&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45804&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45804&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45804&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45804&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45804&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45804&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45804&r=mysqlcfg
#45786 [Fbk->Opn]: FastCGI process exited unexpectedly
ID: 45786 User updated by: karelevzen at gmail dot com Reported By: karelevzen at gmail dot com -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Windows Vista Ultimate x64 SP1 PHP Version: 5.3CVS-2008-08-10 (CVS) Assigned To: fb-req-jani New Comment: I did that.I've downloaded the debug pack, unpacked it to: C:\Users\karel_evzen\Desktop\php-dbg and set the Symbol search path for analysis option in Debug Diagnostic Tool to: C:\Users\karel_evzen\Desktop\php-dbg Yet I get the symbols not found warning. Am I missing something? The debug pack contains runnable PHP, no pdb files. I cant find pdb files for the current 5.3 snapshot. Try it yourself. Previous Comments: [2008-08-13 01:05:43] [EMAIL PROTECTED] Well, you propably should install the debug symbols then? They can be found at same place as the snapshots.. [2008-08-12 20:51:42] karelevzen at gmail dot com It tells me that it was not able to locate debug symbols, so I hope you find everything you need in this report. (I run it twice with the same results.) Entry point php_cgi+5ed6 Create time 12.8.2008 22:45:19 Time spent in user mode 0 Days 0:0:0.15 Time spent in kernel mode 0 Days 0:0:0.31 Function Arg 1 Arg 2 Arg 3 Source php_cgi+5604 01452638 00c0ddcc php5ts!zend_hash_destroy+27 PHP_CGI+5604WARNING - DebugDiag was not able to locate debug symbols for php-cgi.exe, so the information below may be incomplete. In php-cgi__PID__5468__Date__08_12_2008__Time_10_45_29PM__791__Second_Chance_Exception_C005.dmp the assembly instruction at php_cgi+5604 in C:\Program Files (x86)\php\php-cgi.exe from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x on thread 0 [2008-08-12 14:46:42] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2008-08-12 14:41:54] karelevzen at gmail dot com I am not loading any extensions. It's a fresh install with recommended php.ini and only these changes: cgi.force_redirect = 0 cgi.fix_pathinfo=1 fastcgi.impersonate = 1 and correct extension_dir As I said, I've got all the extensions commented out. [2008-08-12 14:26:13] [EMAIL PROTECTED] You're propably loading some shared extensions in your php.ini? Disable all of them and try again. Then enable them one by one to find out the error causing one. Then check that the extension in question isn't compiled in the PHP core binary. (php -m output!) 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/45786 -- Edit this bug report at http://bugs.php.net/?id=45786&edit=1
#45805 [NEW]: sebastian
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 5.3CVS-2008-08-13 (CVS)
PHP Bug Type: Reproducible crash
Bug description: sebastian
Description:
The attached PHP script segfaults with both PHP_5_2 and PHP_5_3.
Reproduce code:
---
getX();
}
public function bar() {
$m = new ReflectionMethod('B', 'foo');
$m->invoke($this);
}
}
set_error_handler(
array('PHPUnit_Util_ErrorHandler', 'handleError'), E_ALL | E_STRICT
);
$o = new B;
$o->bar();
?>
Actual result:
--
[EMAIL PROTECTED] ~ % gdb php
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(gdb) r test.php
Starting program: /usr/local/php-5.3/bin/php test.php
[Thread debugging using libthread_db enabled]
[New Thread 0xb77fc6b0 (LWP 21404)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb77fc6b0 (LWP 21404)]
0x085674c0 in _get_zval_ptr_var (node=0x8a5546c, Ts=0x8c0f888,
should_free=0xbfe03efc, tsrm_ls=0x8a53070)
at /usr/local/src/php/php-5.3/Zend/zend_execute.c:197
197 if (T->str_offset.str->type != IS_STRING
(gdb) bt
#0 0x085674c0 in _get_zval_ptr_var (node=0x8a5546c, Ts=0x8c0f888,
should_free=0xbfe03efc, tsrm_ls=0x8a53070)
at /usr/local/src/php/php-5.3/Zend/zend_execute.c:197
#1 0x085c65fa in ZEND_ASSIGN_SPEC_CV_VAR_HANDLER (execute_data=0x8c0f82c,
tsrm_ls=0x8a53070)
at /usr/local/src/php/php-5.3/Zend/zend_vm_execute.h:27470
#2 0x085c69fd in ZEND_ASSIGN_REF_SPEC_CV_VAR_HANDLER
(execute_data=0x8c0f82c, tsrm_ls=0x8a53070)
at /usr/local/src/php/php-5.3/Zend/zend_vm_execute.h:27515
#3 0x085628ec in execute (op_array=0x8be2214, tsrm_ls=0x8a53070) at
/usr/local/src/php/php-5.3/Zend/zend_vm_execute.h:104
#4 0x08523d5e in zend_call_function (fci=0xbfe04144,
fci_cache=0xbfe04168, tsrm_ls=0x8a53070)
at /usr/local/src/php/php-5.3/Zend/zend_execute_API.c:876
#5 0x08237261 in zim_reflection_method_invoke (ht=1,
return_value=0x8be3e5c, return_value_ptr=0x0, this_ptr=0x8be0854,
return_value_used=0, tsrm_ls=0x8a53070) at
/usr/local/src/php/php-5.3/ext/reflection/php_reflection.c:2510
#6 0x085639bf in zend_do_fcall_common_helper_SPEC
(execute_data=0x8c0f738, tsrm_ls=0x8a53070)
at /usr/local/src/php/php-5.3/Zend/zend_vm_execute.h:315
#7 0x08564a4f in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x8c0f738, tsrm_ls=0x8a53070)
at /usr/local/src/php/php-5.3/Zend/zend_vm_execute.h:428
#8 0x085628ec in execute (op_array=0x8be2b68, tsrm_ls=0x8a53070) at
/usr/local/src/php/php-5.3/Zend/zend_vm_execute.h:104
#9 0x085347e4 in zend_execute_scripts (type=8, tsrm_ls=0x8a53070,
retval=0x0, file_count=3)
at /usr/local/src/php/php-5.3/Zend/zend.c:1199
#10 0x084ad611 in php_execute_script (primary_file=0xbfe06630,
tsrm_ls=0x8a53070)
at /usr/local/src/php/php-5.3/main/main.c:2073
#11 0x085d19a4 in main (argc=2, argv=0xbfe067a4) at
/usr/local/src/php/php-5.3/sapi/cli/php_cli.c:1132
--
Edit bug report at http://bugs.php.net/?id=45805&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45805&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45805&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45805&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45805&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45805&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45805&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45805&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45805&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45805&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45805&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45805&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45805&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45805&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45805&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45805&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45805&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45805&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45805&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45805&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45805&r=mysqlcfg
#45805 [Opn->Ver]: sebastian
ID: 45805
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Verified
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 5.3CVS-2008-08-13 (CVS)
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2008-08-13 06:44:01] [EMAIL PROTECTED]
Description:
The attached PHP script segfaults with both PHP_5_2 and PHP_5_3.
Reproduce code:
---
getX();
}
public function bar() {
$m = new ReflectionMethod('B', 'foo');
$m->invoke($this);
}
}
set_error_handler(
array('PHPUnit_Util_ErrorHandler', 'handleError'), E_ALL | E_STRICT
);
$o = new B;
$o->bar();
?>
Actual result:
--
[EMAIL PROTECTED] ~ % gdb php
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(gdb) r test.php
Starting program: /usr/local/php-5.3/bin/php test.php
[Thread debugging using libthread_db enabled]
[New Thread 0xb77fc6b0 (LWP 21404)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb77fc6b0 (LWP 21404)]
0x085674c0 in _get_zval_ptr_var (node=0x8a5546c, Ts=0x8c0f888,
should_free=0xbfe03efc, tsrm_ls=0x8a53070)
at /usr/local/src/php/php-5.3/Zend/zend_execute.c:197
197 if (T->str_offset.str->type != IS_STRING
(gdb) bt
#0 0x085674c0 in _get_zval_ptr_var (node=0x8a5546c, Ts=0x8c0f888,
should_free=0xbfe03efc, tsrm_ls=0x8a53070)
at /usr/local/src/php/php-5.3/Zend/zend_execute.c:197
#1 0x085c65fa in ZEND_ASSIGN_SPEC_CV_VAR_HANDLER
(execute_data=0x8c0f82c, tsrm_ls=0x8a53070)
at /usr/local/src/php/php-5.3/Zend/zend_vm_execute.h:27470
#2 0x085c69fd in ZEND_ASSIGN_REF_SPEC_CV_VAR_HANDLER
(execute_data=0x8c0f82c, tsrm_ls=0x8a53070)
at /usr/local/src/php/php-5.3/Zend/zend_vm_execute.h:27515
#3 0x085628ec in execute (op_array=0x8be2214, tsrm_ls=0x8a53070) at
/usr/local/src/php/php-5.3/Zend/zend_vm_execute.h:104
#4 0x08523d5e in zend_call_function (fci=0xbfe04144,
fci_cache=0xbfe04168, tsrm_ls=0x8a53070)
at /usr/local/src/php/php-5.3/Zend/zend_execute_API.c:876
#5 0x08237261 in zim_reflection_method_invoke (ht=1,
return_value=0x8be3e5c, return_value_ptr=0x0, this_ptr=0x8be0854,
return_value_used=0, tsrm_ls=0x8a53070) at
/usr/local/src/php/php-5.3/ext/reflection/php_reflection.c:2510
#6 0x085639bf in zend_do_fcall_common_helper_SPEC
(execute_data=0x8c0f738, tsrm_ls=0x8a53070)
at /usr/local/src/php/php-5.3/Zend/zend_vm_execute.h:315
#7 0x08564a4f in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x8c0f738, tsrm_ls=0x8a53070)
at /usr/local/src/php/php-5.3/Zend/zend_vm_execute.h:428
#8 0x085628ec in execute (op_array=0x8be2b68, tsrm_ls=0x8a53070) at
/usr/local/src/php/php-5.3/Zend/zend_vm_execute.h:104
#9 0x085347e4 in zend_execute_scripts (type=8, tsrm_ls=0x8a53070,
retval=0x0, file_count=3)
at /usr/local/src/php/php-5.3/Zend/zend.c:1199
#10 0x084ad611 in php_execute_script (primary_file=0xbfe06630,
tsrm_ls=0x8a53070)
at /usr/local/src/php/php-5.3/main/main.c:2073
#11 0x085d19a4 in main (argc=2, argv=0xbfe067a4) at
/usr/local/src/php/php-5.3/sapi/cli/php_cli.c:1132
--
Edit this bug report at http://bugs.php.net/?id=45805&edit=1
#45447 [Opn->Fbk]: filesystem time functions
ID: 45447 Updated by: [EMAIL PROTECTED] Reported By: Bryan dot Gallant at hma dot com -Status: Open +Status: Feedback Bug Type: Filesystem function related Operating System: Windows Server 2008 PHP Version: 5.2.6 New Comment: What filesystem is used in the one that fails and on the one where it doesn't fail..? Previous Comments: [2008-08-04 21:13:56] Bryan dot Gallant at hma dot com Interesting Update. using the same code on an old Win2k Box against the files on the 2008 server, it works as intended. [2008-07-08 00:12:21] Bryan dot Gallant at hma dot com Sorry, it's the full path in a string. [2008-07-07 23:57:46] Bryan dot Gallant at hma dot com So far I've tried all manner of office documents, tifs, jpegs, text files, etc. [2008-07-07 21:50:54] [EMAIL PROTECTED] And $file is..? [2008-07-07 19:10:34] Bryan dot Gallant at hma dot com Description: All Time related Statistics for Files return "-1". W2K8/IIS7 Reproduce code: --- print_r(stat($file)); Expected result: Unix timestamp on atime,mtime,ctime Actual result: -- Array ( [0] => 0 [1] => 0 [2] => 33188 [3] => 1 [4] => 0 [5] => 0 [6] => -1 [7] => 0 [8] => -1 [9] => -1 [10] => -1 [11] => -1 [12] => -1 [dev] => 0 [ino] => 0 [mode] => 33188 [nlink] => 1 [uid] => 0 [gid] => 0 [rdev] => -1 [size] => 0 [atime] => -1 [mtime] => -1 [ctime] => -1 [blksize] => -1 [blocks] => -1 ) -- Edit this bug report at http://bugs.php.net/?id=45447&edit=1
