[PHP-BUG] Bug #65369 [NEW]: Segfault when restarting Apache while script running with custom Exception
From: steve dot kehlet at gmail dot com
Operating system: CentOS 5.x
PHP version: 5.5Git-2013-07-31 (snap)
Package: Reproducible crash
Bug Type: Bug
Bug description:Segfault when restarting Apache while script running with
custom Exception
Description:
Using php-trunk-201307311830, when I restart Apache while a PHP script is
still
running that has defined a subclass of Exception, it results in a
segfault.
'./configure' '--prefix=/opt/php' '--with-apxs2=/opt/apache/bin/apxs'
'--with-
ldap' '--enable-soap' '--enable-sockets=shared' '--with-pgsql=/opt/pgsql'
'--with-
pdo-pgsql=/opt/pgsql' '--with-mysql' '--with-pdo-mysql' '--with-gd'
'--with-jpeg-
dir' '--with-png-dir' '--with-zlib-dir' '--with-freetype-dir'
'--enable-gd-native-
ttf' '--enable-pcntl' '--with-openssl' '--with-curl=/opt/curl'
'--enable-mbstring'
'--with-mcrypt'
# ./httpd -V
Server version: Apache/2.4.6 (Unix)
Server built: Jul 30 2013 17:40:00
Server's Module Magic Number: 20120211:23
Server loaded: APR 1.4.8, APR-UTIL 1.5.2
Compiled using: APR 1.4.8, APR-UTIL 1.5.2
Architecture: 64-bit
Server MPM: prefork
threaded: no
forked: yes (variable process count)
Server compiled with
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=256
-D HTTPD_ROOT=/opt/apache
-D SUEXEC_BIN=/opt/apache/bin/suexec
-D DEFAULT_PIDLOG=logs/httpd.pid
-D DEFAULT_SCOREBOARD=logs/apache_runtime_status
-D DEFAULT_ERRORLOG=logs/error_log
-D AP_TYPES_CONFIG_FILE=conf/mime.types
-D SERVER_CONFIG_FILE=conf/httpd.conf
# diff php.ini-production php.ini
378c378
expose_php = On
---
expose_php = Off
Test script:
---
?php
class MyException extends Exception {
}
sleep(30);
// Hit the above page with a browser.
// While the browser is spinning, from a terminal window:
/opt/apache/bin/apachectl restart
Expected result:
I expected Apache to restart cleanly, no segfaults, as it does when I
comment out
the MyException class.
Actual result:
--
# ps -efww | grep httpd
root 15667 1 0 13:42 ?00:00:00 /opt/apache/bin/httpd -k
start
mirth15715 15667 0 13:43 ?00:00:00 /opt/apache/bin/httpd -k
start
mirth15719 15667 0 13:43 ?00:00:00 /opt/apache/bin/httpd -k
start
root 15721 15633 0 13:43 pts/000:00:00 grep httpd
#
#
# gdb
GNU gdb (GDB) CentOS (7.0.1-45.el5.centos)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
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 x86_64-redhat-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
(gdb) attach 15715
Attaching to process 15715
Reading symbols from /opt/apache/bin/httpd...done.
Reading symbols from /opt/pcre/lib/libpcre.so.1...done.
Loaded symbols for /opt/pcre/lib/libpcre.so.1
Reading symbols from /opt/apache/lib/libaprutil-1.so.0...done.
Loaded symbols for /opt/apache/lib/libaprutil-1.so.0
Reading symbols from /lib64/libexpat.so.0...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libexpat.so.0
Reading symbols from /opt/apache/lib/libapr-1.so.0...done.
Loaded symbols for /opt/apache/lib/libapr-1.so.0
Reading symbols from /lib64/libuuid.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libuuid.so.1
Reading symbols from /lib64/librt.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib64/librt.so.1
Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libcrypt.so.1
Reading symbols from /lib64/libpthread.so.0...(no debugging symbols
found)...done.
[Thread debugging using libthread_db enabled]
Loaded symbols for /lib64/libpthread.so.0
Reading symbols from /lib64/libdl.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /lib64/libc.so.6...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib64/libnss_files.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/libnss_files.so.2
Reading symbols from /opt/apache/modules/mod_authn_file.so...done.
Loaded symbols for /opt/apache/modules/mod_authn_file.so
Reading symbols from /opt/apache/modules/mod_authn_core.so...done.
Loaded symbols for /opt/apache/modules/mod_authn_core.so
Reading symbols from /opt/apache/modules/mod_authz_host.so...done.
Loaded symbols for /opt/apache/modules/mod_authz_host.so
Req #19994 [Com]: Extracting information from Helix/Real Media
Edit report at https://bugs.php.net/bug.php?id=19994edit=1 ID: 19994 Comment by: steve-php at spamwiz dot com Reported by:thomas at mr-andersen dot no Summary:Extracting information from Helix/Real Media Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: All PHP Version:4.2.3 Block user comment: N Private report: N New Comment: This feature request is probably obsolete, and should be closed. The Real Media file format has a negligible market share at this point. Previous Comments: [2002-10-19 14:13:00] thomas at mr-andersen dot no Hi, Have been using PHP as a tool for som CMS and other back-end systems, And have been missing a feature about extracting information from .rm (Real Media files) Just as I can extract header information from JPEG/TIFF formats with the exif_read_data function. I don't know if this is possible in the first place, But since the release of the Helix project, which is sort of open source focused, this should be possible. It would be a nice feature, the Helix project can be found here: http://www.helixcommunity.org/ I will look for information about this in the mean time, but since my level of expertice is 1.5 year of PHP experience I would need some time on this. best regards thomas -- Edit this bug report at https://bugs.php.net/bug.php?id=19994edit=1
Bug #62097 [Com]: New behavior of string == has a compatibility problem
Edit report at https://bugs.php.net/bug.php?id=62097edit=1 ID: 62097 Comment by: steve at home dot com Reported by:kazuo at o-ishi dot jp Summary:New behavior of string == has a compatibility problem Status: Wont fix Type: Bug Package:Scripting Engine problem Operating System: Gentoo Linux PHP Version:5.4.4RC1 Assigned To:stas Block user comment: N Private report: N New Comment: kazuo at o-ishi dot jp: Just don't expect the PHP type system to make any sense, it's easier than trying to understand it at this point. Obviously the developer you are talking to does not understand this issue. If you want to have reliable behavior, PHP is not for you (unless you stick to a single version and work out the oddities). Previous Comments: [2012-05-31 06:23:30] s...@php.net I believe I did explain the reason and I believe this is reason enough. If you disagree, please feel free to raise it on internals list and if enough of the community supports you it will be reversed. So far I did not hear any more complaints about it. I think it is clear that there is a disagreement between us about how to handle this, and more discussion is not going to bring any improvement. I am closing this bug, if you feel more discussion is required please raise it on the list. [2012-05-31 02:36:51] kazuo at o-ishi dot jp I have shown test cases that work on released version 5.4.3 but not work on developing version. Now, YOU need explain real merit of this backward incompatible change. md5() is not enough reason, because it should always be compared by === instead of ==. Generally, at the case when new behavior (memcmp for large value) is acceptable, we can and we should just use ===. If you have such code sample and can explain what data it accepts, what it does and why it relies on string comparisons cutting numbers, please do so. Your database example is missing data, so I can not see what is going on there and why you think it works differently in 5.4.3 and 5.4.4. (I'm sorry but I cannot understand what you say in this two sentence. Could you explain detail?) In JPY (Japan Yen), we normally use it in integer (e.g. 100 yen). But sometimes it take fraction (e.g. foreign exchange 1 USD = 78.80 JPY). So database column type with fraction is reasonable. And set to / get from the column in integer form is also reasonable. Again, I just report incompatibility from PHP 5.4.3 to PHP 5.4.4RC. This is wrong way if you want to fix security problem, because incompatible change makes the users difficult to migrate to new version. [2012-05-31 00:46:41] s...@php.net I do not see heavy impact - so far I did not see any code sample that did something that makes sense in 5.4.3 but not on 5.4.4. If you have such code sample and can explain what data it accepts, what it does and why it relies on string comparisons cutting numbers, please do so. Your database example is missing data, so I can not see what is going on there and why you think it works differently in 5.4.3 and 5.4.4. [2012-05-30 08:57:43] kazuo at o-ishi dot jp In summary, this is my opinion: Recent changes on string == have problems on compatibility. Impact of the behavior change of == operator is heavy. This change should be excluded from PHP 5.4.x series. I'm sure that current (old) behavior also have problems, but compatibility is better. If it will be changed, it should be a natural extension of current behavior; number-like string is compared as number. (e.g. canonicalize string as number way before memcmp.) Of course, such behavior should be described explicitly in PHP Manual. [2012-05-30 07:18:45] kazuo at o-ishi dot jp Please think that it is money (or member ID). But why? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=62097 -- Edit this bug report at https://bugs.php.net/bug.php?id=62097edit=1
Bug #62008 [Opn-Csd]: signal 6 in curl_multi_fdset
Edit report at https://bugs.php.net/bug.php?id=62008edit=1 ID: 62008 User updated by:steve at dirtyandroid dot com Reported by:steve at dirtyandroid dot com Summary:signal 6 in curl_multi_fdset -Status: Open +Status: Closed Type: Bug Package:cURL related Operating System: Ubuntu Precise -PHP Version:5.3.10-1ubuntu3.1 with Suhosin-Patch (cli) (built: May 4 2012 02:20:36) +PHP Version:5.4.3 (cli) (built: May 31 2012 08:48:27) Block user comment: N Private report: Y New Comment: Solved between curl 7.22 and 7.26 Previous Comments: [2012-05-30 19:47:28] steve at dirtyandroid dot com I've got a backtrace. I've realised that it does in fact crash on particular jobs, rather than randomly after a load of them. Any fixes or workarounds are immensely welcome, this is causing an untold amount of pain for me. Program terminated with signal 6, Aborted. #0 0x7f1ee5839445 in raise () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x7f1ee5839445 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7f1ee583cbab in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x7f1ee5876e2e in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x7f1ee590c007 in __fortify_fail () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x7f1ee590af00 in __chk_fail () from /lib/x86_64-linux-gnu/libc.so.6 #5 0x7f1ee590bfbe in __fdelt_warn () from /lib/x86_64-linux-gnu/libc.so.6 #6 0x7f1ee4d2b33b in curl_multi_fdset () from /usr/lib/x86_64-linux-gnu/libcurl.so.4 #7 0x7f1ee4f5ca45 in zif_curl_multi_select (ht=19794, return_value=0x3609b28, return_value_ptr=0x6, this_ptr=0x, return_value_used=-443070624) at /build/buildd/php5-5.3.10/ext/curl/multi.c:193 #8 0x0070f77d in zend_do_fcall_common_helper_SPEC (execute_data=0x7f1ee014a8c0) at /build/buildd/php5-5.3.10/Zend/zend_vm_execute.h:320 #9 0x006c02eb in execute (op_array=0x1535b68) at /build/buildd/php5-5.3.10/Zend/zend_vm_execute.h:107 #10 0x0068d82c in zend_call_function (fci=0x7fffbe3b8600, fci_cache=0x7f1ee0147d68) at /build/buildd/php5-5.3.10/Zend/zend_execute_API.c:969 #11 0x005cfeb1 in zif_call_user_func (ht=19794, return_value=0x18b9ff0, return_value_ptr=0x6, this_ptr=0x, return_value_used=-443070624) at /build/buildd/php5-5.3.10/ext/standard/basic_functions.c:4778 #12 0x0070f77d in zend_do_fcall_common_helper_SPEC (execute_data=0x7f1ee0147d68) at /build/buildd/php5-5.3.10/Zend/zend_vm_execute.h:320 #13 0x006c02eb in execute (op_array=0x12fae50) at /build/buildd/php5-5.3.10/Zend/zend_vm_execute.h:107 #14 0x0068d82c in zend_call_function (fci=0x7fffbe3b88f0, fci_cache=0x7f1ee01479a0) at /build/buildd/php5-5.3.10/Zend/zend_execute_API.c:969 #15 0x005cfeb1 in zif_call_user_func (ht=19794, return_value=0x18bf778, return_value_ptr=0x6, this_ptr=0x, return_value_used=-443070624) at /build/buildd/php5-5.3.10/ext/standard/basic_functions.c:4778 #16 0x0070f77d in zend_do_fcall_common_helper_SPEC (execute_data=0x7f1ee01479a0) at /build/buildd/php5-5.3.10/Zend/zend_vm_execute.h:320 #17 0x006c02eb in execute (op_array=0x12e6440) at /build/buildd/php5-5.3.10/Zend/zend_vm_execute.h:107 #18 0x0069b850 in zend_execute_scripts (type=0, retval=0x8, file_count=3) at /build/buildd/php5-5.3.10/Zend/zend.c:1308 #19 0x00647f03 in php_execute_script (primary_file=0x7f1ee583def6) at /build/buildd/php5-5.3.10/main/main.c:2323 #20 0x0042c797 in main (argc=32767, argv=0x7fffbe3bbe1a) at /build/buildd/php5-5.3.10/sapi/cli/php_cli.c:1188 Curl stuff from phpinfo: cURL support = enabled cURL Information = 7.22.0 Age = 3 Features AsynchDNS = No Debug = No GSS-Negotiate = Yes IDN = Yes IPv6 = Yes Largefile = Yes NTLM = Yes SPNEGO = No SSL = Yes SSPI = No krb4 = No libz = Yes CharConv = No Protocols = dict, file, ftp, ftps, gopher, http, https, imap, imaps, ldap, pop3, pop3s, rtmp, rtsp, smtp, smtps, telnet, tftp Host = x86_64-pc-linux-gnu SSL Version = OpenSSL/1.0.1 ZLib Version = 1.2.3.4 [2012-05-15 14:17:17] steve at dirtyandroid dot com Sure, I'll give it a go when I get a chance, probably later this week. [2012-05-15 13:46:34] tony2...@php.net Could you pls try to get a decent GDB backtrace? See instructions here: https://bugs.php.net/bugs-generating-backtrace.php [2012-05-13 15:11:19] steve at dirtyandroid dot com I'm sorry but I have no idea what in my 20k line codebase is triggering this, and thus can't give you an example script
[PHP-BUG] Bug #60151 [NEW]: Defunct group listed in events - Sandy PHP UG
From: Operating system: n/a PHP version: Irrelevant Package: Website problem Bug Type: Bug Bug description:Defunct group listed in events - Sandy PHP UG Description: The Sandy PHP UG has been defunct for many years, and nobody has been able to contact them using the information listed. -- Edit bug report at https://bugs.php.net/bug.php?id=60151edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60151r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60151r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60151r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60151r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60151r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60151r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60151r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60151r=needscript Try newer version: https://bugs.php.net/fix.php?id=60151r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60151r=support Expected behavior: https://bugs.php.net/fix.php?id=60151r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60151r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60151r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60151r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60151r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60151r=dst IIS Stability: https://bugs.php.net/fix.php?id=60151r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60151r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60151r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60151r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60151r=mysqlcfg
Bug #55311 [Bgs]: Static methods invoke __call when called from within class
Edit report at https://bugs.php.net/bug.php?id=55311edit=1
ID: 55311
User updated by:steve at twitpic dot com
Reported by:steve at twitpic dot com
Summary:Static methods invoke __call when called from within
class
Status: Bogus
Type: Bug
Package:*General Issues
Operating System: Ubuntu 11.04
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
This is ridiculous- this bug is not bogus, it's completely legitimate,
unexpected
behavior, and totally non documented. As a reasonable programmer, one expects a
static call to behave the same inside of a class as well as outside of a class.
How can we bring the desired behavior up for vote? I think that it's insane
to
not fix it.
Previous Comments:
[2011-07-29 08:33:24] cataphr...@php.net
Closing as bogus, see
http://www.mail-archive.com/internals@lists.php.net/msg52338.html
[2011-07-29 03:31:19] larue...@php.net
The following patch has been added/updated:
Patch Name: bug55311.phpt
Revision: 1311910279
URL:
https://bugs.php.net/patch-display.php?bug=55311patch=bug55311.phptrevision=1311910279
[2011-07-29 03:29:37] larue...@php.net
The following patch has been added/updated:
Patch Name: bug55311.patch
Revision: 1311910177
URL:
https://bugs.php.net/patch-display.php?bug=55311patch=bug55311.patchrevision=1311910177
[2011-07-29 03:28:51] larue...@php.net
looks like for some reason someone change the if/else sequence make this bug,
but I am not sure why he do this.
[2011-07-28 21:04:42] steve at twitpic dot com
Description:
When calling a non-existant static method within an objects method, php invokes
_call instead of
__callStatic. When calling the same non-existant static method outside of the
object, php correctly
invokes __callStatic.
It appears that this broke in php5.3.5 and is still broken in 5.3.6. It works
as
expected in 5.3.3,
however.
Test script:
---
class Test {
public function __call($method, $args) {
echo call\n;
}
public static function __callStatic($method, $args) {
echo callStatic\n;
}
public function testing() {
Test::fakeFunction();
}
}
$t = new Test;
$t-testing();
Test::fakeFunction();
Expected result:
// expected output
callStatic
callStatic
Actual result:
--
// output
call
callStatic
--
Edit this bug report at https://bugs.php.net/bug.php?id=55311edit=1
Bug #51176 [Com]: Static calling in non-static method behaves like $this-
Edit report at https://bugs.php.net/bug.php?id=51176edit=1 ID: 51176 Comment by: steve at twitpic dot com Reported by:majkl578 at gmail dot com Summary:Static calling in non-static method behaves like $this- Status: Bogus Type: Bug Package:Scripting Engine problem Operating System: Irrelevant PHP Version:5.3.2RC3 Assigned To:felipe Block user comment: N Private report: N New Comment: This is ridiculous- this bug is not bogus, it's completely legitimate, unexpected behavior, and totally non documented. As a reasonable programmer, one expects a static call to behave the same inside of a class as well as outside of a class. How can we bring the desired behavior up for vote? I think that it's insane to not fix it. Previous Comments: [2011-05-31 02:06:16] david71rj at gmail dot com Sorry by realive this topic, but I really think that it is a bug. If I want call bar with context, the correct mean is $this-bar(). Else, the static sounds for me like call without context. I'm wrong? Please, read this topic to understand what I'm saying: http://stackoverflow.com/questions/6181603/php-is-handling-incorrectly-my-static- call [2010-11-03 12:03:17] majkl578 at gmail dot com You cannot call foo::start(), because the method is non-static and therefore it does not make sense. Also, self, static and class name are used to call methods statically, not in a object context. For calling method bar in object context, I think '$this-' should be used instead. Obviously parent should not behave this way and respect context, but I think it should be the only exception (as shown in #52713). [2010-11-03 02:45:23] fel...@php.net Hello, I've reverted the wrong changes introduced by trying to fix the issue reported, but actually there is no bug at all. self::bar(), static::bar() and foo::bar() are being called in an object context, hence the __call() is called. I.e. $foo-start(); // invoke the __call method foo::start(); // invoke the __callStatic method Thanks. [2010-11-03 02:35:28] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=305043 Log: - Reverted fix for bug #51176 [2010-03-04 14:27:55] fel...@php.net Hello! This isn't my decision, but the release manager. Thanks. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=51176 -- Edit this bug report at https://bugs.php.net/bug.php?id=51176edit=1
[PHP-BUG] Bug #55311 [NEW]: Static methods invoke __call when called from within class
From:
Operating system: Ubuntu 11.04
PHP version: 5.3.6
Package: *General Issues
Bug Type: Bug
Bug description:Static methods invoke __call when called from within class
Description:
When calling a non-existant static method within an objects method, php
invokes
_call instead of
__callStatic. When calling the same non-existant static method outside of
the
object, php correctly
invokes __callStatic.
It appears that this broke in php5.3.5 and is still broken in 5.3.6. It
works as
expected in 5.3.3,
however.
Test script:
---
class Test {
public function __call($method, $args) {
echo call\n;
}
public static function __callStatic($method, $args) {
echo callStatic\n;
}
public function testing() {
Test::fakeFunction();
}
}
$t = new Test;
$t-testing();
Test::fakeFunction();
Expected result:
// expected output
callStatic
callStatic
Actual result:
--
// output
call
callStatic
--
Edit bug report at https://bugs.php.net/bug.php?id=55311edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55311r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55311r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55311r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55311r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55311r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55311r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55311r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55311r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55311r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55311r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55311r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55311r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55311r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55311r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55311r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55311r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55311r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55311r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55311r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55311r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55311r=mysqlcfg
Bug #55272 [Bgs]: Missing semicolon in DATE_ISO8601 Predefined Constant for date()
Edit report at https://bugs.php.net/bug.php?id=55272edit=1 ID: 55272 User updated by:steve at stringersites dot com Reported by:steve at stringersites dot com Summary:Missing semicolon in DATE_ISO8601 Predefined Constant for date() Status: Bogus Type: Bug Package:Date/time related Operating System: Mac OS X PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Got it. Note that the Google Checkout XML API rejects the semicolon-less timestamp using the predefined constant. The only format it accepts is Y-m-d\TH:i:sP. Not that you're responsible for what Google does, but it's something to think about where the theoretical and practical collide. Previous Comments: [2011-07-25 16:38:00] ahar...@php.net ISO 8601 explicitly allows time zone representations to be basic (without the colon), or extended (with the colon). Both are equally valid, and PHP implements the former in that particular constant. [2011-07-23 20:39:42] steve at stringersites dot com Description: It would appear that there is a mistake in the DATE_ISO8601 predefined constant for the date() function. current output: 2011-07-22T00:00:00-0500 desired output: 2011-07-22T00:00:00-05:00 http://www.php.net/manual/en/class.datetime.php#datetime.constants.iso8601 http://en.wikipedia.org/wiki/ISO_8601 Test script: --- As best as I can tell, there's supposed to be a semicolon between the timezone offset hours:minutes. ?php $d = mktime (0, 0, 0, '03', '08', '2011'); // 2011-03-08T00:00:00-0600 -- actual, incorrect (?) result echo date(DATE_ISO8601, $d).'br'; // 2011-03-08T00:00:00-0600 echo date(Y-m-d\TH:i:sO, $d).'br'; // 2011-03-08T00:00:00-06:00 -- expected result echo date(Y-m-d\TH:i:sP, $d).'br'; ? So the format for DATE_ISO8601 should be Y-m-d\TH:i:sP (capital P at the end), not Y-m-d\TH:i:sO (capital O at the end). Expected result: // 2011-03-08T00:00:00-0600 -- actual, incorrect (?) result echo date(DATE_ISO8601, $d); Actual result: -- // 2011-03-08T00:00:00-06:00 -- expected result echo date(Y-m-d\TH:i:sP, $d); -- Edit this bug report at https://bugs.php.net/bug.php?id=55272edit=1
[PHP-BUG] Bug #55272 [NEW]: Missing semicolon in DATE_ISO8601 Predefined Constant for date()
From: Operating system: Mac OS X PHP version: 5.3.6 Package: Unknown/Other Function Bug Type: Bug Bug description:Missing semicolon in DATE_ISO8601 Predefined Constant for date() Description: It would appear that there is a mistake in the DATE_ISO8601 predefined constant for the date() function. current output: 2011-07-22T00:00:00-0500 desired output: 2011-07-22T00:00:00-05:00 http://www.php.net/manual/en/class.datetime.php#datetime.constants.iso8601 http://en.wikipedia.org/wiki/ISO_8601 Test script: --- As best as I can tell, there's supposed to be a semicolon between the timezone offset hours:minutes. ?php $d = mktime (0, 0, 0, '03', '08', '2011'); // 2011-03-08T00:00:00-0600 -- actual, incorrect (?) result echo date(DATE_ISO8601, $d).'br'; // 2011-03-08T00:00:00-0600 echo date(Y-m-d\TH:i:sO, $d).'br'; // 2011-03-08T00:00:00-06:00 -- expected result echo date(Y-m-d\TH:i:sP, $d).'br'; ? So the format for DATE_ISO8601 should be Y-m-d\TH:i:sP (capital P at the end), not Y-m-d\TH:i:sO (capital O at the end). Expected result: // 2011-03-08T00:00:00-0600 -- actual, incorrect (?) result echo date(DATE_ISO8601, $d); Actual result: -- // 2011-03-08T00:00:00-06:00 -- expected result echo date(Y-m-d\TH:i:sP, $d); -- Edit bug report at https://bugs.php.net/bug.php?id=55272edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55272r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55272r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55272r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55272r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55272r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55272r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55272r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55272r=needscript Try newer version: https://bugs.php.net/fix.php?id=55272r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55272r=support Expected behavior: https://bugs.php.net/fix.php?id=55272r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55272r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55272r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55272r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55272r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55272r=dst IIS Stability: https://bugs.php.net/fix.php?id=55272r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55272r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55272r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55272r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55272r=mysqlcfg
Bug #49788 [Com]: Missing command in make file for Generating phar.php
Edit report at http://bugs.php.net/bug.php?id=49788edit=1 ID: 49788 Comment by: steve at falchion dot com Reported by:venkata dot ballari at gmail dot com Summary:Missing command in make file for Generating phar.php Status: Feedback Type: Bug Package:Compile Failure Operating System: AIX 5.3 PHP Version:5.3.0 Block user comment: N Private report: N New Comment: I have the same issue, after Generating phar.php I get /bin/sh[14]: /home/steve/anisoft/php/php-5.3.3/sapi/cli/pdp: not found Ayone figgure this one out? Previous Comments: [2010-09-22 09:31:29] michael dot gilliam at aramco dot com I downloaded the latest release that was mentioned at the bottom of them message and I still get the same error that was mentioned as this thread was opened. /home/gilliamb/php5.3-201009220630/sapi/cli/php_cli.c: In function 'cli_seek_file_begin': /home/gilliamb/php5.3-201009220630/sapi/cli/php_cli.c:621: warning: comparison is always true due to limited range of data type /home/gilliamb/php5.3-201009220630/sapi/cli/php_cli.c: In function 'main': /home/gilliamb/php5.3-201009220630/sapi/cli/php_cli.c:1402: warning: visibility attribute not supported in this configuration; ignored /home/gilliamb/php5.3-201009220630/sapi/cli/php_cli.c: At top level: /home/gilliamb/php5.3-201009220630/sapi/cli/php_cli.c:1402: warning: visibility attribute not supported in this configuration; ignored /bin/sh /home/gilliamb/php5.3-201009220630/libtool --silent --preserve- dup-deps --mode=compile gcc -Isapi/cli/ -I/home/gilliamb/php5.3- 201009220630/sapi/cli/ -DPHP_ATOM_INC -I/home/gilliamb/php5.3- 201009220630/include -I/home/gilliamb/php5.3-201009220630/main - I/home/gilliamb/php5.3-201009220630 -I/home/gilliamb/php5.3- 201009220630/ext/date/lib -I/home/gilliamb/php5.3-201009220630/ext/ereg/regex - I/opt/freeware/include/libxml2 -I/usr/local/nssg/curl/include - I/usr/local/nssg/openldap/include -I/home/gilliamb/php5.3- 201009220630/ext/mbstring/oniguruma -I/home/gilliamb/php5.3- 201009220630/ext/mbstring/libmbfl -I/home/gilliamb/php5.3- 201009220630/ext/mbstring/libmbfl/mbfl -I/home/gilliamb/php5.3-201009220630/TSRM -I/home/gilliamb/php5.3-201009220630/Zend-I/usr/include -g -O2 - fvisibility=hidden -c /home/gilliamb/php5.3- 201009220630/sapi/cli/php_cli_readline.c -o sapi/cli/php_cli_readline.lo /bin/sh /home/gilliamb/php5.3-201009220630/libtool --silent --preserve- dup-deps --mode=compile gcc -Imain/ -I/home/gilliamb/php5.3-201009220630/main/ -DPHP_ATOM_INC -I/home/gilliamb/php5.3-201009220630/include - I/home/gilliamb/php5.3-201009220630/main -I/home/gilliamb/php5.3-201009220630 - I/home/gilliamb/php5.3-201009220630/ext/date/lib -I/home/gilliamb/php5.3- 201009220630/ext/ereg/regex -I/opt/freeware/include/libxml2 - I/usr/local/nssg/curl/include -I/usr/local/nssg/openldap/include - I/home/gilliamb/php5.3-201009220630/ext/mbstring/oniguruma - I/home/gilliamb/php5.3-201009220630/ext/mbstring/libmbfl - I/home/gilliamb/php5.3-201009220630/ext/mbstring/libmbfl/mbfl - I/home/gilliamb/php5.3-201009220630/TSRM -I/home/gilliamb/php5.3- 201009220630/Zend-I/usr/include -g -O2 -fvisibility=hidden -c main/internal_functions_cli.c -o main/internal_functions_cli.lo echo '\ \ Generating phar.php /bin/sh[14]: /home/gilliamb/php5.3-201009220630/sapi/cli/php: not found. make: 1254-004 The error code from the last command is 127. Stop. [2010-05-09 23:20:11] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-10-14 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2009-10-08 08:16:04] venkata dot ballari at gmail dot com I tried the snapshot available at http://snaps.php.net/php5.3-latest.tar.gz I'm using bash. Still getting errors. -I/usr/include -g -c /home/oa_apps/php5.3-200910070430/ext/fileinfo/libmagic/encoding.c -o ext/fileinfo/libmagic/encoding.lo 1500-052: (S) Cannot write object file. make: 1254-004 The error code from the last command is 1. Stop. [2009-10-06 15:25:26] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ And what
Bug #49788 [Com]: Missing command in make file for Generating phar.php
Edit report at http://bugs.php.net/bug.php?id=49788edit=1 ID: 49788 Comment by: steve at falchion dot com Reported by:venkata dot ballari at gmail dot com Summary:Missing command in make file for Generating phar.php Status: Feedback Type: Bug Package:Compile Failure Operating System: AIX 5.3 PHP Version:5.3.0 Block user comment: N Private report: N New Comment: Sorry for the previous Me too!. After some searching, it appears that sapi/cli/php has not been built when phar ties to run it, so a workaround is to re-configure with --disable-phar (assuming you don't need phar), but it would be nicer if the build order was adjusted so that it worked... *shrug* Hmm.. make test just failed because CLI sapi is not there after make. perhaps I missed a config switch to build it? Tried with --enable-cli (although this is the advertised default) and it compiles php_cli.lo, php_cli_readline.lo and then main/internal_functions_cli.lo and then stops saying complete, but the php executable was never built. There we go. Switched to gmake, and it created the php executable. re-ran configure without --disable-phar and re-ran gmake clean;gmake, this time, no issues. Previous Comments: [2010-12-10 07:54:08] steve at falchion dot com I have the same issue, after Generating phar.php I get /bin/sh[14]: /home/steve/anisoft/php/php-5.3.3/sapi/cli/pdp: not found Ayone figgure this one out? [2010-09-22 09:31:29] michael dot gilliam at aramco dot com I downloaded the latest release that was mentioned at the bottom of them message and I still get the same error that was mentioned as this thread was opened. /home/gilliamb/php5.3-201009220630/sapi/cli/php_cli.c: In function 'cli_seek_file_begin': /home/gilliamb/php5.3-201009220630/sapi/cli/php_cli.c:621: warning: comparison is always true due to limited range of data type /home/gilliamb/php5.3-201009220630/sapi/cli/php_cli.c: In function 'main': /home/gilliamb/php5.3-201009220630/sapi/cli/php_cli.c:1402: warning: visibility attribute not supported in this configuration; ignored /home/gilliamb/php5.3-201009220630/sapi/cli/php_cli.c: At top level: /home/gilliamb/php5.3-201009220630/sapi/cli/php_cli.c:1402: warning: visibility attribute not supported in this configuration; ignored /bin/sh /home/gilliamb/php5.3-201009220630/libtool --silent --preserve- dup-deps --mode=compile gcc -Isapi/cli/ -I/home/gilliamb/php5.3- 201009220630/sapi/cli/ -DPHP_ATOM_INC -I/home/gilliamb/php5.3- 201009220630/include -I/home/gilliamb/php5.3-201009220630/main - I/home/gilliamb/php5.3-201009220630 -I/home/gilliamb/php5.3- 201009220630/ext/date/lib -I/home/gilliamb/php5.3-201009220630/ext/ereg/regex - I/opt/freeware/include/libxml2 -I/usr/local/nssg/curl/include - I/usr/local/nssg/openldap/include -I/home/gilliamb/php5.3- 201009220630/ext/mbstring/oniguruma -I/home/gilliamb/php5.3- 201009220630/ext/mbstring/libmbfl -I/home/gilliamb/php5.3- 201009220630/ext/mbstring/libmbfl/mbfl -I/home/gilliamb/php5.3-201009220630/TSRM -I/home/gilliamb/php5.3-201009220630/Zend-I/usr/include -g -O2 - fvisibility=hidden -c /home/gilliamb/php5.3- 201009220630/sapi/cli/php_cli_readline.c -o sapi/cli/php_cli_readline.lo /bin/sh /home/gilliamb/php5.3-201009220630/libtool --silent --preserve- dup-deps --mode=compile gcc -Imain/ -I/home/gilliamb/php5.3-201009220630/main/ -DPHP_ATOM_INC -I/home/gilliamb/php5.3-201009220630/include - I/home/gilliamb/php5.3-201009220630/main -I/home/gilliamb/php5.3-201009220630 - I/home/gilliamb/php5.3-201009220630/ext/date/lib -I/home/gilliamb/php5.3- 201009220630/ext/ereg/regex -I/opt/freeware/include/libxml2 - I/usr/local/nssg/curl/include -I/usr/local/nssg/openldap/include - I/home/gilliamb/php5.3-201009220630/ext/mbstring/oniguruma - I/home/gilliamb/php5.3-201009220630/ext/mbstring/libmbfl - I/home/gilliamb/php5.3-201009220630/ext/mbstring/libmbfl/mbfl - I/home/gilliamb/php5.3-201009220630/TSRM -I/home/gilliamb/php5.3- 201009220630/Zend-I/usr/include -g -O2 -fvisibility=hidden -c main/internal_functions_cli.c -o main/internal_functions_cli.lo echo '\ \ Generating phar.php /bin/sh[14]: /home/gilliamb/php5.3-201009220630/sapi/cli/php: not found. make: 1254-004 The error code from the last command is 127. Stop. [2010-05-09 23:20:11] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-10-14 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug
Bug #50400 [Com]: Compile fails generating phar.phar
Edit report at http://bugs.php.net/bug.php?id=50400edit=1 ID: 50400 Comment by: steve at computurn dot com Reported by:lepage at grm dot polymtl dot ca Summary:Compile fails generating phar.phar Status: Feedback Type: Bug Package:PHAR related Operating System: Solaris 10 PHP Version:5.3.1 Assigned To:dsp Block user comment: N New Comment: I have a fix for this issue (PHP5.3.3) It's caused by ext/phar/build_precommand.php having a header of #!/usr/bin/php I fixed it on my system by creating a /usr/bin/php symlink to a php executable, but I suspect the proper fix will be to change the #! to point to sapi/cli/php, if that's built when we get to this stage. Previous Comments: [2010-07-05 21:43:00] omars1234 at gmail dot com Tried the new snapshot, no luck. Using Solaris10, gcc 4.2.1. Configured without any options. Generating phar.php *** Error code 139 The following command caused the error: ` if test -x /tmp/php5.3-201007051830/sapi/cli/php; then /tmp/php5.3-201007051830/build/shtool echo -n -- /tmp/php5.3-201007051830/sapi/cli/php -n; if test x != x; then /tmp/php5.3-201007051830/build/shtool echo -n -- -d extension_dir=/tmp/php5.3-201007051830/modules; for i in bz2 zlib phar; do if test -f /tmp/php5.3-201007051830/modules/$i.la; then . /tmp/php5.3-201007051830/modules/$i.la; /tmp/php5.3-201007051830/build/shtool echo -n -- -d extension=$dlname; fi; done; fi; else /tmp/php5.3-201007051830/build/shtool echo -n -- /tmp/php5.3-201007051830/sapi/cli/php; fi;` -d 'open_basedir=' -d 'output_buffering=0' -d 'memory_limit=-1' -d phar.readonly=0 -d 'safe_mode=0' /tmp/php5.3-201007051830/ext/phar/build_precommand.php ext/phar/phar.php make: Fatal error: Command failed for target `ext/phar/phar.php' (my disable-phar version didn't work out either, resulting cli-binary core dumps :( ) [2010-07-02 11:33:17] johan...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-07-02 01:04:44] omars1234 at gmail dot com As a work-around, pass --disable-phar to configure. I don't do anything that explicitly needs phar archives (so far), so I did this to build PHP5.3.2 on Solaris10 after running into the same problem. [2010-01-26 17:09:36] ekcheu at uncg dot edu I've had this issue before. It appears that this error occurs depending upon which version of gcc you are using. After continuing to fail to compile on a version of gcc (4.2.1).. I used blastwave's gcc, and it was able to get past this issue. Don't ask why it compiles find on some versions of gcc and not others. [2009-12-07 20:13:01] lepage at grm dot polymtl dot ca Description: Cannot gcc compile php 5.3.1 on Solaris 10 (sparc) since it's failing with phar/phar.php error. It was the same with php 5.3.0. SunStudio is not an option since many libs are done with gcc and there is incompatibilities with some dependencies. php 515 does compile on Solaris 10. thanks. Reproduce code: --- php-5.3.1% make Generating phar.phar Parse error: syntax error, unexpected $end in /share/concorde/xta3511/install/web/php-5.3.1/ext/phar/phar.php on line 19 *** Error code 255 The following command caused the error: ` if test -x /share/concorde/xta3511/install/web/php-5.3.1/sapi/cli/php; then /share/concorde/xta3511/install/web/php-5.3.1/build/shtool echo -n -- /share/concorde/xta3511/install/web/php-5.3.1/sapi/cli/php -n; if test x != x; then /share/concorde/xta3511/install/web/php-5.3.1/build/shtool echo -n -- -d extension_dir=/share/concorde/xta3511/install/web/php-5.3.1/modules; for i in bz2 zlib phar; do if test -f /share/concorde/xta3511/install/web/php-5.3.1/modules/$i.la; then . /share/concorde/xta3511/install/web/php-5.3.1/modules/$i.la; /share/concorde/xta3511/install/web/php-5.3.1/build/shtool echo -n -- -d extension=$dlname; fi; done; fi; else /share/concorde/xta3511/install/web/php-5.3.1/build/shtool echo -n -- ; fi;` -d 'open_basedir=' -d 'output_buffering=0' -d 'memory_limit=-1' -d phar.readonly=0 -d 'safe_mode=0' ext/phar/phar.php pack -f ext/phar/phar.phar -a pharcommand -c auto -x \\.svn -p 0 -s /share/concorde/xta3511/install/web/php-5.3.1/ext/phar/phar/phar.php -h sha1 -b `if test -x ; then /share/concorde/xta3511/install/web/php-5.3.1/build/shtool echo -n -- ; else /share/concorde/xta3511/install/web/php-5.3.1/build/shtool echo -n -- /usr/local_10/opt/php-531/bin/php; fi; ` /share/concorde/xta3511/install/web
Bug #50270 [Com]: ldap_start_tls problem
Edit report at http://bugs.php.net/bug.php?id=50270edit=1
ID: 50270
Comment by: steve at maraspin dot net
Reported by:jcarlos at dsi dot uclm dot es
Summary:ldap_start_tls problem
Status: To be documented
Type: Bug
Package:LDAP related
Operating System: windows
PHP Version:5.3.1
Block user comment: N
New Comment:
I am also experiencing the same problem with PHP 5.3.2, bundled in Zend
Server CE. I've tried invoking following script both from the cli and
apache on CentOS 5.5 64 bit and it fails on both cases. Following error
message appears:
Warning: ldap_start_tls(): Unable to start TLS: Not Supported in
/tmp/script.php on line 7
On same machine, the same script, interpreted by a PHP 5.1.6 (cli)
interpreter (obtained from CentOS yum repository, php package) works
well. Both php binaries are compiled for 64 bit.
?php
$ldap=ldap://myhost;;
$ds=ldap_connect($ldap,389);
$ldapbind=false;
if(ldap_set_option($ds, LDAP_OPT_PROTOCOL_VERSION, 3)) {
if(ldap_set_option($ds, LDAP_OPT_REFERRALS, 0)) {
if(ldap_start_tls($ds)) {
$ldapbind = ldap_bind($ds,
cn=username,
dc=x,
dc=y,
password
);
if ($ldapbind) {
echo ok;
} else {
echo ko tls;
}
} else {
echo no tls;
}
} else echo no option;
} else {
echo no version;
}
ldap_close($ds);
Previous Comments:
[2009-12-01 11:12:34] jcarlos at dsi dot uclm dot es
I have tested in linux
Width PHP/5.2.10-2ubuntu and Apache/2.2.1.2
INTEGRATING ACTIVE DIRECTORY WITH PHP-LDAP AND TLS IN LINUX
===
I'm not an expert, but it works.
1)I have installed ubuntu 9.10 desktop
2)Packages:
apt-get install apache2
apt-get install libapache2-mod-php5
apt-get install libldap-2.4-2
apt-get install ldap-utils
apt-get install libsasl2-modules-ldap
apt-get install openssl
apt-get install libsasl2-2
apt-get install libkrb5-3
apt-get install kbr5-config
apt-get install kbr5-user
apt-get install php5-ldap
apt-get install php5-sasl
apt-get install php5-auth-pam
3)Put the PEM certificate.
cd /etc/ldap
mkdir certs
copy /myhome/mycert.pem /etc/ldap/certs/mycert.pem
NOTE:webcert.crt rename to mycert.pem. It's the same
4)Edit the file /etc/ldap/ldap.conf and Add:
TLS_REQCERT never
TLS_CACERT /etc/ldap/certs/mycert.pem
5)Create file /var/www/ldaptlstest.php:
?php
$ldap=ldap.myDomain.com;
$usr=u...@mydomain.com;
$pwd=mypassword;
$ds=ldap_connect($ldap);
$ldapbind=false;
if(ldap_set_option($ds, LDAP_OPT_PROTOCOL_VERSION, 3))
if(ldap_set_option($ds, LDAP_OPT_REFERRALS, 0))
if(ldap_start_tls($ds))
$ldapbind = @ldap_bind($ds, $usr, $pwd);
ldap_close($ds);
if(!$ldapbind)
echo ERROR;
else
echo OK;
?
6)Restart the server: /etc/init.d/apache2 restart
7)Open Firefox and write: http://localhost/ldaptlstest.php
;) Works fine
[2009-11-27 09:19:01] jcarlos at dsi dot uclm dot es
In Step 1, I have downloaded the certificate the the url
https://www.myDomain.com
[2009-11-26 11:05:18] paj...@php.net
Moving to the to be documented state, it could be very usefull to have
this info in the ldap documentation.
[2009-11-26 10:54:10] jcarlos at dsi dot uclm dot es
A little manual, for a easy configuration
INTEGRATING ACTIVE DIRECTORY WITH PHP-LDAP AND TLS
==
My configuration:
Apache/2.2.14 (Win32) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.11
NOTE 1: At the momment, the versión 5.3.1 fail with tls
NOTE 2: This example works on windows, but in linux is similar
1) Download the Certificate X.509 (PEM format) from a web browser, I
used Firefox. I put the name webcert.crt
2) Create the folder c:\openldap\sysconf
3) Copy the file webcert.crt to c:\openldap\sysconf
4) With notepad you must create the file c:\openldap\sysconf\ldap.conf
file. The file contents:
TLS_REQCERT never
TLS_CACERT c:\openldap\sysconf\webcert.crt
5) The code:
?php
$ldap=ldap.myDomain.com;
$usr=u...@mydomain.com;
$pwd
#50596 [Fbk-Opn]: File in Wrong Format errors
ID: 50596
User updated by: Steve dot Cleveland at orst dot edu
Reported By: Steve dot Cleveland at orst dot edu
-Status: Feedback
+Status: Open
Bug Type: Compile Failure
Operating System: RHEL5.4 64bit
PHP Version: 5.2.12
New Comment:
That seemed to fix it. Thanks!
Previous Comments:
[2009-12-29 10:39:08] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
I'm pretty sure this is fixed in the repo.
[2009-12-28 21:04:59] Steve dot Cleveland at orst dot edu
I also get the same error with libltdl.so and the --with-mcrypt
option:
# rpm -q --qf %{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n mcrypt
mcrypt-2.6.4-3.el5.i386
mcrypt-2.6.4-3.el5.x86_64
# rpm -q --qf %{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n libtool-ltdl
libtool-ltdl-1.5.22-7.el5_4.x86_64
libtool-ltdl-1.5.22-7.el5_4.i386
# locate libltdl.so
/usr/lib/libltdl.so
/usr/lib/libltdl.so.3
/usr/lib/libltdl.so.3.1.4
/usr/lib64/libltdl.so
/usr/lib64/libltdl.so.3
/usr/lib64/libltdl.so.3.1.4
./configure --with-apxs=/private/httpd/bin/apxs --with-mcrypt
make
...
sapi/apache/mod_php5.lo sapi/apache/php_apache.lo
main/internal_functions.lo -lcrypt -lcrypt -lrt -lmcrypt -lltdl -lresolv
-lm -ldl -lnsl -lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt
-lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt -o libphp5.la
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.so when searching
for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.a when searching
for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.so when searching
for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.a when searching
for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/librt.so when searching for
-lrt
/usr/bin/ld: skipping incompatible /usr/lib/librt.a when searching for
-lrt
/usr/bin/ld: skipping incompatible /usr/lib/libmcrypt.so when searching
for -lmcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libmcrypt.a when searching
for -lmcrypt
/usr/lib/libltdl.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make: *** [libphp5.la] Error 1
[2009-12-28 20:29:04] Steve dot Cleveland at orst dot edu
Sorry, forgot to mention that the compile works fine on 5.2.11 and
previous.
[2009-12-28 20:26:40] Steve dot Cleveland at orst dot edu
Description:
Starting with PHP 5.2.12, the final part of the 'make' process fails.
It appears if a system has both 32bit and 64bit libraries, building the
apache1 module tries to link to the 32bit library and fails with File
in wrong format.
The issue doesn't happen with the CGI/CLI versions.
The apache version is 1.3.41
Reproduce code:
---
# locate libdb-4.3.so
/lib/libdb-4.3.so
/lib64/libdb-4.3.so
/usr/lib/libdb-4.3.so
/usr/lib64/libdb-4.3.so
# rpm -q --qf %{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n db4
db4-4.3.29-10.el5.x86_64
db4-4.3.29-10.el5.i386
./configure --enable-dba --with-db4
--with-apxs=/private/httpd/bin/apxs
make
Expected result:
successful build
Actual result:
--
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.so when searching
for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.a when searching
for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.so when searching
for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.a when searching
for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/librt.so when searching for
-lrt
/usr/bin/ld: skipping incompatible /usr/lib/librt.a when searching for
-lrt
/usr/lib/libdb-4.3.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make: *** [libphp5.la] Error 1
--
Edit this bug report at http://bugs.php.net/?id=50596edit=1
#50596 [NEW]: File in Wrong Format errors
From: Steve dot Cleveland at orst dot edu
Operating system: RHEL5.4 64bit
PHP version: 5.2.12
PHP Bug Type: Compile Failure
Bug description: File in Wrong Format errors
Description:
Starting with PHP 5.2.12, the final part of the 'make' process fails. It
appears if a system has both 32bit and 64bit libraries, building the
apache1 module tries to link to the 32bit library and fails with File in
wrong format.
The issue doesn't happen with the CGI/CLI versions.
The apache version is 1.3.41
Reproduce code:
---
# locate libdb-4.3.so
/lib/libdb-4.3.so
/lib64/libdb-4.3.so
/usr/lib/libdb-4.3.so
/usr/lib64/libdb-4.3.so
# rpm -q --qf %{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n db4
db4-4.3.29-10.el5.x86_64
db4-4.3.29-10.el5.i386
./configure --enable-dba --with-db4 --with-apxs=/private/httpd/bin/apxs
make
Expected result:
successful build
Actual result:
--
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.so when searching for
-lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.a when searching for
-lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.so when searching for
-lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.a when searching for
-lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/librt.so when searching for
-lrt
/usr/bin/ld: skipping incompatible /usr/lib/librt.a when searching for
-lrt
/usr/lib/libdb-4.3.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make: *** [libphp5.la] Error 1
--
Edit bug report at http://bugs.php.net/?id=50596edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50596r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50596r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50596r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50596r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50596r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50596r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50596r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50596r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50596r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50596r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50596r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50596r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50596r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50596r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50596r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50596r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50596r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50596r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50596r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50596r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50596r=mysqlcfg
#50596 [Com]: File in Wrong Format errors
ID: 50596
Comment by: Steve dot Cleveland at orst dot edu
Reported By: Steve dot Cleveland at orst dot edu
Status: Open
Bug Type: Compile Failure
Operating System: RHEL5.4 64bit
PHP Version: 5.2.12
New Comment:
Sorry, forgot to mention that the compile works fine on 5.2.11 and
previous.
Previous Comments:
[2009-12-28 20:26:40] Steve dot Cleveland at orst dot edu
Description:
Starting with PHP 5.2.12, the final part of the 'make' process fails.
It appears if a system has both 32bit and 64bit libraries, building the
apache1 module tries to link to the 32bit library and fails with File
in wrong format.
The issue doesn't happen with the CGI/CLI versions.
The apache version is 1.3.41
Reproduce code:
---
# locate libdb-4.3.so
/lib/libdb-4.3.so
/lib64/libdb-4.3.so
/usr/lib/libdb-4.3.so
/usr/lib64/libdb-4.3.so
# rpm -q --qf %{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n db4
db4-4.3.29-10.el5.x86_64
db4-4.3.29-10.el5.i386
./configure --enable-dba --with-db4
--with-apxs=/private/httpd/bin/apxs
make
Expected result:
successful build
Actual result:
--
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.so when searching
for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.a when searching
for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.so when searching
for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.a when searching
for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/librt.so when searching for
-lrt
/usr/bin/ld: skipping incompatible /usr/lib/librt.a when searching for
-lrt
/usr/lib/libdb-4.3.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make: *** [libphp5.la] Error 1
--
Edit this bug report at http://bugs.php.net/?id=50596edit=1
#50596 [Com]: File in Wrong Format errors
ID: 50596
Comment by: Steve dot Cleveland at orst dot edu
Reported By: Steve dot Cleveland at orst dot edu
Status: Open
Bug Type: Compile Failure
Operating System: RHEL5.4 64bit
PHP Version: 5.2.12
New Comment:
I also get the same error with libltdl.so and the --with-mcrypt
option:
# rpm -q --qf %{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n mcrypt
mcrypt-2.6.4-3.el5.i386
mcrypt-2.6.4-3.el5.x86_64
# rpm -q --qf %{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n libtool-ltdl
libtool-ltdl-1.5.22-7.el5_4.x86_64
libtool-ltdl-1.5.22-7.el5_4.i386
# locate libltdl.so
/usr/lib/libltdl.so
/usr/lib/libltdl.so.3
/usr/lib/libltdl.so.3.1.4
/usr/lib64/libltdl.so
/usr/lib64/libltdl.so.3
/usr/lib64/libltdl.so.3.1.4
./configure --with-apxs=/private/httpd/bin/apxs --with-mcrypt
make
...
sapi/apache/mod_php5.lo sapi/apache/php_apache.lo
main/internal_functions.lo -lcrypt -lcrypt -lrt -lmcrypt -lltdl -lresolv
-lm -ldl -lnsl -lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt
-lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt -o libphp5.la
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.so when searching
for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.a when searching
for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.so when searching
for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.a when searching
for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/librt.so when searching for
-lrt
/usr/bin/ld: skipping incompatible /usr/lib/librt.a when searching for
-lrt
/usr/bin/ld: skipping incompatible /usr/lib/libmcrypt.so when searching
for -lmcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libmcrypt.a when searching
for -lmcrypt
/usr/lib/libltdl.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make: *** [libphp5.la] Error 1
Previous Comments:
[2009-12-28 20:29:04] Steve dot Cleveland at orst dot edu
Sorry, forgot to mention that the compile works fine on 5.2.11 and
previous.
[2009-12-28 20:26:40] Steve dot Cleveland at orst dot edu
Description:
Starting with PHP 5.2.12, the final part of the 'make' process fails.
It appears if a system has both 32bit and 64bit libraries, building the
apache1 module tries to link to the 32bit library and fails with File
in wrong format.
The issue doesn't happen with the CGI/CLI versions.
The apache version is 1.3.41
Reproduce code:
---
# locate libdb-4.3.so
/lib/libdb-4.3.so
/lib64/libdb-4.3.so
/usr/lib/libdb-4.3.so
/usr/lib64/libdb-4.3.so
# rpm -q --qf %{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n db4
db4-4.3.29-10.el5.x86_64
db4-4.3.29-10.el5.i386
./configure --enable-dba --with-db4
--with-apxs=/private/httpd/bin/apxs
make
Expected result:
successful build
Actual result:
--
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.so when searching
for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.a when searching
for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.so when searching
for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/libcrypt.a when searching
for -lcrypt
/usr/bin/ld: skipping incompatible /usr/lib/librt.so when searching for
-lrt
/usr/bin/ld: skipping incompatible /usr/lib/librt.a when searching for
-lrt
/usr/lib/libdb-4.3.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make: *** [libphp5.la] Error 1
--
Edit this bug report at http://bugs.php.net/?id=50596edit=1
#49179 [NEW]: zero problem in if and switch
From: steve at ezd dot com
Operating system: linux
PHP version: 5.2.10
PHP Bug Type: *General Issues
Bug description: zero problem in if and switch
Description:
please run source code, it's self explained
it seems that when use 0 to compare with string, it returns true all the
time,
problem in if is when using ==, === has no problem
in switch case, it matches the first non number case
Reproduce code:
---
if (0==a) echo this is ture.;
$check=0;
switch ($check)
{
case 'a':
echo this is a ;
break;
default :
echo no match;
}
Expected result:
no match
Actual result:
--
this is ture.this is a
--
Edit bug report at http://bugs.php.net/?id=49179edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49179r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49179r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49179r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49179r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49179r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49179r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49179r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49179r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49179r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49179r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49179r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49179r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49179r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49179r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49179r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49179r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49179r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49179r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49179r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49179r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49179r=mysqlcfg
#23815 [Com]: imagecopymerge doesn't respect alpha-channel in PNG-24 file
ID: 23815
Comment by: steve at redmonkey dot org
Reported By: bjorn at smokingmedia dot com
Status: Assigned
Bug Type: GD related
Operating System: Linux pluto 2.4.18lvm-r1
PHP Version: 5.2.9
Assigned To: pajoye
New Comment:
Thanks, understood. Although, I do think it would be a useful feature,
perhaps there's scope for an 'imagecopymergealpha' type function in the
future?
Previous Comments:
[2009-07-20 08:43:04] paj...@php.net
imagecopymerge was not meant to support the alpha channel but to
emulate it via pct. It was also not meant to use both the alpha or the
pct value to blend an image over another.
[2009-07-20 05:44:49] steve at redmonkey dot org
To make life a little easier I've put the notes and examples together
on a simple web page at http://www.redmonkey.org/php-bug-23815/
After investigating the code base a little further I've realised my
patch solution can be made more efficient as there is no need to make a
copy of the source or pass the image over to gdImageCopy once the new
alpha level has been set as we've already done the all the work and can
simply set the pixels RGBA index within the second image scan.
The revised patch (which is also available from a link on the web page)
is as follows
--- php-5.3.0/ext/gd/libgd/gd.c 2009-05-27 08:17:54.0 +0100
+++ php-5.3.0-build/ext/gd/libgd/gd.c 2009-07-20 05:54:21.709936176
+0100
@@ -2255,6 +2255,67 @@
int ncR, ncG, ncB;
toy = dstY;
+ if (pct == 100) {
+ /* no opacity adjustment required pass through to gdImageCopy()
*/
+ gdImageCopy(dst, src, dstX, dstY, srcX, srcY, w, h);
+ return;
+ }
+
+ if (pct == 0) {
+ /* 0% opacity? nothing needs to be done */
+ return;
+ }
+
+ if (src-trueColor dst-trueColor) {
+ /* support for maintaining the alpha (transparency) of both
source
and
+* destination images (assuming they are true colour) while
opacity
blending.
+*/
+ int ca, cr, cg, cb;
+ float na;
+ float ac;
+
+ /* we need to loop through the src image to get the max
transparency
level */
+ int mt = 0;
+
+ for (y = 0; y h; y++) {
+ for (x = 0; x w; x++) {
+ c = gdImageGetTrueColorPixel (src, srcX + x,
srcY + y);
+ ca = gdImageAlpha(src, c);
+
+ mt = ca mt ? ca : mt;
+ }
+ }
+
+ /* src has no transparency? set to use full alpha range */
+ mt = mt == gdAlphaOpaque ? gdAlphaMax : mt;
+
+ /* alpha correction factor */
+ ac = (float)mt / gdAlphaMax;
+
+ /* loop through the image again and set/adjust alpha channel
level
*/
+ for (y = 0; y h; y++) {
+ for (x = 0; x w; x++) {
+ c = gdImageGetTrueColorPixel (src, srcX + x,
srcY + y);
+ ca = gdImageAlpha(src, c);
+ cr = gdImageRed(src, c);
+ cg = gdImageGreen(src, c);
+ cb = gdImageBlue(src, c);
+
+ na = (ca + gdAlphaMax - (gdAlphaMax *
((float)pct / 100))) * ac;
+ na = (na gdAlphaMax)? gdAlphaMax : ((na
gdAlphaOpaque)?
gdAlphaOpaque: na);
+
+ int nc = gdImageColorAllocateAlpha(src, cr, cg,
cb, (int)na);
+ if (nc == -1) {
+ gdImageColorClosestAlpha(src, cr, cg,
cb, (int)na);
+ }
+
+ gdImageSetPixel (dst, dstX + x, dstY + y, nc);
+ }
+ }
+
+ return;
+ }
+
for (y = srcY; y (srcY + h); y++) {
tox = dstX;
for (x = srcX; x (srcX + w); x++) {
[2009-07-20 01:52:43] steve dot denim at redmonkey dot org
I have run into the same problem and can reproduce the example from
checat at yandex dot ru.
I have also provided additional examples and a patch for the solution I
have come with.
For the examples I've used two image files 'tux.png' for the background
(destination) image and 'ff-logo-sm.png' for the overlay (source) image,
these can be found at www.redmonkey.org/php-bug-23815/tux.png and
www.redmonkey.org/php-bug-23815/ff-logo-sm.png respectively.
If I run these images through imagecopy() with the following code..
$bg
#23815 [Com]: imagecopymerge doesn't respect alpha-channel in PNG-24 file
ID: 23815
Comment by: steve dot denim at redmonkey dot org
Reported By: bjorn at smokingmedia dot com
Status: Assigned
Bug Type: GD related
Operating System: Linux pluto 2.4.18lvm-r1
PHP Version: 5.2.9
Assigned To: pajoye
New Comment:
I have run into the same problem and can reproduce the example from
checat at yandex dot ru.
I have also provided additional examples and a patch for the solution I
have come with.
For the examples I've used two image files 'tux.png' for the background
(destination) image and 'ff-logo-sm.png' for the overlay (source) image,
these can be found at www.redmonkey.org/php-bug-23815/tux.png and
www.redmonkey.org/php-bug-23815/ff-logo-sm.png respectively.
If I run these images through imagecopy() with the following code..
$bg = imagecreatefrompng('tux.png');
$over = imagecreatefrompng('ff-logo-sm.png');
imagealphablending($bg, true);
imagesavealpha($bg, true);
imagecopy($bg, $over, 276, 300, 0, 0, 123, 119);
imagepng($bg, 'tux-fox-imagecopy.png');
The alpha channels of both images seem to be handleed and
merged/blended in a way that I think most users would expect, the
resulting image can be found at
www.redmonkey.org/php-bug-23815/tux-fox-imagecopy.png
However, if I run the two images through imagecopymerge with the
following code..
$bg = imagecreatefrompng('tux.png');
$over = imagecreatefrompng('ff-logo-sm.png');
imagealphablending($bg, true);
imagesavealpha($bg, true);
imagecopymerge($bg, $over, 276, 300, 0, 0, 123, 119, 100);
imagepng($bg, 'tux-fox-imagecopymerge-100-without-patch.png');
The resulting image is not what I would expect, in this case, it seems
that the alpha channel of the destination image is maintained but the
alpha channel of the source image is completely ignored, the resulting
image can be found at
www.redmonkey.org/php-bug-23815/tux-fox-imagecopymerge-100-without-patch.png
Applying a 50% reduction in opacity..
$bg = imagecreatefrompng('tux.png');
$over = imagecreatefrompng('ff-logo-sm.png');
imagealphablending($bg, true);
imagesavealpha($bg, true);
imagecopymerge($bg, $over, 276, 300, 0, 0, 123, 119, 50);
imagepng($bg, 'tux-fox-imagecopymerge-50-without-patch.png');
Also has the same issue, the resulting image can be found at
www.redmonkey.org/php-bug-23815/tux-fox-imagecopymerge-50-without-patch.png
After applying my patch the results from imagcopymerge are more inline
with what I persoanlly would expect in that the alpha channels of both
images are maintained during the copy/merge process.
With the following code..
$bg = imagecreatefrompng('tux.png');
$over = imagecreatefrompng('ff-logo-sm.png');
imagealphablending($bg, true);
imagesavealpha($bg, true);
imagecopymerge($bg, $over, 276, 300, 0, 0, 123, 119, 100);
imagepng($bg, 'tux-fox-imagecopymerge-100-with-patch.png');
The resulting image can be viewed at
www.redmonkey.org/php-bug-23815/tux-fox-imagecopymerge-100-with-patch.png
And with the following code..
$bg = imagecreatefrompng('tux.png');
$over = imagecreatefrompng('ff-logo-sm.png');
imagealphablending($bg, true);
imagesavealpha($bg, true);
imagecopymerge($bg, $over, 276, 300, 0, 0, 123, 119, 50);
imagepng($bg, 'tux-fox-imagecopymerge-50-with-patch.png');
The resulting image can be viewed at
www.redmonkey.org/php-bug-23815/tux-fox-imagecopymerge-50-with-patch.png
The patch as applied to ext/gd/libgd/gd.c is as follows.
--- php-5.3.0/ext/gd/libgd/gd.c 2009-05-27 08:17:54.0 +0100
+++ php-5.3.0-build/ext/gd/libgd/gd.c 2009-07-19 22:28:37.312702552
+0100
@@ -2255,6 +2255,83 @@
int ncR, ncG, ncB;
toy = dstY;
+ if (pct == 100) {
+ /* no opacity adjustment required pass through to gdImageCopy()
*/
+ gdImageCopy(dst, src, dstX, dstY, srcX, srcY, w, h);
+ return;
+ }
+
+ if (pct == 0) {
+ /* 0% opacity? nothing needs to be done */
+ return;
+ }
+
+ if (src-trueColor dst-trueColor) {
+ /* support for maintaining the alpha (transparency) of both
source
and
+* destination images (assuming they are true colour) while
opacity
blending.
+*/
+ gdImagePtr srcback;
+ int ca, cr, cg, cb;
+ float na;
+ float ac;
+
+ /* we adjust the alpha levels on a copy of the source image, the
copy
+* only needs to be as large as the crop area if there is one
+*/
+ srcback = gdImageCreateTrueColor (w, h);
+ if (srcback==NULL) {
+ return;
+ }
+
+ gdImageAlphaBlending(srcback, 0);
+ gdImageSaveAlpha(srcback, 1);
+ gdImageCopy(srcback, src, 0, 0, srcX, srcY, w, h);
+
+ /* we need to loop through the src image to get the max
transparency
level */
+ int mt = 0
#23815 [Com]: imagecopymerge doesn't respect alpha-channel in PNG-24 file
ID: 23815
Comment by: steve at redmonkey dot org
Reported By: bjorn at smokingmedia dot com
Status: Assigned
Bug Type: GD related
Operating System: Linux pluto 2.4.18lvm-r1
PHP Version: 5.2.9
Assigned To: pajoye
New Comment:
To make life a little easier I've put the notes and examples together
on a simple web page at http://www.redmonkey.org/php-bug-23815/
After investigating the code base a little further I've realised my
patch solution can be made more efficient as there is no need to make a
copy of the source or pass the image over to gdImageCopy once the new
alpha level has been set as we've already done the all the work and can
simply set the pixels RGBA index within the second image scan.
The revised patch (which is also available from a link on the web page)
is as follows
--- php-5.3.0/ext/gd/libgd/gd.c 2009-05-27 08:17:54.0 +0100
+++ php-5.3.0-build/ext/gd/libgd/gd.c 2009-07-20 05:54:21.709936176
+0100
@@ -2255,6 +2255,67 @@
int ncR, ncG, ncB;
toy = dstY;
+ if (pct == 100) {
+ /* no opacity adjustment required pass through to gdImageCopy()
*/
+ gdImageCopy(dst, src, dstX, dstY, srcX, srcY, w, h);
+ return;
+ }
+
+ if (pct == 0) {
+ /* 0% opacity? nothing needs to be done */
+ return;
+ }
+
+ if (src-trueColor dst-trueColor) {
+ /* support for maintaining the alpha (transparency) of both
source
and
+* destination images (assuming they are true colour) while
opacity
blending.
+*/
+ int ca, cr, cg, cb;
+ float na;
+ float ac;
+
+ /* we need to loop through the src image to get the max
transparency
level */
+ int mt = 0;
+
+ for (y = 0; y h; y++) {
+ for (x = 0; x w; x++) {
+ c = gdImageGetTrueColorPixel (src, srcX + x,
srcY + y);
+ ca = gdImageAlpha(src, c);
+
+ mt = ca mt ? ca : mt;
+ }
+ }
+
+ /* src has no transparency? set to use full alpha range */
+ mt = mt == gdAlphaOpaque ? gdAlphaMax : mt;
+
+ /* alpha correction factor */
+ ac = (float)mt / gdAlphaMax;
+
+ /* loop through the image again and set/adjust alpha channel
level
*/
+ for (y = 0; y h; y++) {
+ for (x = 0; x w; x++) {
+ c = gdImageGetTrueColorPixel (src, srcX + x,
srcY + y);
+ ca = gdImageAlpha(src, c);
+ cr = gdImageRed(src, c);
+ cg = gdImageGreen(src, c);
+ cb = gdImageBlue(src, c);
+
+ na = (ca + gdAlphaMax - (gdAlphaMax *
((float)pct / 100))) * ac;
+ na = (na gdAlphaMax)? gdAlphaMax : ((na
gdAlphaOpaque)?
gdAlphaOpaque: na);
+
+ int nc = gdImageColorAllocateAlpha(src, cr, cg,
cb, (int)na);
+ if (nc == -1) {
+ gdImageColorClosestAlpha(src, cr, cg,
cb, (int)na);
+ }
+
+ gdImageSetPixel (dst, dstX + x, dstY + y, nc);
+ }
+ }
+
+ return;
+ }
+
for (y = srcY; y (srcY + h); y++) {
tox = dstX;
for (x = srcX; x (srcX + w); x++) {
Previous Comments:
[2009-07-20 01:52:43] steve dot denim at redmonkey dot org
I have run into the same problem and can reproduce the example from
checat at yandex dot ru.
I have also provided additional examples and a patch for the solution I
have come with.
For the examples I've used two image files 'tux.png' for the background
(destination) image and 'ff-logo-sm.png' for the overlay (source) image,
these can be found at www.redmonkey.org/php-bug-23815/tux.png and
www.redmonkey.org/php-bug-23815/ff-logo-sm.png respectively.
If I run these images through imagecopy() with the following code..
$bg = imagecreatefrompng('tux.png');
$over = imagecreatefrompng('ff-logo-sm.png');
imagealphablending($bg, true);
imagesavealpha($bg, true);
imagecopy($bg, $over, 276, 300, 0, 0, 123, 119);
imagepng($bg, 'tux-fox-imagecopy.png');
The alpha channels of both images seem to be handleed and
merged/blended in a way that I think most users would expect, the
resulting image can be found at
www.redmonkey.org/php-bug-23815/tux-fox-imagecopy.png
However, if I run the two images through imagecopymerge with the
following code..
$bg = imagecreatefrompng('tux.png');
$over
#48778 [Com]: Files on NTFS Mounted Volumes (Junctions) inaccessible
ID: 48778 Comment by: Steve at b-en-e dot com Reported By: cs at koch-aplsystems dot de Status: Open Bug Type: *General Issues Operating System: win32 only - XP SP3 PHP Version: 5.3.0 New Comment: Confirmed here. 5.2.8 does not have this problem, but 5.2.10 does, so it was introduced in the previous versions. Removing the junction from the picture solves the problem. Note that it is not only the source files: if the error log is directed to a junctioned folder apache ends the request with a connection reset by peer. Previous Comments: [2009-07-02 15:18:33] cs at koch-aplsystems dot de Description: Apache 2.2 DocumentRoot is on a NTFS drive with a Mounted Volume (NTFS Junction) Partition. All files the seem inaccessible to PHP 5.3.x (5.2.x version do not show this problem) Changing Apache DocumentRoot to a real directory on c: works around the problem. Reproduce code: --- not needed Expected result: php script loading Actual result: -- Fatal error: Unknown: Failed opening required 'C:/Web/apache-root/my_file.php' (include_path='.') in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/?id=48778edit=1
#33500 [Com]: imap_open() fails when the server advertises GSSAPI
ID: 33500
Comment by: steve dot englart at gmail dot com
Reported By: ed2019 at columbia dot edu
Status: Open
Bug Type: Feature/Change Request
Operating System: RHEL4
PHP Version: 4.3.10
New Comment:
I can't connect to Exchange 2007 sp1
PHP running on Windows 2000
C:\phpphp -v
PHP 5.2.8 (cli) (built: Dec 8 2008 19:31:23)
with Pear Net_POP3 1.3.6 stable
example from getMessage() after logon...
Error in authentication: USER NOT supported authentication
method!. This server supports these methods: GSSAPI, but I support APO
P,PLAIN,LOGIN,USER
Previous Comments:
[2009-01-07 20:07:47] spryde at aas dot com
Bug still present, 5.2.8, Centos 5.2.
[2008-12-07 03:59:17] phalenor at gmail dot com
imap_open() absolutely needs a way to specify the order of
authentication mechanisms to try. If one is attempting to do
username/password auth to an imap server that supports GSSAPI,
imap_open() tries GSSAPI then stops, never attempting to do PLAIN auth
or otherwise.
This should not be viewed as a misconfiguration of the imap server, as
clients that use c-client manage to try multiple auth mechs.
[2008-10-10 13:36:24] php at eikel dot org
Hello,
this problem still exists in PHP 5.2.6. As stated by Mark Crispin [1]
this problem is probably a bug in the PHP IMAP implementation. Any
suggestions how to fix this problem?
Regards,
Benjamin
[1]
http://mailman2.u.washington.edu/pipermail/imap-uw/2005-June/000101.html
[2008-06-20 15:04:41] josh_barth at hotmail dot com
If you happen to run across this error while attempting to connect to
an Exchange server... In my case Exchange 2007 from Ubuntu
Install Kerberos client i.e heimdal-client
Switch to the apache userfor Ubuntu that is www-data:
su www-data
kinit usern...@domainname.com 'Mind the case lo...@upper
klist 'Will show current ticket granting ticket and other tokens
Note: krbtgt will expire and this procedure will need to be repeated I
am currently researching a method to ensure an active krbtgt at all
times
Try testing with this script as the apache user, replacing ipaddress,
username, domainname and password.
?php
$mbox =
imap_open({ipaddress:993/imap/ssl/novalidate-cert/notls/debug}INBOX,
domainname/username, password) or
die(imap_last_error().brConnection Failure!);
echo h1Mailboxes/h1\n;
$folders = imap_listmailbox($mbox, {ipaddress:993}, *);
if ($folders == false) {
echo Call failedbr /\n;
} else {
foreach ($folders as $val) {
echo $val . br /\n;
}
}
echo h1Headers in INBOX/h1\n;
$headers = imap_headers($mbox);
if ($headers == false) {
echo Call failedbr /\n;
} else {
foreach ($headers as $val) {
echo $val . br /\n;
}
}
imap_close($mbox);
?
[2008-05-26 10:36:17] ruben at dedigate dot com
This issue is also in PHP5 ... there's no way to open an imap/pop
connection to an exchange2007 server that announces GSSAPI :-(
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/33500
--
Edit this bug report at http://bugs.php.net/?id=33500edit=1
#46309 [NEW]: JSON encode simplexml object loses attributes on leaf nodes
From: steve at stevegoodwin dot net
Operating system: Windows
PHP version: 5.2.6
PHP Bug Type: JSON related
Bug description: JSON encode simplexml object loses attributes on leaf nodes
Description:
If you json encode a simplexml object, any xml leaf nodes will lose
their attributes
The attached script has two small xml strings. One with attributes
on the leaf node, one without.
When you run the script, attribute values disappear for the second
json string
Reproduce code:
---
?php
$xml_string1 = '?xml version=1.0?ItemListItem
ID=456ExtraTagABC/ExtraTag/ItemItem
ID=789ExtraTagDEF/ExtraTag/Item/ItemList';
$xml_string2 = '?xml version=1.0?ItemListItem
ID=456ABC/ItemItem ID=789DEF/Item/ItemList';
$xml_obj = simplexml_load_string($xml_string1);
$json = json_encode($xml_obj);
print Input XML Document: . htmlentities($xml_string1) .
br/attributes are present:br/$jsonbr/br/;
$xml_obj = simplexml_load_string($xml_string2);
$json = json_encode($xml_obj);
print Input XML Document: . htmlentities($xml_string2) .
br/attributes are bNot/b present:br/$jsonbr/br/;
phpinfo();
?
Expected result:
Input XML Document: ?xml version=1.0?ItemListItem
ID=456ExtraTagABC/ExtraTag/ItemItem
ID=789ExtraTagDEF/ExtraTag/Item/ItemList
attributes are present:
{Item:[{@attributes:{ID:456},ExtraTag:ABC},{@attributes
:{ID:789},ExtraTag:DEF}]}
Input XML Document: ?xml version=1.0?ItemListItem
ID=456ABC/ItemItem ID=789DEF/Item/ItemList
attributes are Not present:
{Item:[ABC,DEF]}
Actual result:
--
json string above labeled with attributes are present: is correctly
json encoded.
json string above labeled with attributes are Not present: is
incorrectly json encoded. The json object does not have the
attribute name or values
--
Edit bug report at http://bugs.php.net/?id=46309edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46309r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46309r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46309r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=46309r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=46309r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=46309r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=46309r=needscript
Try newer version:http://bugs.php.net/fix.php?id=46309r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=46309r=support
Expected behavior:http://bugs.php.net/fix.php?id=46309r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46309r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46309r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=46309r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46309r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=46309r=dst
IIS Stability:http://bugs.php.net/fix.php?id=46309r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=46309r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=46309r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=46309r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=46309r=mysqlcfg
#45046 [NEW]: Missing php5servlet.dll in distribution
From: steve at thebroughs dot com Operating system: Windows PHP version: 5.2.6 PHP Bug Type: *General Issues Bug description: Missing php5servlet.dll in distribution Description: I'm trying to install PHP into a TOMCAT server and have read a number of articles that refer to php5servlet.dll. This file is available in V5.2.5 but is not included the latest release. Is this file missing, or has it been replaced with another DLL? -- Edit bug report at http://bugs.php.net/?id=45046edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45046r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45046r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45046r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45046r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45046r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45046r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45046r=needscript Try newer version:http://bugs.php.net/fix.php?id=45046r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45046r=support Expected behavior:http://bugs.php.net/fix.php?id=45046r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45046r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45046r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45046r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45046r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45046r=dst IIS Stability:http://bugs.php.net/fix.php?id=45046r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45046r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45046r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45046r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45046r=mysqlcfg
#38238 [Com]: PHP with PEAR running on IIS
ID: 38238 Comment by: steve dot mills84 at gmail dot com Reported By: rmarescu at gmail dot com Status: No Feedback Bug Type: IIS related Operating System: MS Windows Server 2003 PHP Version: 5.1.4 New Comment: Also having this used under IIS 6, PHP 5.2.6 ISAPI Previous Comments: [2007-03-13 21:18:29] jmvoodoo at gmail dot com I am getting this same behavior with 4.4.6, latest stable version that i'm aware of. [2007-02-01 10:43:39] [EMAIL PROTECTED] Upgrade to the latest stable version. [2007-02-01 07:02:25] shinijin at mail dot ru PHP has encountered an Access Violation at 7C8224B PHP 5.1.4 Win IIS MySQL Curent bug apears during the HTML pages generation from php. Is there any progress on this issue? [2006-10-10 20:43:49] chavousc at gmail dot com I, too, am receiving access violation 7C8224B2 on IIS using the ISAPI module. It only starts to occur after the site has been running for a few hours to a few days... I'm running PHP version 5.1.6 mysql 5.0.24-community-nt Win2k3/IIS/ISAPI module I will happily assist however I can. I'm not sure if I'll be able to get the backtrace on my production machine, but if you think it will help, I will try! [2006-09-25 19:45:53] webmaster at impactbs dot com Just as a follow up, switching to CGI has stabilized the site but it's running more slowly. 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/38238 -- Edit this bug report at http://bugs.php.net/?id=38238edit=1
#12127 [Com]: Function fgetcsv() lost some letters
ID: 12127 Comment by: steve at google dot com Reported By: bitlz at mail dot ru Status: No Feedback Bug Type: Filesystem function related Operating System: Windows 2000 Professional PHP Version: 4.3.1 New Comment: confirming on PHP 5.2.0-8 Csv file line:- 1,Alert Status,État de l'alerte fgetcsv ignores the É It only happens if É is right after the delimiter , Only way I got around this was to save the file as UTF8 as mention in the earlier comment. Didnt work even with setlocale(LC_ALL,'fr_FR.ISO-8859-1') Previous Comments: [2007-06-01 12:58:59] laus at tinevej dot dk I got the same problem in php-5.2.2 with danish special letters (ÆØÅ) when it is saved in iso-8859-1. But if i save the csv files as utf-8 the problem disappears. [2006-11-24 09:32:47] info at netangels dot ru Guys The problem still occurs even in PHP 5.2.0 and PHP 5.1.x as well as in 5.0.x but we've found a workaround. If csv-file is in russian encoding (cp1251) then php-script should do: setlocale(LC_ALL, ru_RU); BEFORE call fgetcsv() if current locale is not ru_RU. If locale is ru_RU already, it works well on all versions of php from 4.3.x up to the latest 5.2.0 without requiring setlocale() [2003-03-09 18:41:00] [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. [2003-02-28 07:25:15] [EMAIL PROTECTED] And actually bug #21689 is a duplicate of this report... [2003-02-28 07:16:20] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip I've already committed a fix for this issue. 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/12127 -- Edit this bug report at http://bugs.php.net/?id=12127edit=1
#44859 [NEW]: is_readable() returns incorrect result
From: phpbugs at steve dot ipapp dot com
Operating system: Win 2000 SP4
PHP version: 5.2.5
PHP Bug Type: Filesystem function related
Bug description: is_readable() returns incorrect result
Description:
NT ACL Permissions can be modified in Windows by right clicking on the
file, going to properties, and security. Clicking the Everyone user and
hitting Deny Read, will prevent ANYTHING from reading, even if they have
READ permissions granted elsewhere.
is_readable() doesn't seem to care and thinks that all these files are
readable, when in fact they aren't. is_writeable() probably has the same
problem. Previous Bugs Identified with this have been closed: 41519.
Reproduce code:
---
$some_file = 'C:\\path\to\file.txt';
if(is_readable($some_file))
{
echo file_get_contents($some_file);
} else
{
echo This file isn't readable;
}
Expected result:
With NTFS ACL Permissions set to allow reading:
*Contents of File*
With NTFS ACL Permissions set to disallow reading:
This file isn't readable;
Actual result:
--
With NTFS ACL Permissions set to allow reading:
*Contents of File*
With NTFS ACL Permissions set to disallow reading:
Warning: file_get_contents(C:\\path\to\file.txt)
[function.file-get-contents]: failed to open stream: Permission denied in
C:\\path\to\script.php on line 4
--
Edit bug report at http://bugs.php.net/?id=44859edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44859r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44859r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44859r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44859r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44859r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44859r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44859r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44859r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44859r=support
Expected behavior:http://bugs.php.net/fix.php?id=44859r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44859r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44859r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44859r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44859r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44859r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44859r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44859r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44859r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44859r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44859r=mysqlcfg
#44411 [Opn]: Broken Compatibility
ID: 44411
User updated by: phpbugs at steve dot ipapp dot com
Reported By: phpbugs at steve dot ipapp dot com
Status: Open
Bug Type: SimpleXML related
Operating System: ANY
PHP Version: 5.2.5
New Comment:
But then what is the difference between strict comparision and loose
comparison for SimpleXMLObjects?
I'm then also unclear as to what exactly == was doing prior to 5.2.0.
It seemed to convey the idea atleast to me and one other person that the
classical object equality of 'if all the members are equal' seemed to
work. Furthermore if this functionality was not buggy or superious would
there be some way to have another method, perhaps equals() that achieves
this?
Previous Comments:
[2008-03-12 04:41:51] hubert dot roksor at gmail dot com
As per the manual chapter you quoted, the comparison operator compares
_objects_, and that's the key word here. You expect two equal XML trees
to be represented by two equal objects, and even though this expectation
is understandable, it is simply not the case. Those objects are
different. In fact, even if $sax1-value is equal to $sax1-value and
they come from the same tree, they are not identical. ($sax1-value !==
$sax1-value)
The bottom line is the comparison operator compares objects. If you
need an operator that understands the underlying data you will have to
use another mean. The solution proposed in the other bug report (compare
them as XML strings) sounds reasonable.
It would be nice to mention this quirk in the manual though, perhaps as
a new example? Comparing Elements and Elements
[2008-03-12 01:35:37] phpbugs at steve dot ipapp dot com
Description:
In PHP 5.0.x and 5.1.x two SimpleXMLElement objects were considered
equal if they represented the same data.
In PHP 5.2.x this does not seem to be the case anymore. This was
previously listed as bug 39866 [http://bugs.php.net/bug.php?id=39866],
but for some reason this was listed as bogus. In that bug it was noted
that we should look at Example 5 at http://php.net/simplexml. I'm
assuming this is Example 6 now [Comparing Elements and Attributes with
Text] , but this is incorrect as comparision will implicity cast
it to string anyway.
According to
http://www.php.net/manual/en/language.oop5.object-comparison.php:
When using the comparison operator (==), object variables are compared
in a simple manner, namely: Two object instances are equal if they have
the same attributes and values, and are instances of the same class...
On the other hand, when using the identity operator (===), object
variables are identical if and only if they refer to the same instance
of the same class.
Furthermore this backwards incompatible change is not listed in :
http://us.php.net/manual/en/migration52.incompatible.php.
Currently there is no equals method that we can call to get the
previous functionality back, and at the present moment this makes == no
longer transitive as especially since this makes == no longer
transitive as 'doc' == x1, 'doc' == x2, but x1 != x2.
I do not understand why ==, nor do I see value in, doing a strict
comparison for SimpleXMLObjects as ==, when according to the PHP Object
Comparison manual this should be ===.
Therefore I believe this is a bug.
Reproduce code:
---
$xmldoc = xmlvaluefoo/value/xml;
$sax1 = new SimpleXMLElement($xmldoc);
$sax2 = new SimpleXMLElement($xmldoc);
if($sax1 == $sax2)
{
echo TRUE;
} else
{
echo FALSE;
}
echo \n\n\n;
Expected result:
TRUE
Actual result:
--
FALSE
--
Edit this bug report at http://bugs.php.net/?id=44411edit=1
#44411 [NEW]: Broken Compatibility
From: phpbugs at steve dot ipapp dot com
Operating system: ANY
PHP version: 5.2.5
PHP Bug Type: SimpleXML related
Bug description: Broken Compatibility
Description:
In PHP 5.0.x and 5.1.x two SimpleXMLElement objects were considered equal
if they represented the same data.
In PHP 5.2.x this does not seem to be the case anymore. This was
previously listed as bug 39866 [http://bugs.php.net/bug.php?id=39866], but
for some reason this was listed as bogus. In that bug it was noted that we
should look at Example 5 at http://php.net/simplexml. I'm assuming this is
Example 6 now [Comparing Elements and Attributes with Text] , but this is
incorrect as comparision will implicity cast
it to string anyway.
According to
http://www.php.net/manual/en/language.oop5.object-comparison.php:
When using the comparison operator (==), object variables are compared in
a simple manner, namely: Two object instances are equal if they have the
same attributes and values, and are instances of the same class... On the
other hand, when using the identity operator (===), object variables are
identical if and only if they refer to the same instance of the same
class.
Furthermore this backwards incompatible change is not listed in :
http://us.php.net/manual/en/migration52.incompatible.php.
Currently there is no equals method that we can call to get the previous
functionality back, and at the present moment this makes == no longer
transitive as especially since this makes == no longer transitive as 'doc'
== x1, 'doc' == x2, but x1 != x2.
I do not understand why ==, nor do I see value in, doing a strict
comparison for SimpleXMLObjects as ==, when according to the PHP Object
Comparison manual this should be ===.
Therefore I believe this is a bug.
Reproduce code:
---
$xmldoc = xmlvaluefoo/value/xml;
$sax1 = new SimpleXMLElement($xmldoc);
$sax2 = new SimpleXMLElement($xmldoc);
if($sax1 == $sax2)
{
echo TRUE;
} else
{
echo FALSE;
}
echo \n\n\n;
Expected result:
TRUE
Actual result:
--
FALSE
--
Edit bug report at http://bugs.php.net/?id=44411edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44411r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44411r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44411r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44411r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44411r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44411r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44411r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44411r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44411r=support
Expected behavior:http://bugs.php.net/fix.php?id=44411r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44411r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44411r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44411r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44411r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44411r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44411r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44411r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44411r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44411r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44411r=mysqlcfg
#43582 [Fbk-Opn]: Core dump in _zend_mm_alloc_int
ID: 43582 User updated by: steve at grommit dot com Reported By: steve at grommit dot com -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: OpenSolaris (snv_75a) PHP Version: 5.2.5 New Comment: Nope - still crashes. I installed from the CVS tarball pointed at below, and just got the following core dump: [EMAIL PROTECTED]:core] 501$ mdb core.httpd.9922 Loading modules: [ libc.so.1 libnvpair.so.1 libuutil.so.1 libavl.so.1 ld.so.1 ] $c libphp5.so`_zend_mm_alloc_int+0x11f(82329e8, 40) libphp5.so`_emalloc+0x27(40) libphp5.so`_safe_emalloc+0xa0(10, 4, 0) libphp5.so`_ecalloc+0x2a(10, 4) libphp5.so`_zend_hash_init+0x8e(8047738, a, 0, 0, 0) libphp5.so`ps_srlzr_encode_php+0x48(80477b4, 80477ec) libphp5.so`php_session_encode+0x42(80477ec) libphp5.so`php_session_save_current_state+0x246(0, fdbb9d5c, 8047824, fd3d2cac, 82a6c40, fd2ac45c) libphp5.so`php_session_flush+0x54(8047878, fd2ac476, 1, e, fd2902bb, 82329e8) libphp5.so`zm_deactivate_session+0xb(1, e) libphp5.so`module_registry_cleanup+0x1a(82a6c78) libphp5.so`zend_hash_apply+0x54(fd413d60, fd2ac45c) libphp5.so`zend_deactivate_modules+0x55(838, fd414fc0, fd3d2cac, fd3d2cac, fd414fc0, 838) libphp5.so`php_request_shutdown+0x125(0) libphp5.so`php_handler+0x4ae(838) ap_run_handler+0x25(838) ap_invoke_handler+0xba(838) ap_process_request+0x50(838) ap_process_http_connection+0x52(8372260) ap_run_process_connection+0x25(8372260) ap_process_connection+0x3a(8372260, 8371fc8) child_main+0x2f6(6) make_child+0x84(80beaf8, 6) perform_idle_server_maintenance+0xe2(80bcc58) ap_mpm_run+0x234(80bcc58, 80ead10, 80beaf8) main+0x6e8(3, 8047e38, 8047e48) _start+0x7a(3, 8047ed4, 8047eeb, 8047eee, 0, 8047ef4) Since it looks like it happened at a different instruction, here's the disassembly: libphp5.so`_zend_mm_alloc_int+0x11f::dis libphp5.so`_zend_mm_alloc_int+0x104:testl %esi,%esi libphp5.so`_zend_mm_alloc_int+0x106: jne+0x7 libphp5.so`_zend_mm_alloc_int+0x10f libphp5.so`_zend_mm_alloc_int+0x108: jmp+0x231 libphp5.so`_zend_mm_alloc_int+0x33e libphp5.so`_zend_mm_alloc_int+0x10d:movl %ecx,%esi libphp5.so`_zend_mm_alloc_int+0x10f:movl 0x2874(%ebx),%eax libphp5.so`_zend_mm_alloc_int+0x115:movl (%eax),%eax libphp5.so`_zend_mm_alloc_int+0x117:testl %eax,%eax libphp5.so`_zend_mm_alloc_int+0x119: je +0x2 libphp5.so`_zend_mm_alloc_int+0x11d libphp5.so`_zend_mm_alloc_int+0x11b:call *%eax libphp5.so`_zend_mm_alloc_int+0x11d:movl (%esi),%eax libphp5.so`_zend_mm_alloc_int+0x11f:cmpl 0x4(%esi,%eax),%eax libphp5.so`_zend_mm_alloc_int+0x123: jne+0x15libphp5.so`_zend_mm_alloc_int+0x13a libphp5.so`_zend_mm_alloc_int+0x125:movl 0x4(%esi),%edx libphp5.so`_zend_mm_alloc_int+0x128:cmpl $0x3,%edx libphp5.so`_zend_mm_alloc_int+0x12b: je +0x1clibphp5.so`_zend_mm_alloc_int+0x149 libphp5.so`_zend_mm_alloc_int+0x12d:movl %edx,%eax libphp5.so`_zend_mm_alloc_int+0x12f:andl $0xfffc,%eax libphp5.so`_zend_mm_alloc_int+0x132:movl %esi,%ecx libphp5.so`_zend_mm_alloc_int+0x134:subl %eax,%ecx libphp5.so`_zend_mm_alloc_int+0x136:cmpl %edx,(%ecx) libphp5.so`_zend_mm_alloc_int+0x138: je +0xf libphp5.so`_zend_mm_alloc_int+0x149 and the register contents: $r %cs = 0x0043%eax = 0x3a726f72 %ds = 0x004b%ebx = 0xfd3d2cac %ss = 0x004b%ecx = 0x082329e8 %es = 0x004b%edx = 0x0003 %fs = 0x%esi = 0x087460e0 %gs = 0x01c3%edi = 0x %eip = 0xfd28f74b libphp5.so`_zend_mm_alloc_int+0x11f %ebp = 0x0804765c %kesp = 0x %eflags = 0x0246 id=0 vip=0 vif=0 ac=0 vm=0 rf=0 nt=0 iopl=0x0 status=of,df,IF,tf,sf,ZF,af,PF,cf %esp = 0x08047634 %trapno = 0xe %err = 0x4 It's definitely a recurring crash - unfortunately since it's in httpd, I don't know how to figure out what page/PHP instruction is causing it to trip. Got any suggestions for what I can do to help to try and narrow down the cause? Previous Comments: [2007-12-13 09:18:42] [EMAIL PROTECTED] 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 [2007-12-12 18:10:07] steve at grommit dot com Description: I'm seeing consistent core dumps of httpd in libphp5.so (compiled on my Solaris Nevada build 75a machine), all of them here: libphp5.so`_zend_mm_alloc_int+0x5e(82329e8, 2d) This is snv_75a on a quad core Intel xeon with PHP 5.2.5 and Apache2 2.2.3. Actual result: -- Stack trace: [EMAIL PROTECTED]:core] 501$ mdb core.httpd
#43582 [NEW]: Core dump in _zend_mm_alloc_int
From: steve at grommit dot com Operating system: OpenSolaris (snv_75a) PHP version: 5.2.5 PHP Bug Type: Apache2 related Bug description: Core dump in _zend_mm_alloc_int Description: I'm seeing consistent core dumps of httpd in libphp5.so (compiled on my Solaris Nevada build 75a machine), all of them here: libphp5.so`_zend_mm_alloc_int+0x5e(82329e8, 2d) This is snv_75a on a quad core Intel xeon with PHP 5.2.5 and Apache2 2.2.3. Actual result: -- Stack trace: [EMAIL PROTECTED]:core] 501$ mdb core.httpd.22142 $Loading modules: [ libc.so.1 libnvpair.so.1 libuutil.so.1 libavl.so.1 ld.so.1 ] $c libphp5.so`_zend_mm_alloc_int+0x5e(82329e8, 2d) libphp5.so`_emalloc+0x27(2d) libphp5.so`_zend_hash_quick_add_or_update+0x1f1(85cec90, 8999260, a, 7f4f5fed, 80438a8, 4) libphp5.so`_get_zval_ptr_ptr+0x17e(880a6c0, 8043940, 80438f0, 1) libphp5.so`ZEND_RECV_INIT_SPEC_CONST_HANDLER+0x103(8044168) libphp5.so`execute+0x12d(8714c90) libphp5.so`zend_do_fcall_common_helper_SPEC+0x29f(8044fd8) libphp5.so`ZEND_DO_FCALL_SPEC_CONST_HANDLER+0x67(8044fd8) libphp5.so`execute+0x12d(8906200) libphp5.so`zend_do_fcall_common_helper_SPEC+0x29f(8047558) libphp5.so`ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER+0x15(8047558) libphp5.so`execute+0x12d(823daf8) libphp5.so`zend_execute_scripts+0x128(8, 0, 3, 0, 8047b24, 0) libphp5.so`php_execute_script+0x26d(8047b24) libphp5.so`php_handler+0x426(838) ap_run_handler+0x25(838) ap_invoke_handler+0xba(838) ap_process_request+0x50(838) ap_process_http_connection+0x52(8372260) ap_run_process_connection+0x25(8372260) ap_process_connection+0x3a(8372260, 8371fc8) child_main+0x2f6(13) make_child+0x84(80beaf8, 13) perform_idle_server_maintenance+0xe2(80bcc58) ap_mpm_run+0x234(80bcc58, 80ead10, 80beaf8) main+0x6e8(3, 8047e38, 8047e48) _start+0x7a(3, 8047ed4, 8047eeb, 8047eee, 0, 8047ef4) Dissassembly of that portion of the code: libphp5.so`_zend_mm_alloc_int+0x5e::dis libphp5.so`_zend_mm_alloc_int+0x3f: shrl $0x3,%esi libphp5.so`_zend_mm_alloc_int+0x42: leal -0x2(%esi),%ecx libphp5.so`_zend_mm_alloc_int+0x45: cmpl %edx,%eax libphp5.so`_zend_mm_alloc_int+0x47: jb +0x44e libphp5.so`_zend_mm_alloc_int+0x49b libphp5.so`_zend_mm_alloc_int+0x4d: movl 0x8(%ebp),%eax libphp5.so`_zend_mm_alloc_int+0x50: movl %eax,-0x4(%ebp) libphp5.so`_zend_mm_alloc_int+0x53: movl 0x3c(%eax,%esi,4),%edx libphp5.so`_zend_mm_alloc_int+0x57: testl %edx,%edx libphp5.so`_zend_mm_alloc_int+0x59: je +0x18libphp5.so`_zend_mm_alloc_int+0x73 libphp5.so`_zend_mm_alloc_int+0x5b: leal 0x8(%edx),%eax libphp5.so`_zend_mm_alloc_int+0x5e: movl 0x8(%edx),%ecx libphp5.so`_zend_mm_alloc_int+0x61: movl -0x4(%ebp),%edx libphp5.so`_zend_mm_alloc_int+0x64: movl %ecx,0x3c(%edx,%esi,4) libphp5.so`_zend_mm_alloc_int+0x68: movl -0x10(%ebp),%ecx libphp5.so`_zend_mm_alloc_int+0x6b: subl %ecx,0x40(%edx) libphp5.so`_zend_mm_alloc_int+0x6e: jmp+0x443 libphp5.so`_zend_mm_alloc_int+0x4b6 libphp5.so`_zend_mm_alloc_int+0x73: movl -0x4(%ebp),%eax libphp5.so`_zend_mm_alloc_int+0x76: movl 0x4(%eax),%eax libphp5.so`_zend_mm_alloc_int+0x79: shrl %cl,%eax libphp5.so`_zend_mm_alloc_int+0x7b: testl %eax,%eax libphp5.so`_zend_mm_alloc_int+0x7d: je +0x1blibphp5.so`_zend_mm_alloc_int+0x9a Register contents: $r %cs = 0x0043%eax = 0x41373041 %ds = 0x004b%ebx = 0xfd3d156c %ss = 0x004b%ecx = 0x0005 %es = 0x004b%edx = 0x41373039 %fs = 0x%esi = 0x0007 %gs = 0x01c3%edi = 0x %eip = 0xfd28f552 libphp5.so`_zend_mm_alloc_int+0x5e %ebp = 0x080437ec %kesp = 0x %eflags = 0x0206 id=0 vip=0 vif=0 ac=0 vm=0 rf=0 nt=0 iopl=0x0 status=of,df,IF,tf,sf,zf,af,PF,cf %esp = 0x080437c4 %trapno = 0xe %err = 0x4 -- Edit bug report at http://bugs.php.net/?id=43582edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43582r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43582r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43582r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43582r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43582r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43582r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43582r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43582r=needscript Try newer version:http://bugs.php.net/fix.php?id=43582r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43582r=support Expected behavior:http://bugs.php.net/fix.php?id=43582r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43582r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php
#43488 [NEW]: httpd.conf generation / php5apache2_2.dll
From: steve dot buzonas at gmail dot com Operating system: Windows XP Pro SP2 PHP version: 5.2.5 PHP Bug Type: Unknown/Other Function Bug description: httpd.conf generation / php5apache2_2.dll Description: When I use the MSI installer it does not provide a file named php5apache2_2.dll; instead it is php5apache2_2_filter.dll I'm not sure if it's something I excluded in my install configuration. I have the same results every time I try the repair option. I no longer have a problem, I just wanted to point this out in case other people have this problem. There are no bugs on it, nor is anything listed in the FAQ. -- Edit bug report at http://bugs.php.net/?id=43488edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43488r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43488r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43488r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43488r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43488r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43488r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43488r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43488r=needscript Try newer version:http://bugs.php.net/fix.php?id=43488r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43488r=support Expected behavior:http://bugs.php.net/fix.php?id=43488r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43488r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43488r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43488r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43488r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43488r=dst IIS Stability:http://bugs.php.net/fix.php?id=43488r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43488r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43488r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43488r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43488r=mysqlcfg
#43488 [Opn]: httpd.conf generation / php5apache2_2.dll
ID: 43488 User updated by: steve dot buzonas at gmail dot com Reported By: steve dot buzonas at gmail dot com Status: Open Bug Type: Unknown/Other Function Operating System: Windows XP Pro SP2 PHP Version: 5.2.5 New Comment: I submitted the solution but not the problem. It is similar to an item listed in the FAQ. If you try to access a PHP script in the browser with PHP installed you end up with a blank screen. The FAQ suggests PHP is not properly configured and to view source and you should see the PHP code. This is the same problem only when the PHP code is not visible via a view source. Previous Comments: [2007-12-03 18:59:55] steve dot buzonas at gmail dot com Description: When I use the MSI installer it does not provide a file named php5apache2_2.dll; instead it is php5apache2_2_filter.dll I'm not sure if it's something I excluded in my install configuration. I have the same results every time I try the repair option. I no longer have a problem, I just wanted to point this out in case other people have this problem. There are no bugs on it, nor is anything listed in the FAQ. -- Edit this bug report at http://bugs.php.net/?id=43488edit=1
#41939 [NEW]: Bizarre behaviour testing a variable
From: steve at tequilasolutions dot com Operating system: FC4 PHP version: 5.2.3 PHP Bug Type: Variables related Bug description: Bizarre behaviour testing a variable Description: I have a variable set to 0. if ($var==on) returns true!! This behaviour is not there in php4 Reproduce code: --- [EMAIL PROTECTED] php -v PHP 4.3.11 (cgi) (built: Jun 16 2005 17:25:40) Copyright (c) 1997-2004 The PHP Group [EMAIL PROTECTED] php ? $val = 0; if ($val==on) print on\n; ? [EMAIL PROTECTED] php5 ? $val = 0; if ($val==on) print on\n; ? on [EMAIL PROTECTED] php5 ? $var = 0; if ($var=='anything') print anything; ? [EMAIL PROTECTED] This bug is also in PHP/5.0.4 and may have been there since then. [EMAIL PROTECTED] Expected result: 0 should not equal 'on' or 'anything' -- Edit bug report at http://bugs.php.net/?id=41939edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41939r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41939r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41939r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41939r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41939r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41939r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41939r=needscript Try newer version:http://bugs.php.net/fix.php?id=41939r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41939r=support Expected behavior:http://bugs.php.net/fix.php?id=41939r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41939r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41939r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41939r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41939r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41939r=dst IIS Stability:http://bugs.php.net/fix.php?id=41939r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41939r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41939r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41939r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41939r=mysqlcfg
#40514 [NEW]: Segmentation fault on session_register of undeclared variable
From: steve at webdrive dot co dot nz
Operating system: Debian Linux 3.1
PHP version: 4.4.5
PHP Bug Type: Session related
Bug description: Segmentation fault on session_register of undeclared variable
Description:
The upgrade from PHP 4.4.4 to 4.4.5 caused a Segmentation Fault on a
client's osCommerce site. I've tracked the problem down to a
session_register function call on a undeclared variable.
Reproduce code:
---
?php
session_start();
// Uncomment the following line to prevent the Segmentation Fault
//$myvar = 1;
session_register(myvar);
echo Hello World;
?
Expected result:
Hello World and no Segmentation Fault in Apache's error log:
[Sat Feb 17 21:14:16 2007] [notice] child pid 20549 exit signal
Segmentation fault (11)
Actual result:
--
0x080dbbc2 in php_add_session_var (name=0x850b75c myvar, namelen=5)
at /usr/src/apache-php/build/php-4.4.5/ext/session/session.c:287
287 if ((Z_TYPE_PP(sym_global) == IS_ARRAY
Z_ARRVAL_PP(sym_global) == EG(symbol_table)) || *sym_global ==
PS(http_session_vars)) {
--
Edit bug report at http://bugs.php.net/?id=40514edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40514r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40514r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40514r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40514r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40514r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40514r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40514r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40514r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40514r=support
Expected behavior:http://bugs.php.net/fix.php?id=40514r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40514r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40514r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40514r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40514r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40514r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40514r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40514r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40514r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40514r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40514r=mysqlcfg
#39749 [Fbk-Opn]: function call returns crash under certain conditions
ID: 39749 User updated by: steve-php-dev at spamwiz dot com Reported By: steve-php-dev at spamwiz dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: CentOS 3 PHP Version: 5.2.0 New Comment: As I stated earlier, the problem does NOT happen if I enable debug. Previous Comments: [2006-12-06 11:57:58] [EMAIL PROTECTED] Please try to get some more information using valgrind (and --enable-debug). [2006-12-06 00:09:24] steve-php-dev at spamwiz dot com The problem actually occurs on several different machines, whenever I use the RPM built with those configure options. I've tried it on a 2.4 GHz Celeron, a 1 GHz Duron, and a 2.66 GHz P4. Using my alternate RPM that has the other configure options, I don't see the problem. That's fortunate, because the one without the problem is the one on all of my production machines. The problem only happens on my monitoring machine. The problem does not happen in CLI, however the configure options are (yet again) different. I have three different CLI versions, and it works with all three. Here are their configure options: './configure' '--mandir=/usr/share/man' '--with-config-file-path=/etc/php' '--with-config-file-scan-dir=/etc/php/cli.d' '--with-mysql=/usr' '--with-mysqli=/usr/bin/mysql_config' '--with-zlib' '--enable-mbstring' '--with-openssl' '--disable-cgi' '--enable-pcntl' '--without-pear' '--enable-soap' '--with-rrdtool' '--with-snmp' '--with-gmp' '--without-spl' '--without-sqlite' '--without-pdo' './configure' '--mandir=/usr/share/man' '--with-config-file-path=/etc/php' '--with-config-file-scan-dir=/etc/php/cli.d' '--with-mysql=/usr' '--with-mysqli=/usr/bin/mysql_config' '--disable-cgi' '--enable-soap' '--with-readline' '--with-zlib' '--with-ldap' '--with-ncurses' '--with-imap' '--with-imap-ssl' '--with-kerberos=/usr/kerberos' '--with-gmp' '--without-spl' '--without-sqlite' '--without-pdo' './configure' '--mandir=/usr/share/man' '--with-config-file-path=/etc/php' '--with-config-file-scan-dir=/etc/php/gd.d' '--with-mysql=/usr' '--with-mysqli=/usr/bin/mysql_config' '--with-zlib' '--enable-mbstring' '--with-openssl' '--disable-cgi' '--enable-pcntl' '--without-pear' '--enable-soap' '--with-gd' '--enable-gd-native-ttf' [2006-12-05 23:37:29] [EMAIL PROTECTED] What is the difference between these two servers? Could you try to run this code with CLI and valgrind? [2006-12-05 23:29:53] steve-php-dev at spamwiz dot com It still happens with the CVS version. [2006-12-05 23:04:55] [EMAIL PROTECTED] Ok, great. 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/39749 -- Edit this bug report at http://bugs.php.net/?id=39749edit=1
#39749 [Fbk-Opn]: function call returns crash under certain conditions
ID: 39749 User updated by: steve-php-dev at spamwiz dot com Reported By: steve-php-dev at spamwiz dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: CentOS 3 PHP Version: 5.2.0 New Comment: I have fixed the problem by changing the CFLAGS variable from O3 -mmmx -march=i686 -mcpu=i686 -funroll-loops to -O3 -msse -mmmx -march=i686 -mcpu=pentium4 -mfpmath=sse -funroll-loops. I'm not sure how that helps, but it's the only thing that fixed it. The second one is the CFLAGS used by my other RPM build of apache+php. Previous Comments: [2006-12-06 23:00:04] [EMAIL PROTECTED] Yes, I know. But this just means that with valgrind you should be able to see more. Run it this way: USE_ZEND_ALLOC=0 valgrind --tool=memcheck php script.php [2006-12-06 22:44:46] steve-php-dev at spamwiz dot com As I stated earlier, the problem does NOT happen if I enable debug. [2006-12-06 11:57:58] [EMAIL PROTECTED] Please try to get some more information using valgrind (and --enable-debug). [2006-12-06 00:09:24] steve-php-dev at spamwiz dot com The problem actually occurs on several different machines, whenever I use the RPM built with those configure options. I've tried it on a 2.4 GHz Celeron, a 1 GHz Duron, and a 2.66 GHz P4. Using my alternate RPM that has the other configure options, I don't see the problem. That's fortunate, because the one without the problem is the one on all of my production machines. The problem only happens on my monitoring machine. The problem does not happen in CLI, however the configure options are (yet again) different. I have three different CLI versions, and it works with all three. Here are their configure options: './configure' '--mandir=/usr/share/man' '--with-config-file-path=/etc/php' '--with-config-file-scan-dir=/etc/php/cli.d' '--with-mysql=/usr' '--with-mysqli=/usr/bin/mysql_config' '--with-zlib' '--enable-mbstring' '--with-openssl' '--disable-cgi' '--enable-pcntl' '--without-pear' '--enable-soap' '--with-rrdtool' '--with-snmp' '--with-gmp' '--without-spl' '--without-sqlite' '--without-pdo' './configure' '--mandir=/usr/share/man' '--with-config-file-path=/etc/php' '--with-config-file-scan-dir=/etc/php/cli.d' '--with-mysql=/usr' '--with-mysqli=/usr/bin/mysql_config' '--disable-cgi' '--enable-soap' '--with-readline' '--with-zlib' '--with-ldap' '--with-ncurses' '--with-imap' '--with-imap-ssl' '--with-kerberos=/usr/kerberos' '--with-gmp' '--without-spl' '--without-sqlite' '--without-pdo' './configure' '--mandir=/usr/share/man' '--with-config-file-path=/etc/php' '--with-config-file-scan-dir=/etc/php/gd.d' '--with-mysql=/usr' '--with-mysqli=/usr/bin/mysql_config' '--with-zlib' '--enable-mbstring' '--with-openssl' '--disable-cgi' '--enable-pcntl' '--without-pear' '--enable-soap' '--with-gd' '--enable-gd-native-ttf' [2006-12-05 23:37:29] [EMAIL PROTECTED] What is the difference between these two servers? Could you try to run this code with CLI and valgrind? 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/39749 -- Edit this bug report at http://bugs.php.net/?id=39749edit=1
#39749 [NEW]: array_merge() crashes under certain conditions
From: steve-php-dev at spamwiz dot com Operating system: CentOS 3 PHP version: 5.2.0 PHP Bug Type: Reproducible crash Bug description: array_merge() crashes under certain conditions Description: If more than two arrays are passed to array_merge(), I get a segfault. This happens on one server, but not another. Here is the configure command for the one that has the problem, followed by the configure for the one that does not have the problem: BAD SERVER './configure' '--with-mysql=/usr' '--with-mysqli=/usr/bin/mysql_config' '--with-zlib' '--enable-soap' '--enable-mbstring' '--with-openssl' '--with-config-file-path=/etc/php' '--with-config-file-scan-dir=/etc/php/apache.d' '--with-apache=../apache_1.3.37' '--enable-track-vars' '--without-pear' '--disable-cli' '--with-imap' '--with-imap-ssl' '--with-ldap' '--with-kerberos' '--with-gmp' '--without-spl' '--without-sqlite' '--without-pdo' '--enable-gd-native-ttf' '--with-gd' '--with-png-dir' '--with-freetype-dir' '--with-mssql' GOOD SERVER './configure' '--with-mysql=/usr' '--with-mysqli=/usr/bin/mysql_config' '--enable-soap' '--with-zlib' '--enable-mbstring' '--with-openssl' '--with-config-file-path=/etc/php' '--with-config-file-scan-dir=/etc/php/apache.d' '--with-apache=../apache_1.3.37' '--enable-track-vars' '--without-pear' '--disable-cli' '--with-gmp' '--without-spl' '--without-sqlite' '--without-pdo' Reproduce code: --- ? $arr1 = array(1, 2, 3); $arr2 = array(4, 5, 6); $arr3 = array(7, 8, 9); $arr = array_merge($arr1, $arr2, $arr3); header(Content-Type: text/plain); print_r($arr); ? Expected result: Array ( [0] = 1 [1] = 2 [2] = 3 [3] = 4 [4] = 5 [5] = 6 [6] = 7 [7] = 8 [8] = 9 ) Actual result: -- segfault -- Edit bug report at http://bugs.php.net/?id=39749edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39749r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39749r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39749r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39749r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39749r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39749r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39749r=needscript Try newer version:http://bugs.php.net/fix.php?id=39749r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39749r=support Expected behavior:http://bugs.php.net/fix.php?id=39749r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39749r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39749r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39749r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39749r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39749r=dst IIS Stability:http://bugs.php.net/fix.php?id=39749r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39749r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39749r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39749r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39749r=mysqlcfg
#39749 [Fbk-Opn]: function call returns crash under certain conditions
ID: 39749
User updated by: steve-php-dev at spamwiz dot com
-Summary: array_merge() crashes under certain conditions
Reported By: steve-php-dev at spamwiz dot com
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: CentOS 3
PHP Version: 5.2.0
New Comment:
The following produces a segfault:
?
function function_call($arg1, $arg2, $arg3) {}
$arr1 = array(1, 2, 3);
$arr2 = array(4, 5, 6);
$arr3 = array(7, 8, 9);
$arr = function_call($arr1, $arr2, $arr3);
echo done;
?
If you echo something and exit inside the function, it does not
segfault.
Previous Comments:
[2006-12-05 22:00:56] [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.
What is the difference between these two servers?
[2006-12-05 21:47:35] steve-php-dev at spamwiz dot com
Description:
If more than two arrays are passed to array_merge(), I get a segfault.
This happens on one server, but not another. Here is the configure
command for the one that has the problem, followed by the configure for
the one that does not have the problem:
BAD SERVER
'./configure' '--with-mysql=/usr' '--with-mysqli=/usr/bin/mysql_config'
'--with-zlib' '--enable-soap' '--enable-mbstring' '--with-openssl'
'--with-config-file-path=/etc/php'
'--with-config-file-scan-dir=/etc/php/apache.d'
'--with-apache=../apache_1.3.37' '--enable-track-vars' '--without-pear'
'--disable-cli' '--with-imap' '--with-imap-ssl' '--with-ldap'
'--with-kerberos' '--with-gmp' '--without-spl' '--without-sqlite'
'--without-pdo' '--enable-gd-native-ttf' '--with-gd' '--with-png-dir'
'--with-freetype-dir' '--with-mssql'
GOOD SERVER
'./configure' '--with-mysql=/usr' '--with-mysqli=/usr/bin/mysql_config'
'--enable-soap' '--with-zlib' '--enable-mbstring' '--with-openssl'
'--with-config-file-path=/etc/php'
'--with-config-file-scan-dir=/etc/php/apache.d'
'--with-apache=../apache_1.3.37' '--enable-track-vars' '--without-pear'
'--disable-cli' '--with-gmp' '--without-spl' '--without-sqlite'
'--without-pdo'
Reproduce code:
---
?
$arr1 = array(1, 2, 3);
$arr2 = array(4, 5, 6);
$arr3 = array(7, 8, 9);
$arr = array_merge($arr1, $arr2, $arr3);
header(Content-Type: text/plain);
print_r($arr);
?
Expected result:
Array
(
[0] = 1
[1] = 2
[2] = 3
[3] = 4
[4] = 5
[5] = 6
[6] = 7
[7] = 8
[8] = 9
)
Actual result:
--
segfault
--
Edit this bug report at http://bugs.php.net/?id=39749edit=1
#39749 [Fbk-Opn]: function call returns crash under certain conditions
ID: 39749
User updated by: steve-php-dev at spamwiz dot com
Reported By: steve-php-dev at spamwiz dot com
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: CentOS 3
PHP Version: 5.2.0
New Comment:
(gdb) run -X
Starting program: /usr/local/apache/bin/httpd -X
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1218542944 (LWP 8821)]
Processing config directory: /usr/local/apache/conf/vhosts/*.conf
Processing config file: /usr/local/apache/conf/vhosts/dev-apache.conf
Processing config file: /usr/local/apache/conf/vhosts/empty.conf
Processing config directory: /etc/httpd/conf.d/*.conf
Processing config file: /etc/httpd/conf.d/apt-proxy.conf
Processing config file: /etc/httpd/conf.d/monitor.conf
Processing config file: /etc/httpd/conf.d/nagios.conf
[Tue Dec 5 15:49:35 2006] [warn] NameVirtualHost *:80 has no
VirtualHosts
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1218542944 (LWP 8821)]
0x080e294e in _zval_ptr_dtor ()
(gdb) bt
#0 0x080e294e in _zval_ptr_dtor ()
#1 0x08109698 in zend_get_zval_ptr_ptr ()
#2 0x08108b28 in execute ()
#3 0x080eecae in zend_execute_scripts ()
#4 0x080b6161 in php_execute_script ()
#5 0x0814fa6a in apache_php_module_main ()
#6 0x080ac6b8 in ap_get_server_built ()
#7 0x080abc71 in ap_get_server_built ()
#8 0x083f0043 in ap_invoke_handler ()
#9 0x08409857 in ap_update_mtime ()
#10 0x08408941 in ap_process_request ()
#11 0x0840179e in suck_in_ap_validate_password ()
#12 0x083fff68 in suck_in_ap_validate_password ()
#13 0x083fef95 in suck_in_ap_validate_password ()
#14 0x083fcb26 in main ()
(gdb)
Previous Comments:
[2006-12-05 22:41:22] steve-php-dev at spamwiz dot com
The following produces a segfault:
?
function function_call($arg1, $arg2, $arg3) {}
$arr1 = array(1, 2, 3);
$arr2 = array(4, 5, 6);
$arr3 = array(7, 8, 9);
$arr = function_call($arr1, $arr2, $arr3);
echo done;
?
If you echo something and exit inside the function, it does not
segfault.
[2006-12-05 22:00:56] [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.
What is the difference between these two servers?
[2006-12-05 21:47:35] steve-php-dev at spamwiz dot com
Description:
If more than two arrays are passed to array_merge(), I get a segfault.
This happens on one server, but not another. Here is the configure
command for the one that has the problem, followed by the configure for
the one that does not have the problem:
BAD SERVER
'./configure' '--with-mysql=/usr' '--with-mysqli=/usr/bin/mysql_config'
'--with-zlib' '--enable-soap' '--enable-mbstring' '--with-openssl'
'--with-config-file-path=/etc/php'
'--with-config-file-scan-dir=/etc/php/apache.d'
'--with-apache=../apache_1.3.37' '--enable-track-vars' '--without-pear'
'--disable-cli' '--with-imap' '--with-imap-ssl' '--with-ldap'
'--with-kerberos' '--with-gmp' '--without-spl' '--without-sqlite'
'--without-pdo' '--enable-gd-native-ttf' '--with-gd' '--with-png-dir'
'--with-freetype-dir' '--with-mssql'
GOOD SERVER
'./configure' '--with-mysql=/usr' '--with-mysqli=/usr/bin/mysql_config'
'--enable-soap' '--with-zlib' '--enable-mbstring' '--with-openssl'
'--with-config-file-path=/etc/php'
'--with-config-file-scan-dir=/etc/php/apache.d'
'--with-apache=../apache_1.3.37' '--enable-track-vars' '--without-pear'
'--disable-cli' '--with-gmp' '--without-spl' '--without-sqlite'
'--without-pdo'
Reproduce code:
---
?
$arr1 = array(1, 2, 3);
$arr2 = array(4, 5, 6);
$arr3 = array(7, 8, 9);
$arr = array_merge($arr1, $arr2, $arr3);
header(Content-Type: text/plain);
print_r($arr);
?
Expected result:
Array
(
[0] = 1
[1] = 2
[2] = 3
[3] = 4
[4] = 5
[5] = 6
[6] = 7
[7] = 8
[8] = 9
)
Actual result:
--
segfault
--
Edit this bug report at http://bugs.php.net/?id=39749edit=1
#39749 [Fbk-Opn]: function call returns crash under certain conditions
ID: 39749
User updated by: steve-php-dev at spamwiz dot com
Reported By: steve-php-dev at spamwiz dot com
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: CentOS 3
PHP Version: 5.2.0
New Comment:
I'm downloading the CVS version now. I neglected to --enable-debug
when generating the backtrace. When it was enabled, the problem didn't
occur, however. I will update again after trying the latest CVS.
Previous Comments:
[2006-12-05 22:57:06] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-12-05 22:51:06] steve-php-dev at spamwiz dot com
(gdb) run -X
Starting program: /usr/local/apache/bin/httpd -X
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1218542944 (LWP 8821)]
Processing config directory: /usr/local/apache/conf/vhosts/*.conf
Processing config file: /usr/local/apache/conf/vhosts/dev-apache.conf
Processing config file: /usr/local/apache/conf/vhosts/empty.conf
Processing config directory: /etc/httpd/conf.d/*.conf
Processing config file: /etc/httpd/conf.d/apt-proxy.conf
Processing config file: /etc/httpd/conf.d/monitor.conf
Processing config file: /etc/httpd/conf.d/nagios.conf
[Tue Dec 5 15:49:35 2006] [warn] NameVirtualHost *:80 has no
VirtualHosts
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1218542944 (LWP 8821)]
0x080e294e in _zval_ptr_dtor ()
(gdb) bt
#0 0x080e294e in _zval_ptr_dtor ()
#1 0x08109698 in zend_get_zval_ptr_ptr ()
#2 0x08108b28 in execute ()
#3 0x080eecae in zend_execute_scripts ()
#4 0x080b6161 in php_execute_script ()
#5 0x0814fa6a in apache_php_module_main ()
#6 0x080ac6b8 in ap_get_server_built ()
#7 0x080abc71 in ap_get_server_built ()
#8 0x083f0043 in ap_invoke_handler ()
#9 0x08409857 in ap_update_mtime ()
#10 0x08408941 in ap_process_request ()
#11 0x0840179e in suck_in_ap_validate_password ()
#12 0x083fff68 in suck_in_ap_validate_password ()
#13 0x083fef95 in suck_in_ap_validate_password ()
#14 0x083fcb26 in main ()
(gdb)
[2006-12-05 22:41:22] steve-php-dev at spamwiz dot com
The following produces a segfault:
?
function function_call($arg1, $arg2, $arg3) {}
$arr1 = array(1, 2, 3);
$arr2 = array(4, 5, 6);
$arr3 = array(7, 8, 9);
$arr = function_call($arr1, $arr2, $arr3);
echo done;
?
If you echo something and exit inside the function, it does not
segfault.
[2006-12-05 22:00:56] [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.
What is the difference between these two servers?
[2006-12-05 21:47:35] steve-php-dev at spamwiz dot com
Description:
If more than two arrays are passed to array_merge(), I get a segfault.
This happens on one server, but not another. Here is the configure
command for the one that has the problem, followed by the configure for
the one that does not have the problem:
BAD SERVER
'./configure' '--with-mysql=/usr' '--with-mysqli=/usr/bin/mysql_config'
'--with-zlib' '--enable-soap' '--enable-mbstring' '--with-openssl'
'--with-config-file-path=/etc/php'
'--with-config-file-scan-dir=/etc/php/apache.d'
'--with-apache=../apache_1.3.37' '--enable-track-vars' '--without-pear'
'--disable-cli' '--with-imap' '--with-imap-ssl' '--with-ldap'
'--with-kerberos' '--with-gmp' '--without-spl' '--without-sqlite'
'--without-pdo' '--enable-gd-native-ttf' '--with-gd' '--with-png-dir'
'--with-freetype-dir' '--with-mssql'
GOOD SERVER
'./configure' '--with-mysql=/usr' '--with-mysqli=/usr/bin/mysql_config'
'--enable-soap' '--with-zlib' '--enable-mbstring' '--with-openssl'
'--with-config-file-path=/etc/php'
'--with-config-file-scan-dir=/etc/php/apache.d'
'--with-apache=../apache_1.3.37' '--enable-track-vars' '--without-pear'
'--disable-cli' '--with-gmp' '--without-spl' '--without-sqlite'
'--without-pdo'
Reproduce code:
---
?
$arr1 = array(1, 2, 3);
$arr2 = array(4, 5, 6);
$arr3 = array(7, 8, 9);
$arr = array_merge($arr1, $arr2, $arr3);
header(Content-Type: text/plain);
print_r($arr
#39749 [Fbk-Opn]: function call returns crash under certain conditions
ID: 39749
User updated by: steve-php-dev at spamwiz dot com
Reported By: steve-php-dev at spamwiz dot com
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: CentOS 3
PHP Version: 5.2.0
New Comment:
It still happens with the CVS version.
Previous Comments:
[2006-12-05 23:04:55] [EMAIL PROTECTED]
Ok, great.
[2006-12-05 23:04:16] steve-php-dev at spamwiz dot com
I'm downloading the CVS version now. I neglected to --enable-debug
when generating the backtrace. When it was enabled, the problem didn't
occur, however. I will update again after trying the latest CVS.
[2006-12-05 22:57:06] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-12-05 22:51:06] steve-php-dev at spamwiz dot com
(gdb) run -X
Starting program: /usr/local/apache/bin/httpd -X
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1218542944 (LWP 8821)]
Processing config directory: /usr/local/apache/conf/vhosts/*.conf
Processing config file: /usr/local/apache/conf/vhosts/dev-apache.conf
Processing config file: /usr/local/apache/conf/vhosts/empty.conf
Processing config directory: /etc/httpd/conf.d/*.conf
Processing config file: /etc/httpd/conf.d/apt-proxy.conf
Processing config file: /etc/httpd/conf.d/monitor.conf
Processing config file: /etc/httpd/conf.d/nagios.conf
[Tue Dec 5 15:49:35 2006] [warn] NameVirtualHost *:80 has no
VirtualHosts
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1218542944 (LWP 8821)]
0x080e294e in _zval_ptr_dtor ()
(gdb) bt
#0 0x080e294e in _zval_ptr_dtor ()
#1 0x08109698 in zend_get_zval_ptr_ptr ()
#2 0x08108b28 in execute ()
#3 0x080eecae in zend_execute_scripts ()
#4 0x080b6161 in php_execute_script ()
#5 0x0814fa6a in apache_php_module_main ()
#6 0x080ac6b8 in ap_get_server_built ()
#7 0x080abc71 in ap_get_server_built ()
#8 0x083f0043 in ap_invoke_handler ()
#9 0x08409857 in ap_update_mtime ()
#10 0x08408941 in ap_process_request ()
#11 0x0840179e in suck_in_ap_validate_password ()
#12 0x083fff68 in suck_in_ap_validate_password ()
#13 0x083fef95 in suck_in_ap_validate_password ()
#14 0x083fcb26 in main ()
(gdb)
[2006-12-05 22:41:22] steve-php-dev at spamwiz dot com
The following produces a segfault:
?
function function_call($arg1, $arg2, $arg3) {}
$arr1 = array(1, 2, 3);
$arr2 = array(4, 5, 6);
$arr3 = array(7, 8, 9);
$arr = function_call($arr1, $arr2, $arr3);
echo done;
?
If you echo something and exit inside the function, it does not
segfault.
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/39749
--
Edit this bug report at http://bugs.php.net/?id=39749edit=1
#39749 [Fbk-Opn]: function call returns crash under certain conditions
ID: 39749 User updated by: steve-php-dev at spamwiz dot com Reported By: steve-php-dev at spamwiz dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: CentOS 3 PHP Version: 5.2.0 New Comment: The problem actually occurs on several different machines, whenever I use the RPM built with those configure options. I've tried it on a 2.4 GHz Celeron, a 1 GHz Duron, and a 2.66 GHz P4. Using my alternate RPM that has the other configure options, I don't see the problem. That's fortunate, because the one without the problem is the one on all of my production machines. The problem only happens on my monitoring machine. The problem does not happen in CLI, however the configure options are (yet again) different. I have three different CLI versions, and it works with all three. Here are their configure options: './configure' '--mandir=/usr/share/man' '--with-config-file-path=/etc/php' '--with-config-file-scan-dir=/etc/php/cli.d' '--with-mysql=/usr' '--with-mysqli=/usr/bin/mysql_config' '--with-zlib' '--enable-mbstring' '--with-openssl' '--disable-cgi' '--enable-pcntl' '--without-pear' '--enable-soap' '--with-rrdtool' '--with-snmp' '--with-gmp' '--without-spl' '--without-sqlite' '--without-pdo' './configure' '--mandir=/usr/share/man' '--with-config-file-path=/etc/php' '--with-config-file-scan-dir=/etc/php/cli.d' '--with-mysql=/usr' '--with-mysqli=/usr/bin/mysql_config' '--disable-cgi' '--enable-soap' '--with-readline' '--with-zlib' '--with-ldap' '--with-ncurses' '--with-imap' '--with-imap-ssl' '--with-kerberos=/usr/kerberos' '--with-gmp' '--without-spl' '--without-sqlite' '--without-pdo' './configure' '--mandir=/usr/share/man' '--with-config-file-path=/etc/php' '--with-config-file-scan-dir=/etc/php/gd.d' '--with-mysql=/usr' '--with-mysqli=/usr/bin/mysql_config' '--with-zlib' '--enable-mbstring' '--with-openssl' '--disable-cgi' '--enable-pcntl' '--without-pear' '--enable-soap' '--with-gd' '--enable-gd-native-ttf' Previous Comments: [2006-12-05 23:37:29] [EMAIL PROTECTED] What is the difference between these two servers? Could you try to run this code with CLI and valgrind? [2006-12-05 23:29:53] steve-php-dev at spamwiz dot com It still happens with the CVS version. [2006-12-05 23:04:55] [EMAIL PROTECTED] Ok, great. [2006-12-05 23:04:16] steve-php-dev at spamwiz dot com I'm downloading the CVS version now. I neglected to --enable-debug when generating the backtrace. When it was enabled, the problem didn't occur, however. I will update again after trying the latest CVS. [2006-12-05 22:57:06] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip 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/39749 -- Edit this bug report at http://bugs.php.net/?id=39749edit=1
#39605 [NEW]: Function Error
From: steve at directprint dot com dot au Operating system: MacOS X Server 10.4.8 PHP version: 5.2.0 PHP Bug Type: Directory function related Bug description: Function Error Description: Aftrer upgrading to 5.2.0, I now get a blank page. Below is the from the web error log. Reproduce code: --- [Thu Nov 23 21:59:21 2006] [error] PHP Warning: require_once(./global.php) [a href='function.require-once'function.require-once/a]: failed to open stream: No such file or directory in /Volumes/SOHOraid/forum/index.php on line 55 [Thu Nov 23 21:59:21 2006] [error] PHP Fatal error: require_once() [a href='function.require'function.require/a]: Failed opening required './global.php' (include_path='.:/usr/local/php5/lib/php') in /Volumes/SOHOraid/forum/index.php on line 55 Expected result: Forum index Actual result: -- Blank Page -- Edit bug report at http://bugs.php.net/?id=39605edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39605r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39605r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39605r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39605r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39605r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39605r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39605r=needscript Try newer version:http://bugs.php.net/fix.php?id=39605r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39605r=support Expected behavior:http://bugs.php.net/fix.php?id=39605r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39605r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39605r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39605r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39605r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39605r=dst IIS Stability:http://bugs.php.net/fix.php?id=39605r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39605r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39605r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39605r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39605r=mysqlcfg
#39343 [Opn]: PHP wont compile with latest Curl
ID: 39343 User updated by: steve dot kirtley at gmail dot com Reported By: steve dot kirtley at gmail dot com Status: Open Bug Type: cURL related Operating System: Red Hat / Apache/1.3.26 PHP Version: 4.4.4 New Comment: Thanks for the quick reply - hoping you can help me solve this one... Sorry, full error from Make command below: [EMAIL PROTECTED] php-4.4.4]# make /bin/sh /home/willis_s/php-4.4.4/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/curl/ -I/home/willis_s/php-4.4.4/ext/curl/ -DPHP_ATOM_INC -I/home/willis_s/php-4.4.4/include -I/home/willis_s/php-4.4.4/main -I/home/willis_s/php-4.4.4 -I/usr/lib/include -I/usr/local/mysql/include -I/usr/local/oracle/rdbms/public -I/usr/local/oracle/rdbms/demo -I/home/willis_s/php-4.4.4/ext/xml/expat -I/home/willis_s/php-4.4.4/TSRM -I/home/willis_s/php-4.4.4/Zend-g -O2 -prefer-non-pic -c /home/willis_s/php-4.4.4/ext/curl/curl.c -o ext/curl/curl.lo /home/willis_s/php-4.4.4/ext/curl/curl.c: In function `zm_startup_curl': /home/willis_s/php-4.4.4/ext/curl/curl.c:261: `CURLOPT_FTPASCII' undeclared (first use in this function) /home/willis_s/php-4.4.4/ext/curl/curl.c:261: (Each undeclared identifier is reported only once /home/willis_s/php-4.4.4/ext/curl/curl.c:261: for each function it appears in.) /home/willis_s/php-4.4.4/ext/curl/curl.c:299: `CURLOPT_PASSWDFUNCTION' undeclared (first use in this function) make: *** [ext/curl/curl.lo] Error 1 [EMAIL PROTECTED] php-4.4.4]# Previous Comments: [2006-11-02 22:27:06] daniel at haxx dot se 1. You cut off the build error too early so the error doesn't really show 2. They aren't deprecated _functions_, they are deprecated symbols == defines in the curl public header file. [2006-11-02 11:04:23] steve dot kirtley at gmail dot com Description: Installed latest libcurl and curl libraries (no previous version) which worked fine with PHP 4.4.2 - however will not compile with 4.4.4 Reproduce code: --- Using following configure command, (which worked and still works with 4.4.2): ./configure --with-db --with-gdbm --with-xml --with-apxs=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --with-oci8=/usr/local/oracle --enable-sigchild --enable-trans-sid --with-pgsq --with-curl=/usr/lib Configure is successful but errors shown below appear when running 'make' /bin/sh /home/willis_s/php-4.4.4/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/curl/ -I/home/willis_s/php-4.4.4/ext/curl/ -DPHP_ATOM_INC -I/home/willis_s/php-4.4.4/include -I/home/willis_s/php-4.4.4/main -I/home/willis_s/php-4.4.4 -I/usr/lib/include -I/usr/local/mysql/include -I/usr/local/oracle/rdbms/public -I/usr/local/oracle/rdbms/demo -I/home/willis_s/php-4.4.4/ext/xml/expat -I/home/willis_s/php-4.4.4/TSRM -I/home/willis_s/php-4.4.4/Zend-g -O2 -prefer-non-pic -c /home/willis_s/php-4.4.4/ext/curl/curl.c -o ext/curl/curl.lo Expected result: With PHP 4.4.2 installs without issues using same process. Have posted onto the curl mailing list who advised these PHP ext files are referencing deprecated functions. -- Edit this bug report at http://bugs.php.net/?id=39343edit=1
#39343 [NEW]: PHP wont compile with latest Curl
From: steve dot kirtley at gmail dot com Operating system: Red Hat / Apache/1.3.26 PHP version: 4.4.4 PHP Bug Type: cURL related Bug description: PHP wont compile with latest Curl Description: Installed latest libcurl and curl libraries (no previous version) which worked fine with PHP 4.4.2 - however will not compile with 4.4.4 Reproduce code: --- Using following configure command, (which worked and still works with 4.4.2): ./configure --with-db --with-gdbm --with-xml --with-apxs=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --with-oci8=/usr/local/oracle --enable-sigchild --enable-trans-sid --with-pgsq --with-curl=/usr/lib Configure is successful but errors shown below appear when running 'make' /bin/sh /home/willis_s/php-4.4.4/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/curl/ -I/home/willis_s/php-4.4.4/ext/curl/ -DPHP_ATOM_INC -I/home/willis_s/php-4.4.4/include -I/home/willis_s/php-4.4.4/main -I/home/willis_s/php-4.4.4 -I/usr/lib/include -I/usr/local/mysql/include -I/usr/local/oracle/rdbms/public -I/usr/local/oracle/rdbms/demo -I/home/willis_s/php-4.4.4/ext/xml/expat -I/home/willis_s/php-4.4.4/TSRM -I/home/willis_s/php-4.4.4/Zend-g -O2 -prefer-non-pic -c /home/willis_s/php-4.4.4/ext/curl/curl.c -o ext/curl/curl.lo Expected result: With PHP 4.4.2 installs without issues using same process. Have posted onto the curl mailing list who advised these PHP ext files are referencing deprecated functions. -- Edit bug report at http://bugs.php.net/?id=39343edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39343r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39343r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39343r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39343r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39343r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39343r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39343r=needscript Try newer version:http://bugs.php.net/fix.php?id=39343r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39343r=support Expected behavior:http://bugs.php.net/fix.php?id=39343r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39343r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39343r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39343r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39343r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39343r=dst IIS Stability:http://bugs.php.net/fix.php?id=39343r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39343r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39343r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39343r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39343r=mysqlcfg
#39118 [NEW]: Private members accessible to print_r
From: steve at mountainmedia dot com
Operating system: Fedora Core 4/Linux 2.6.14.3
PHP version: 5.1.6
PHP Bug Type: Class/Object related
Bug description: Private members accessible to print_r
Description:
Private variables are accessible to the print_r function outside of the
object. Even if one cannot access the variable directly, one could easily
parse the output of print_r to grab private data from an object.
Reproduce code:
---
?
class Example {
private $secret = My secret;
public $notsecret = Not my secret;
}
$ex = new Example;
$x = print_r ($ex, true);
print $x;
?
Expected result:
I expected the private members to be invisible or replaced with something
to indicate the lack of access such as Private.
Actual result:
--
Example Object
(
[secret:private] = My secret
[notsecret] = Not my secret
)
Private variables are displayed and data is stored in the string variable
$x which one could easily parse to get the value of secret:private.
--
Edit bug report at http://bugs.php.net/?id=39118edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39118r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39118r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39118r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39118r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39118r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39118r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39118r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39118r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39118r=support
Expected behavior:http://bugs.php.net/fix.php?id=39118r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39118r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39118r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39118r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39118r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39118r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39118r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39118r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39118r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39118r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39118r=mysqlcfg
#39118 [Bgs-Opn]: Private members accessible to print_r
ID: 39118
User updated by: steve at mountainmedia dot com
Reported By: steve at mountainmedia dot com
-Status: Bogus
+Status: Open
Bug Type: Class/Object related
Operating System: Fedora Core 4/Linux 2.6.14.3
PHP Version: 5.1.6
New Comment:
The visibility of a property or method can be defined by prefixing the
declaration with the keywords: public, protected or private. Public
declared items can be accessed everywhere. Protected limits access to
inherited and parent classes (and to the class that defines the item).
Private limits visibility only to the class that defines the item.
How do you see this as not a bug considering that last statement in the
documentation on Visibility in PHP 5 Classes (see
http://us2.php.net/manual/en/language.oop5.visibility.php).
This is either a bug or bad documentation. In all logic and
understanding, the visibility of a private property should be hidden
from any functions such as print_r, overriding the purpose of print_r.
Previous Comments:
[2006-10-10 16:22:07] [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
[2006-10-10 16:11:15] steve at mountainmedia dot com
Description:
Private variables are accessible to the print_r function outside of the
object. Even if one cannot access the variable directly, one could
easily parse the output of print_r to grab private data from an object.
Reproduce code:
---
?
class Example {
private $secret = My secret;
public $notsecret = Not my secret;
}
$ex = new Example;
$x = print_r ($ex, true);
print $x;
?
Expected result:
I expected the private members to be invisible or replaced with
something to indicate the lack of access such as Private.
Actual result:
--
Example Object
(
[secret:private] = My secret
[notsecret] = Not my secret
)
Private variables are displayed and data is stored in the string
variable $x which one could easily parse to get the value of
secret:private.
--
Edit this bug report at http://bugs.php.net/?id=39118edit=1
#39118 [Bgs]: Private members accessible to print_r
ID: 39118
User updated by: steve at mountainmedia dot com
Reported By: steve at mountainmedia dot com
Status: Bogus
Bug Type: Class/Object related
Operating System: Fedora Core 4/Linux 2.6.14.3
PHP Version: 5.1.6
New Comment:
print_r(), var_dump() and var_export() will also show protected and
private properties of objects with PHP 5.
Can this behavior be disabled? A new feature perhaps?
Previous Comments:
[2006-10-10 16:47:59] [EMAIL PROTECTED]
http://php.net/print_r
[2006-10-10 16:40:16] steve at mountainmedia dot com
The visibility of a property or method can be defined by prefixing the
declaration with the keywords: public, protected or private. Public
declared items can be accessed everywhere. Protected limits access to
inherited and parent classes (and to the class that defines the item).
Private limits visibility only to the class that defines the item.
How do you see this as not a bug considering that last statement in the
documentation on Visibility in PHP 5 Classes (see
http://us2.php.net/manual/en/language.oop5.visibility.php).
This is either a bug or bad documentation. In all logic and
understanding, the visibility of a private property should be hidden
from any functions such as print_r, overriding the purpose of print_r.
[2006-10-10 16:22:07] [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
[2006-10-10 16:11:15] steve at mountainmedia dot com
Description:
Private variables are accessible to the print_r function outside of the
object. Even if one cannot access the variable directly, one could
easily parse the output of print_r to grab private data from an object.
Reproduce code:
---
?
class Example {
private $secret = My secret;
public $notsecret = Not my secret;
}
$ex = new Example;
$x = print_r ($ex, true);
print $x;
?
Expected result:
I expected the private members to be invisible or replaced with
something to indicate the lack of access such as Private.
Actual result:
--
Example Object
(
[secret:private] = My secret
[notsecret] = Not my secret
)
Private variables are displayed and data is stored in the string
variable $x which one could easily parse to get the value of
secret:private.
--
Edit this bug report at http://bugs.php.net/?id=39118edit=1
#38633 [NEW]: unable to configure with IMAP and GD support simultaneously
From: steve dot lu at cycast dot com
Operating system: MacOSX10.3.9
PHP version: 5.1.5
PHP Bug Type: *Configuration Issues
Bug description: unable to configure with IMAP and GD support simultaneously
Description:
When I run this configure script, it fails.
./configure --prefix=/user/libphp5-install
--with-jpeg-dir=/user/libjpeg-install --with-png-dir=/user/libpng-install
--with-freetype-dir=/user/freetype-install
--with-kerberos=/usr
--with-imap=/user/imap-2004g --with-imap-ssl=/usr/openssl
--with-openssl=/usr/openssl --with-zlib-dir=/usr/zlib-install --with-gd
The console output says:
checking for IMAP support... yes
checking for IMAP Kerberos support... no
checking for IMAP SSL support... /Scodigo/openssl
checking for pam_start in -lpam... yes
checking for crypt in -lcrypt... no
checking for OpenSSL version... = 0.9.6
checking for CRYPTO_free in -lcrypto... (cached) yes
checking for SSL_CTX_set_ssl_version in -lssl... (cached) yes
checking whether build with IMAP works... no
configure: error: build test failed. Please check the config.log for
details.
The config.log says:
configure:48375: checking whether build with IMAP works
configure:48413: gcc -o conftest -I/usr/include -g -O2 -no-cpp-precomp
-L/usr/lib -L/Scodigo/libxml2-install/lib -L/Scodigo/libxml2-install/lib
-L/Scodigo/openssl/lib -L/Scodigo/openssl/lib -L/Scodigo/zlib-install/lib
-L/Scodigo/zlib-install/lib
-L/Users/stevelu/Documents/PHP-10.3.9/sw/curl-install/lib
-L/Users/stevelu/Documents/PHP-10.3.9/sw/curl-install/lib
-L/Scodigo/curl-install/lib -L/Scodigo/curl-install/lib
-L/Scodigo/libjpeg-install/lib -L/Scodigo/libjpeg-install/lib
-L/Scodigo/libpng-install/lib -L/Scodigo/libpng-install/lib
-L/Scodigo/freetype-install/lib -L/Scodigo/freetype-install/lib
-L/Scodigo/imap-2004g/lib -L/Scodigo/imap-2004g/lib conftest.c -lc-client
-lssl -lcrypto -lpam -lfreetype -lpng -lz -ljpeg -lssl -lcrypto -lcurl -lz
-lssl -lcrypto -lm -lxml2 -lz -liconv -lm -lgssapi_krb5 -lkrb5 -lk5crypto
-lcom_err -lcurl -lssl -lcrypto -lz -lxml2 -lz -liconv -lm -lgssapi_krb5
-lkrb5 -lk5crypto -lcom_err 15
configure: failed program was:
#line 48386 configure
#include confdefs.h
void mm_log(void){}
void mm_dlog(void){}
void mm_flags(void){}
void mm_fatal(void){}
void mm_critical(void){}
void mm_nocritical(void){}
void mm_notify(void){}
void mm_login(void){}
void mm_diskerror(void){}
void mm_status(void){}
void mm_lsub(void){}
void mm_list(void){}
void mm_exists(void){}
void mm_searched(void){}
void mm_expunged(void){}
char mail_newbody();
int main() {
mail_newbody();
return 0;
}
Notice that there is no link error, it just failed without giving any
reason.
However, if I run this configure script:
./configure --prefix=/user/libphp5-install
--with-jpeg-dir=/user/libjpeg-install --with-png-dir=/user/libpng-install
--with-freetype-dir=/user/freetype-install
--with-kerberos=/usr
--with-imap=/user/imap-2004g --with-imap-ssl=/usr/openssl
--with-openssl=/usr/openssl --with-zlib-dir=/usr/zlib-install
Without bundled GD support, everything ran fine.
So does this configure script with GD but without IMAP:
./configure --prefix=/user/libphp5-install
--with-jpeg-dir=/user/libjpeg-install --with-png-dir=/user/libpng-install
--with-freetype-dir=/user/freetype-install
--with-openssl=/usr/openssl --with-zlib-dir=/usr/zlib-install --with-gd
This seems to suggest there is some sort of conflict between GD and IMAP
support in the configure script.
Looking into configure script does not tell me anything immediately.
Please help.
Thanks,
Steve
--
Edit bug report at http://bugs.php.net/?id=38633edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38633r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38633r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38633r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38633r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38633r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38633r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38633r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38633r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38633r=support
Expected behavior:http://bugs.php.net/fix.php?id=38633r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38633r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38633r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38633r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38633r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38633r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38633r=isapi
#38633 [Bgs]: unable to configure with IMAP and GD support simultaneously
ID: 38633
User updated by: steve dot lu at cycast dot com
Reported By: steve dot lu at cycast dot com
Status: Bogus
Bug Type: *Configuration Issues
Operating System: MacOSX10.3.9
PHP Version: 5.1.5
New Comment:
It would be nice to find out what fails in the configure script so I
can replicate the problem and thus narrow down to the true culprit.
Is there anyone who is familiar with the configure script can give me
few pointers?
Thanks
Previous Comments:
[2006-08-28 17:33:29] [EMAIL PROTECTED]
Not PHP problem.
[2006-08-28 17:02:40] steve dot lu at cycast dot com
Description:
When I run this configure script, it fails.
./configure --prefix=/user/libphp5-install
--with-jpeg-dir=/user/libjpeg-install
--with-png-dir=/user/libpng-install
--with-freetype-dir=/user/freetype-install
--with-kerberos=/usr
--with-imap=/user/imap-2004g --with-imap-ssl=/usr/openssl
--with-openssl=/usr/openssl --with-zlib-dir=/usr/zlib-install
--with-gd
The console output says:
checking for IMAP support... yes
checking for IMAP Kerberos support... no
checking for IMAP SSL support... /Scodigo/openssl
checking for pam_start in -lpam... yes
checking for crypt in -lcrypt... no
checking for OpenSSL version... = 0.9.6
checking for CRYPTO_free in -lcrypto... (cached) yes
checking for SSL_CTX_set_ssl_version in -lssl... (cached) yes
checking whether build with IMAP works... no
configure: error: build test failed. Please check the config.log for
details.
The config.log says:
configure:48375: checking whether build with IMAP works
configure:48413: gcc -o conftest -I/usr/include -g -O2 -no-cpp-precomp
-L/usr/lib -L/Scodigo/libxml2-install/lib
-L/Scodigo/libxml2-install/lib -L/Scodigo/openssl/lib
-L/Scodigo/openssl/lib -L/Scodigo/zlib-install/lib
-L/Scodigo/zlib-install/lib
-L/Users/stevelu/Documents/PHP-10.3.9/sw/curl-install/lib
-L/Users/stevelu/Documents/PHP-10.3.9/sw/curl-install/lib
-L/Scodigo/curl-install/lib -L/Scodigo/curl-install/lib
-L/Scodigo/libjpeg-install/lib -L/Scodigo/libjpeg-install/lib
-L/Scodigo/libpng-install/lib -L/Scodigo/libpng-install/lib
-L/Scodigo/freetype-install/lib -L/Scodigo/freetype-install/lib
-L/Scodigo/imap-2004g/lib -L/Scodigo/imap-2004g/lib conftest.c
-lc-client -lssl -lcrypto -lpam -lfreetype -lpng -lz -ljpeg -lssl
-lcrypto -lcurl -lz -lssl -lcrypto -lm -lxml2 -lz -liconv -lm
-lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lcurl -lssl -lcrypto -lz
-lxml2 -lz -liconv -lm -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err 15
configure: failed program was:
#line 48386 configure
#include confdefs.h
void mm_log(void){}
void mm_dlog(void){}
void mm_flags(void){}
void mm_fatal(void){}
void mm_critical(void){}
void mm_nocritical(void){}
void mm_notify(void){}
void mm_login(void){}
void mm_diskerror(void){}
void mm_status(void){}
void mm_lsub(void){}
void mm_list(void){}
void mm_exists(void){}
void mm_searched(void){}
void mm_expunged(void){}
char mail_newbody();
int main() {
mail_newbody();
return 0;
}
Notice that there is no link error, it just failed without giving any
reason.
However, if I run this configure script:
./configure --prefix=/user/libphp5-install
--with-jpeg-dir=/user/libjpeg-install
--with-png-dir=/user/libpng-install
--with-freetype-dir=/user/freetype-install
--with-kerberos=/usr
--with-imap=/user/imap-2004g --with-imap-ssl=/usr/openssl
--with-openssl=/usr/openssl --with-zlib-dir=/usr/zlib-install
Without bundled GD support, everything ran fine.
So does this configure script with GD but without IMAP:
./configure --prefix=/user/libphp5-install
--with-jpeg-dir=/user/libjpeg-install
--with-png-dir=/user/libpng-install
--with-freetype-dir=/user/freetype-install
--with-openssl=/usr/openssl --with-zlib-dir=/usr/zlib-install
--with-gd
This seems to suggest there is some sort of conflict between GD and
IMAP support in the configure script.
Looking into configure script does not tell me anything immediately.
Please help.
Thanks,
Steve
--
Edit this bug report at http://bugs.php.net/?id=38633edit=1
#28227 [Com]: PHP CGI depends upon non-standard SCRIPT_FILENAME
ID: 28227 Comment by: steve at suzail dot org Reported By: lukem at NetBSD dot org Status: Assigned Bug Type: CGI related Operating System: * PHP Version: 5CVS, 4CVS (2005-02-04) Assigned To: fmk New Comment: Still present in php-5.1.2-Win32 What's the big deal with fixing this problem? It's such a major problem but needs so little to fix it. Previous Comments: [2005-08-04 21:31:43] pgf at foxharp dot boston dot ma dot us why hasn't this been fixed? is there a real problem with fixing it? i'm faced with a bug report against the busybox web server that i'd rather not fix, given that the problem is clearly a php problem. [2005-07-26 05:24:44] joey at clean dot q7 dot com it took me many hours of poking around to finally find this page to figure out why php isn't working under the httpd server provided under busybox. php is clearly doing the wrong thing with respect to the cgi specification. SCRIPT_FILENAME is not a standard header and can not be relied on to function. [2005-05-30 18:33:55] masta at yazzy dot org I ran into this exact same issue with php4-cgi (ver 4.3.11) on FreeBSD due to the SCRIPT_FILENAME problem. I found two ways to avoid the non-standard CGI var is to hack the http server used (mini_httpd) or use LukeM's modifications to php4. Considering that CGI is a standards based domain, modification of the webserver to support non-standard CGI variables is not proper, thus the modification to PHP itself is the solution. I found that the the LukeM modification still allows for proper execution in apache. Can somebody in the php team fix this please? [2005-02-11 03:04:50] [EMAIL PROTECTED] The provided patch was not correct, according to Frank. Assigning to him for now. [2004-12-17 03:02:28] lukem at NetBSD dot org This bug is still present in 4.3.10 as well. Note that NetBSD's pkgsrc system has been using the patch I provided for a few months now, and we haven't received any reports of problems with PHP with that patch when running as a: * php.so module under Apache * php CGI under Apache * php CGI under web servers that don't support the non-standard SCRIPT_FILENAME Please consider applying this patch, because without it PHP is useless as a CGI except under Apache IIS. 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/28227 -- Edit this bug report at http://bugs.php.net/?id=28227edit=1
#36062 [NEW]: Faulting application when Excel instantiates
From: steve dot gilbreth at autodesk dot com Operating system: Windows Server 2003 PHP version: 4.4.2 PHP Bug Type: Reproducible crash Bug description: Faulting application when Excel instantiates Description: When running application on Windows 2003 Server (IIS 6) Excel Com object fails to instantiate with the following error: Faulting application excel.exe, version 11.0.6560.0, stamp 4296b6f2, faulting module mso.dll, version 11.0.6568.0, stamp 42e18ef6, debug? 0, fault address 0x0003446c Reproduce code: --- // starting excel $excel = new COM(Excel.application, NULL, CP_UTF8) or die(Unable to instantiate excel); Expected result: Excel Com object in variable $excel Actual result: -- Event log entry: Faulting application excel.exe, version 11.0.6560.0, stamp 4296b6f2, faulting module mso.dll, version 11.0.6568.0, stamp 42e18ef6, debug? 0, fault address 0x0003446c. -- Edit bug report at http://bugs.php.net/?id=36062edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36062r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36062r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36062r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36062r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36062r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36062r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36062r=needscript Try newer version:http://bugs.php.net/fix.php?id=36062r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36062r=support Expected behavior:http://bugs.php.net/fix.php?id=36062r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36062r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36062r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36062r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36062r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36062r=dst IIS Stability:http://bugs.php.net/fix.php?id=36062r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36062r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36062r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36062r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36062r=mysqlcfg
#34570 [NEW]: Implement some sort of setproctitle() in cli version
From: steve-php-dev at spwiz dot com Operating system: Linux 2.4 kernel PHP version: 5.0.5 PHP Bug Type: Feature/Change Request Bug description: Implement some sort of setproctitle() in cli version Description: I'm using the pcntl module in the CLI SAPI to fork off several processes. I'd like the processes to be able to identify themselves in ps. In Linux, you can do this by editing argv[0]. On BSD, you use the setproctitle() function. Other higher level languages support this feature. A simple perl script to do this on Linux would be: $0 = bogus; sleep 10; I tried modifying $argv[0], but that only modified the PHP scripts copy of argv, not the real argv. It'd be nice if there was a way to modify the process title directly. Ideally, it would be cross-platform (for Unix variants, at least). This was originally requested in 2002 (http://bugs.php.net/bug.php?id=18400), but was rejected. When using the pcntl functions in the CLI version, it really would be a useful feature. -- Edit bug report at http://bugs.php.net/?id=34570edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34570r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34570r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34570r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34570r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34570r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34570r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34570r=needscript Try newer version: http://bugs.php.net/fix.php?id=34570r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34570r=support Expected behavior: http://bugs.php.net/fix.php?id=34570r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34570r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34570r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34570r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34570r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34570r=dst IIS Stability: http://bugs.php.net/fix.php?id=34570r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34570r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34570r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34570r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34570r=mysqlcfg
#33610 [NEW]: stat cache can cause problems after changing directory
From: steve at nexusuk dot org
Operating system: Linux (Fedora Core 4)
PHP version: 5.0.4
PHP Bug Type: Filesystem function related
Bug description: stat cache can cause problems after changing directory
Description:
If you use relative path names and change the working directory then the
cached data may point at the wrong file.
Reproduce code:
---
$a = file_exists('foo.txt');
chdir('bar');
$b = file_exists('foo.txt');
Expected result:
The second file_exists() call should check the file exists since it is not
the same file as the original call.
The stat cache should probably reference files by their absolute path
names, or chdir() should clear the stat cache to ensure this doesn't
happen.
Actual result:
--
If 'foo.txt' existed when checked the first time then the second
file_exists() call will also return true, even if 'bar/foo.txt' doesn't
exist.
--
Edit bug report at http://bugs.php.net/?id=33610edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33610r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33610r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33610r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33610r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33610r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33610r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33610r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33610r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33610r=support
Expected behavior: http://bugs.php.net/fix.php?id=33610r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33610r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33610r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33610r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33610r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33610r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33610r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33610r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33610r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33610r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33610r=mysqlcfg
#28746 [Com]: money_format broke in php 4.3.6
ID: 28746
Comment by: steve at jigstop dot com
Reported By: isp at derdev dot com
Status: No Feedback
Bug Type: Output Control
Operating System: linux
PHP Version: 4.3.6
New Comment:
I have this same issue on PHP 4.3.10 on IIS 5.0
Documentation stats this works on all PHP 4.3.0 yet it apparently
does not.
It looks like this funtion may require other software installed on the
server besides PHP. Why can't this just be included in PHP like ever
other PHP function I have used?
Previous Comments:
[2004-06-21 01:00:04] 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.
[2004-06-13 19:01:24] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Works fine here, keep in mind that PHP's money_format()
function is a direct wrapper around the libc C equivalent.
If it does not work this has likely to do with your libc
then PHP.
[2004-06-11 21:48:32] isp at derdev dot com
Description:
The combination of setlocale and money_format worked for me in php
4.3.4. Upgrading to php 4.3.6 and changing servers seems to have
broken setlocale and/or money_format.
Reproduce code:
---
?php
$item=987654.321;
setlocale(LC_MONETARY, 'en_US');
print money_format('%.2n',$item);
# prints 987654.321
?
Expected result:
$987,654.32
Actual result:
--
987654.32
--
Edit this bug report at http://bugs.php.net/?id=28746edit=1
#33130 [Bgs]: Odd behavior with session handling
ID: 33130 User updated by: steve at gamesareforchildren dot com Reported By: steve at gamesareforchildren dot com Status: Bogus Bug Type: Session related Operating System: Windows XP SP2, all updates PHP Version: 5.0.4 New Comment: What the heck? How short does an example script have to be? The files I gave you were six lines total! The least you could do is look at them. If the support channels were going to provide an explanation for me, they would have 30 hours ago. I've already started rewriting in ASP. I don't see why I ever bothered to waste so much time writing this long description. Good luck, -Steve Previous Comments: [2005-05-25 11:01:24] [EMAIL PROTECTED] 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. There is no bug. You're just doing something wrong (and as we didn't get any SHORT example script - bogus) [2005-05-25 00:22:56] steve at gamesareforchildren dot com Oops, sorry - I specified the wrong directory. The correct locations for the files are: http://www.shoemakervillage.org/cd/20.html http://www.shoemakervillage.org/cd/20.php http://www.shoemakervillage.org/cd/21.php I also forgot to mention about the trans_sid setting - I tried it a while ago. Unfortunately, it did nothing - my understanding was that the ID would be contained in the URL. Even with it set to 1 and use_cookies set to zero, it must have still been using cookies because no URL identifier was included. Also, I spent another few hours thinking there was still something obvious I overlooked, and set up PHP for the IIS server. You can try that one out at http://www.shoemakervillage.org:81/php/20.html. The source is the same as on the Apache server. I get similarly unpredictable results - but interestingly I discovered that on both installations if I pressed Back after getting to 21.php, the print_r command on 20.php would print out all three values. If I then tried to re-enter the Surname value into 20.php, the Name value would again disappear. Hope this helps, -Steve [2005-05-24 23:55:59] [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 ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. I get 404 Not Found for both URLs. Also, set session.use_trans_sid On and try again. [2005-05-24 19:31:07] steve at gamesareforchildren dot com I misunderstood what expected result meant. If things were working correctly, the array would contain all the variables, even from previous pages. In reality, it contains only variables added to the session array in the current page. [2005-05-24 19:29:42] steve at gamesareforchildren dot com Description: After spending 25 hours over three days reading through thousands of websites and attempting every configuration change imaginable, including downgrading PHP and Apache and then re-upgrading, I can only conclude that this issue is a bug. Look at the files provided and try out the forms. In most cases, the session data is not carried across pages. session_start() is being called in all instances. Files are indeed being created in the directory specified in php.ini, but they also contain only the data from the most recent page; it's as if the old data is somehow being lost. Yet, in Firefox, at least, I can see that a PHPSESSID cookie has been created, yet the data displayed in the browser is still incorrect. The only clue I got was that this issue might have something to do with virtual hosts, but I spent three hours on that alone and was unable to resolve the problem; disabling virtual hosts is not an available solution. The problem did not arise until I purchased and configured an additional domain name for this server. Here are some additional statistics if they are of use: OS: Windows XP SP2, all available updates installed PHP: version 5.0.4 (downgrade fails to fix
#33130 [NEW]: Odd behavior with session handling
From: steve at gamesareforchildren dot com Operating system: Windows XP SP2, all updates PHP version: 5.0.4 PHP Bug Type: Apache2 related Bug description: Odd behavior with session handling Description: After spending 25 hours over three days reading through thousands of websites and attempting every configuration change imaginable, including downgrading PHP and Apache and then re-upgrading, I can only conclude that this issue is a bug. Look at the files provided and try out the forms. In most cases, the session data is not carried across pages. session_start() is being called in all instances. Files are indeed being created in the directory specified in php.ini, but they also contain only the data from the most recent page; it's as if the old data is somehow being lost. Yet, in Firefox, at least, I can see that a PHPSESSID cookie has been created, yet the data displayed in the browser is still incorrect. The only clue I got was that this issue might have something to do with virtual hosts, but I spent three hours on that alone and was unable to resolve the problem; disabling virtual hosts is not an available solution. The problem did not arise until I purchased and configured an additional domain name for this server. Here are some additional statistics if they are of use: OS: Windows XP SP2, all available updates installed PHP: version 5.0.4 (downgrade fails to fix problem) Apache: version 2.0.54 (downgrade fails to fix problem) Other applications running: RealVNC, WinWebMail E-Mail server, Activeworlds world server software, and IIS 5 (on port 81) Router problems are not an issue, because I set this computer as the DMZ. Reproduce code: --- http://www.shoemakervillage.org/20.html Code is located at http://www.shoemakervillage.org/20.txt, http://www.shoemakervillage.org/21.txt PHP INI is at http://www.shoemakervillage.org/php.ini httpd.conf is at http://www.shoemakervillage.org/httpd.conf Expected result: Array will not contain session variables brought over from previous pages. In IE, the array will sometimes contain previous variables. In Firefox, the array never contains previous variables. Tested using web browsers from three systems. Actual result: -- Array ( [Surname] = Steve2 [Submit] = Submit ) Name is not contained in the array. -- Edit bug report at http://bugs.php.net/?id=33130edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33130r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33130r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33130r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33130r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33130r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33130r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33130r=needscript Try newer version: http://bugs.php.net/fix.php?id=33130r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33130r=support Expected behavior: http://bugs.php.net/fix.php?id=33130r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33130r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33130r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33130r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33130r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33130r=dst IIS Stability: http://bugs.php.net/fix.php?id=33130r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33130r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33130r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33130r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33130r=mysqlcfg
#33130 [Opn]: Odd behavior with session handling
ID: 33130 User updated by: steve at gamesareforchildren dot com Reported By: steve at gamesareforchildren dot com Status: Open Bug Type: Apache2 related Operating System: Windows XP SP2, all updates PHP Version: 5.0.4 New Comment: I misunderstood what expected result meant. If things were working correctly, the array would contain all the variables, even from previous pages. In reality, it contains only variables added to the session array in the current page. Previous Comments: [2005-05-24 19:29:42] steve at gamesareforchildren dot com Description: After spending 25 hours over three days reading through thousands of websites and attempting every configuration change imaginable, including downgrading PHP and Apache and then re-upgrading, I can only conclude that this issue is a bug. Look at the files provided and try out the forms. In most cases, the session data is not carried across pages. session_start() is being called in all instances. Files are indeed being created in the directory specified in php.ini, but they also contain only the data from the most recent page; it's as if the old data is somehow being lost. Yet, in Firefox, at least, I can see that a PHPSESSID cookie has been created, yet the data displayed in the browser is still incorrect. The only clue I got was that this issue might have something to do with virtual hosts, but I spent three hours on that alone and was unable to resolve the problem; disabling virtual hosts is not an available solution. The problem did not arise until I purchased and configured an additional domain name for this server. Here are some additional statistics if they are of use: OS: Windows XP SP2, all available updates installed PHP: version 5.0.4 (downgrade fails to fix problem) Apache: version 2.0.54 (downgrade fails to fix problem) Other applications running: RealVNC, WinWebMail E-Mail server, Activeworlds world server software, and IIS 5 (on port 81) Router problems are not an issue, because I set this computer as the DMZ. Reproduce code: --- http://www.shoemakervillage.org/20.html Code is located at http://www.shoemakervillage.org/20.txt, http://www.shoemakervillage.org/21.txt PHP INI is at http://www.shoemakervillage.org/php.ini httpd.conf is at http://www.shoemakervillage.org/httpd.conf Expected result: Array will not contain session variables brought over from previous pages. In IE, the array will sometimes contain previous variables. In Firefox, the array never contains previous variables. Tested using web browsers from three systems. Actual result: -- Array ( [Surname] = Steve2 [Submit] = Submit ) Name is not contained in the array. -- Edit this bug report at http://bugs.php.net/?id=33130edit=1
#33130 [Fbk-Opn]: Odd behavior with session handling
ID: 33130 User updated by: steve at gamesareforchildren dot com Reported By: steve at gamesareforchildren dot com -Status: Feedback +Status: Open Bug Type: Session related Operating System: Windows XP SP2, all updates PHP Version: 5.0.4 New Comment: Oops, sorry - I specified the wrong directory. The correct locations for the files are: http://www.shoemakervillage.org/cd/20.html http://www.shoemakervillage.org/cd/20.php http://www.shoemakervillage.org/cd/21.php I also forgot to mention about the trans_sid setting - I tried it a while ago. Unfortunately, it did nothing - my understanding was that the ID would be contained in the URL. Even with it set to 1 and use_cookies set to zero, it must have still been using cookies because no URL identifier was included. Also, I spent another few hours thinking there was still something obvious I overlooked, and set up PHP for the IIS server. You can try that one out at http://www.shoemakervillage.org:81/php/20.html. The source is the same as on the Apache server. I get similarly unpredictable results - but interestingly I discovered that on both installations if I pressed Back after getting to 21.php, the print_r command on 20.php would print out all three values. If I then tried to re-enter the Surname value into 20.php, the Name value would again disappear. Hope this helps, -Steve Previous Comments: [2005-05-24 23:55:59] [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 ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. I get 404 Not Found for both URLs. Also, set session.use_trans_sid On and try again. [2005-05-24 19:31:07] steve at gamesareforchildren dot com I misunderstood what expected result meant. If things were working correctly, the array would contain all the variables, even from previous pages. In reality, it contains only variables added to the session array in the current page. [2005-05-24 19:29:42] steve at gamesareforchildren dot com Description: After spending 25 hours over three days reading through thousands of websites and attempting every configuration change imaginable, including downgrading PHP and Apache and then re-upgrading, I can only conclude that this issue is a bug. Look at the files provided and try out the forms. In most cases, the session data is not carried across pages. session_start() is being called in all instances. Files are indeed being created in the directory specified in php.ini, but they also contain only the data from the most recent page; it's as if the old data is somehow being lost. Yet, in Firefox, at least, I can see that a PHPSESSID cookie has been created, yet the data displayed in the browser is still incorrect. The only clue I got was that this issue might have something to do with virtual hosts, but I spent three hours on that alone and was unable to resolve the problem; disabling virtual hosts is not an available solution. The problem did not arise until I purchased and configured an additional domain name for this server. Here are some additional statistics if they are of use: OS: Windows XP SP2, all available updates installed PHP: version 5.0.4 (downgrade fails to fix problem) Apache: version 2.0.54 (downgrade fails to fix problem) Other applications running: RealVNC, WinWebMail E-Mail server, Activeworlds world server software, and IIS 5 (on port 81) Router problems are not an issue, because I set this computer as the DMZ. Reproduce code: --- http://www.shoemakervillage.org/20.html Code is located at http://www.shoemakervillage.org/20.txt, http://www.shoemakervillage.org/21.txt PHP INI is at http://www.shoemakervillage.org/php.ini httpd.conf is at http://www.shoemakervillage.org/httpd.conf Expected result: Array will not contain session variables brought over from previous pages. In IE, the array will sometimes contain previous variables. In Firefox, the array never contains previous variables. Tested using web browsers from three systems. Actual result: -- Array ( [Surname] = Steve2 [Submit] = Submit ) Name is not contained in the array. -- Edit this bug report at http://bugs.php.net/?id=33130edit=1
#32483 [Com]: ./configure check crashes
ID: 32483 Comment by: steve at jeamland dot org Reported By: pieter dot donche at ua dot ac dot be Status: No Feedback Bug Type: Compile Failure Operating System: solaris 2.9 PHP Version: 5CVS-2005-03-30 New Comment: I'm seeing this on Solaris 9 with PHP 4.3.11, here are some more details and stacktrace: The crash only occurs if the crypt (-lcrypt) library is included in the library list.. I don't believe this is needed if openssl is included as it provides this function as a macro. Using the compilation parameters from config.log but without the crypt library it works fine: % gcc -o test -g -O2 -D_POSIX_PTHREAD_SEMANTICS -L/opt/newdb/lib -R/usr/ucblib -L/usr/ucblib -R/opt/GNUgcc/lib/gcc/sparcv9-sun-solaris2.9/3.4.3 -L/opt/GNUgcc/lib/gcc/sparcv9-sun-solaris2.9/3.4.3 -R/opt/openssl/lib -L/opt/openssl/lib -R/opt/GNUgdbm/lib -L/opt/GNUgdbm/lib -R/opt/newdb/lib -L/opt/newdb/lib -R/opt/libxml2/lib -L/opt/libxml2/lib -R/opt/libjpg/lib -L/opt/libjpg/lib -R/opt/libpng/lib -L/opt/libpng/lib -R/opt/freetype/lib -L/opt/freetype/lib -R/opt/GNUmp/lib -L/opt/GNUmp/lib -R/opt/c-client/lib -L/opt/c-client/lib -R/opt/libmcrypt/lib -L/opt/libmcrypt/lib -R/opt/mysql/lib/mysql -L/opt/mysql/lib/mysql test.c -lmysqlclient -lmcrypt -lltdl -lssl -lcrypto -lpam -lgmp -lintl -lfreetype -lpng -lz -ljpeg -lz -ldb-4.1 -ldb-4.1 -lgdbm -lbz2 -lz -lssl -lcrypto -lresolv -lm -ldl -lnsl -lsocket -lgcc -lxml2 -lz -lm -lsocket -lnsl % ./test % echo $? 0 and with the crypt library: % gcc -o test -g -O2 -D_POSIX_PTHREAD_SEMANTICS -L/opt/newdb/lib -R/usr/ucblib -L/usr/ucblib -R/opt/GNUgcc/lib/gcc/sparcv9-sun-solaris2.9/3.4.3 -L/opt/GNUgcc/lib/gcc/sparcv9-sun-solaris2.9/3.4.3 -R/opt/openssl/lib -L/opt/openssl/lib -R/opt/GNUgdbm/lib -L/opt/GNUgdbm/lib -R/opt/newdb/lib -L/opt/newdb/lib -R/opt/libxml2/lib -L/opt/libxml2/lib -R/opt/libjpg/lib -L/opt/libjpg/lib -R/opt/libpng/lib -L/opt/libpng/lib -R/opt/freetype/lib -L/opt/freetype/lib -R/opt/GNUmp/lib -L/opt/GNUmp/lib -R/opt/c-client/lib -L/opt/c-client/lib -R/opt/libmcrypt/lib -L/opt/libmcrypt/lib -R/opt/mysql/lib/mysql -L/opt/mysql/lib/mysql test.c -lmysqlclient -lmcrypt -lltdl -lssl -lcrypto -lpam -lgmp -lintl -lfreetype -lpng -lz -ljpeg -lz -ldb-4.1 -ldb-4.1 -lgdbm -lbz2 -lz -lssl -lcrypto -lresolv -lm -ldl -lnsl -lsocket -lgcc -lxml2 -lz -lm -lsocket -lnsl -lcrypt % ./test zsh: segmentation fault (core dumped) ./test #0 0x7e8754e4 in DES_set_key_unchecked () from /opt/openssl/lib/libcrypto.so.0.9.7 #1 0x7e87e554 in _des_crypt () from /opt/openssl/lib/libcrypto.so.0.9.7 #2 0x00010ae4 in main () at test.c:15 Previous Comments: [2005-04-08 01:00:04] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2005-03-31 21:52:03] [EMAIL PROTECTED] Try to compile what you have in config.log, there should be the source file (you can remove the #include confdefs.h line from it) using the compile line above the failed test. And try get a GDB backtrace of the crash. [2005-03-31 16:45:04] pieter dot donche at ua dot ac dot be I have installed OpenSSL for the first time on Jan 28, 2004 (version 0.0.6l), and then on May 25, 2004 the version 0.9.7d both with --openssldir=/usr/local Yesterday(see above) I reinstalled 0.9.7d with no options in its .configure, so that it installs in its default place /usr/local/ssl. The problems exist already much longer than yesterday.. I also see I have a /usr/local/md5 directory, which was in 2002, installed to check fingerprints of Solaris binaries because we had had an intrusion. The tool was supplied by SUN. [2005-03-31 00:05:16] [EMAIL PROTECTED] Do you have many OpenSSL versions installed? Make sure you have exactly ONE version only. And that the libraries/headers match each other. [2005-03-30 17:40:14] pieter dot donche at ua dot ac dot be checking for standard DES.. yes ... no **ATTENTION** message make starts and completes without crashing BTW In previous case where the standard DES was not found, it still always was possible to do a make of php that did complete without crasjing, but when doing a make install it always crashed at Installing PEAR environment. I had the same problem with apache-1.3 and php-4.3.10 The remainder of the comments for this report are too long. To view the rest of the comments
#32630 [NEW]: strange error being generated by PHP
From: steve dot cersosimo at bellsouth dot com Operating system: Solaris 5.8 PHP version: 5.0.4 PHP Bug Type: SNMP related Bug description: strange error being generated by PHP Description: This relates to bug ID # 32613. I could not comment on that bug because it was marked as bogus. I too am getting a similar error, but only occasionally, and only when I use the proc_open or pcntl functions to fork additional PHP processes. The errors I get are: Cannot rename /var/net-snmp/snmpapp.conf to /var/net-snmp/snmpapp.0.conf Cannot unlink /var/net-snmp/snmpapp.conf Cannot unlink /var/net-snmp/snmpapp.0.conf Any help would be appreciated, Steve Cersosimo -- Edit bug report at http://bugs.php.net/?id=32630edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32630r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32630r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32630r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32630r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32630r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32630r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32630r=needscript Try newer version: http://bugs.php.net/fix.php?id=32630r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32630r=support Expected behavior: http://bugs.php.net/fix.php?id=32630r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32630r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32630r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32630r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32630r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32630r=dst IIS Stability: http://bugs.php.net/fix.php?id=32630r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32630r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32630r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32630r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32630r=mysqlcfg
#32480 [NEW]: PHP exiting with non-zero status or seg fault
From: steve dot cersosimo at bellsouth dot com Operating system: Solaris 5.8 PHP version: 5.0.3 PHP Bug Type: OCI8 related Bug description: PHP exiting with non-zero status or seg fault Description: I currently have my Oracle 8 environment set up properly as far as I can tell. With the simple code below, I do not understand why PHP is exiting with a 255. I think it should exit with a 0 status. In other cases I get a segmentation fault, but I believe if the problem here is solved, the seg fault will go away. Interestingly, the connection works fine, I can query and update perfectly. This is causing me problems when it generates a segmentation fault and dumps that string to the browser. Reproduce code: --- # cat ocitest #!/usr/local/bin/php ?php error_reporting(E_ALL); $db = (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP) (HOST = 172.16.0.153)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=SPEED.WORLD))); $connection = oci_connect(speed, pass, $db); var_dump($connection); ? # ocitest resource(6) of type (oci8 connection) # echo $? 255 -- Edit bug report at http://bugs.php.net/?id=32480edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32480r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32480r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32480r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32480r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32480r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32480r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32480r=needscript Try newer version: http://bugs.php.net/fix.php?id=32480r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32480r=support Expected behavior: http://bugs.php.net/fix.php?id=32480r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32480r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32480r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32480r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32480r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32480r=dst IIS Stability: http://bugs.php.net/fix.php?id=32480r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32480r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32480r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32480r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32480r=mysqlcfg
#32480 [Fbk-Opn]: PHP exiting with non-zero status or seg fault
ID: 32480 User updated by: steve dot cersosimo at bellsouth dot com Reported By: steve dot cersosimo at bellsouth dot com -Status: Feedback +Status: Open Bug Type: OCI8 related Operating System: Solaris 5.8 PHP Version: 5.0.3 New Comment: That seems to have fixed the problem. Should I wait for an official release, or is it safe to run the code you provided in a production environment. Unless it is too much for this format, what was the problem? Previous Comments: [2005-03-29 11:09:26] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip [2005-03-29 11:01:48] steve dot cersosimo at bellsouth dot com Description: I currently have my Oracle 8 environment set up properly as far as I can tell. With the simple code below, I do not understand why PHP is exiting with a 255. I think it should exit with a 0 status. In other cases I get a segmentation fault, but I believe if the problem here is solved, the seg fault will go away. Interestingly, the connection works fine, I can query and update perfectly. This is causing me problems when it generates a segmentation fault and dumps that string to the browser. Reproduce code: --- # cat ocitest #!/usr/local/bin/php ?php error_reporting(E_ALL); $db = (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP) (HOST = 172.16.0.153)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=SPEED.WORLD))); $connection = oci_connect(speed, pass, $db); var_dump($connection); ? # ocitest resource(6) of type (oci8 connection) # echo $? 255 -- Edit this bug report at http://bugs.php.net/?id=32480edit=1
#32480 [Fbk-Opn]: PHP exiting with non-zero status or seg fault
ID: 32480 User updated by: steve dot cersosimo at bellsouth dot com Reported By: steve dot cersosimo at bellsouth dot com -Status: Feedback +Status: Open Bug Type: OCI8 related Operating System: Solaris 5.8 PHP Version: 5.0.3 New Comment: I think the problem was somewhere in the OCI8 stuff. Here are my results from a few tests. # cat clitest #!/usr/local/bin/php ?php ? # clitest # echo $? 0 # cat clitest2 #!/home/software/apps/php5-STABLE-200503291430/sapi/cli/php ?php ? # clitest2 # echo $? 0 # cat ocitest #!/usr/local/bin/php ?php error_reporting(E_ALL); $db = (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP) (HOST = 172.16.0.153)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=SPEED.WORLD))); $connection = oci_connect(speed, pass, $db); var_dump($connection); ? # ocitest resource(6) of type (oci8 connection) # echo $? 255 # cat ocitest2 #!/home/software/apps/php5-STABLE-200503291430/sapi/cli/php ?php error_reporting(E_ALL); $db = (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP) (HOST = 172.16.0.153)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=SPEED.WORLD))); $connection = oci_connect(speed, pass, $db); var_dump($connection); ? # ocitest2 resource(6) of type (oci8 connection) # echo $? 0 Both of the first 2 tests exited with a 0 status, while the OCI8 test was only successful with the newly compiled PHP. Previous Comments: [2005-03-29 17:49:58] [EMAIL PROTECTED] I bet the problem is not OCI8 related and was fixed by this patch: http://cvs.php.net/diff.php/php-src/sapi/cli/php_cli.c?r1=1.51.2.36r2=1.51.2.37ty=u Could you please try to run PHP-CLI with simple ?php ? script and check the status ? [2005-03-29 17:44:56] steve dot cersosimo at bellsouth dot com That seems to have fixed the problem. Should I wait for an official release, or is it safe to run the code you provided in a production environment. Unless it is too much for this format, what was the problem? [2005-03-29 11:09:26] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip [2005-03-29 11:01:48] steve dot cersosimo at bellsouth dot com Description: I currently have my Oracle 8 environment set up properly as far as I can tell. With the simple code below, I do not understand why PHP is exiting with a 255. I think it should exit with a 0 status. In other cases I get a segmentation fault, but I believe if the problem here is solved, the seg fault will go away. Interestingly, the connection works fine, I can query and update perfectly. This is causing me problems when it generates a segmentation fault and dumps that string to the browser. Reproduce code: --- # cat ocitest #!/usr/local/bin/php ?php error_reporting(E_ALL); $db = (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP) (HOST = 172.16.0.153)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=SPEED.WORLD))); $connection = oci_connect(speed, pass, $db); var_dump($connection); ? # ocitest resource(6) of type (oci8 connection) # echo $? 255 -- Edit this bug report at http://bugs.php.net/?id=32480edit=1
#32293 [NEW]: Trouble accessing NNTP server
From: steve at harpservices dot com Operating system: Win XP/Pro PHP version: 5.0.3 PHP Bug Type: *General Issues Bug description: Trouble accessing NNTP server Description: I'm trying to access news.php.net and get extremely slow performance which causes by NNTP client (Forte Agent) to time out with a message Connection closed unexpectedly by server. The problem has persisted for several weeks. Are there any special settings that my NNTP client requires to use your site? I'm using an anonymous login and the site will begin to pull message headers and then crap out after about 60 seconds. I saw previous messages where you had to fix it or gave it a kick. Thanks for any help you can offer, Steve -- Edit bug report at http://bugs.php.net/?id=32293edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32293r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32293r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32293r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32293r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32293r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32293r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32293r=needscript Try newer version: http://bugs.php.net/fix.php?id=32293r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32293r=support Expected behavior: http://bugs.php.net/fix.php?id=32293r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32293r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32293r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32293r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32293r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32293r=dst IIS Stability: http://bugs.php.net/fix.php?id=32293r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32293r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32293r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32293r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32293r=mysqlcfg
#31421 [NEW]: get_current_user call crashes with Access Violation at 01CE1DAD
From: steve dot gilbreth at autodesk dot com Operating system: Win 2000 SP4 PHP version: 4.3.9 PHP Bug Type: Reproducible crash Bug description: get_current_user call crashes with Access Violation at 01CE1DAD Description: Call to get_current_user crashes when page is refreshed. I have to restart IIS 5.0 and the call will work 1st time only. If I refresh the page then ...ka-boom! Reproduce code: --- ?php echo html head titletest/title /head body; echo DEBUG: before call to get_current_user ...; $cu = get_current_user(); echo brDEBUG: after call. $cu; echo /body /html; ? Expected result: DEBUG: before call to get_current_user ... DEBUG: after call. userXX Actual result: -- PHP has encountered an Access Violation at 02271DAD DEBUG: before call to get_current_user ... -- Edit bug report at http://bugs.php.net/?id=31421edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31421r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31421r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31421r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31421r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31421r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31421r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31421r=needscript Try newer version: http://bugs.php.net/fix.php?id=31421r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31421r=support Expected behavior: http://bugs.php.net/fix.php?id=31421r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31421r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31421r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31421r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31421r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31421r=dst IIS Stability: http://bugs.php.net/fix.php?id=31421r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31421r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31421r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31421r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31421r=mysqlcfg
#30265 [NEW]: Can access properties but no methods of Win32_Process object
From: steve at qzed dot com
Operating system: Windows 2000
PHP version: 4.3.8
PHP Bug Type: COM related
Bug description: Can access properties but no methods of Win32_Process object
Description:
I am using the COM object of PHP to access WMI.
I can access Win32_Process objects and display their property values.
When I try to use Win32_Process method SetPriority I get a PHP error:
'Unable to lookup setpriority: Unknown name.'
Reproduce code:
---
?php
set_time_limit(0);
$shell = new COM(WScript.Shell);
$cmd = 'php.exe st1.php';
$st1 = $shell-Exec($cmd);
echo $cmd. Started as ProcessID .$st1-ProcessID.\n;
$wmi = new
COM('WinMgmts:{impersonationLevel=impersonate}!//./root/cimv2');
$query = Select * from Win32_Process where ProcessID =
.$st1-ProcessID;
$stillRunning = true;
while ($stillRunning) {
$stillRunning = False;
$processes = $wmi-ExecQuery($query);
while ($process = $processes-Next()) {
if ($process-ProcessID == $st1-ProcessID) {
echo process .$process-ProcessID. still running\n;
echo process .$process-ProcessID. priority is
.$process-Priority.\n;
$priority = 128;
$process-SetPriority($priority); //high
$stillRunning = true;
}
}
sleep(2);
}
echo process .$st1-ProcessID. ended;
?
Expected result:
D:\d2php tm.php
Content-type: text/html
X-Powered-By: PHP/4.3.8
php.exe st1.php Started as ProcessID 1052
process 1052 still running
process 1052 priority is 8
process 1052 still running
process 1052 priority is 8
process 1052 still running
process 1052 priority is 8
^C
Actual result:
--
D:\d2php tm.php
Content-type: text/html
X-Powered-By: PHP/4.3.8
php.exe st1.php Started as ProcessID 1488
process 1488 still running
process 1488 priority is 8
br /
bWarning/b: (null)(): Unable to lookup setpriority: Unknown name.
in bD:\d2\tm.php/b on line b31/bbr /
process 1488 still running
process 1488 priority is 8
br /
bWarning/b: (null)(): Unable to lookup setpriority: Unknown name.
in bD:\d2\tm.php/b on line b31/bbr /
process 1488 still running
process 1488 priority is 8
br /
bWarning/b: (null)(): Unable to lookup setpriority: Unknown name.
in bD:\d2\tm.php/b on line b31/bbr /
process 1488 still running
process 1488 priority is 8
br /
bWarning/b: (null)(): Unable to lookup setpriority: Unknown name.
in bD:\d2\tm.php/b on line b31/bbr /
^C
--
Edit bug report at http://bugs.php.net/?id=30265edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30265r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30265r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30265r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30265r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30265r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30265r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30265r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30265r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30265r=support
Expected behavior: http://bugs.php.net/fix.php?id=30265r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30265r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30265r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30265r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30265r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30265r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30265r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30265r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30265r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30265r=mysqlcfg
#30265 [Opn-Bgs]: Can access properties but no methods of Win32_Process object
ID: 30265
User updated by: steve at qzed dot com
Reported By: steve at qzed dot com
-Status: Open
+Status: Bogus
Bug Type: COM related
Operating System: Windows 2000
PHP Version: 4.3.8
New Comment:
This isn't an issue with PHP.
The SetPriority method on the Win32_Process Method is only available on
Windows XP and Windows 2003.
Previous Comments:
[2004-09-28 20:36:29] steve at qzed dot com
Description:
I am using the COM object of PHP to access WMI.
I can access Win32_Process objects and display their property values.
When I try to use Win32_Process method SetPriority I get a PHP error:
'Unable to lookup setpriority: Unknown name.'
Reproduce code:
---
?php
set_time_limit(0);
$shell = new COM(WScript.Shell);
$cmd = 'php.exe st1.php';
$st1 = $shell-Exec($cmd);
echo $cmd. Started as ProcessID .$st1-ProcessID.\n;
$wmi = new
COM('WinMgmts:{impersonationLevel=impersonate}!//./root/cimv2');
$query = Select * from Win32_Process where ProcessID =
.$st1-ProcessID;
$stillRunning = true;
while ($stillRunning) {
$stillRunning = False;
$processes = $wmi-ExecQuery($query);
while ($process = $processes-Next()) {
if ($process-ProcessID == $st1-ProcessID) {
echo process .$process-ProcessID. still running\n;
echo process .$process-ProcessID. priority is
.$process-Priority.\n;
$priority = 128;
$process-SetPriority($priority); //high
$stillRunning = true;
}
}
sleep(2);
}
echo process .$st1-ProcessID. ended;
?
Expected result:
D:\d2php tm.php
Content-type: text/html
X-Powered-By: PHP/4.3.8
php.exe st1.php Started as ProcessID 1052
process 1052 still running
process 1052 priority is 8
process 1052 still running
process 1052 priority is 8
process 1052 still running
process 1052 priority is 8
^C
Actual result:
--
D:\d2php tm.php
Content-type: text/html
X-Powered-By: PHP/4.3.8
php.exe st1.php Started as ProcessID 1488
process 1488 still running
process 1488 priority is 8
br /
bWarning/b: (null)(): Unable to lookup setpriority: Unknown name.
in bD:\d2\tm.php/b on line b31/bbr /
process 1488 still running
process 1488 priority is 8
br /
bWarning/b: (null)(): Unable to lookup setpriority: Unknown name.
in bD:\d2\tm.php/b on line b31/bbr /
process 1488 still running
process 1488 priority is 8
br /
bWarning/b: (null)(): Unable to lookup setpriority: Unknown name.
in bD:\d2\tm.php/b on line b31/bbr /
process 1488 still running
process 1488 priority is 8
br /
bWarning/b: (null)(): Unable to lookup setpriority: Unknown name.
in bD:\d2\tm.php/b on line b31/bbr /
^C
--
Edit this bug report at http://bugs.php.net/?id=30265edit=1
#29676 [NEW]: Octal truncated and used at first invalid digit, no error, no warning
From: steve dot phpnet at softcorp dot us Operating system: Windows, Linux PHP version: 4.3.8 PHP Bug Type: *Compile Issues Bug description: Octal truncated and used at first invalid digit, no error, no warning Description: Dear PHP gods... An invalid octal value of 08 or 09 is ignored starting with the first invalid digit (the 8 or the 9). The valid digits preceding the first invalid are taken resulting in octal 00. This behavior is fully documented (see Example 10-2 Octal Wierdness in the Integers section). This causes serious negative side-effects and is very easy to fall into. Plus, it is inconsistent. Other such coding errors with numerical constants are flagged as a PARSE ERROR. IMHO, coding 08 or 09 should produce a PARSE ERROR just like coding 0A or 0X0G does. The practical example where I encountered this error was with gmmktime. With several rows of gmmktime calls, I coded leading zeroes on the decimal arguments to make them line up in columns, not intending that they become octals. August (08) and September (09) were invalid octals and zero was used for the month instead. gmmktime did not flag month 00 as an error (gmmktime feature) and produced the wrong date. Observing very strange behavior and researching this, I found out why. IMHO this is a bug. Documenting this as an octal feature instead of rejecting the erroneous octals takes something away from the outstanding language that PHP is. Hope I'm not wasting your time... Most Respectfully... -Steve Jackson Reproduce code: --- ?php print - DECIMAL\n; $x = 8;print d=$x\n; // GOOD $x = 9;print d=$x\n; // GOOD $x = A;print d=$x\n; // ASSUMED TO BE A STRING WITH LETTER 'A' print - HEXADECIMAL\n; $x = 0x0E; print h=$x\n; // GOOD $x = 0x0F; print h=$x\n; // GOOD //$x = 0x0G; print h=$x\n; // PRODUCES PARSE ERROR print - OCTAL\n; $x = 06; print x=$x\n; // GOOD $x = 07; print x=$x\n; // GOOD $x = 08; print x=$xSHOULD PRODUCE PARSE ERROR. ZERO USED. \n; $x = 019; print x=$xSHOULD PRODUCE PARSE ERROR. ONE USED. \n; //$x = 0A; print x=$x\n; // PRODUCES PARSE ERROR print - PRACTICAL EXAMPLE\n; print Unintended result from gmmktime: . \n; $date = gmmktime ( 0, 0, 0, 08, 01, 2004 ); // SHOULD BE PARSE ERROR print date=$date . \n; print gmdate( n/j/Y H:i:s, $date ) . \n; ? Expected result: PARSE ERROR on the indicated lines. Actual result: -- Octal 08 and 019 were ignored. 00 and 01, respectively, were used instead without any warning or error at all. -- Edit bug report at http://bugs.php.net/?id=29676edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29676r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29676r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29676r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29676r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29676r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29676r=needscript Try newer version: http://bugs.php.net/fix.php?id=29676r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29676r=support Expected behavior: http://bugs.php.net/fix.php?id=29676r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29676r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29676r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29676r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29676r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29676r=dst IIS Stability: http://bugs.php.net/fix.php?id=29676r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29676r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29676r=float
#28933 [Com]: segfault using mysqli_fetch_array
ID: 28933 Comment by: steve at rueb dot com Reported By: francesco at pnpitalia dot it Status: Open Bug Type: Reproducible crash Operating System: linux gentoo 2q2004 PHP Version: 5CVS-2004-06-26 (dev) New Comment: I am seeing the same behavior with mysqli_fetch_assoc() on i386. MySQL 4.1.3beta PHP 5.0.0 final --with-mysqli --with-zlib --with-dom --with-gdbm Previous Comments: [2004-06-26 12:58:26] francesco at pnpitalia dot it Description: Using mysqli_fetch_array with *all* parameter (result and type) crashes php php -e test_mysqli.php gdb php core (gdb) bt #0 zend_object_store_get_object (zobject=0x2a) at /INSTALL/php/php-src/Zend/zend_objects_API.c:192 #1 0x0051ad48 in php_mysqli_fetch_into_hash (ht=2, return_value=0x2a957b0dd0, this_ptr=0x0, return_value_used=-1073757328, override_flags=0, into_object=0) at /INSTALL/php/php-src/ext/mysqli/mysqli.c:602 #2 0x00522b1f in zif_mysqli_fetch_array (ht=0, return_value=0x7fbfffc3b0, this_ptr=0x2, return_value_used=-1073757328) at /INSTALL/php/php-src/ext/mysqli/mysqli_nonapi.c:183 #3 0x0069fa3b in zend_do_fcall_common_helper (execute_data=0x7fbfffcac0, opline=0x2a957b6360, op_array=0x2a957b1a10) at /INSTALL/php/php-src/Zend/zend_execute.c:2699 #4 0x0069fb8a in zend_do_fcall_handler (execute_data=0x7fbfffcac0, opline=0x2a957b6360, op_array=0x2a957b1a10) at /INSTALL/php/php-src/Zend/zend_execute.c:2828 #5 0x0069c350 in execute (op_array=0x2a957b1a10) at /INSTALL/php/php-src/Zend/zend_execute.c:1391 #6 0x0067cba9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /INSTALL/php/php-src/Zend/zend.c:1061 #7 0x00641f4f in php_execute_script (primary_file=0x7fb100) at /INSTALL/php/php-src/main/main.c:1627 #8 0x006aa3d5 in main (argc=3, argv=0x7fb268) at /INSTALL/php/php-src/sapi/cli/php_cli.c:943 other info: #uname -a Linux db 2.6.7-mm1 #2 SMP Mon Jun 21 11:36:21 CEST 2004 x86_64 5 GNU/Linux #cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 5 model name : AMD Opteron(tm) Processor 246 stepping: 8 cpu MHz : 1992.117 cache size : 1024 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow bogomips: 3915.77 TLB size: 1088 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts ttp processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 5 model name : AMD Opteron(tm) Processor 246 stepping: 8 cpu MHz : 1992.117 cache size : 1024 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow bogomips: 3981.31 TLB size: 1088 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts ttp gcc --version gcc (GCC) 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. gcc --version gcc (GCC) 3.4.0 20040601 (Gentoo Linux 3.4.0-r6, ssp-3.4-2, pie-8.7.6.3) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. mysql --version mysql Ver 14.5 Distrib 5.0.1-alpha, for unknown-linux (x86_64) (also with 4.1.2) system is gentoo linux ~amd64 #making php ./configure \ \ --enable-debug \ \ --prefix=/usr \ --with-apxs2=/usr/local/apache/bin/apxs \ --with-readline --disable-cgi \ --enable-cli --enable-embed \ --with-ndbm=/usr --with-db4=/usr \ --with-mcrypt=/usr --with-mhash=/usr \ --with-ming=/usr --with-gdbm=/usr \ --with-java=/opt/blackdown-jdk-1.4.2_rc1 \ --without-pgsql --with-xpm-dir=/usr/X11R6 \ --with-pdflib=/usr --with-gd \ --enable-gd-native-ttf --with-png \ --with-png-dir=/usr --with-jpeg \ --with-jpeg-dir=/usr --enable-exif \ --with-tiff --with-tiff-dir=/usr \ --with-freetype-dir=/usr --with-ttf=/usr \ --with-t1lib=/usr --with-gettext \ --with-qtdom=/usr/qt/3 --with-pspell=/usr \ --with-openssl=/usr --without-imap \ --without-ldap --with-dom=/usr \ --with-dom-xslt=/usr --with-dom-exslt=/usr \ --without-kerberos --with-pam \ --disable-memory-limit --enable-ipv6 \ --with-curlwrappers --with-curl
#28933 [Com]: segfault using mysqli_fetch_array
ID: 28933 Comment by: steve at rueb dot com Reported By: francesco at pnpitalia dot it Status: Open Bug Type: Reproducible crash Operating System: linux gentoo 2q2004 PHP Version: 5CVS-2004-06-26 (dev) New Comment: This seems to be fixed in CVS. Previous Comments: [2004-07-17 21:16:19] steve at rueb dot com I am seeing the same behavior with mysqli_fetch_assoc() on i386. MySQL 4.1.3beta PHP 5.0.0 final --with-mysqli --with-zlib --with-dom --with-gdbm [2004-06-26 12:58:26] francesco at pnpitalia dot it Description: Using mysqli_fetch_array with *all* parameter (result and type) crashes php php -e test_mysqli.php gdb php core (gdb) bt #0 zend_object_store_get_object (zobject=0x2a) at /INSTALL/php/php-src/Zend/zend_objects_API.c:192 #1 0x0051ad48 in php_mysqli_fetch_into_hash (ht=2, return_value=0x2a957b0dd0, this_ptr=0x0, return_value_used=-1073757328, override_flags=0, into_object=0) at /INSTALL/php/php-src/ext/mysqli/mysqli.c:602 #2 0x00522b1f in zif_mysqli_fetch_array (ht=0, return_value=0x7fbfffc3b0, this_ptr=0x2, return_value_used=-1073757328) at /INSTALL/php/php-src/ext/mysqli/mysqli_nonapi.c:183 #3 0x0069fa3b in zend_do_fcall_common_helper (execute_data=0x7fbfffcac0, opline=0x2a957b6360, op_array=0x2a957b1a10) at /INSTALL/php/php-src/Zend/zend_execute.c:2699 #4 0x0069fb8a in zend_do_fcall_handler (execute_data=0x7fbfffcac0, opline=0x2a957b6360, op_array=0x2a957b1a10) at /INSTALL/php/php-src/Zend/zend_execute.c:2828 #5 0x0069c350 in execute (op_array=0x2a957b1a10) at /INSTALL/php/php-src/Zend/zend_execute.c:1391 #6 0x0067cba9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /INSTALL/php/php-src/Zend/zend.c:1061 #7 0x00641f4f in php_execute_script (primary_file=0x7fb100) at /INSTALL/php/php-src/main/main.c:1627 #8 0x006aa3d5 in main (argc=3, argv=0x7fb268) at /INSTALL/php/php-src/sapi/cli/php_cli.c:943 other info: #uname -a Linux db 2.6.7-mm1 #2 SMP Mon Jun 21 11:36:21 CEST 2004 x86_64 5 GNU/Linux #cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 5 model name : AMD Opteron(tm) Processor 246 stepping: 8 cpu MHz : 1992.117 cache size : 1024 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow bogomips: 3915.77 TLB size: 1088 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts ttp processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 5 model name : AMD Opteron(tm) Processor 246 stepping: 8 cpu MHz : 1992.117 cache size : 1024 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow bogomips: 3981.31 TLB size: 1088 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts ttp gcc --version gcc (GCC) 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. gcc --version gcc (GCC) 3.4.0 20040601 (Gentoo Linux 3.4.0-r6, ssp-3.4-2, pie-8.7.6.3) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. mysql --version mysql Ver 14.5 Distrib 5.0.1-alpha, for unknown-linux (x86_64) (also with 4.1.2) system is gentoo linux ~amd64 #making php ./configure \ \ --enable-debug \ \ --prefix=/usr \ --with-apxs2=/usr/local/apache/bin/apxs \ --with-readline --disable-cgi \ --enable-cli --enable-embed \ --with-ndbm=/usr --with-db4=/usr \ --with-mcrypt=/usr --with-mhash=/usr \ --with-ming=/usr --with-gdbm=/usr \ --with-java=/opt/blackdown-jdk-1.4.2_rc1 \ --without-pgsql --with-xpm-dir=/usr/X11R6 \ --with-pdflib=/usr --with-gd \ --enable-gd-native-ttf --with-png \ --with-png-dir=/usr --with-jpeg \ --with-jpeg-dir=/usr --enable-exif \ --with-tiff --with-tiff-dir=/usr \ --with-freetype-dir=/usr --with-ttf=/usr \ --with-t1lib=/usr --with-gettext \ --with-qtdom=/usr/qt/3 --with-pspell=/usr \ --with-openssl=/usr --without-imap \ --without-ldap --with-dom=/usr
#25876 [Com]: session_start(): Failed to initialize storage module
ID: 25876
Comment by: steve at bespokeinternet dot com
Reported By: golden at riscom dot com
Status: Closed
Bug Type: Session related
Operating System: freebsd 4.8
PHP Version: 4.3.3
New Comment:
We have had this problem with various sites running off the same server
(Apache/1.3.29 - Unix Server). A recent upgrade to 4.3.6 has not
resolved the problem.
Same sites worked fine on other servers running recent versions of
PHP.
Error message is sporadic and disappears with one or two refreshes.
With versions prior to 4.3.6 it was necessary to restart Apache to
clear the problem - that doesn't seem to be the case since the
upgrade.
Suggest reopening this bug report.
Previous Comments:
[2004-05-05 07:27:32] tkaeser at gmx dot net
Hi,
had the same error, added the following line before starting the
session:
ini_set('session.save_handler', 'files');
this fixed it in my case...
I don't have any idea why this works, got it from
http://lists.mushaake.org/pipermail/php/Week-of-Mon-20031117/004091.html
[2004-04-05 08:17:56] venkat at ehostpros dot com
#
Problem :
Fatal error: session_start(): Failed to initialize storage module
#
The solution (fingers crossed) was to clear the session.save_path
directory - it got thousands of session files there.
Hope it helps someone out there.
#
The above solution works fine :)
Thanks,
Venkatesh.G
[2004-04-01 16:37:42] php dot net at harrysufehmi dot com
I just experienced this problem with php 4.3.3
The solution (fingers crossed) was to clear the session.save_path
directory - it got thousands of session files there.
Hope it helps someone out there.
[2004-03-08 05:38:31] hck7 at mailcity dot com
We installed PHP 4.3.1 and this problem disappears!!!
Thanks for all !!!
[2004-03-02 04:49:14] ozone at sange dot fi
As suggested by mivox on Feb 12 in comments to bug 26038, which seems
to be a duplicate of this one, I added a line in my apache.conf:
php_value session.save_handler files
(source: http://bugs.php.net/bug.php?id=260389 )
After this I haven't seen any problems (running for a bit less than a
day), but it's hard to say whether it really helped.
Maybe there are still problems with the initialization of session
parameters when PHP is running as a module and the same code is used to
serve lots of requests.
For me the problems started when using FreeBSD 4-STABLE (4.8 I think,
or even earlier) with PHP 4.2.x and continued with PHP 4.3.x, but they
were very infrequent when using Apache 1.3. Upgrading to Apache 2 made
problems turn up much more often and users started complaining loudly.
I applied the patch from CVS that was supposed to fix the problem to
PHP 4.3.4 (from FreeBSD ports) but it didn't help. Of course that's not
quite the same as trying a recent snapshot, but other people have tried
that and it didn't help either.
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/25876
--
Edit this bug report at http://bugs.php.net/?id=25876edit=1
#25863 [Com]: IIS: The specified CGI application misbehaved
ID: 25863 Comment by: steve at xcvr dot com Reported By: salmanarshad2000 at yahoo dot com Status: Closed Bug Type: CGI related Operating System: win32 only PHP Version: 4CVS, 5CVS, 6CVS.. New Comment: I've had had this issue occur in my fresh installation of 4.3.6 (Win2K, CGI), even after applying all the recommended fixes/changes/configurations. So far, I've found that if I remove one particular image, the problem goes away. Put the image back, and the problem creeps up again. I've changed around the img tag, and still cannot get rid of the ...CGI application misbehaved FWIW, this page uses SSL. Previous Comments: [2004-01-27 07:06:04] salmanarshad2000 at yahoo dot com Saw the problem for two more days after installing PHP version 4.3.4 (replacing version 4.3.3), after that the problem completely disappeared. [2003-12-12 16:46:57] nigel dot salt at hotmail dot com I followed all the hints here but IIS 5 and PHP 5 would still not behave. What was necessary in the end was: 1) Set [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Script Map] .php=your path to php\\php.exe 2) ensure there is not a php.ini in the windows system folder and that there is one wherever you've put PHP 3) edit php.ini and set cgi force redirect to 0 and cgi.rfc2616_headers = 1 4) Put the PHP scripts in their own folder underneath the inetpub root 5) Open the IIS console, right click your new php folder In the Directory tab set application name to the name of the folder set executable and script as permission set application protection to low Click configuration and check that .php is mapped to wherever you put PHP Restart IIS Try a very simple PHP page and it should work Nigel [2003-10-14 08:44:21] salmanarshad2000 at yahoo dot com Description: This bug or issue has been around for quite a while and seems like nobody cares. The bug list is filled with hundreds of complains about the The specified CGI application misbehaved ... error each time these people have BOGUSed or CLOSEd saying things like The version you are using is too old, please try the latest version ..., This is not a php bug, please go to ..., Not enough evidence ... or Problem with Windows, not PHP. Quite a few versions of php have been released in the meanwhile, but this issue hasn't been fixed, people who upgrade their php installation come back with the same complains. I see no good reason for this ignorance. Problem Statement - When browsing a php application, the IIS server randomly throws the error message: CGI Error The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: BLANK Observations This happened only when: - PHP.exe is used as a CGI on IIS - The php scripts contained 2 or more frames (e.g. phpMyAdmin) - MySQL operation was executed (update, insert, delete etc.) - header(Location: ...) is used to redirect user after a MySQL operation to a page that also performs a MySQL operation - The pages are viewed from local computer - A very fast computer is used This did not happened when: - Apache server for windows with php support was used - The php scripts contained 2 or more frames but all frames contained php scripts with Hello World and a random number - Frequency of errors was much lesser when same pages were accessed from the network - Pentium 2, 300 MHz was used (a slow computer) History --- Following bugs are all related to this problem. This is just a reminder for the fact that this issue has been discussed quite a few times and it is still present. People also found these interesting things that might help to get the problem solved. - BugID #25567 getting errors when doing a mysql_db_query() and then header(location) - BugID #24916 header(location) - BugID #23208 using two or more frames - BugID #19381 no details :( - BugID #19676 works on one (slow) system but does not work on other - BugID #18901 header(location) after delete or update, error occurs under under load - BugID #16313 header(location) and db operations - BugID #23050 mysql_query() followed by header(location) - BugID #17468 header(location) - BugID #9852 thousands of lines describing the problem, including frames, manually slowing down the script, pages work from outside the machine nut not locally, two database connections in rapid succession etc Things that have been said earlier -- This is a problem with Microsoft OS No this is not, it works on exact same OS running on slower hardware or when the application is accessed across a network. And even if it is, the developers should try to find a work around instead
#28094 [NEW]: class type hints ambiguity
From: steve at przepiora dot org
Operating system: windows xp
PHP version: 5.0.0RC1
PHP Bug Type: Zend Engine 2 problem
Bug description: class type hints ambiguity
Description:
When using class type hints with a string a runtime error occurs.
Reproduce code:
---
?php
function foo(string $bar){
echo $bar;
}
foo(baz);
?
Expected result:
The printout of baz
Actual result:
--
Fatal error: Argument 1 must be an object of class string in c:\program
files\apache group\Apache\htdocs\index.php on line 2
--
Edit bug report at http://bugs.php.net/?id=28094edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28094r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28094r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28094r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28094r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28094r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28094r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28094r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28094r=support
Expected behavior: http://bugs.php.net/fix.php?id=28094r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28094r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28094r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28094r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28094r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28094r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28094r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28094r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28094r=float
#27744 [Bgs]: 141.23 - 141.00 = 0.22999999999999 ?
ID: 27744 User updated by: t dot steve at ariadne-quatra dot com Reported By: t dot steve at ariadne-quatra dot com Status: Bogus Bug Type: Math related Operating System: * PHP Version: * New Comment: Guys, guys, guys... :) I want to make one thing clear: No offense was meant, and I still think PHP is great, and that I learned something new - even though I think this is probably not the correct forum for that. :) I never imagined this would turn out to be such a long discussion - it seems I accidentally touched on something that others came across too. Just as pont of interest: We also use PHP for our (travel agency..) intra+extranet admin system, and among other things, we use PHP-generated forms to order hotel rooms for our clients. At times we get forms requesting a hotel room for 3.999.. nights :)) Now I know why. Thanks again for all the reactions, and keep up the excellent work! :) Previous Comments: [2004-03-31 10:28:25] [EMAIL PROTECTED] For a computer there is simply no such thing as exactly 0.23, it is as simple as that. When displaying floating point numbers, either use printf() and specify the number of significant digits you want or use PHP's precision setting. As for this suggestion: Maybe a magicless solution would be: don't use greater precision then either the minuend or subtrahend (the one with greatest precision). Reducing precision during the calculation would magnify rounding errors greatly when doing a series of operations on the floating point values. You want to apply lower precision at the end at display time, not during the calculation. And at display time we don't know what the precicion of the operands were that led to this value which is why you need to explicitly express what precision you want values displayed at. [2004-03-31 06:41:40] garbo_doe at hotmail dot com echo (string)(75000.00 - 74999.00); returns 1, not 0.99. Is this a bug then? ;) Guys, how in the world is PHP supposed to magically guess what precision you want results displayed in. Maybe a magicless solution would be: don't use greater precision then either the minuend or subtrahend (the one with greatest precision). Thanks for you answers and for PHP - it's great! :-) (I hope I'm not too annoying continuing this discussion...I sense some irritation, we have already explained, on this matter :-) [2004-03-31 03:12:23] [EMAIL PROTECTED] Since you don't believe us: http://docs.sun.com/source/806-3568/ncg_goldberg.html [2004-03-30 21:40:21] [EMAIL PROTECTED] Floating point values in computers are never exact. It's a fact of life, and an issue that is not only encountered with PHP but other languages as well. [2004-03-30 21:35:54] t dot steve at ariadne-quatra dot com Hi! I am sure I am something, apologies for that. :( Guys, how in the world is PHP supposed to magically guess what precision you want results displayed in. 141.23 - 141 _is_ precisely 0.23. If I was asking for 1/3, then I would understand the decimal places. But how come 141.23-141 turns out to have so many decimal places in the end instead of just being 0.23 - the mathematically correct and precise result? 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/27744 -- Edit this bug report at http://bugs.php.net/?id=27744edit=1
#27744 [Bgs]: 141.23 - 141.00 = 0.22999999999999 ?
ID: 27744
User updated by: t dot steve at ariadne-quatra dot com
Reported By: t dot steve at ariadne-quatra dot com
Status: Bogus
Bug Type: Math related
Operating System: *
PHP Version: *
New Comment:
Hi!
I am sure I am something, apologies for that. :(
Guys, how in the world is PHP supposed to magically guess what
precision you want results displayed in.
141.23 - 141 _is_ precisely 0.23. If I was asking for 1/3, then I would
understand the decimal places. But how come 141.23-141 turns out to
have so many decimal places in the end instead of just being 0.23 - the
mathematically correct and precise result?
Previous Comments:
[2004-03-30 19:59:05] [EMAIL PROTECTED]
Guys, how in the world is PHP supposed to magically guess what
precision you want results displayed in. If you know you always want
lower precision, set that in your php.ini file. Or if you just want it
temporarily simply do:
$old = ini_set('precision',2);
echo (string)(750 - 749.99);
ini_set('precision',$old);
[2004-03-30 19:47:47] [EMAIL PROTECTED]
create table a ( b float,c float );
Query OK, 0 rows affected (0.11 sec)
mysql insert into a (b,c) values (141.23,141);
Query OK, 1 row affected (0.07 sec)
mysql select b-c from a;
+--+
| b-c |
+--+
| 0.22999572753906 |
+--+
1 row in set (0.00 sec)
[2004-03-30 13:45:03] [EMAIL PROTECTED]
That is the whole point of the answer. Floating point values are not
accurate and are not nice. And we do not do a bunch of work just to
make them look better in certain circumstances.
[2004-03-30 12:07:45] garbo_doe at hotmail dot com
IMHO I think this is a bug. Of course there are problems with
floatingpoint values in binary form, especially when rounded many
times. But in an operation like ?php echo (string)(750 - 749.99) ? it
shouldn't return 0.00 but 0.01.
I did a quick test in Delphi: showmessage(floattostr(750 - 749.99));
returns 0.01, not 0.00.
I had to solve it in PHP but multiplying with 100, then subtract and
then divide the result by 100 again.
It's not pretty :-D
(0.00999[infinite 9's] IS exactly the same as 0.01, but it should
remember the infinite with a bit or something, so (1/3)*3 = 1 and not
0.9)
(this is similar as bug #8164)
[2004-03-29 01:06:46] [EMAIL PROTECTED]
Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.
Thank you for your interest in PHP.
.
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/27744
--
Edit this bug report at http://bugs.php.net/?id=27744edit=1
#27744 [NEW]: 141.23 - 141.00 = 0.22999999999999 ?
From: t dot steve at ariadne-quatra dot com Operating system: Windows 2000 Server SP4 PHP version: 5.0.0RC1 PHP Bug Type: Math related Bug description: 141.23 - 141.00 = 0.22 ? Description: Subtraction does not work as expected. Windows 2000 Server SP4 IIS5 PHP5RC1 Reproduce code: --- $result=141.23-141.00; echo $result; (or $result=141.23-141; echo $result; - same result) Expected result: 0.23 Actual result: -- 0.22 -- Edit bug report at http://bugs.php.net/?id=27744edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27744r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27744r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27744r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27744r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27744r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27744r=needscript Try newer version: http://bugs.php.net/fix.php?id=27744r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27744r=support Expected behavior: http://bugs.php.net/fix.php?id=27744r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27744r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27744r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27744r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27744r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27744r=dst IIS Stability: http://bugs.php.net/fix.php?id=27744r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27744r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27744r=float
#27221 [Com]: $_POST superglobal variable not populated after posting a form
ID: 27221 Comment by: steve dot carrico at louisville dot edu Reported By: patrick at studioemma dot be Status: Bogus Bug Type: *General Issues Operating System: Redhat 7.3 PHP Version: 4.3.4 New Comment: I don't beleive this is a PHP bug. We started receiving similar problem reports at the university I work for after the latest Internet Explorer security update was released. I came across the following Microsoft Knowledge Base article yesterday and the software update linked under the Resolution section appears to fix the problem: http://support.microsoft.com/default.aspx?scid=kb;en-us;831167 Previous Comments: [2004-02-12 10:02:39] [EMAIL PROTECTED] Can not reproduce using latest CVS (or even with 4.3.4) [2004-02-12 05:10:24] patrick at studioemma dot be I will wait for the definite release. I can however allready add these comments: - only occurs on SSL - occurs when some fields (no reserved words as names) have spaces, numeric values, and perhaps others. In the meantime I moved to just HTTP instead of HTTPS [2004-02-11 15:02:01] [EMAIL PROTECTED] Just try the snapshot first. [2004-02-11 14:51:49] patrick at studioemma dot be my httpd.conf only mentions: AddType application/x-httpd-php .php4 .php3 .phtml .php AddType application/x-httpd-php-source .phps However I have found a key to the origin: apparently the values I enter in the form influence the problem. I have been able to reproduce but cannot figure out any logic. I have to mention I'm only using a-zA-Z and - signs.. it's like black magic... I have not yet installed the snapshot, will definitely await final release. I have to mention as well that I just upgraded to 4.3.4 from 4.3.2 where the problem occured as well. [2004-02-11 14:04:52] [EMAIL PROTECTED] Obviously you are not using Apache2, so Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE- latest.zip 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/27221 -- Edit this bug report at http://bugs.php.net/?id=27221edit=1
#26618 [Opn]: Using % % tags makes include() not to work (sometimes)
ID: 26618 User updated by: t dot steve at ariadne-quatra dot com Reported By: t dot steve at ariadne-quatra dot com Status: Open Bug Type: IIS related Operating System: Windows 2000 server SP4 PHP Version: 5CVS-2003-12-14 New Comment: Another note: This cannot be an IIS related bug, it must be related to PHP itself since all previous versions of PHP worked fine even with the ASP delimiters (% %) which I have to use. The problem arose only as of version 5.x - including the latest build which I just tested. Previous Comments: [2003-12-16 03:04:33] t dot steve at ariadne-quatra dot com YES, with conventional ?php ? tags the includes work perfectly and consistently! :) However, this IS still a problem - I need to use the % % because of the editor I must use (FP...)! ASP-style tags ARE - in theory - supported, aren't they? (They are enabled in the INI file, and I have been using them in all our sites for ages without any problems!) So then the problem changes to ASP-style % % tags versus regular ?php ? tags... Do I have to open a new bug report, or just leave this one open? Thanks! [2003-12-16 02:48:32] [EMAIL PROTECTED] Try using the PHP tags, not those ugly ASP tags. (% % - ?php ?) [2003-12-14 10:46:58] t dot steve at ariadne-quatra dot com Description: PHP5 beta2 IIS5 Windows 2000 SP4 ISAPI mode - Worked correctly with PHP4.3.4 with Zend 2.0.1 - With PHP5 beta2 (also ISAPI mode) a simple PHP page which uses include_once([local path]) to include the menu part of a web page sometimes works, sometimes does not (sometimes the menu is included, sometimes it is not). (There is only the single include_once in the code, so this is NOT an issue of my trying to include something twice with include_ONCE... ) - The page contains NO other PHP code, just the lines below: % include_once(c:/wwwroot/domain.com/english/inc/header.inc); % (html_head.inc is the file to be included, it contains only html code, no php) - Again, note that the exact same page, exact same setup works fine under 4.3.4 - and has done so with previous versions! - Under PHP5, with every refresh of the page the inclusion of the file is erratic - every few refreshes the inclusion is not done. If you need any part of my php.ini, let me know please. Thanks, Steve Reproduce code: --- html head titleThe world of services/title /head body % include_once(c:/wwwroot/domain.com/english/inc/header.inc); % Please select from the menu on the left! /body /html Expected result: A page with the menu on the left (created fromt he included file), plus the contents. Actual result: -- Only the contents apperas, the inclusion is not done. -- Edit this bug report at http://bugs.php.net/?id=26618edit=1
#26618 [Fbk-Opn]: include_once() sometimes works, sometimes doesn't with each page refresh
ID: 26618 User updated by: t dot steve at ariadne-quatra dot com Reported By: t dot steve at ariadne-quatra dot com -Status: Feedback +Status: Open Bug Type: Zend Engine 2 problem Operating System: Windows 2000 server SP4 PHP Version: 5CVS-2003-12-14 New Comment: YES, with conventional ?php ? tags the includes work perfectly and consistently! :) However, this IS still a problem - I need to use the % % because of the editor I must use (FP...)! ASP-style tags ARE - in theory - supported, aren't they? (They are enabled in the INI file, and I have been using them in all our sites for ages without any problems!) So then the problem changes to ASP-style % % tags versus regular ?php ? tags... Do I have to open a new bug report, or just leave this one open? Thanks! Previous Comments: [2003-12-16 02:48:32] [EMAIL PROTECTED] Try using the PHP tags, not those ugly ASP tags. (% % - ?php ?) [2003-12-15 22:04:48] t dot steve at ariadne-quatra dot com - No, I get no errors even after adding 'error_reporting(E_ALL);'. - Yes, the same behaviour even if I use include() instead of include_once(). [2003-12-15 09:25:33] [EMAIL PROTECTED] Do you get any errors if you put 'error_reporting(E_ALL);' before the include_once() line? Does this happen if you use include() ? [2003-12-15 08:40:15] t dot steve at ariadne-quatra dot com The same :( - includes are done eratically. A note here: this is also the case if I start to wander around the site (as opposed to just refreshing the same page again and again), i.e. as the various pages are loaded, sometimes the inlude is done, sometimes it is not. [2003-12-14 20:21:56] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip 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/26618 -- Edit this bug report at http://bugs.php.net/?id=26618edit=1
#26618 [Fbk-Opn]: include_once() sometimes works, sometimes doesn't with each page refresh
ID: 26618 User updated by: t dot steve at ariadne-quatra dot com Reported By: t dot steve at ariadne-quatra dot com -Status: Feedback +Status: Open Bug Type: Zend Engine 2 problem Operating System: Windows 2000 server SP4 PHP Version: 5.0.0b2 (beta2) New Comment: The same :( - includes are done eratically. A note here: this is also the case if I start to wander around the site (as opposed to just refreshing the same page again and again), i.e. as the various pages are loaded, sometimes the inlude is done, sometimes it is not. Previous Comments: [2003-12-14 20:21:56] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2003-12-14 10:46:58] t dot steve at ariadne-quatra dot com Description: PHP5 beta2 IIS5 Windows 2000 SP4 ISAPI mode - Worked correctly with PHP4.3.4 with Zend 2.0.1 - With PHP5 beta2 (also ISAPI mode) a simple PHP page which uses include_once([local path]) to include the menu part of a web page sometimes works, sometimes does not (sometimes the menu is included, sometimes it is not). (There is only the single include_once in the code, so this is NOT an issue of my trying to include something twice with include_ONCE... ) - The page contains NO other PHP code, just the lines below: % include_once(c:/wwwroot/domain.com/english/inc/header.inc); % (html_head.inc is the file to be included, it contains only html code, no php) - Again, note that the exact same page, exact same setup works fine under 4.3.4 - and has done so with previous versions! - Under PHP5, with every refresh of the page the inclusion of the file is erratic - every few refreshes the inclusion is not done. If you need any part of my php.ini, let me know please. Thanks, Steve Reproduce code: --- html head titleThe world of services/title /head body % include_once(c:/wwwroot/domain.com/english/inc/header.inc); % Please select from the menu on the left! /body /html Expected result: A page with the menu on the left (created fromt he included file), plus the contents. Actual result: -- Only the contents apperas, the inclusion is not done. -- Edit this bug report at http://bugs.php.net/?id=26618edit=1
#26618 [Fbk-Opn]: include_once() sometimes works, sometimes doesn't with each page refresh
ID: 26618 User updated by: t dot steve at ariadne-quatra dot com Reported By: t dot steve at ariadne-quatra dot com -Status: Feedback +Status: Open Bug Type: Zend Engine 2 problem Operating System: Windows 2000 server SP4 PHP Version: 5CVS-2003-12-14 New Comment: - No, I get no errors even after adding 'error_reporting(E_ALL);'. - Yes, the same behaviour even if I use include() instead of include_once(). Previous Comments: [2003-12-15 09:25:33] [EMAIL PROTECTED] Do you get any errors if you put 'error_reporting(E_ALL);' before the include_once() line? Does this happen if you use include() ? [2003-12-15 08:40:15] t dot steve at ariadne-quatra dot com The same :( - includes are done eratically. A note here: this is also the case if I start to wander around the site (as opposed to just refreshing the same page again and again), i.e. as the various pages are loaded, sometimes the inlude is done, sometimes it is not. [2003-12-14 20:21:56] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2003-12-14 10:46:58] t dot steve at ariadne-quatra dot com Description: PHP5 beta2 IIS5 Windows 2000 SP4 ISAPI mode - Worked correctly with PHP4.3.4 with Zend 2.0.1 - With PHP5 beta2 (also ISAPI mode) a simple PHP page which uses include_once([local path]) to include the menu part of a web page sometimes works, sometimes does not (sometimes the menu is included, sometimes it is not). (There is only the single include_once in the code, so this is NOT an issue of my trying to include something twice with include_ONCE... ) - The page contains NO other PHP code, just the lines below: % include_once(c:/wwwroot/domain.com/english/inc/header.inc); % (html_head.inc is the file to be included, it contains only html code, no php) - Again, note that the exact same page, exact same setup works fine under 4.3.4 - and has done so with previous versions! - Under PHP5, with every refresh of the page the inclusion of the file is erratic - every few refreshes the inclusion is not done. If you need any part of my php.ini, let me know please. Thanks, Steve Reproduce code: --- html head titleThe world of services/title /head body % include_once(c:/wwwroot/domain.com/english/inc/header.inc); % Please select from the menu on the left! /body /html Expected result: A page with the menu on the left (created fromt he included file), plus the contents. Actual result: -- Only the contents apperas, the inclusion is not done. -- Edit this bug report at http://bugs.php.net/?id=26618edit=1
#26618 [Fbk-Opn]: include_once() sometimes works, sometimes doesn't with each page refresh
ID: 26618 User updated by: t dot steve at ariadne-quatra dot com Reported By: t dot steve at ariadne-quatra dot com -Status: Feedback +Status: Open Bug Type: Zend Engine 2 problem Operating System: Windows 2000 server SP4 PHP Version: 5CVS-2003-12-14 New Comment: I always downloaded http://snaps.php.net/win32/php5-win32-latest.zip each time I tried something new! It was no different this time - a new download and install before I tried what you requested! (No local proxy or cache - I am downloading the actual file each time!) I have ALL PHP-related DLLs in my PHP dir, nothing in WINNT and so on... I checked and double-checked! Each time I want to try PHP5 this is what I do: - stop IIS - rename PHP (whcih is where my current PHP version resides) to PHP4 - create a new, empty PHP dir, and expand the downloaded ZIP in there - copy the php4isapi.dll from the sapi folder up one level to the PHP folder (this is how I have IIS set up) - no need to move anything anywhere else, my system is set up so that there is no need to copy any DLLS to the WINNT directory (I also checked to make sure there are none there - there aren't!) - then restart IIS - test... Please let me know if there is anything else I can do to help! Many thanks! Steve Previous Comments: [2003-12-15 23:58:55] [EMAIL PROTECTED] Are you absolutely sure you are using the latest CVS snapshot? Grab the latest now, remove ALL (and I mean _all_) php related dlls from your system before you install it. Most important one being php4ts.dll (make sure you only have ONE of those around). Also make sure IIS is not running when you install PHP.. [2003-12-15 22:04:48] t dot steve at ariadne-quatra dot com - No, I get no errors even after adding 'error_reporting(E_ALL);'. - Yes, the same behaviour even if I use include() instead of include_once(). [2003-12-15 09:25:33] [EMAIL PROTECTED] Do you get any errors if you put 'error_reporting(E_ALL);' before the include_once() line? Does this happen if you use include() ? [2003-12-15 08:40:15] t dot steve at ariadne-quatra dot com The same :( - includes are done eratically. A note here: this is also the case if I start to wander around the site (as opposed to just refreshing the same page again and again), i.e. as the various pages are loaded, sometimes the inlude is done, sometimes it is not. [2003-12-14 20:21:56] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip 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/26618 -- Edit this bug report at http://bugs.php.net/?id=26618edit=1
#26618 [Opn]: include_once() sometimes works, sometimes doesn't with each page refresh
ID: 26618 User updated by: t dot steve at ariadne-quatra dot com Reported By: t dot steve at ariadne-quatra dot com Status: Open Bug Type: Zend Engine 2 problem Operating System: Windows 2000 server SP4 PHP Version: 5CVS-2003-12-14 New Comment: Sorry, to clarify: by It was no different this time - ... I meant that I did it the same way this time as well. Previous Comments: [2003-12-16 00:11:22] t dot steve at ariadne-quatra dot com I always downloaded http://snaps.php.net/win32/php5-win32-latest.zip each time I tried something new! It was no different this time - a new download and install before I tried what you requested! (No local proxy or cache - I am downloading the actual file each time!) I have ALL PHP-related DLLs in my PHP dir, nothing in WINNT and so on... I checked and double-checked! Each time I want to try PHP5 this is what I do: - stop IIS - rename PHP (whcih is where my current PHP version resides) to PHP4 - create a new, empty PHP dir, and expand the downloaded ZIP in there - copy the php4isapi.dll from the sapi folder up one level to the PHP folder (this is how I have IIS set up) - no need to move anything anywhere else, my system is set up so that there is no need to copy any DLLS to the WINNT directory (I also checked to make sure there are none there - there aren't!) - then restart IIS - test... Please let me know if there is anything else I can do to help! Many thanks! Steve [2003-12-15 23:58:55] [EMAIL PROTECTED] Are you absolutely sure you are using the latest CVS snapshot? Grab the latest now, remove ALL (and I mean _all_) php related dlls from your system before you install it. Most important one being php4ts.dll (make sure you only have ONE of those around). Also make sure IIS is not running when you install PHP.. [2003-12-15 22:04:48] t dot steve at ariadne-quatra dot com - No, I get no errors even after adding 'error_reporting(E_ALL);'. - Yes, the same behaviour even if I use include() instead of include_once(). [2003-12-15 09:25:33] [EMAIL PROTECTED] Do you get any errors if you put 'error_reporting(E_ALL);' before the include_once() line? Does this happen if you use include() ? [2003-12-15 08:40:15] t dot steve at ariadne-quatra dot com The same :( - includes are done eratically. A note here: this is also the case if I start to wander around the site (as opposed to just refreshing the same page again and again), i.e. as the various pages are loaded, sometimes the inlude is done, sometimes it is not. 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/26618 -- Edit this bug report at http://bugs.php.net/?id=26618edit=1
#26618 [NEW]: include_once() sometimes works, sometimes doesn't with each page refresh
From: t dot steve at ariadne-quatra dot com Operating system: Windows 2000 server SP4 PHP version: 5.0.0b2 (beta2) PHP Bug Type: Unknown/Other Function Bug description: include_once() sometimes works, sometimes doesn't with each page refresh Description: PHP5 beta2 IIS5 Windows 2000 SP4 ISAPI mode - Worked correctly with PHP4.3.4 with Zend 2.0.1 - With PHP5 beta2 (also ISAPI mode) a simple PHP page which uses include_once([local path]) to include the menu part of a web page sometimes works, sometimes does not (sometimes the menu is included, sometimes it is not). (There is only the single include_once in the code, so this is NOT an issue of my trying to include something twice with include_ONCE... ) - The page contains NO other PHP code, just the lines below: % include_once(c:/wwwroot/domain.com/english/inc/header.inc); % (html_head.inc is the file to be included, it contains only html code, no php) - Again, note that the exact same page, exact same setup works fine under 4.3.4 - and has done so with previous versions! - Under PHP5, with every refresh of the page the inclusion of the file is erratic - every few refreshes the inclusion is not done. If you need any part of my php.ini, let me know please. Thanks, Steve Reproduce code: --- html head titleThe world of services/title /head body % include_once(c:/wwwroot/domain.com/english/inc/header.inc); % Please select from the menu on the left! /body /html Expected result: A page with the menu on the left (created fromt he included file), plus the contents. Actual result: -- Only the contents apperas, the inclusion is not done. -- Edit bug report at http://bugs.php.net/?id=26618edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26618r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26618r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26618r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26618r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26618r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26618r=needscript Try newer version: http://bugs.php.net/fix.php?id=26618r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26618r=support Expected behavior: http://bugs.php.net/fix.php?id=26618r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26618r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26618r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26618r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26618r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26618r=dst IIS Stability: http://bugs.php.net/fix.php?id=26618r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26618r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26618r=float
#25270 [Opn]: error with php
ID: 25270 User updated by: steve at 69cash dot com Reported By: steve at 69cash dot com Status: Open Bug Type: Unknown/Other Function Operating System: win2k PHP Version: 4.3.3 New Comment: hey.. i got it.. all you have to do is use the php.exe instead of the .dll Thanks tho Previous Comments: [2003-08-27 07:21:38] steve at 69cash dot com Description: PHP has encountered an Access Violation at 77FC8DBD I keep getting that error on my php page. I am getting alot of traffic.. close to 50 clicks per second. It seems to only be doing this 50% of the time. After a hour or so the computer will jump to 100% cpu usage and the web page will stop loading. Does anybody know how to fix this? I really need help. Thanks Reproduce code: --- There is no code.. It is just anything with php Expected result: display the page? ;) Actual result: -- PHP has encountered an Access Violation at 77FC8DBD That is all it says.. -- Edit this bug report at http://bugs.php.net/?id=25270edit=1
#24335 [Bgs-Opn]: Use of $$var and arrays
ID: 24335
User updated by: steve at oneniltrade dot com
Reported By: steve at oneniltrade dot com
-Status: Bogus
+Status: Open
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 4.3.2
New Comment:
Hi
This may not be a 'bug' as such, but it was submitted as much as a
feature request as a bug report, it would be really useful if it did
work as i've described (or at least I think so.) Any chance of this
feature being added to a future version?
Previous Comments:
[2003-06-26 05:24:38] [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
You can only use variable variables for the name of the array itself --
you can't specify any subscripts using this mechanism.
I suggest you post the underlying problem you are trying to solve to
php-general to see if anyone has any alternative suggestions.
[2003-06-25 08:58:25] steve at oneniltrade dot com
Description:
I'm trying to use variable variables to build up an array in a
recursive function, but this doesn't seem to be possible.
the following short amount of code illustrates the problem.
$str=array;
${$str}[1]=one;
print_r ($$str);
echo br;
print_r ($array);
.Output..
Array ([1]=one)
Array ([1]=one)
As expected,
However
$str=array[1];
$$str=One;
print_r ($$str);
echo br;
print_r ($array);
Output..
One
No output, ie $array has no value.
Although $str has the value array[1], $$str is not the same as
$array[1], as I believe it should be. (Or needs to be to get my
function to work)
--
Edit this bug report at http://bugs.php.net/?id=24335edit=1
#24335 [NEW]: Use of $$var and arrays
From: steve at oneniltrade dot com
Operating system: Linux
PHP version: 4.3.2
PHP Bug Type: Feature/Change Request
Bug description: Use of $$var and arrays
Description:
I'm trying to use variable variables to build up an array in a recursive
function, but this doesn't seem to be possible.
the following short amount of code illustrates the problem.
$str=array;
${$str}[1]=one;
print_r ($$str);
echo br;
print_r ($array);
.Output..
Array ([1]=one)
Array ([1]=one)
As expected,
However
$str=array[1];
$$str=One;
print_r ($$str);
echo br;
print_r ($array);
Output..
One
No output, ie $array has no value.
Although $str has the value array[1], $$str is not the same as $array[1],
as I believe it should be. (Or needs to be to get my function to work)
--
Edit bug report at http://bugs.php.net/?id=24335edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24335r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24335r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24335r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24335r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24335r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24335r=support
Expected behavior: http://bugs.php.net/fix.php?id=24335r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24335r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24335r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24335r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24335r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24335r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24335r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24335r=gnused
#23861 [Bgs-Opn]: php_gd2.dll - The Specified procedure cannot be found
ID: 23861 User updated by: steve at enerds dot ca Reported By: steve at enerds dot ca -Status: Bogus +Status: Open Bug Type: Dynamic loading Operating System: Windows PHP Version: 4.3.2RC4 New Comment: I am still having the problem with multiple Windows machine, with different configurations. In all cases, the gd2.dll loads with php 4.3.1, however when I upgrade to the RC 4.3.2 gd2 cannot load. Please advise. Thanks in advance Previous Comments: [2003-05-28 21:57:53] steve at enerds dot ca This is *NOT* a configuration problem. Using 4.3.1, without changing my configuration file, paths, or anything else (just the appropriate dll's), it works - gd2 extension loads. When I change to the 4.3.2 RC4 code, it does not work. This is using the exact same machine, web server, configuration, etc. [2003-05-28 19:50:31] [EMAIL PROTECTED] 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. Thank you for your interest in PHP. This issue has come up over and over again. It's NOT a bug. You've just installed PHP improperly. Ask further support questions on the appropriate mailing list. [2003-05-28 13:48:42] steve at enerds dot ca OS: Windows XP Professional, Sp1 Web Server: Apache 2.0.45 Win 32 In trying the new 4.3.2 RC4, I am trying to load the gd2 library without success. When I modify my php.ini and un-comment the line: extension=php_gd2.dll I get the following error. Unknown(): Unable to load dynamic library 'c:\php\extensions\php_gd2.dll' - The specified procedure cannot be found The dll does exist at that path, and I have verified it is actually being able to find it. In changing the dll name to php_test.dll the error message changes to the appropriate: The specified module cannot be found Regards, ~Steve -- Edit this bug report at http://bugs.php.net/?id=23861edit=1
#23861 [Opn-Bgs]: php_gd2.dll - The Specified procedure cannot be found
ID: 23861 User updated by: steve at enerds dot ca Reported By: steve at enerds dot ca -Status: Open +Status: Bogus Bug Type: Dynamic loading Operating System: Windows PHP Version: 4.3.2RC4 New Comment: *puts head down with sheepish grin* For some reason or another our sysadmin had a copy of the dll's in c:\windows and c:\windows\system32.Once I deleted those from c:\windows and updated those in c:\windows\system32 all was well. Sorry for the inconvenience, appreciate the support ~Steve Previous Comments: [2003-05-29 20:57:17] steve at enerds dot ca I am still having the problem with multiple Windows machine, with different configurations. In all cases, the gd2.dll loads with php 4.3.1, however when I upgrade to the RC 4.3.2 gd2 cannot load. Please advise. Thanks in advance [2003-05-28 21:57:53] steve at enerds dot ca This is *NOT* a configuration problem. Using 4.3.1, without changing my configuration file, paths, or anything else (just the appropriate dll's), it works - gd2 extension loads. When I change to the 4.3.2 RC4 code, it does not work. This is using the exact same machine, web server, configuration, etc. [2003-05-28 19:50:31] [EMAIL PROTECTED] 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. Thank you for your interest in PHP. This issue has come up over and over again. It's NOT a bug. You've just installed PHP improperly. Ask further support questions on the appropriate mailing list. [2003-05-28 13:48:42] steve at enerds dot ca OS: Windows XP Professional, Sp1 Web Server: Apache 2.0.45 Win 32 In trying the new 4.3.2 RC4, I am trying to load the gd2 library without success. When I modify my php.ini and un-comment the line: extension=php_gd2.dll I get the following error. Unknown(): Unable to load dynamic library 'c:\php\extensions\php_gd2.dll' - The specified procedure cannot be found The dll does exist at that path, and I have verified it is actually being able to find it. In changing the dll name to php_test.dll the error message changes to the appropriate: The specified module cannot be found Regards, ~Steve -- Edit this bug report at http://bugs.php.net/?id=23861edit=1
#23861 [NEW]: php_gd2.dll - The Specified procedure cannot be found
From: steve at enerds dot ca Operating system: Windows PHP version: 4.3.2RC4 PHP Bug Type: Dynamic loading Bug description: php_gd2.dll - The Specified procedure cannot be found OS: Windows XP Professional, Sp1 Web Server: Apache 2.0.45 Win 32 In trying the new 4.3.2 RC4, I am trying to load the gd2 library without success. When I modify my php.ini and un-comment the line: extension=php_gd2.dll I get the following error. Unknown(): Unable to load dynamic library 'c:\php\extensions\php_gd2.dll' - The specified procedure cannot be found The dll does exist at that path, and I have verified it is actually being able to find it. In changing the dll name to php_test.dll the error message changes to the appropriate: The specified module cannot be found Regards, ~Steve -- Edit bug report at http://bugs.php.net/?id=23861edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=23861r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=23861r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=23861r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=23861r=needtrace Try newer version: http://bugs.php.net/fix.php?id=23861r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=23861r=support Expected behavior: http://bugs.php.net/fix.php?id=23861r=notwrong Not enough info:http://bugs.php.net/fix.php?id=23861r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=23861r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=23861r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=23861r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=23861r=dst IIS Stability: http://bugs.php.net/fix.php?id=23861r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=23861r=gnused
#21653 [Com]: Warning: fsockopen() [function.fsockopen]: php_hostconnect: connect failed
ID: 21653 Comment by: steve at hostusa dot biz Reported By: support at hostcolor dot com Status: Open Bug Type: Sockets related Operating System: RedHat 7.2 PHP Version: 4.3.0 New Comment: I also am experiencing this issue after just updating php. Here are 2 links that are displaying the errors... https://www.hostusa.biz/status.php https://www.hostusa.biz/whois/index.php (do a whois lookup) Any info on this would be appreciated. Previous Comments: [2003-03-19 19:21:45] laudanp at yahoo dot com Much appreciated. [2003-03-18 19:16:07] [EMAIL PROTECTED] Re-opening [2003-03-18 16:25:20] laudanp at yahoo dot com I can't change status to Open because I don't own the bug report. So all I can do, to my knowledge, is just Add Comment. Thanks [2003-03-18 16:22:37] laudanp at yahoo dot com Ok, the problem wasn't resolved using php 4.3.x. This is the response from my host admin: start quote I do not normally install snapshot builds, the latest releases are used. Released versions undergo a testing phase that a development tree do not have. This applies to most software. The snapshot installed now is marked as 4.3.2-RC, or release candidate, which means that if we do not get too many bug reports for this version it will become a release. However, a PHP developer will undoubtably know more about PHP than I do. If they are suggesting the use of this version they must be comfortable enough for it to be used in a production environment. I am not sure what you are needing to know now, if a PHP contributor or developer recommends use of this version it should be fine. The upgrade was performed in the same manner all of your custom builds are installed: PHP is configured/built. PHP is installed into the apache source tree. Any other apache modules are installed at this time. Apache is built, including PHP as a static module. The new binary or binaries are copied to your system. Apache is restarted. The only difference between the upgrade and the usual install process for your httpd was that a different PHP source tree was used. /end quote My host has read this bug report and has seen your suggestion. The response is as above. Help? Ideas? Thanks in advance. [2003-03-09 18:47:59] [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. 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/21653 -- Edit this bug report at http://bugs.php.net/?id=21653edit=1
#21827 [Com]: form post magic variables clumped together
ID: 21827 Comment by: steve at bluearena dot com Reported By: sol at zewy dot com Status: Feedback Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.3.0 New Comment: Upgrading to 4.3.2-dev has fixed the bug for me. Many thanks. Previous Comments: [2003-02-13 00:43:45] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip I can not reproduce this with PHP 4.3.1-dev. [2003-01-22 18:26:39] sol at zewy dot com Here's how to stop the clumps (workaround) 1. Always have the first form variable have a name 5 or more letters 2. Don't have a name on the submit button 3. Have the value of any hidden field 4 or more letters or numbers -Sol [2003-01-22 18:18:35] sol at zewy dot com Hello, When I post a html form with 3 hidden fields, with 3 or less alphanumerics as the values, and 4 or less alphanumerics as the NAME of the first field, and a submit button having a name value, the first field variable has clumped all the other post data in it, instead of just the magic variable for field 1 like it should. Using phpinfo, there is _ENV[+] after _ENV[REMOTE_PORT] that shows the telltale clump, or a line and a square when the form does not meet the above situation. I do not know what this _ENV[+] is but think it's a clue. There's also _SERVER[+] and in the Environment a plain + after REMOTE_PORT that will be the name of my hidden field 1 with the clump data. I have seen many other complaints in the bug section about variables missing or broken, but noone tracked down the cause as well as this. It takes 3 simultaneous conditions. You can see this in action at http://www.zewy.com/phpclump.php I'm going to put a hidden field with 1000 as the value on every page as my work-around. 999 didn't work, it's only 3 alphanumerics. If you could find a fix it would be appreciated. BTW, one day, it's my dream to have millions of $$$ and donate it to open source developers.. You make the world a better place. Thanks -- Edit this bug report at http://bugs.php.net/?id=21827edit=1
#21306 [Com]: warnning about cannot change the session settings
ID: 21306
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: linux
PHP Version: 4.3.0
New Comment:
I upgraded to 4.3.0 from 4.2.3 a couple weeks ago. I did not see this
problem at all until today, when I uploaded two minor changes to my web
site. We get several hundred thousand page views per day, and since
this upload we're getting 3-4 of this error per minute. So for most
page views it doesn't happen, but it's definitely happening frequently
and regularly.
The first change was to our error handler. We specifically trigger
errors using $php_errormsg if it exists (after the session is started),
so that we can catch stupid users who try to upload humongous images to
our site (we limit them to 40KB). Some bright young individual
uploaded a 476MB file ten times this morning, so we added some code
(three lines) to log the date, time, username, and file size. Here is
the code we added:
$fp = fopen(/tmp/big_images.log, 'a');
fwrite($fp, sprintf(%s: %s (%s KB)\n, date(Y-m-d H:i:s),
$_SESSION['auth']-auth['username'], $kb));
fclose($fp);
While typing this, I made a change which seems to have fixed the
problem. I have a function called session_setup() which makes sure the
session id is unique, and call session_set_save_handler() or whatever
the name of that function is. The trigger_error mentioned above used
to be called after calling session_setup() in my authentication include
file. I moved it to inside the session_setup() function, after setting
the save_handler. For some reason, this fixed the problem.
Odd.
Perhaps this can help someone else somehow?
Previous Comments:
[2003-01-05 16:03:24] [EMAIL PROTECTED]
Have a working installation of os-commerce in 4.2.3. Upgraded to 4.3.0,
and now I get the same error listed here.
All I want to do is confirm that this is NOT a script error. I'm not
going to dig through some code I didn't write to track this down.
Thanks
[2003-01-01 10:11:39] [EMAIL PROTECTED]
note that, i don't even use one ini_set()
and the script is impossible to session_set_save_handler() twice;
seems php don't re-initize correctly, same as
http://bugs.php.net/bug.php?id=19292
but i'm just guessing
[2002-12-31 02:52:19] [EMAIL PROTECTED]
i forgot to note that, this issue is random happend
i can't reproduce it, but my user trigger it and i saw errors in log
and my script is in production, it's too complex
i am not able to give full script
but my function look like:
function mysessionstart() {
if (session_id()) return
session_set_save_handler(
'_sess_open',
'_sess_close',
'_sess_read',
'_sess_write',
'_sess_destroy',
'_sess_gc'
);
session_start();
}
it works fine until get warnning in php-4.3.0
here the config is:
session.save_handler = files
session.save_path = /tmp
session.use_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain =
session.serialize_handler = php
session.gc_probability = 1
session.gc_maxlifetime = 1440
containing ids.
session.referer_check =
session.entropy_length = 0
session.entropy_file =
;session.entropy_length = 16
;session.entropy_file = /dev/urandom
session.cache_limiter = nocache
session.cache_expire = 180
session.use_trans_sid = 1
url_rewriter.tags =
a=href,area=href,frame=src,input=src,form=fakeentry
[2002-12-31 02:27:43] [EMAIL PROTECTED]
THis is most likely not a bug, can you show us the script, and the
session.* settings in php.ini?
Derick
[2002-12-31 02:00:45] [EMAIL PROTECTED]
i've got this problem after i upgrade from php4.2.2 to 4.3.0:
[31-Dec-2002 15:30:03] PHP Warning: Unknown(): A session is active.
You cannot change the session module's ini settings at this time. in
Unknown on line 0
seems a internal error, php script
hope this to be fix soon
--
Edit this bug report at http://bugs.php.net/?id=21306edit=1
#20857 [Com]: snmpset does not work
ID: 20857
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: SNMP related
Operating System: Linux RH 7.3
PHP Version: 4.3.0RC2
New Comment:
This problem still exists for the php 4.3.0 release. I am also using
net-snmp 5.0.6
The patch posted by [EMAIL PROTECTED] fixed the problem. I updated the
offsets in his patch for the 4.3.0 sources.
The updated patch can be found at:
http://www.deinon.com/php/php-4.3.0-snmpset.patch
Previous Comments:
[2002-12-07 04:35:59] [EMAIL PROTECTED]
I tried this patch in diff -u format. Note that there is also a change
in the php_error_docref-string, becaue the output was not very
informative. Of course, I would prefer, that a php-snmp maintainer
would have a look at it.
--- snmp.c.orig Mon Nov 11 22:37:18 2002
+++ snmp.c Sat Dec 7 11:23:24 2002
@@ -197,7 +197,7 @@
static void php_snmp_internal(INTERNAL_FUNCTION_PARAMETERS,
int st,
struct snmp_session *session,
- char *objid)
+ char *objid, char type, char* value)
{
struct snmp_session *ss;
struct snmp_pdu *pdu=NULL, *response;
@@ -211,8 +211,6 @@
char buf[2048];
char buf2[2048];
int keepwalking=1;
- char type = (char) 0;
- char *value = (char *) 0;
char *err;
if (st = 2) { /* walk */
@@ -267,7 +265,12 @@
} else if (st == 11) {
pdu = snmp_pdu_create(SNMP_MSG_SET);
if (snmp_add_var(pdu, name, name_length, type, value)) {
- php_error_docref(NULL TSRMLS_CC, E_WARNING, Could not
add
variable: %s, name);
+#ifdef HAVE_NET_SNMP
+ snprint_objid(buf, sizeof(buf), name, name_length);
+#else
+ sprint_objid(buf, name, name_length);
+#endif
+ php_error_docref(NULL TSRMLS_CC, E_WARNING, Could not
+add
variable: %s %c %s, buf, type, value);
snmp_close(ss);
RETURN_FALSE;
}
@@ -466,7 +469,7 @@
session.authenticator = NULL;
- php_snmp_internal(INTERNAL_FUNCTION_PARAM_PASSTHRU, st, session,
Z_STRVAL_PP(a3));
+ php_snmp_internal(INTERNAL_FUNCTION_PARAM_PASSTHRU, st, session,
Z_STRVAL_PP(a3), type, value);
}
/* }}} */
@@ -849,7 +852,7 @@
session.retries = retries;
session.timeout = timeout;
- php_snmp_internal(INTERNAL_FUNCTION_PARAM_PASSTHRU, st, session,
Z_STRVAL_PP(a8));
+ php_snmp_internal(INTERNAL_FUNCTION_PARAM_PASSTHRU, st, session,
Z_STRVAL_PP(a8), type, value);
}
/* }}} */
[2002-12-06 18:37:58] [EMAIL PROTECTED]
Do you have a patch for this?
[2002-12-06 08:12:46] [EMAIL PROTECTED]
I use php-4.3.0RC2 with net-snmp-5.0.6. It works so far, but snmpset()
always shows a warning Could not add variable: and the variable is
not set.
I found out, that there is a bug in ext/snmp.c. Here, type and value of
the varible are not passed to php_snmp_internal(), so these variables
are always 0 and snmp_add_var() fails. So, as a solution, php_snmp and
php_snmpv3 should pass type and value to php_snmp_internal ant
everything is ok.
--
Edit this bug report at http://bugs.php.net/?id=20857edit=1
#19265 [Bgs]: header + relative location + cgi + aliasmatch fails
ID: 19265
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Output Control
Operating System: Linux
PHP Version: 4CVS-2002-09-06
New Comment:
I am trying to demonstrate that the same PHP code which works on the
Apache module, fails with the CGI module. Both with Internet Explorer
as the client.
Previous Comments:
[2002-10-08 12:09:18] [EMAIL PROTECTED]
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.
Thank you for your interest in PHP.
If people use incorrect (relative pathes) in the Location: header they
cannot expect consistent behaviour. It may work in some browser and it
may not work in others.
[2002-09-07 06:28:24] [EMAIL PROTECTED]
A relative location works most of the time. It always works with the
Apache module, and the CGI version only fails when the aliasmatch
directive is set.
Anyway, I worked around this by using mod_rewrite instead of
AliasMatch, so I'm not particularly bothered - but I'm quite sure that
a lot of people use relative URIs with the Location header so it might
be worth looking into.
I realise the official standard says the URIs should be absolute, but
IE, Netscape, and Lynx, maybe others, support relative.
Steve
[2002-09-06 19:40:38] [EMAIL PROTECTED]
First of all, your redirect is wrong.
You must use absolute URI for Location header.
Try absolute URI, if it fixes.
[2002-09-06 09:36:01] [EMAIL PROTECTED]
I have run into a problem with the above setup on both the latest
snapshot and also 4.2.2 - sorry if it's not a bug.
?
if(!$test) die(header(Location: /?test=true));
else die(redirected ok: $REQUEST_URI);
?
This works fine, and as expected, the output is:
redirected ok: /?test=true
However if I have the following lines in my httpd.conf:
DocumentRoot /home/bla/html
AliasMatch ^/sess/(.{4})/(.*) /home/bla/html/$2
And change the script to:
?
if(!$test) die(header(Location: /sess/1234/?test=true));
else die(redirected ok: $REQUEST_URI);
?
The output is:
redirected ok: /
I'm not quite sure what is going on here. I have just switched from an
Apache module to CGI version for security reasons and wasn't quite
expecting this problem so came into an interesting problem, a loop in
my program, and crashes out with an error 500:
GET / HTTP/1.0
host: www.mydomain.com
HTTP/1.1 500 Internal Server Error
Date: Fri, 06 Sep 2002 14:30:35 GMT
Server: Apache/1.3.26 (Unix) PHP/4.2.2 mod_ssl/2.8.10 OpenSSL/0.9.6g
X-Powered-By: PHP/4.2.3, PHP/4.2.3, PHP/4.2.3, PHP/4.2.3, PHP/4.2.3,
PHP/4.2.3, PHP/4.2.3, PHP/4.2.3, PHP/4.2.3, PHP/4.2.3, PHP/4.2.3,
PHP/4.2.3, PHP/4.2.3, PHP/4.2.3, PHP/4.2.3, PHP/4.2.3, PHP/4.2.3,
PHP/4.2.3, PHP/4.2.3, PHP/4.2.3, PHP/4.2.3, PHP/4.2.3
Connection: close
Content-Type: text/html; charset=iso-8859-1
Changing it to a absolute URL in the header(Location fixes the
problem but it would be a pain to change this in all my scripts. Thanks
a lot for your help.
--
Edit this bug report at http://bugs.php.net/?id=19265edit=1
Bug #17443: Procedure not found (3 times) while starting Apache
From: [EMAIL PROTECTED] Operating system: Windows 2000 (SP2) PHP version: 4.2.1 PHP Bug Type: Apache related Bug description: Procedure not found (3 times) while starting Apache After installing PHP v4.2.1 (SAPI), I started the Apache 1.3.24 service (which I've been using across several PHP releases with no issue). I got the following message three times: The procedure entry point -ecalloc could not be located in the dynamic link library php4ts.dll. PHP seemed to run fine anyway, with php pages loading as usual. This problem didn't occur with any PHP release since August of 2001. -- Edit bug report at http://bugs.php.net/?id=17443edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17443r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17443r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17443r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17443r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17443r=support Expected behavior: http://bugs.php.net/fix.php?id=17443r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17443r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17443r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17443r=globals
