#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:
This appears (in our case anyway) to be triggered by the use of an
"exit" statement in the session_set_save_handler session_write
function. We had a benign error in our custom session_write function
(caused by the session data not changing when it was writing out)..
this caused an error message to be written to a log file, and then the
"exit;" statement. In PHP 4.2, this exit apparently caused no problems
but now it generates this seemingly unrelated error message.
Incidently, because this message is generated at the time of
session_write (rather than during actual content generation) it also
caused an interaction with ob_gzhandler (gzip compression) such that
blank pages were being served up.. we had to disable ob_gzhandler to
even see the "A session is active..." messages.. This seems buggy to
me.
Previous Comments:
[2003-01-27 20:12:46] [EMAIL PROTECTED]
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?
[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
The remainder of the comments
Bug #17447: Unexpected undefined (builtin) variables such as 'DOCUMENT_ROOT' AND 'PHP_SELF'
From: [EMAIL PROTECTED] Operating system: WinMe+Apache203 / XP+IIS5 PHP version: 4.2.1 PHP Bug Type: *Web Server problem Bug description: Unexpected undefined (builtin) variables such as 'DOCUMENT_ROOT' AND 'PHP_SELF' I installed PHP V4.2.1 on Win ME with Apache2.0.3 and discovered that several PHP builtin variables were reported as undefined. Likewise I installed V4.2.0 and observed the same problem. I then upgraded OS to XP with IIS5.1 and reinstalled the latter versions of PHP and obserevd the same problem. I then installed PHP V4.0.6 and noticed that PHP recognised most of the builtin variables. However 'DOCUMENT_ROOT' still wasn't recognised and session_start fn failed. The PHP scripts have been proven online. -- Edit bug report at http://bugs.php.net/?id=17447&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17447&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17447&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17447&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17447&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17447&r=support Expected behavior: http://bugs.php.net/fix.php?id=17447&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17447&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17447&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17447&r=globals
Bug #16412: Using session_start() repeatedly (on different pages) causes HTTP 500
From: [EMAIL PROTECTED] Operating system: Windows XP PHP version: 4.1.2 PHP Bug Type: Session related Bug description: Using session_start() repeatedly (on different pages) causes HTTP 500 I've had this with a more complex script but here is a cut down version. When I call session_start() in my script then link to another page that calls session_start() I eventually get HTTP 500 internal server error. This usually happens after 3 or 4 links. Its fine for the first few links usually. I'm running on the version of IIS that comes with XP Pro. I changed none of the php.ini setting during installation apart from the session var directory which is now f:\data\websites\sessions. The version of PHP is the binary of v4.1.2 for windows downloaded from php.net. I'm running as CGI. Here is an example of the code that exhibits the problem. If I keep clicking the "Click me" link it throws the error after 3-4 clicks most of the time. Click me Rob -- Edit bug report at http://bugs.php.net/?id=16412&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16412&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16412&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16412&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16412&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16412&r=support Expected behavior: http://bugs.php.net/fix.php?id=16412&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16412&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16412&r=submittedtwice
Bug #16412 Updated: Using session_start() repeatedly (on different pages) causes HTTP 500
ID: 16412 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: Windows XP PHP Version: 4.1.2 New Comment: Ok this is wierd but I've noticed that once I started getting the HTTP 500 errors I couldnt get even a simple script eg to work. I tried checking the "Check that file exists" on the application extension mapping in IIS and it all seems to work now. Odd. Previous Comments: [2002-04-03 12:04:53] [EMAIL PROTECTED] I've had this with a more complex script but here is a cut down version. When I call session_start() in my script then link to another page that calls session_start() I eventually get HTTP 500 internal server error. This usually happens after 3 or 4 links. Its fine for the first few links usually. I'm running on the version of IIS that comes with XP Pro. I changed none of the php.ini setting during installation apart from the session var directory which is now f:\data\websites\sessions. The version of PHP is the binary of v4.1.2 for windows downloaded from php.net. I'm running as CGI. Here is an example of the code that exhibits the problem. If I keep clicking the "Click me" link it throws the error after 3-4 clicks most of the time. Click me Rob -- Edit this bug report at http://bugs.php.net/?id=16412&edit=1
#15259 [Com]: PHP fails if RLimitMEM directive is used
ID: 15259 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: RedHat Linux 7.2 PHP Version: 4.1.x New Comment: Since upgrading to the RedHat standard php-4.1.2-7.2.6 RPM version, I have found a much simpler test case demonstrating the problem. >From the command line: - $ php -v 4.1.2 $ ulimit -v 3 $ php -v Content-type: text/html PHP Fatal error: Unable to start session mm module in Unknown on line 0 - This shows that PHP doesn't work properly when the memory RLIMIT is ~30 MB. This is a problem for people who use PHP in CGI mode in hosting environments with memory limits. Again, this is related to the use of "--with-mm" when compiling. If PHP is compiled *without* the "--with-mm" line, the problem does not occur. Hope this helps. Previous Comments: [2002-05-01 14:07:04] [EMAIL PROTECTED] I have done some more investigation and found that the problem only occurs when PHP is compiled "--with-mm" (which is the Red Hat default). If PHP is compiled without "mm" support, the problem does not happen (which is an acceptable workaround for me, and which should be useful for others who experience this problem). I still do not quite understand why the original problem happens, though. I suspect that PHP is using mm to allocate a large chunk of shared memory (perhaps around 32 MB?), and that allocation somehow fails in a silent manner. Then PHP tries to use that memory to read the POSTed data on STDIN, which fails. When this problem happens, I don't receive a "premature end of script headers" message or anything like that. PHP seems to work normally (in my limited testing) -- it is simply unable to see the POSTed data from the form. It acts as though the POSTed data was never sent (data sent by method GET works properly). I suspect if I tried some more extensive testing, I'd find that other parts of PHP that rely on mm memory allocation would fail under these circumstances, too (but I don't know what those are to be able to test specifics). Anyway, I've found my workaround and am happy, but it does seem that something in the mm code isn't quite right to cause silent failures. It's possible that this problem (apparent silent failure when memory can't be allocated by mm) might also occur in other low-memory situations, too, and that the artificially imposed RLimit limitation perhaps just makes it extremely visible and repeatable. If it helps others to test, this problem is easily duplicated by: 1. Set up Apache with the directive "RLimitMEM 2000" (for example -- anything above 10 MB and below 40 MB shows the problem on my machine). 2. Compile PHP as a CGI "--with-mm" (I'm also using the rest of the default build options from the Red Hat 7.2 package; I suppose it's theoretically possible that those are affecting it, too -- if you can't duplicate, use the full-blown Red Hat build options). 3. Create a trivial test page that uses method POST to send data to any PHP script. 4. The PHP script will incorrectly act as if no parameters were POSTed. 5. Recompile PHP without the "--with-mm" line and the problem goes away. Hope this is useful. [2002-05-01 06:14:57] [EMAIL PROTECTED] Please research about the error message "premature end of script headers" also. It seems this could be Change Request. [2002-05-01 03:19:16] [EMAIL PROTECTED] I don't think this should be classified as a "bogus" bug. I ran into the same issue when using resource limits in cgiwrap, sbox, and a custom version of suexec that calls setrlimit(RLIMIT_AS, ...). For some reason I can't determine, PHP refuses to parse POSTed CGI parameters from STDIN when the RLIMIT_AS value is less than 40 MB (on my machine), despite the fact that PHP itself never uses more than about 8 MB. If I raise the RLIMIT_AS value above 40 MB, it works with no trouble. Perl CGI scripts do not have the same problem. As with the previous poster, using PHP's built-in memory limit is not an option for me -- I'm allowing customers to run their own PHP scripts on shared servers, and the memory limit must be enforced at the OS level to prevent users from running system calls, etc., that exceed the limit. This issue is unfortunately preventing me from offering PHP to several thousand customers. I hope that this bug can be reopened and fixed. I have spent several hours trying to figure out the cause of it in the hope that I could send a patch, but alas, I can't see where the problem is. [2002-01-28 18:22:49] [EMAIL PROTECTED] I can't just use PHP Limit.. I need to be a
Bug #15259 Updated: PHP fails if RLimitMEM directive is used
ID: 15259 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Apache related Operating System: RedHat Linux 7.2 PHP Version: 4.0.6 New Comment: I don't think this should be classified as a "bogus" bug. I ran into the same issue when using resource limits in cgiwrap, sbox, and a custom version of suexec that calls setrlimit(RLIMIT_AS, ...). For some reason I can't determine, PHP refuses to parse POSTed CGI parameters from STDIN when the RLIMIT_AS value is less than 40 MB (on my machine), despite the fact that PHP itself never uses more than about 8 MB. If I raise the RLIMIT_AS value above 40 MB, it works with no trouble. Perl CGI scripts do not have the same problem. As with the previous poster, using PHP's built-in memory limit is not an option for me -- I'm allowing customers to run their own PHP scripts on shared servers, and the memory limit must be enforced at the OS level to prevent users from running system calls, etc., that exceed the limit. This issue is unfortunately preventing me from offering PHP to several thousand customers. I hope that this bug can be reopened and fixed. I have spent several hours trying to figure out the cause of it in the hope that I could send a patch, but alas, I can't see where the problem is. Previous Comments: [2002-01-28 18:22:49] [EMAIL PROTECTED] I can't just use PHP Limit.. I need to be able to LIMIT the resources on Memory for other things (Perl, FrontPage, and other cgi programs) [2002-01-28 17:56:48] [EMAIL PROTECTED] This cannot be implemented. Use PHP memory limit. [2002-01-28 14:45:33] [EMAIL PROTECTED] I have php compiled as cgi and calling the php binary from apache via AddHandler. I have thousands of users on this box and I have RLimitMEM directives. Using 4.0.6 and 4.1.1 I noticed if I have RLimitMEM defined, having a form POST to the php binary, i get : premature end of script headers. If I remark out the RLimitMEM entry in the directive, all is good? Any work arounds? -- Edit this bug report at http://bugs.php.net/?id=15259&edit=1
Bug #15259 Updated: PHP fails if RLimitMEM directive is used
ID: 15259 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: RedHat Linux 7.2 PHP Version: 4.1.x New Comment: I have done some more investigation and found that the problem only occurs when PHP is compiled "--with-mm" (which is the Red Hat default). If PHP is compiled without "mm" support, the problem does not happen (which is an acceptable workaround for me, and which should be useful for others who experience this problem). I still do not quite understand why the original problem happens, though. I suspect that PHP is using mm to allocate a large chunk of shared memory (perhaps around 32 MB?), and that allocation somehow fails in a silent manner. Then PHP tries to use that memory to read the POSTed data on STDIN, which fails. When this problem happens, I don't receive a "premature end of script headers" message or anything like that. PHP seems to work normally (in my limited testing) -- it is simply unable to see the POSTed data from the form. It acts as though the POSTed data was never sent (data sent by method GET works properly). I suspect if I tried some more extensive testing, I'd find that other parts of PHP that rely on mm memory allocation would fail under these circumstances, too (but I don't know what those are to be able to test specifics). Anyway, I've found my workaround and am happy, but it does seem that something in the mm code isn't quite right to cause silent failures. It's possible that this problem (apparent silent failure when memory can't be allocated by mm) might also occur in other low-memory situations, too, and that the artificially imposed RLimit limitation perhaps just makes it extremely visible and repeatable. If it helps others to test, this problem is easily duplicated by: 1. Set up Apache with the directive "RLimitMEM 2000" (for example -- anything above 10 MB and below 40 MB shows the problem on my machine). 2. Compile PHP as a CGI "--with-mm" (I'm also using the rest of the default build options from the Red Hat 7.2 package; I suppose it's theoretically possible that those are affecting it, too -- if you can't duplicate, use the full-blown Red Hat build options). 3. Create a trivial test page that uses method POST to send data to any PHP script. 4. The PHP script will incorrectly act as if no parameters were POSTed. 5. Recompile PHP without the "--with-mm" line and the problem goes away. Hope this is useful. Previous Comments: [2002-05-01 06:14:57] [EMAIL PROTECTED] Please research about the error message "premature end of script headers" also. It seems this could be Change Request. [2002-05-01 03:19:16] [EMAIL PROTECTED] I don't think this should be classified as a "bogus" bug. I ran into the same issue when using resource limits in cgiwrap, sbox, and a custom version of suexec that calls setrlimit(RLIMIT_AS, ...). For some reason I can't determine, PHP refuses to parse POSTed CGI parameters from STDIN when the RLIMIT_AS value is less than 40 MB (on my machine), despite the fact that PHP itself never uses more than about 8 MB. If I raise the RLIMIT_AS value above 40 MB, it works with no trouble. Perl CGI scripts do not have the same problem. As with the previous poster, using PHP's built-in memory limit is not an option for me -- I'm allowing customers to run their own PHP scripts on shared servers, and the memory limit must be enforced at the OS level to prevent users from running system calls, etc., that exceed the limit. This issue is unfortunately preventing me from offering PHP to several thousand customers. I hope that this bug can be reopened and fixed. I have spent several hours trying to figure out the cause of it in the hope that I could send a patch, but alas, I can't see where the problem is. [2002-01-28 18:22:49] [EMAIL PROTECTED] I can't just use PHP Limit.. I need to be able to LIMIT the resources on Memory for other things (Perl, FrontPage, and other cgi programs) [2002-01-28 17:56:48] [EMAIL PROTECTED] This cannot be implemented. Use PHP memory limit. [2002-01-28 14:45:33] [EMAIL PROTECTED] I have php compiled as cgi and calling the php binary from apache via AddHandler. I have thousands of users on this box and I have RLimitMEM directives. Using 4.0.6 and 4.1.1 I noticed if I have RLimitMEM defined, having a form POST to the php binary, i get : premature end of script headers. If I remark out the RLimitMEM entry in the directive, all is good? Any work arounds? --
#49765 [NEW]: Closure: Unreachable static declaration breaks lexical reference
From: rob...@php.net Operating system: * PHP version: 5.3SVN-2009-10-04 (snap) PHP Bug Type: Scripting Engine problem Bug description: Closure: Unreachable static declaration breaks lexical reference Description: Hi, Closures' lexical variable descriptors are stored in the same container as function-scope statics: zend_function.op_array.static_variables. This can cause unexpected behaviour when the same name is used for a lexical variable and a function-scope static. For example, the testcase below shows how an apparently unreachable function-scope static declaration impacts an assignment to a lexical reference. This is because static declarations are identified at compile time (regardless of the execution path within the function), and they end up taking precedence over lexical vars. Reproduce code: --- http://bugs.php.net/?id=49765&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49765&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49765&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49765&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49765&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49765&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49765&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49765&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49765&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49765&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49765&r=support Expected behavior: http://bugs.php.net/fix.php?id=49765&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49765&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49765&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49765&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49765&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49765&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49765&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49765&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49765&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49765&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49765&r=mysqlcfg
#26737 [NEW]: unexpected __sleep() serialization behavior
From: rob at cue dot cc
Operating system: Mac OSX 10.3.2
PHP version: 5.0.0b2 (beta2)
PHP Bug Type: Session related
Bug description: unexpected __sleep() serialization behavior
Description:
I have an object instance ($obj_root) that I want to
persist in a
session.
The object's class (object_container) defines the
__sleep() function, and
returns the array of member variables to be serialized.
function __sleep()
{
return array("objs");
}
The member variable 'objs' ($this->objs = array('foo');)
is not serialized as expected;
Arrays or other object-types result in null strings.
Upon comparing the serialized instance strings, I have
discovered that the string-ified names of the member
variables are very different:
serialize() without __sleep() wraps null chars around
the instance class name, followed by the member variable
name.
obj_root|O:16:"object_container":1:{s:
22:"[EMAIL PROTECTED]@objs";a:1:{s:3:"foo"
serialize() with __sleep() uses the plain member
variable name, and dismisses it as null.
If I use the __sleep() function and supply the member
variable name with null chars quoting the class name the
serialization works.
function __sleep()
{
return array("\0object_container\0objs");
}
Could this be a bug, or should the documentation be
updated to reflect this curious behaviour of __sleep().
--
Edit bug report at http://bugs.php.net/?id=26737&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26737&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26737&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26737&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26737&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26737&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26737&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26737&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26737&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26737&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26737&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26737&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26737&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26737&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26737&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26737&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26737&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26737&r=float
#26737 [NoF->Opn]: unexpected __sleep() serialization behavior
ID: 26737
User updated by: rob at cue dot cc
Reported By: rob at cue dot cc
-Status: No Feedback
+Status: Open
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS
New Comment:
will compile from cvs soon, and check for bug.
Previous Comments:
[2004-01-06 20:51:56] [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-12-30 20:11:12] [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-29 00:20:44] rob at cue dot cc
Description:
I have an object instance ($obj_root) that I want to
persist in a
session.
The object's class (object_container) defines the
__sleep() function, and
returns the array of member variables to be serialized.
function __sleep()
{
return array("objs");
}
The member variable 'objs' ($this->objs = array('foo');)
is not serialized as expected;
Arrays or other object-types result in null strings.
Upon comparing the serialized instance strings, I have
discovered that the string-ified names of the member
variables are very different:
serialize() without __sleep() wraps null chars around
the instance class name, followed by the member variable
name.
obj_root|O:16:"object_container":1:{s:
22:"[EMAIL PROTECTED]@objs";a:1:{s:3:"foo"
serialize() with __sleep() uses the plain member
variable name, and dismisses it as null.
If I use the __sleep() function and supply the member
variable name with null chars quoting the class name the
serialization works.
function __sleep()
{
return array("\0object_container\0objs");
}
Could this be a bug, or should the documentation be
updated to reflect this curious behaviour of __sleep().
--
Edit this bug report at http://bugs.php.net/?id=26737&edit=1
#23963 [NEW]: option --with-cybermut= in configure, but not taken into account
From: rob at alterlinks dot fr Operating system: Linux Mandrake 8.1 PHP version: 4.3.2 PHP Bug Type: *E-commerce functions Bug description: option --with-cybermut= in configure, but not taken into account As the previous version 4.2.3 (which worked), I've compiled 4.3.2 with the following options : ./configure --with-mysql --with-apxs=/usr/local/apache/bin/apxs --with-config-file-path=/usr/local/apache/conf --with-cybermut=/usr/local/bank --with-zlib-dir=/usr/local/lib --with-jpeg-dir=/usr/local/lib --with-png-dir=/usr/local/lib --with-zlib --with-gd --with-openssl --with-gdbm-dir=/usr/local/lib --with-dbm-dir=/usr/lib --with-gdbm --with-dbm --enable-ftp --enable-bcmath --enable-calendar --enable-shared --disable-static --with-freetype-dir=./freetype After restarting Apache : Fatal error: Call to undefined function: cybermut_creerformulairecm() in /var/www/awsales/french/tothebank.php on line 128 I've restored the backup of libphp4.so from the 4.2.3 version to get the function to work again. -- Edit bug report at http://bugs.php.net/?id=23963&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=23963&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=23963&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=23963&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=23963&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=23963&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=23963&r=support Expected behavior: http://bugs.php.net/fix.php?id=23963&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=23963&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=23963&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=23963&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=23963&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=23963&r=dst IIS Stability: http://bugs.php.net/fix.php?id=23963&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=23963&r=gnused
#32422 [Fbk->Opn]: Access Violation on calling PEAR Date::before
ID: 32422 User updated by: rob at wildlime dot com Reported By: rob at wildlime dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Windows XP SP2 PHP Version: 4.3.10 New Comment: Using PHP/5.1.0-dev access violation immediately on starting Apache stack trace: php5ts!zend_do_inherit_interfaces+0x14e (yes, that's all) I haven't installed PEAR yet... Previous Comments: [2005-03-30 08:54:10] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip (yes, it's PHP5, but I'd like to know if this happens with it too..) [2005-03-30 01:49:22] rob at wildlime dot com Using PHP/4.3.11RC2-dev (btw, is it intentional that pear installs to c:\php\pear\pear?) Same result - frequent access violation. stack trace: ntdll!RtlpCoalesceFreeBlocks+0x21 ntdll!RtlFreeHeap+0x2e9 msvcrt!free+0xc3 msvcrt!__crtsetenv+0x193 msvcrt!_putenv_lk+0x42 msvcrt!_putenv+0x20 WARNING: Stack unwind information not available. Following frames may be wrong. php4ts!php_get_inf+0xfae [2005-03-29 10:27:43] [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 ..and provide the trace when using the snapshot. [2005-03-29 07:53:56] rob at wildlime dot com Here's another stack trace, using the MS debugger to get access to the symbol names ntdll!RtlpCoalesceFreeBlocks+0x21 ntdll!RtlFreeHeap+0x2e9 msvcrt!free+0xc3 msvcrt!__crtsetenv+0x193 msvcrt!_putenv_lk+0x42 msvcrt!_putenv+0x20 WARNING: Stack unwind information not available. Following frames may be wrong. php4ts!php_get_inf+0xf6e Error details from the debugger: (268.ddc): Access violation - code c005 (!!! second chance !!!) eax=0418 ebx=0083 ecx=7ffda000 edx=00830608 esi=0082fd68 edi=00830180 eip=7c910c27 esp=0108d978 ebp=0108d984 iopl=0 nv up ei ng nz na po cy cs=001b ss=0023 ds=0023 es=0023 fs=003b gs= efl=0287 ntdll!RtlpCoalesceFreeBlocks+0x21: 7c910c27 f6460501 testbyte ptr [esi+0x5],0x1 ds:0023:0082fd6d=?? (NB still using php 4.3.10) ---- [2005-03-29 02:05:42] rob at wildlime dot com Installed php 4.3.11 RC1 (windows) to c:\php, but PEAR wont't install. The error on running go-pear.bat, accepting the defaults, is: "failed to write c:\php\pear\data\PEAR\.tmppackage.dtd" There is plenty of disk space and I'm using an admin account. 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/32422 -- Edit this bug report at http://bugs.php.net/?id=32422&edit=1
#32422 [Opn]: Access Violation on calling PEAR Date::before
ID: 32422 User updated by: rob at wildlime dot com Reported By: rob at wildlime dot com Status: Open Bug Type: Reproducible crash Operating System: Windows XP SP2 PHP Version: 4.3.10 New Comment: The access violation on starting Apache goes away if I disable all the extensions I was previously using (mysql, curl, openssl) I have tested this using php.ini-recommended, the only change being setting the extension dir from ./ to c:\php\ext Previous Comments: [2005-03-31 01:30:15] rob at wildlime dot com Using PHP/5.1.0-dev access violation immediately on starting Apache stack trace: php5ts!zend_do_inherit_interfaces+0x14e (yes, that's all) I haven't installed PEAR yet... [2005-03-30 08:54:10] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip (yes, it's PHP5, but I'd like to know if this happens with it too..) [2005-03-30 01:49:22] rob at wildlime dot com Using PHP/4.3.11RC2-dev (btw, is it intentional that pear installs to c:\php\pear\pear?) Same result - frequent access violation. stack trace: ntdll!RtlpCoalesceFreeBlocks+0x21 ntdll!RtlFreeHeap+0x2e9 msvcrt!free+0xc3 msvcrt!__crtsetenv+0x193 msvcrt!_putenv_lk+0x42 msvcrt!_putenv+0x20 WARNING: Stack unwind information not available. Following frames may be wrong. php4ts!php_get_inf+0xfae [2005-03-29 10:27:43] [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 ..and provide the trace when using the snapshot. [2005-03-29 07:53:56] rob at wildlime dot com Here's another stack trace, using the MS debugger to get access to the symbol names ntdll!RtlpCoalesceFreeBlocks+0x21 ntdll!RtlFreeHeap+0x2e9 msvcrt!free+0xc3 msvcrt!__crtsetenv+0x193 msvcrt!_putenv_lk+0x42 msvcrt!_putenv+0x20 WARNING: Stack unwind information not available. Following frames may be wrong. php4ts!php_get_inf+0xf6e Error details from the debugger: (268.ddc): Access violation - code c005 (!!! second chance !!!) eax=0418 ebx=0083 ecx=7ffda000 edx=00830608 esi=0082fd68 edi=00830180 eip=7c910c27 esp=0108d978 ebp=0108d984 iopl=0 nv up ei ng nz na po cy cs=001b ss=0023 ds=0023 es=0023 fs=003b gs= efl=0287 ntdll!RtlpCoalesceFreeBlocks+0x21: 7c910c27 f6460501 testbyte ptr [esi+0x5],0x1 ds:0023:0082fd6d=?? (NB still using php 4.3.10) 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/32422 -- Edit this bug report at http://bugs.php.net/?id=32422&edit=1
#33306 [NEW]: // or # Comment including %> crashes !
From: rob at span dot com Operating system: Win2003 / Apache2 PHP version: 5.0.4 PHP Bug Type: Unknown/Other Function Bug description: // or # Comment including %> crashes ! Description: PHP5 doesn't like comments including %> PHP4 was happy enough with them... Do you know how hard it is to search for '%>' ? Reproduce code: --- // Insure £9<£600 1.5%>£600 # Insure £9<£600 1.5%>£600 but /* Insure £9<£600 1.5%>£600 */ Expected result: nothing !!! Actual result: -- Parse error: syntax error, unexpected $end in blah.php on line 193 i.e. after the ?> on the final line -- Edit bug report at http://bugs.php.net/?id=33306&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33306&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33306&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33306&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33306&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33306&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33306&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33306&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33306&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33306&r=support Expected behavior: http://bugs.php.net/fix.php?id=33306&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33306&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33306&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33306&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33306&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33306&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33306&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33306&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33306&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33306&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33306&r=mysqlcfg
#30776 [NEW]: unreadable answer from parser
From: rob at alterlinks dot fr Operating system: Linux 2.6.3-7 PHP version: 5.0.2 PHP Bug Type: *General Issues Bug description: unreadable answer from parser Description: Please see bug #28243 I know, as reported, it is maybe *not* a bug, one has to use the correct syntax ! But, when using the parser result : expecting T_PAAMAYIM_NEKUDOTAYIM is not understandable, at least not to me. PHP4 returns an understandble code. Reproduce code: --- (indeed, the above code is *incorrect*, it's only to provoque de parser's return code) Expected result: Parse error: parse error, unexpected T_STRING, expecting T_VARIABLE or '$' in /var/www/sites/premiere/phpinfo.php on line 2 Actual result: -- Parse error: parse error, unexpected ')', expecting T_PAAMAYIM_NEKUDOTAYIM in /var/www/sites/bios/phpinfo.php on line 2 -- Edit bug report at http://bugs.php.net/?id=30776&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30776&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30776&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30776&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30776&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30776&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30776&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30776&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30776&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30776&r=support Expected behavior: http://bugs.php.net/fix.php?id=30776&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30776&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30776&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30776&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30776&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30776&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30776&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30776&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30776&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30776&r=mysqlcfg
#30776 [Fbk->Opn]: unreadable answer from parser
ID: 30776 User updated by: rob at alterlinks dot fr Reported By: rob at alterlinks dot fr -Status: Feedback +Status: Open Bug Type: *General Issues Operating System: Linux 2.6.3-7 PHP Version: 5.0.2 New Comment: Thanks for your reply. However, can you explain why PHP4 reports a readable error, in relation to the misstake I'm maken, as where PHP5 reports me something in Hebrew while the error I'm making seems to have nothing to do with classes ?? What is the error it reports you for the code below ? Previous Comments: [2004-11-13 21:16:21] [EMAIL PROTECTED] I can't reproduce it. But I'd advise you to read this: http://www.php.net/manual/en/language.oop5.paamayim-nekudotayim.php [2004-11-13 20:53:32] rob at alterlinks dot fr Description: Please see bug #28243 I know, as reported, it is maybe *not* a bug, one has to use the correct syntax ! But, when using the parser result : expecting T_PAAMAYIM_NEKUDOTAYIM is not understandable, at least not to me. PHP4 returns an understandble code. Reproduce code: --- (indeed, the above code is *incorrect*, it's only to provoque de parser's return code) Expected result: Parse error: parse error, unexpected T_STRING, expecting T_VARIABLE or '$' in /var/www/sites/premiere/phpinfo.php on line 2 Actual result: -- Parse error: parse error, unexpected ')', expecting T_PAAMAYIM_NEKUDOTAYIM in /var/www/sites/bios/phpinfo.php on line 2 -- Edit this bug report at http://bugs.php.net/?id=30776&edit=1
#30776 [Fbk->Opn]: unreadable answer from parser
ID: 30776 User updated by: rob at alterlinks dot fr Reported By: rob at alterlinks dot fr -Status: Feedback +Status: Open Bug Type: *General Issues Operating System: Linux 2.6.3-7 PHP Version: 5.0.2 New Comment: I'm happy for you, for me it doesn't with PHP 5.0.2. It does with PHP4, not with PHP5.0.2 (the exact same code). Either it's fixed in whatever version you're using, either I can't conclude otherwise than that there is a difference in behaviour between my PHP4 and PHP5.0.2 Anyway, lets forget about it, it's not that big of a deal, I guess I'll just have to go learn Hebrew ;) Previous Comments: [2004-11-13 21:40:38] [EMAIL PROTECTED] It reports exactly what you have expected: "Parse error: parse error, unexpected T_VAR, expecting T_STRING or T_VARIABLE or '$' in .." ---- [2004-11-13 21:36:33] rob at alterlinks dot fr Thanks for your reply. However, can you explain why PHP4 reports a readable error, in relation to the misstake I'm maken, as where PHP5 reports me something in Hebrew while the error I'm making seems to have nothing to do with classes ?? What is the error it reports you for the code below ? [2004-11-13 21:16:21] [EMAIL PROTECTED] I can't reproduce it. But I'd advise you to read this: http://www.php.net/manual/en/language.oop5.paamayim-nekudotayim.php ---- [2004-11-13 20:53:32] rob at alterlinks dot fr Description: Please see bug #28243 I know, as reported, it is maybe *not* a bug, one has to use the correct syntax ! But, when using the parser result : expecting T_PAAMAYIM_NEKUDOTAYIM is not understandable, at least not to me. PHP4 returns an understandble code. Reproduce code: --- (indeed, the above code is *incorrect*, it's only to provoque de parser's return code) Expected result: Parse error: parse error, unexpected T_STRING, expecting T_VARIABLE or '$' in /var/www/sites/premiere/phpinfo.php on line 2 Actual result: -- Parse error: parse error, unexpected ')', expecting T_PAAMAYIM_NEKUDOTAYIM in /var/www/sites/bios/phpinfo.php on line 2 -- Edit this bug report at http://bugs.php.net/?id=30776&edit=1
#30776 [Bgs]: unreadable answer from parser
ID: 30776 User updated by: rob at alterlinks dot fr Reported By: rob at alterlinks dot fr Status: Bogus Bug Type: *General Issues Operating System: Linux 2.6.3-7 PHP Version: 5.0.2 New Comment: Good evening, I don't like the status "bogus"; It's maybe not a bug, at least nothing to be really worried about, but if I wouldn't see the result with my own eyes on my screen, I wonder how one can say that there is *no* bug. Would I be able to dream and come up with a word like that ? lol Please see : http://bios.alterlinks.fr/phpinfo.php http://bios.alterlinks.fr/phpinfo2.php and http://premiere.alterlinks.fr/phpinfo.php http://premiere.alterlinks.fr/phpinfo2.php between phpinfo and phpinfo2 the only difference is the line : unset (variable); which has been added. Anyway, just leave the incident closed as it's no big deal, just to show you that I'm not dreaming :) Best regards, Previous Comments: [2004-11-13 21:53:35] [EMAIL PROTECTED] No bug -> bogus. -------- [2004-11-13 21:50:56] rob at alterlinks dot fr I'm happy for you, for me it doesn't with PHP 5.0.2. It does with PHP4, not with PHP5.0.2 (the exact same code). Either it's fixed in whatever version you're using, either I can't conclude otherwise than that there is a difference in behaviour between my PHP4 and PHP5.0.2 Anyway, lets forget about it, it's not that big of a deal, I guess I'll just have to go learn Hebrew ;) [2004-11-13 21:40:38] [EMAIL PROTECTED] It reports exactly what you have expected: "Parse error: parse error, unexpected T_VAR, expecting T_STRING or T_VARIABLE or '$' in .." -------- [2004-11-13 21:36:33] rob at alterlinks dot fr Thanks for your reply. However, can you explain why PHP4 reports a readable error, in relation to the misstake I'm maken, as where PHP5 reports me something in Hebrew while the error I'm making seems to have nothing to do with classes ?? What is the error it reports you for the code below ? [2004-11-13 21:16:21] [EMAIL PROTECTED] I can't reproduce it. But I'd advise you to read this: http://www.php.net/manual/en/language.oop5.paamayim-nekudotayim.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/30776 -- Edit this bug report at http://bugs.php.net/?id=30776&edit=1
#27375 [Com]: $DOCUMENT_ROOT sometimes empty when register_globals=on
ID: 27375
Comment by: rob at realmsolutions dot com
Reported By: oliver at update dot ch
Status: Bogus
Bug Type: Apache2 related
Operating System: Linux
PHP Version: 4.3.3.
New Comment:
OK, I've got similar but even weirder problem. I just installed the
latest production releases of apache2/php and now I occasionally get
_wrong_ values in the DOCUMENT_ROOT variable. Instead of containing
the pathname of the current virtual host, it sometimes contains the
pathname of a different virtual host also configured on this server!
There is definitely some problem here, if I click from vhost site to
vhost site, I can get these errors repeatedly. Since I'm including
files based on the DOCUMENT_ROOT, it manifests itself as an error that
looks like this:
Warning:
main(/home/wrongwebsite/www/includes/functions_generic.php): failed to
open stream: No such file or directory in
/home/correctwebsite/www/includes/config.php on line 47
In this example its _should_ be including the file functions_generic
from "correctwebsite", not "wrongwebsite"
After the first instance of this error, it seems to go away until I
switch to another website, where it may or may not happen again...
FYI, here are the flags set in my virtualhost:
php_admin_flag engine on
php_admin_flag safe_mode off
php_admin_flag register_globals off
php_admin_flag display_errors on
Previous Comments:
[2004-02-25 06:17:12] [EMAIL PROTECTED]
If you had bothered searching the bug database first you would have
find couple of dozen similar reports. And also that this is most likely
FIXED in CVS. (get stable snapshot from http://snaps.php.net/ )
[2004-02-25 02:04:35] oliver at update dot ch
Sorry about that. I'm not the pro on stuff like this.
But I try again:
Configuration:
--
'./configure' '--with-apxs2=/opt/httpd-2.0.47/bin/apxs'
'--with-config-file-path=/etc/httpd2' '--prefix=/opt/
php-4.x' '--enable-versioning' '--with-gd' '--with-jpeg-
dir=/usr' '--with-xpm-dir=/usr' '--with-bz2' '--with-
freetype-dir=/usr' '--enable-gd-native-ttf' '--enable-
debug=no' '--with-exec-dir=/opt/php-4.x/run' '--enable-
track-vars=yes' '--disable-cgi' '--enable-calendar' '--
with-ttf' '--with-imap' '--with-ft' '--with-xml' '--
with-mhash' '--with-mcrypt' '--with-bcmath' '--with-
snmp' '--enable-ucd-snmp-hack' '--enable-ucd-snmp-
compatibility' '--with-pdflib=/opt/pdflib-4.0' '--with-
zlib' '--enable-trans-sid' '--with-openssl' '--with-
wddx' '--with-crack' '--with-kerberos' '--with-gettext'
Reproduce code:
---
register_globals: ""
$GLOBALS["DOCUMENT_ROOT"] = "
$DOCUMENT_ROOT: ""
$_SERVER["DOCUMENT_ROOT"]: ""
Expected result:
register_globals: "1"
$GLOBALS["DOCUMENT_ROOT"] = "/home/www/
$DOCUMENT_ROOT: "/home/www/"
$_SERVER["DOCUMENT_ROOT"]: "/home/www/"
Result (tested on 02/24/04):
--
register_globals: "1"
$GLOBALS["DOCUMENT_ROOT"] = ""
$DOCUMENT_ROOT: ""
$_SERVER["DOCUMENT_ROOT"]: "/home/www/"
PHP-Version is 4.3.3.
The thing is, that I couldn't reproduce the result today
(02/25). So I guess, you can really let vanish this
report. Thanks for the help anyway.
[2004-02-24 16:57:50] [EMAIL PROTECTED]
Second try. (If I have to ask these same things for the 3rd time, this
bug report will vanish mysteriously..)
1. How did you configure Apache? (configure line used)
2. What MPM are you using with Apache?
3. What is register_globals set to WHEN this happens?
(put var_dump(ini_get("register_globals")); in the beginning of your
script, see bug #24253 what a nice short test script looks like)
4. Are you sure there aren't any .htaccess files or vhosts setting
register_globals to something else? Or setting any other php.ini
options? (using php_value, php_admin_value, php_flag or php_admin_flag
directives)
5. How was PHP configured into Apache? (as module or CGI binary??)
[2004-02-24 12:59:58] oliver at update dot ch
register_globals is always set on. register_globals is
set
#27375 [Com]: $DOCUMENT_ROOT sometimes empty when register_globals=on
ID: 27375 Comment by: rob at realmsolutions dot com Reported By: oliver at update dot ch Status: Bogus Bug Type: Apache2 related Operating System: Linux PHP Version: 4.3.3. New Comment: OK, this was not fixed by the latest snapshot, which I just tried, and still get the same results... Please reopen this bug, its not bogus. Here's more info, let me know if you need anything else. I've installed apache 2.0.48 with the latest php 4.3.4 snapshot. I always have register globals off in both php.ini and defined that way in the vhost too. I always refer to the variable as $_SERVER["DOCUMENT_ROOT"]. I have about 80 virtualhosts set up, and I've had a wide variety of them have the DOCUMENT_ROOT var get the wrong pathname. But the weird thing is that when the pathname is wrong, its always the same path from another vhost. The wierd thing is, that particular vhost doesnt really stand out in any obvious way... its not the first vhost in the config, its not the last either... kinda in the middle. its not alphabetically first or last, its not the site that gets the most traffic, nor the least. The only thing unusual about it is that it has alot of complex mod_rewriting going on, however, its not the only vhost that uses complex mod_rewriting either so I'm kinda stumped as to why it always seems to have the _same_wrong_path_ in the DOCUMENT_ROOT variable! If you want or need any more info, please just ask or tell me what to do! Previous Comments: -------- [2004-03-07 03:22:29] rob at realmsolutions dot com OK, I've got similar but even weirder problem. I just installed the latest production releases of apache2/php and now I occasionally get _wrong_ values in the DOCUMENT_ROOT variable. Instead of containing the pathname of the current virtual host, it sometimes contains the pathname of a different virtual host also configured on this server! There is definitely some problem here, if I click from vhost site to vhost site, I can get these errors repeatedly. Since I'm including files based on the DOCUMENT_ROOT, it manifests itself as an error that looks like this: Warning: main(/home/wrongwebsite/www/includes/functions_generic.php): failed to open stream: No such file or directory in /home/correctwebsite/www/includes/config.php on line 47 In this example its _should_ be including the file functions_generic from "correctwebsite", not "wrongwebsite" After the first instance of this error, it seems to go away until I switch to another website, where it may or may not happen again... FYI, here are the flags set in my virtualhost: php_admin_flag engine on php_admin_flag safe_mode off php_admin_flag register_globals off php_admin_flag display_errors on [2004-02-25 06:17:12] [EMAIL PROTECTED] If you had bothered searching the bug database first you would have find couple of dozen similar reports. And also that this is most likely FIXED in CVS. (get stable snapshot from http://snaps.php.net/ ) [2004-02-25 02:04:35] oliver at update dot ch Sorry about that. I'm not the pro on stuff like this. But I try again: Configuration: -- './configure' '--with-apxs2=/opt/httpd-2.0.47/bin/apxs' '--with-config-file-path=/etc/httpd2' '--prefix=/opt/ php-4.x' '--enable-versioning' '--with-gd' '--with-jpeg- dir=/usr' '--with-xpm-dir=/usr' '--with-bz2' '--with- freetype-dir=/usr' '--enable-gd-native-ttf' '--enable- debug=no' '--with-exec-dir=/opt/php-4.x/run' '--enable- track-vars=yes' '--disable-cgi' '--enable-calendar' '-- with-ttf' '--with-imap' '--with-ft' '--with-xml' '-- with-mhash' '--with-mcrypt' '--with-bcmath' '--with- snmp' '--enable-ucd-snmp-hack' '--enable-ucd-snmp- compatibility' '--with-pdflib=/opt/pdflib-4.0' '--with- zlib' '--enable-trans-sid' '--with-openssl' '--with- wddx' '--with-crack' '--with-kerberos' '--with-gettext' Reproduce code: --- register_globals: "" $GLOBALS["DOCUMENT_ROOT"] = " $DOCUMENT_ROOT: "" $_SERVER["DOCUMENT_ROOT"]: "" Expected result: register_globals: "1" $GLOBALS["DOCUMENT_ROOT"] = "/home/www/ $DOCUMENT_ROOT: "/home/www/" $_SERVER["DOCUMENT_ROOT"]:
#27375 [Com]: $DOCUMENT_ROOT sometimes empty when register_globals=on
ID: 27375 Comment by: rob at realmsolutions dot com Reported By: oliver at update dot ch Status: Bogus Bug Type: Apache2 related Operating System: Linux PHP Version: 4.3.3. New Comment: ACK. When I compiled/installed the latest snapshot last night, it didnt install the module for some reason... So I did a clean config/make/make install and this time it did install properly. Now it appears that the problem may be fixed.. After several minutes of trying to reproduce the error, I'm unable to, so as of now, I am thinking this bug is fixed. Previous Comments: [2004-03-07 04:36:30] rob at realmsolutions dot com OK, this was not fixed by the latest snapshot, which I just tried, and still get the same results... Please reopen this bug, its not bogus. Here's more info, let me know if you need anything else. I've installed apache 2.0.48 with the latest php 4.3.4 snapshot. I always have register globals off in both php.ini and defined that way in the vhost too. I always refer to the variable as $_SERVER["DOCUMENT_ROOT"]. I have about 80 virtualhosts set up, and I've had a wide variety of them have the DOCUMENT_ROOT var get the wrong pathname. But the weird thing is that when the pathname is wrong, its always the same path from another vhost. The wierd thing is, that particular vhost doesnt really stand out in any obvious way... its not the first vhost in the config, its not the last either... kinda in the middle. its not alphabetically first or last, its not the site that gets the most traffic, nor the least. The only thing unusual about it is that it has alot of complex mod_rewriting going on, however, its not the only vhost that uses complex mod_rewriting either so I'm kinda stumped as to why it always seems to have the _same_wrong_path_ in the DOCUMENT_ROOT variable! If you want or need any more info, please just ask or tell me what to do! ---- [2004-03-07 03:22:29] rob at realmsolutions dot com OK, I've got similar but even weirder problem. I just installed the latest production releases of apache2/php and now I occasionally get _wrong_ values in the DOCUMENT_ROOT variable. Instead of containing the pathname of the current virtual host, it sometimes contains the pathname of a different virtual host also configured on this server! There is definitely some problem here, if I click from vhost site to vhost site, I can get these errors repeatedly. Since I'm including files based on the DOCUMENT_ROOT, it manifests itself as an error that looks like this: Warning: main(/home/wrongwebsite/www/includes/functions_generic.php): failed to open stream: No such file or directory in /home/correctwebsite/www/includes/config.php on line 47 In this example its _should_ be including the file functions_generic from "correctwebsite", not "wrongwebsite" After the first instance of this error, it seems to go away until I switch to another website, where it may or may not happen again... FYI, here are the flags set in my virtualhost: php_admin_flag engine on php_admin_flag safe_mode off php_admin_flag register_globals off php_admin_flag display_errors on [2004-02-25 06:17:12] [EMAIL PROTECTED] If you had bothered searching the bug database first you would have find couple of dozen similar reports. And also that this is most likely FIXED in CVS. (get stable snapshot from http://snaps.php.net/ ) [2004-02-25 02:04:35] oliver at update dot ch Sorry about that. I'm not the pro on stuff like this. But I try again: Configuration: -- './configure' '--with-apxs2=/opt/httpd-2.0.47/bin/apxs' '--with-config-file-path=/etc/httpd2' '--prefix=/opt/ php-4.x' '--enable-versioning' '--with-gd' '--with-jpeg- dir=/usr' '--with-xpm-dir=/usr' '--with-bz2' '--with- freetype-dir=/usr' '--enable-gd-native-ttf' '--enable- debug=no' '--with-exec-dir=/opt/php-4.x/run' '--enable- track-vars=yes' '--disable-cgi' '--enable-calendar' '-- with-ttf' '--with-imap' '--with-ft' '--with-xml' '-- with-mhash' '--with-mcrypt' '--with-bcmath' '--with- snmp' '--enable-ucd-snmp-hack' '--enable-ucd-snmp- compatibility' '--with-pdflib=/opt/pdflib-4.0' '--with- zlib' '--enable-trans-sid' '--with-openssl' '
#32197 [NEW]: ZLib implementation does not support dictionaries
From: rob at wyrick dot org Operating system: Gentoo Linux PHP version: Irrelevant PHP Bug Type: Feature/Change Request Bug description: ZLib implementation does not support dictionaries Description: zlib allows you to specify dictionaries to be used while inflating or deflating. The php APIs are lacking this functionality. Properly picked dictionaries can VASTLY improve your compression ratio. My company is doing this, but I can't use PHP to access the database due to this missing feature in PHP's zlib API. -- Edit bug report at http://bugs.php.net/?id=32197&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32197&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32197&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32197&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32197&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32197&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32197&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32197&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32197&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32197&r=support Expected behavior: http://bugs.php.net/fix.php?id=32197&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32197&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32197&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32197&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32197&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32197&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32197&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32197&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32197&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32197&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32197&r=mysqlcfg
#32422 [NEW]: Access Violation on calling PEAR Date::before
From: rob at wildlime dot com Operating system: Windows XP SP2 PHP version: 4.3.10 PHP Bug Type: Reproducible crash Bug description: Access Violation on calling PEAR Date::before Description: Experiencing an intermittent (once every 5-10 requests) access violation. btw, I have posted this to the PHP bug list rather than the PEAR one as it is a crash, not just a script error. Here's the info I can glean from the debugger. I'm afraid I don't have the debug builds. Windows XP pro SP2 Apache/1.3.33 (Win32) PHP/4.3.10 stack trace: 7C910C27 C:\WINDOWS\system32\ntdll.dll 7C910D5C C:\WINDOWS\system32\ntdll.dll 77C2C2DE C:\WINDOWS\system32\msvcrt.dll 77C39AE9 C:\WINDOWS\system32\msvcrt.dll 77C35F5D C:\WINDOWS\system32\msvcrt.dll 77C35FEC C:\WINDOWS\system32\msvcrt.dll 10047D4E c:\php4\php4ts.dll or sometimes: 77C46137 C:\WINDOWS\system32\msvcrt.dll 100CA6AE c:\php4\php4ts.dll 60002E50 c:\php4\php4apache.dll 6000186F c:\php4\php4apache.dll dll base addresses: 0x6000 php4apache.dll 0x1000 php4ts.dll Reproduce code: --- before($now); ?> Expected result: nothing - no output, so blank browser window Actual result: -- Access violation every 5-10 requests. -- Edit bug report at http://bugs.php.net/?id=32422&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32422&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32422&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32422&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32422&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32422&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32422&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32422&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32422&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32422&r=support Expected behavior: http://bugs.php.net/fix.php?id=32422&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32422&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32422&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32422&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32422&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32422&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32422&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32422&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32422&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32422&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32422&r=mysqlcfg
#32422 [Opn]: Access Violation on calling PEAR Date::before
ID: 32422 User updated by: rob at wildlime dot com Reported By: rob at wildlime dot com Status: Open Bug Type: Reproducible crash Operating System: Windows XP SP2 PHP Version: 4.3.10 New Comment: I *think* the fault is happening in function php4ts.virtual_getcwd_ex Previous Comments: [2005-03-23 04:07:10] rob at wildlime dot com Description: Experiencing an intermittent (once every 5-10 requests) access violation. btw, I have posted this to the PHP bug list rather than the PEAR one as it is a crash, not just a script error. Here's the info I can glean from the debugger. I'm afraid I don't have the debug builds. Windows XP pro SP2 Apache/1.3.33 (Win32) PHP/4.3.10 stack trace: 7C910C27 C:\WINDOWS\system32\ntdll.dll 7C910D5C C:\WINDOWS\system32\ntdll.dll 77C2C2DE C:\WINDOWS\system32\msvcrt.dll 77C39AE9 C:\WINDOWS\system32\msvcrt.dll 77C35F5D C:\WINDOWS\system32\msvcrt.dll 77C35FEC C:\WINDOWS\system32\msvcrt.dll 10047D4E c:\php4\php4ts.dll or sometimes: 77C46137 C:\WINDOWS\system32\msvcrt.dll 100CA6AE c:\php4\php4ts.dll 60002E50 c:\php4\php4apache.dll 6000186F c:\php4\php4apache.dll dll base addresses: 0x6000 php4apache.dll 0x1000 php4ts.dll Reproduce code: --- before($now); ?> Expected result: nothing - no output, so blank browser window Actual result: -- Access violation every 5-10 requests. -- Edit this bug report at http://bugs.php.net/?id=32422&edit=1
#32422 [Opn]: Access Violation on calling PEAR Date::before
ID: 32422 User updated by: rob at wildlime dot com Reported By: rob at wildlime dot com Status: Open Bug Type: Reproducible crash Operating System: Windows XP SP2 PHP Version: 4.3.10 New Comment: having said that, it's just borked in php4ts.zend_strndup Previous Comments: [2005-03-23 05:01:09] rob at wildlime dot com I *think* the fault is happening in function php4ts.virtual_getcwd_ex [2005-03-23 04:07:10] rob at wildlime dot com Description: Experiencing an intermittent (once every 5-10 requests) access violation. btw, I have posted this to the PHP bug list rather than the PEAR one as it is a crash, not just a script error. Here's the info I can glean from the debugger. I'm afraid I don't have the debug builds. Windows XP pro SP2 Apache/1.3.33 (Win32) PHP/4.3.10 stack trace: 7C910C27 C:\WINDOWS\system32\ntdll.dll 7C910D5C C:\WINDOWS\system32\ntdll.dll 77C2C2DE C:\WINDOWS\system32\msvcrt.dll 77C39AE9 C:\WINDOWS\system32\msvcrt.dll 77C35F5D C:\WINDOWS\system32\msvcrt.dll 77C35FEC C:\WINDOWS\system32\msvcrt.dll 10047D4E c:\php4\php4ts.dll or sometimes: 77C46137 C:\WINDOWS\system32\msvcrt.dll 100CA6AE c:\php4\php4ts.dll 60002E50 c:\php4\php4apache.dll 6000186F c:\php4\php4apache.dll dll base addresses: 0x6000 php4apache.dll 0x1000 php4ts.dll Reproduce code: --- before($now); ?> Expected result: nothing - no output, so blank browser window Actual result: -- Access violation every 5-10 requests. -- Edit this bug report at http://bugs.php.net/?id=32422&edit=1
#32422 [Fbk->Opn]: Access Violation on calling PEAR Date::before
ID: 32422 User updated by: rob at wildlime dot com Reported By: rob at wildlime dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Windows XP SP2 PHP Version: 4.3.10 New Comment: Installed php 4.3.11 RC1 (windows) to c:\php, but PEAR wont't install. The error on running go-pear.bat, accepting the defaults, is: "failed to write c:\php\pear\data\PEAR\.tmppackage.dtd" There is plenty of disk space and I'm using an admin account. Previous Comments: [2005-03-23 08:20:48] [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 [2005-03-23 05:06:20] rob at wildlime dot com having said that, it's just borked in php4ts.zend_strndup ---- [2005-03-23 05:01:09] rob at wildlime dot com I *think* the fault is happening in function php4ts.virtual_getcwd_ex ---- [2005-03-23 04:07:10] rob at wildlime dot com Description: Experiencing an intermittent (once every 5-10 requests) access violation. btw, I have posted this to the PHP bug list rather than the PEAR one as it is a crash, not just a script error. Here's the info I can glean from the debugger. I'm afraid I don't have the debug builds. Windows XP pro SP2 Apache/1.3.33 (Win32) PHP/4.3.10 stack trace: 7C910C27 C:\WINDOWS\system32\ntdll.dll 7C910D5C C:\WINDOWS\system32\ntdll.dll 77C2C2DE C:\WINDOWS\system32\msvcrt.dll 77C39AE9 C:\WINDOWS\system32\msvcrt.dll 77C35F5D C:\WINDOWS\system32\msvcrt.dll 77C35FEC C:\WINDOWS\system32\msvcrt.dll 10047D4E c:\php4\php4ts.dll or sometimes: 77C46137 C:\WINDOWS\system32\msvcrt.dll 100CA6AE c:\php4\php4ts.dll 60002E50 c:\php4\php4apache.dll 6000186F c:\php4\php4apache.dll dll base addresses: 0x6000 php4apache.dll 0x1000 php4ts.dll Reproduce code: --- before($now); ?> Expected result: nothing - no output, so blank browser window Actual result: -- Access violation every 5-10 requests. -- Edit this bug report at http://bugs.php.net/?id=32422&edit=1
#32422 [Opn]: Access Violation on calling PEAR Date::before
ID: 32422 User updated by: rob at wildlime dot com Reported By: rob at wildlime dot com Status: Open Bug Type: Reproducible crash Operating System: Windows XP SP2 PHP Version: 4.3.10 New Comment: Here's another stack trace, using the MS debugger to get access to the symbol names ntdll!RtlpCoalesceFreeBlocks+0x21 ntdll!RtlFreeHeap+0x2e9 msvcrt!free+0xc3 msvcrt!__crtsetenv+0x193 msvcrt!_putenv_lk+0x42 msvcrt!_putenv+0x20 WARNING: Stack unwind information not available. Following frames may be wrong. php4ts!php_get_inf+0xf6e Error details from the debugger: (268.ddc): Access violation - code c005 (!!! second chance !!!) eax=0418 ebx=0083 ecx=7ffda000 edx=00830608 esi=0082fd68 edi=00830180 eip=7c910c27 esp=0108d978 ebp=0108d984 iopl=0 nv up ei ng nz na po cy cs=001b ss=0023 ds=0023 es=0023 fs=003b gs= efl=0287 ntdll!RtlpCoalesceFreeBlocks+0x21: 7c910c27 f6460501 testbyte ptr [esi+0x5],0x1 ds:0023:0082fd6d=?? (NB still using php 4.3.10) Previous Comments: [2005-03-29 02:05:42] rob at wildlime dot com Installed php 4.3.11 RC1 (windows) to c:\php, but PEAR wont't install. The error on running go-pear.bat, accepting the defaults, is: "failed to write c:\php\pear\data\PEAR\.tmppackage.dtd" There is plenty of disk space and I'm using an admin account. [2005-03-23 08:20:48] [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 ---- [2005-03-23 05:06:20] rob at wildlime dot com having said that, it's just borked in php4ts.zend_strndup -------- [2005-03-23 05:01:09] rob at wildlime dot com I *think* the fault is happening in function php4ts.virtual_getcwd_ex -------- [2005-03-23 04:07:10] rob at wildlime dot com Description: Experiencing an intermittent (once every 5-10 requests) access violation. btw, I have posted this to the PHP bug list rather than the PEAR one as it is a crash, not just a script error. Here's the info I can glean from the debugger. I'm afraid I don't have the debug builds. Windows XP pro SP2 Apache/1.3.33 (Win32) PHP/4.3.10 stack trace: 7C910C27 C:\WINDOWS\system32\ntdll.dll 7C910D5C C:\WINDOWS\system32\ntdll.dll 77C2C2DE C:\WINDOWS\system32\msvcrt.dll 77C39AE9 C:\WINDOWS\system32\msvcrt.dll 77C35F5D C:\WINDOWS\system32\msvcrt.dll 77C35FEC C:\WINDOWS\system32\msvcrt.dll 10047D4E c:\php4\php4ts.dll or sometimes: 77C46137 C:\WINDOWS\system32\msvcrt.dll 100CA6AE c:\php4\php4ts.dll 60002E50 c:\php4\php4apache.dll 6000186F c:\php4\php4apache.dll dll base addresses: 0x6000 php4apache.dll 0x1000 php4ts.dll Reproduce code: --- before($now); ?> Expected result: nothing - no output, so blank browser window Actual result: -- Access violation every 5-10 requests. -- Edit this bug report at http://bugs.php.net/?id=32422&edit=1
#32422 [Fbk->Opn]: Access Violation on calling PEAR Date::before
ID: 32422 User updated by: rob at wildlime dot com Reported By: rob at wildlime dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Windows XP SP2 PHP Version: 4.3.10 New Comment: Using PHP/4.3.11RC2-dev (btw, is it intentional that pear installs to c:\php\pear\pear?) Same result - frequent access violation. stack trace: ntdll!RtlpCoalesceFreeBlocks+0x21 ntdll!RtlFreeHeap+0x2e9 msvcrt!free+0xc3 msvcrt!__crtsetenv+0x193 msvcrt!_putenv_lk+0x42 msvcrt!_putenv+0x20 WARNING: Stack unwind information not available. Following frames may be wrong. php4ts!php_get_inf+0xfae Previous Comments: [2005-03-29 10:27:43] [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 ..and provide the trace when using the snapshot. [2005-03-29 07:53:56] rob at wildlime dot com Here's another stack trace, using the MS debugger to get access to the symbol names ntdll!RtlpCoalesceFreeBlocks+0x21 ntdll!RtlFreeHeap+0x2e9 msvcrt!free+0xc3 msvcrt!__crtsetenv+0x193 msvcrt!_putenv_lk+0x42 msvcrt!_putenv+0x20 WARNING: Stack unwind information not available. Following frames may be wrong. php4ts!php_get_inf+0xf6e Error details from the debugger: (268.ddc): Access violation - code c005 (!!! second chance !!!) eax=0418 ebx=0083 ecx=7ffda000 edx=00830608 esi=0082fd68 edi=00830180 eip=7c910c27 esp=0108d978 ebp=0108d984 iopl=0 nv up ei ng nz na po cy cs=001b ss=0023 ds=0023 es=0023 fs=003b gs= efl=0287 ntdll!RtlpCoalesceFreeBlocks+0x21: 7c910c27 f6460501 testbyte ptr [esi+0x5],0x1 ds:0023:0082fd6d=?? (NB still using php 4.3.10) [2005-03-29 02:05:42] rob at wildlime dot com Installed php 4.3.11 RC1 (windows) to c:\php, but PEAR wont't install. The error on running go-pear.bat, accepting the defaults, is: "failed to write c:\php\pear\data\PEAR\.tmppackage.dtd" There is plenty of disk space and I'm using an admin account. ---- [2005-03-23 04:07:10] rob at wildlime dot com Description: Experiencing an intermittent (once every 5-10 requests) access violation. btw, I have posted this to the PHP bug list rather than the PEAR one as it is a crash, not just a script error. Here's the info I can glean from the debugger. I'm afraid I don't have the debug builds. Windows XP pro SP2 Apache/1.3.33 (Win32) PHP/4.3.10 stack trace: 7C910C27 C:\WINDOWS\system32\ntdll.dll 7C910D5C C:\WINDOWS\system32\ntdll.dll 77C2C2DE C:\WINDOWS\system32\msvcrt.dll 77C39AE9 C:\WINDOWS\system32\msvcrt.dll 77C35F5D C:\WINDOWS\system32\msvcrt.dll 77C35FEC C:\WINDOWS\system32\msvcrt.dll 10047D4E c:\php4\php4ts.dll or sometimes: 77C46137 C:\WINDOWS\system32\msvcrt.dll 100CA6AE c:\php4\php4ts.dll 60002E50 c:\php4\php4apache.dll 6000186F c:\php4\php4apache.dll dll base addresses: 0x6000 php4apache.dll 0x1000 php4ts.dll Reproduce code: --- before($now); ?> Expected result: nothing - no output, so blank browser window Actual result: -- Access violation every 5-10 requests. -- Edit this bug report at http://bugs.php.net/?id=32422&edit=1
#32422 [Fbk->Opn]: Access Violation on calling PEAR Date::before
ID: 32422 User updated by: rob at wildlime dot com Reported By: rob at wildlime dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Windows XP SP2 PHP Version: 4.3.10 New Comment: sorry for the delay... using PHP/5.1.0-dev - no extensions loaded - PEAR installed (default packages and Date) Got the same access violation. stack trace: ntdll!RtlpCoalesceFreeBlocks+0x21 ntdll!RtlFreeHeap+0x2e9 msvcrt!free+0xc3 msvcrt!__crtsetenv+0x193 msvcrt!_putenv_lk+0x42 msvcrt!_putenv+0x20 WARNING: Stack unwind information not available. Following frames may be wrong. php5ts!php_get_inf+0x1083 Previous Comments: [2005-03-31 08:16:01] [EMAIL PROTECTED] Using extensions from different PHP version will not work of course.. but does the PEAR crap work any better? [2005-03-31 01:41:01] rob at wildlime dot com The access violation on starting Apache goes away if I disable all the extensions I was previously using (mysql, curl, openssl) I have tested this using php.ini-recommended, the only change being setting the extension dir from ./ to c:\php\ext [2005-03-31 01:30:15] rob at wildlime dot com Using PHP/5.1.0-dev access violation immediately on starting Apache stack trace: php5ts!zend_do_inherit_interfaces+0x14e (yes, that's all) I haven't installed PEAR yet... [2005-03-30 08:54:10] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip (yes, it's PHP5, but I'd like to know if this happens with it too..) [2005-03-30 01:49:22] rob at wildlime dot com Using PHP/4.3.11RC2-dev (btw, is it intentional that pear installs to c:\php\pear\pear?) Same result - frequent access violation. stack trace: ntdll!RtlpCoalesceFreeBlocks+0x21 ntdll!RtlFreeHeap+0x2e9 msvcrt!free+0xc3 msvcrt!__crtsetenv+0x193 msvcrt!_putenv_lk+0x42 msvcrt!_putenv+0x20 WARNING: Stack unwind information not available. Following frames may be wrong. php4ts!php_get_inf+0xfae 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/32422 -- Edit this bug report at http://bugs.php.net/?id=32422&edit=1
#32422 [Opn]: Access Violation on calling PEAR Date::before
ID: 32422 User updated by: rob at wildlime dot com Reported By: rob at wildlime dot com Status: Open Bug Type: Reproducible crash Operating System: Windows XP SP2 PHP Version: 4.3.10 New Comment: btw, the extensions loaded before were the ones packaged with PHP5, not old 4.3.10 ones! Previous Comments: [2005-04-06 04:21:17] rob at wildlime dot com sorry for the delay... using PHP/5.1.0-dev - no extensions loaded - PEAR installed (default packages and Date) Got the same access violation. stack trace: ntdll!RtlpCoalesceFreeBlocks+0x21 ntdll!RtlFreeHeap+0x2e9 msvcrt!free+0xc3 msvcrt!__crtsetenv+0x193 msvcrt!_putenv_lk+0x42 msvcrt!_putenv+0x20 WARNING: Stack unwind information not available. Following frames may be wrong. php5ts!php_get_inf+0x1083 [2005-03-31 08:16:01] [EMAIL PROTECTED] Using extensions from different PHP version will not work of course.. but does the PEAR crap work any better? [2005-03-31 01:41:01] rob at wildlime dot com The access violation on starting Apache goes away if I disable all the extensions I was previously using (mysql, curl, openssl) I have tested this using php.ini-recommended, the only change being setting the extension dir from ./ to c:\php\ext [2005-03-31 01:30:15] rob at wildlime dot com Using PHP/5.1.0-dev access violation immediately on starting Apache stack trace: php5ts!zend_do_inherit_interfaces+0x14e (yes, that's all) I haven't installed PEAR yet... [2005-03-30 08:54:10] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip (yes, it's PHP5, but I'd like to know if this happens with it too..) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/32422 -- Edit this bug report at http://bugs.php.net/?id=32422&edit=1
#32422 [Opn]: Access Violation on calling PEAR Date::before
ID: 32422 User updated by: rob at wildlime dot com Reported By: rob at wildlime dot com Status: Open Bug Type: Reproducible crash Operating System: Windows XP SP2 PHP Version: 4.3.10 New Comment: Looks like this bug has been encountered before: http://pear.php.net/bugs/bug.php?id=2344 .. but the Date package owners maintain that it's not their problem. (Dunno how I didn't find that earlier :-/ I did search the bug DBs before posting, honest!) Previous Comments: [2005-04-06 04:23:22] rob at wildlime dot com btw, the extensions loaded before were the ones packaged with PHP5, not old 4.3.10 ones! [2005-04-06 04:21:17] rob at wildlime dot com sorry for the delay... using PHP/5.1.0-dev - no extensions loaded - PEAR installed (default packages and Date) Got the same access violation. stack trace: ntdll!RtlpCoalesceFreeBlocks+0x21 ntdll!RtlFreeHeap+0x2e9 msvcrt!free+0xc3 msvcrt!__crtsetenv+0x193 msvcrt!_putenv_lk+0x42 msvcrt!_putenv+0x20 WARNING: Stack unwind information not available. Following frames may be wrong. php5ts!php_get_inf+0x1083 [2005-03-31 08:16:01] [EMAIL PROTECTED] Using extensions from different PHP version will not work of course.. but does the PEAR crap work any better? [2005-03-31 01:41:01] rob at wildlime dot com The access violation on starting Apache goes away if I disable all the extensions I was previously using (mysql, curl, openssl) I have tested this using php.ini-recommended, the only change being setting the extension dir from ./ to c:\php\ext [2005-03-31 01:30:15] rob at wildlime dot com Using PHP/5.1.0-dev access violation immediately on starting Apache stack trace: php5ts!zend_do_inherit_interfaces+0x14e (yes, that's all) I haven't installed PEAR yet... 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/32422 -- Edit this bug report at http://bugs.php.net/?id=32422&edit=1
#32422 [Asn]: Access Violation on calling PEAR Date::before
ID: 32422 User updated by: rob at wildlime dot com Reported By: rob at wildlime dot com Status: Assigned Bug Type: Reproducible crash Operating System: Windows XP SP2 PHP Version: 4.3.10 Assigned To: pierre New Comment: Any chance of PHP catching the exception in putenv/gettenv and chucking a more informative error? Would help anyone else who hits this problem. Previous Comments: [2005-04-08 00:27:12] [EMAIL PROTECTED] Pierre promised to look into this..(or rather bogus this with good explanation..) [2005-04-06 05:52:25] rob at wildlime dot com Looks like this bug has been encountered before: http://pear.php.net/bugs/bug.php?id=2344 .. but the Date package owners maintain that it's not their problem. (Dunno how I didn't find that earlier :-/ I did search the bug DBs before posting, honest!) [2005-04-06 04:23:22] rob at wildlime dot com btw, the extensions loaded before were the ones packaged with PHP5, not old 4.3.10 ones! [2005-04-06 04:21:17] rob at wildlime dot com sorry for the delay... using PHP/5.1.0-dev - no extensions loaded - PEAR installed (default packages and Date) Got the same access violation. stack trace: ntdll!RtlpCoalesceFreeBlocks+0x21 ntdll!RtlFreeHeap+0x2e9 msvcrt!free+0xc3 msvcrt!__crtsetenv+0x193 msvcrt!_putenv_lk+0x42 msvcrt!_putenv+0x20 WARNING: Stack unwind information not available. Following frames may be wrong. php5ts!php_get_inf+0x1083 [2005-03-31 08:16:01] [EMAIL PROTECTED] Using extensions from different PHP version will not work of course.. but does the PEAR crap work any better? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/32422 -- Edit this bug report at http://bugs.php.net/?id=32422&edit=1
#29435 [NEW]: Segmentation Fault 11 in strlen()
From: rob at alterlinks dot fr Operating system: Linux Mandrake 2.4.19-16 PHP version: 5.0.0 PHP Bug Type: Reproducible crash Bug description: Segmentation Fault 11 in strlen() Description: Tested with PHP5.0.0 and later Snapshots with Apache 1.3.31 and 2.0.50, systematically a Segmentation Fault 11 (error_log Apache), blank page is shown. OK with PHP4.3.8. Result of debug : [EMAIL PROTECTED] logs]# gdb ../bin/httpd GNU gdb 5.2.1-2mdk (Mandrake Linux) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-mandrake-linux-gnu"... (gdb) run -X Starting program: /usr/local/free_websites/bin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x40186bc3 in strlen () from /lib/i686/libc.so.6 (gdb) Result of bt #0 0x40186bc3 in strlen () from /lib/i686/libc.so.6 #1 0x40473993 in add_property_string_ex (arg=0x1, key=0x82a4664 "\001", key_len=0, str=0x1 , duplicate=135993744) at /download/php5-200407261830/Zend/zend_API.c:1132 #2 0x4032b406 in zif_mysql_fetch_field (ht=1, return_value=0x82a4664, this_ptr=0x0, return_value_used=1) at /download/php5-200407261830/ext/mysql/php_mysql.c:2250 #3 0x40497feb in zend_do_fcall_common_helper (execute_data=0xbfffd280, opline=0x820b7dc, op_array=0x824cd28) at /download/php5-200407261830/Zend/zend_execute.c:2699 #4 0x40498760 in zend_do_fcall_handler (execute_data=0xbfffd280, opline=0x820b7dc, op_array=0x824cd28) at /download/php5-200407261830/Zend/zend_execute.c:2831 #5 0x4049460c in execute (op_array=0x824cd28) at /download/php5-200407261830/Zend/zend_execute.c:1391 #6 0x40498184 in zend_do_fcall_common_helper (execute_data=0xbfffd350, opline=0x4088fb70, op_array=0x829207c) at /download/php5-200407261830/Zend/zend_execute.c:2728 #7 0x40498652 in zend_do_fcall_by_name_handler (execute_data=0xbfffd350, opline=0x4088fb70, op_array=0x829207c) at /download/php5-200407261830/Zend/zend_execute.c:2813 #8 0x4049460c in execute (op_array=0x829207c) at /download/php5-200407261830/Zend/zend_execute.c:1391 #9 0x40470841 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /download/php5-200407261830/Zend/zend.c:1068 #10 0x404295b2 in php_execute_script (primary_file=0xb600) at /download/php5-200407261830/main/main.c:1631 #11 0x404a149e in php_handler (r=0x842ab78) at /download/php5-200407261830/sapi/apache2handler/sapi_apache2.c:535 #12 0x0807e18b in ap_run_handler (r=0x842ab78) at config.c:152 #13 0x0807e72e in ap_invoke_handler (r=0x6) at config.c:358 #14 0x0806d1fb in ap_process_request (r=0x842ab78) at http_request.c:246 #15 0x08068fef in ap_process_http_connection (c=0x81f2058) at http_core.c:250 #16 0x08087e2b in ap_run_process_connection (c=0x81f2058) at connection.c:42 #17 0x0807cbf1 in child_main (child_num_arg=4) at prefork.c:609 #18 0x0807cdad in make_child (s=0x80bb120, slot=0) at prefork.c:649 #19 0x0807ce0e in startup_children (number_to_start=5) at prefork.c:721 #20 0x0807d553 in ap_mpm_run (_pconf=0x80b89f0, plog=0x80f0ad0, s=0x80b69e8) at prefork.c:940 #21 0x0808299a in main (argc=2, argv=0xb994) at main.c:617 #22 0x4012a082 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) Reproduce code: --- phpMyAdmin script, page sql.php Expected result: Display of contents of Database tables Actual result: -- Segmentation Fault 11 (no coredump), see gdb results (bt) -- Edit bug report at http://bugs.php.net/?id=29435&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29435&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29435&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29435&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29435&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29435&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29435&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29435&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29435&r=support Expected behavior: http://bugs.php.net/fix.php?id=29435&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29435&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29435&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29435&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29435&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29435&r=dst IIS Stability: http://bugs.php.ne
#29569 [NEW]: stream_set_timeout does not allow you to disable timeout
From: rob at rem5 dot com
Operating system: NIX 2.4.x
PHP version: 5.0.0
PHP Bug Type: Feature/Change Request
Bug description: stream_set_timeout does not allow you to disable timeout
Description:
when trying to keep a stream open using stream_set_timeout it will not
allow the connection to stay open. I tried setting it to 0.. as well as
9. However it will not stay open more than 30
seconds.
Reproduce code:
---
#!/usr/local/php5/bin/php -qn
\n";
} else {
while ($conn = stream_socket_accept($socket)) {
fwrite($conn, "Simple Echo Using stream_socket_server() in PHP");
$foo = fgets($conn);
fwrite($conn, $foo);
fclose($conn);
}
fclose($socket);
}
?>
Expected result:
stream_socket_server() should stay open and accepting connections.
Actual result:
--
craps out after 30 secs
--
Edit bug report at http://bugs.php.net/?id=29569&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29569&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29569&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=29569&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=29569&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29569&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29569&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29569&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=29569&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29569&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=29569&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=29569&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=29569&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29569&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=29569&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29569&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=29569&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29569&r=float
#29569 [Opn->Bgs]: stream_set_timeout does not allow you to disable timeout
ID: 29569
User updated by: rob at rem5 dot com
Reported By: rob at rem5 dot com
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: NIX 2.4.x
PHP Version: 5.0.0
New Comment:
error with my script and my head.
Previous Comments:
[2004-08-08 06:00:47] rob at rem5 dot com
Description:
when trying to keep a stream open using stream_set_timeout it will not
allow the connection to stay open. I tried setting it to 0.. as well as
9. However it will not stay open more than 30
seconds.
Reproduce code:
---
#!/usr/local/php5/bin/php -qn
\n";
} else {
while ($conn = stream_socket_accept($socket)) {
fwrite($conn, "Simple Echo Using stream_socket_server() in PHP");
$foo = fgets($conn);
fwrite($conn, $foo);
fclose($conn);
}
fclose($socket);
}
?>
Expected result:
stream_socket_server() should stay open and accepting connections.
Actual result:
--
craps out after 30 secs
--
Edit this bug report at http://bugs.php.net/?id=29569&edit=1
#48291 [NEW]: Sttotime returning wrong dates
From: rob at guidamedia dot com
Operating system: iis
PHP version: 5.2.9
PHP Bug Type: Scripting Engine problem
Bug description: Sttotime returning wrong dates
Description:
When converting weeks and days to a date using strtotime, some months
return the wrong dates. For instance, strtotime("first thursday",
mktime(0,0,0,11,1,2009)) returns 11/4/2009, which is a wednesday. There are
also issues using "last".
This seems to be happening with November 2009. I am not sure about other
years or other months. I think I had issues there as well, but
infrequently. I tried seeing if the issue is with any month when the first
day of the month is sunday, but it does not appear to be the case.
I am creating a new function to handle strtotime in this manner, because I
found more issues with using this function and creating a series of dates
that are incremented by a year.
Reproduce code:
---
public function getDateFromWeekAndDayOfMonth($d, $m, $y){
$fistDayOfMonth = mktime(0, 0, 0, $m, 1, $y)
$firstWeekForDay = strtotime("first " . $d, $fistDayOfMonth);
return $firstWeekForDay;
}
Expected result:
For the First Thursday in November 1, 2009, I expect to have the datetime
for 11-5-2009.
Actual result:
--
11-4-2009
--
Edit bug report at http://bugs.php.net/?id=48291&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48291&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48291&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48291&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48291&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48291&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48291&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48291&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48291&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48291&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48291&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48291&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48291&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48291&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48291&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48291&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48291&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48291&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48291&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48291&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48291&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48291&r=mysqlcfg
#48717 [NEW]: Cannot pass datatype long (> 2147483647) in SOAP requests
From: rob at zcore dot org Operating system: Debian GNU/Linux PHP version: 5.2.10 PHP Bug Type: SOAP related Bug description: Cannot pass datatype long (> 2147483647) in SOAP requests Description: For some reason Array ( [0] => dummy Object ( [id] => 10047678003 [pass] => XxX ) ) is transformed to http://schemas.xmlsoap.org/soap/envelope/"; xmlns:ns1="http://impl.ejb.flog.zcore.org/";> 2147483647 XxX while it's based on this XSD snipplet: Expected result: http://schemas.xmlsoap.org/soap/envelope/"; xmlns:ns1="http://impl.ejb.flog.zcore.org/";> 10047678003 XxX Actual result: -- http://schemas.xmlsoap.org/soap/envelope/"; xmlns:ns1="http://impl.ejb.flog.zcore.org/";> 2147483647 XxX -- Edit bug report at http://bugs.php.net/?id=48717&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48717&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48717&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48717&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48717&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48717&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48717&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48717&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48717&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48717&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48717&r=support Expected behavior: http://bugs.php.net/fix.php?id=48717&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48717&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48717&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48717&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48717&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48717&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48717&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48717&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48717&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48717&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48717&r=mysqlcfg
#48717 [Com]: Cannot pass datatype long (> 2147483647) in SOAP requests
ID: 48717 Comment by: rob at zcore dot org Reported By: rob at zcore dot org Status: Open Bug Type: SOAP related Operating System: Debian GNU/Linux PHP Version: 5.2.10 New Comment: Sorry, this one is way t dirty. Previous Comments: [2009-07-14 13:59:07] ghostbaer at gmx dot de Hi, a very dirty workaround is to download the wsdl an rewrite it locally to another datatype. Changing this line: to should work at least. But it's a very, very, VERY, VERY, VEWY, VEWY, VEWYVEWYVEWY dirty workaround and you'll got to hell for this or even worse! [2009-06-29 11:06:13] rob at zcore dot org Description: For some reason Array ( [0] => dummy Object ( [id] => 10047678003 [pass] => XxX ) ) is transformed to http://schemas.xmlsoap.org/soap/envelope/"; xmlns:ns1="http://impl.ejb.flog.zcore.org/";> 2147483647 XxX while it's based on this XSD snipplet: Expected result: http://schemas.xmlsoap.org/soap/envelope/"; xmlns:ns1="http://impl.ejb.flog.zcore.org/";> 10047678003 XxX Actual result: -- http://schemas.xmlsoap.org/soap/envelope/"; xmlns:ns1="http://impl.ejb.flog.zcore.org/";> 2147483647 XxX -- Edit this bug report at http://bugs.php.net/?id=48717&edit=1
#48717 [Opn]: Cannot pass datatype long (> 2147483647) in SOAP requests
ID: 48717 User updated by: rob at zcore dot org Reported By: rob at zcore dot org Status: Open Bug Type: SOAP related Operating System: Debian GNU/Linux -PHP Version: 5.2.10 +PHP Version: 5.2.11 New Comment: Hi, in the meantime my company upgraded to 5.2.11 (security reasons); the bug seems to be in there, too. Unluckily updating to HEAD is no option, since we are using the ZendPlatform. Regs Rob Previous Comments: [2009-09-25 17:23:01] persiancity at gmail dot com another note: I get corrent result sends from a server using PHP 5.2.42 Incorrect result sends from a server with PHP 5.2.9 [2009-09-25 17:20:18] persiancity at gmail dot com I am not pro in SOAP so maybe provide me __getLastRequest/Response testing code? [2009-09-25 16:51:46] sjo...@php.net I can not reproduce it with PHP 5.2 HEAD. Can you check with a sniffer, or with __getLastRequest/Response if the error also occurs in the request? [2009-09-25 16:42:45] persiancity at gmail dot com I have the same problem ( http://bugs.php.net/bug.php?id=49669 ) but float replacement not working! [2009-07-15 14:18:50] rob at zcore dot org Sorry, this one is way t dirty. 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/48717 -- Edit this bug report at http://bugs.php.net/?id=48717&edit=1
#49878 [NEW]: Fileinfo functions not found
From: rob at apgood dot com Operating system: Windows Serer 2003 PHP version: 5.3SVN-2009-10-14 (snap) PHP Bug Type: PHP options/info functions Bug description: Fileinfo functions not found Description: Installed Windows binaries (php-5.3.0-Win32-VC6-x86.msi) with Fileinfo functions selected to be installed. However, the very simple attached script results in error: [Wed Oct 14 09:43:58 2009] [error] [client 173.10.71.237] PHP Fatal error: Call to undefined function finfo_open() in D:\\Apache\\casetracker\\finfo1.php on line 2 Reproduce code: --- Expected result: a mime-type description of: "image/vnd.microsoft.icon" or (less correctly): "image/x-icon" Actual result: -- in error.log, [Wed Oct 14 09:43:58 2009] [error] [client 173.10.71.237] PHP Fatal error: Call to undefined function finfo_open() in D:\\Apache\\casetracker\\finfo1.php on line 2 -- Edit bug report at http://bugs.php.net/?id=49878&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49878&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49878&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49878&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49878&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49878&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49878&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49878&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49878&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49878&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49878&r=support Expected behavior: http://bugs.php.net/fix.php?id=49878&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49878&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49878&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49878&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49878&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49878&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49878&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49878&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49878&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49878&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49878&r=mysqlcfg
#46297 [NEW]: Round Issue
From: rob at washeretoo dot com Operating system: Linux PHP version: 5.2.6 PHP Bug Type: Math related Bug description: Round Issue Description: round (1125.005, 2) returns "1125.01" as expected round(11125.005, 2) returns "11125" when the value before the decimal point gets to large it simply strips the decimal point value off!?? Reproduce code: --- print round (1125.005, 2); print round(11125.005, 2); Expected result: round(11125.005, 2) should return 11125.01 Actual result: -- round(11125.005, 2) returns 11125 -- Edit bug report at http://bugs.php.net/?id=46297&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46297&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46297&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46297&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46297&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=46297&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46297&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=46297&r=needscript Try newer version:http://bugs.php.net/fix.php?id=46297&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46297&r=support Expected behavior:http://bugs.php.net/fix.php?id=46297&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46297&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46297&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46297&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46297&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=46297&r=dst IIS Stability:http://bugs.php.net/fix.php?id=46297&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46297&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46297&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46297&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=46297&r=mysqlcfg
#46548 [Opn]: NULL return values in complex objects are not returned
ID: 46548 User updated by: rob at kinesissurvey dot com Reported By: rob at kinesissurvey dot com Status: Open Bug Type: SOAP related Operating System: Linux PHP Version: 5.2.6 New Comment: The wsdl file moved, so please ignore that link. The wsdl is included in the zip file, anyway. Previous Comments: [2008-11-11 17:24:10] rob at kinesissurvey dot com Description: Null elements are ignored, instead of being returned as null. I believe this is the same as bug #41745; however, the bug system would not let me post my comment there (maybe because it's in "Feedback" status?), so I'm posting it here. Since this bug has existed for over a year, a new bug report probably won't hurt things. I have a small test case. This bug is still present in PHP 5.2.6, and based on the 5.3 alpha notes, it has not been fixed there yet, either. Reproduce code: --- http://web4.kinesissurvey.com/rproject/sv500/nullbugclient.php Notice the "status" key is missing from the second array element. The wsdl file being used is at: http://web4.kinesissurvey.com/rproject/sv500/wsdl/panel/nullbug.wsdl You can get the source at: http://web4.kinesissurvey.com/rproject/sv500/nullbug.zip Expected result: Array ( [0] => Array ( [id] => 1 [name] => Survey number 1 [uri] => http://www.kinesissurvey.com/html.pro?ID=1 [status] => completed ) [1] => Array ( [id] => 2 [name] => Survey number 2 [uri] => http://www.kinesissurvey.com/html.pro?ID=2 [status] => ) ) Actual result: -- Array ( [0] => Array ( [id] => 1 [name] => Survey number 1 [uri] => http://www.kinesissurvey.com/html.pro?ID=1 [status] => completed ) [1] => Array ( [id] => 2 [name] => Survey number 2 [uri] => http://www.kinesissurvey.com/html.pro?ID=2 ) ) -- Edit this bug report at http://bugs.php.net/?id=46548&edit=1
#46548 [NEW]: NULL return values in complex objects are not returned
From: rob at kinesissurvey dot com Operating system: Linux PHP version: 5.2.6 PHP Bug Type: SOAP related Bug description: NULL return values in complex objects are not returned Description: Null elements are ignored, instead of being returned as null. I believe this is the same as bug #41745; however, the bug system would not let me post my comment there (maybe because it's in "Feedback" status?), so I'm posting it here. Since this bug has existed for over a year, a new bug report probably won't hurt things. I have a small test case. This bug is still present in PHP 5.2.6, and based on the 5.3 alpha notes, it has not been fixed there yet, either. Reproduce code: --- http://web4.kinesissurvey.com/rproject/sv500/nullbugclient.php Notice the "status" key is missing from the second array element. The wsdl file being used is at: http://web4.kinesissurvey.com/rproject/sv500/wsdl/panel/nullbug.wsdl You can get the source at: http://web4.kinesissurvey.com/rproject/sv500/nullbug.zip Expected result: Array ( [0] => Array ( [id] => 1 [name] => Survey number 1 [uri] => http://www.kinesissurvey.com/html.pro?ID=1 [status] => completed ) [1] => Array ( [id] => 2 [name] => Survey number 2 [uri] => http://www.kinesissurvey.com/html.pro?ID=2 [status] => ) ) Actual result: -- Array ( [0] => Array ( [id] => 1 [name] => Survey number 1 [uri] => http://www.kinesissurvey.com/html.pro?ID=1 [status] => completed ) [1] => Array ( [id] => 2 [name] => Survey number 2 [uri] => http://www.kinesissurvey.com/html.pro?ID=2 ) ) -- Edit bug report at http://bugs.php.net/?id=46548&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46548&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46548&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46548&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46548&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46548&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46548&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46548&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46548&r=needscript Try newer version: http://bugs.php.net/fix.php?id=46548&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46548&r=support Expected behavior: http://bugs.php.net/fix.php?id=46548&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46548&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46548&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46548&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46548&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46548&r=dst IIS Stability: http://bugs.php.net/fix.php?id=46548&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46548&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46548&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46548&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46548&r=mysqlcfg
#49878 [Com]: Fileinfo functions not found
ID: 49878 Comment by: rob at apgood dot com Reported By: rob at apgood dot com Status: No Feedback Bug Type: PHP options/info functions Operating System: Windows Serer 2003 PHP Version: 5.3SVN-2009-10-14 (snap) New Comment: in php.ini: extension_dir = "C:\Program Files\PHP\ext" extension=php_fileinfo.dll dependencies: C:\Program Files\PHP\ext\php_fileinfo.dll (exists) output: fileinfo extension is not avaliable, please compile it. Previous Comments: [2009-10-22 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-14 17:10:22] paj...@php.net Did you activate the extension via php.ini (see phpinfo();)? [2009-10-14 17:08:37] rob at apgood dot com Description: Installed Windows binaries (php-5.3.0-Win32-VC6-x86.msi) with Fileinfo functions selected to be installed. However, the very simple attached script results in error: [Wed Oct 14 09:43:58 2009] [error] [client 173.10.71.237] PHP Fatal error: Call to undefined function finfo_open() in D:\\Apache\\casetracker\\finfo1.php on line 2 Reproduce code: --- Expected result: a mime-type description of: "image/vnd.microsoft.icon" or (less correctly): "image/x-icon" Actual result: -- in error.log, [Wed Oct 14 09:43:58 2009] [error] [client 173.10.71.237] PHP Fatal error: Call to undefined function finfo_open() in D:\\Apache\\casetracker\\finfo1.php on line 2 -- Edit this bug report at http://bugs.php.net/?id=49878&edit=1
#49878 [Bgs->Opn]: Fileinfo functions not found
ID: 49878 User updated by: rob at apgood dot com Reported By: rob at apgood dot com -Status: Bogus +Status: Open Bug Type: PHP options/info functions Operating System: Windows Serer 2003 PHP Version: 5.3SVN-2009-10-14 (snap) New Comment: Sorry for the long delay. I rolled back to a prior version that supported mime_content_type(). Now, new functionality requires that I use 5.3 (this same function fails on 5.2, as well). I searched the database and web and found similar descriptions, but none of the "fixes" I discovered worked for me. I stepped up to 5.3.2-dev (which has the php_fileinfo.dll as part of the package), and it did not work, either. Previous Comments: [2009-12-16 19:39:26] paj...@php.net set the extension_dir correctly and use extension=php_fileinfo.dll. Not a bug > bogus. [2009-12-16 19:34:11] rob at apgood dot com in php.ini: extension_dir = "C:\Program Files\PHP\ext" extension=php_fileinfo.dll dependencies: C:\Program Files\PHP\ext\php_fileinfo.dll (exists) output: fileinfo extension is not avaliable, please compile it. [2009-10-22 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-14 17:10:22] paj...@php.net Did you activate the extension via php.ini (see phpinfo();)? -------- [2009-10-14 17:08:37] rob at apgood dot com Description: Installed Windows binaries (php-5.3.0-Win32-VC6-x86.msi) with Fileinfo functions selected to be installed. However, the very simple attached script results in error: [Wed Oct 14 09:43:58 2009] [error] [client 173.10.71.237] PHP Fatal error: Call to undefined function finfo_open() in D:\\Apache\\casetracker\\finfo1.php on line 2 Reproduce code: --- Expected result: a mime-type description of: "image/vnd.microsoft.icon" or (less correctly): "image/x-icon" Actual result: -- in error.log, [Wed Oct 14 09:43:58 2009] [error] [client 173.10.71.237] PHP Fatal error: Call to undefined function finfo_open() in D:\\Apache\\casetracker\\finfo1.php on line 2 -- Edit this bug report at http://bugs.php.net/?id=49878&edit=1
#49878 [Opn]: Fileinfo functions not found
ID: 49878 User updated by: rob at apgood dot com Reported By: rob at apgood dot com Status: Open Bug Type: PHP options/info functions Operating System: Windows Serer 2003 PHP Version: 5.3SVN-2009-10-14 (snap) New Comment: set the extension_dir to "ext" and to the fully-qualified path. same result. Previous Comments: [2009-12-16 19:40:01] rob at apgood dot com Sorry for the long delay. I rolled back to a prior version that supported mime_content_type(). Now, new functionality requires that I use 5.3 (this same function fails on 5.2, as well). I searched the database and web and found similar descriptions, but none of the "fixes" I discovered worked for me. I stepped up to 5.3.2-dev (which has the php_fileinfo.dll as part of the package), and it did not work, either. [2009-12-16 19:39:26] paj...@php.net set the extension_dir correctly and use extension=php_fileinfo.dll. Not a bug > bogus. [2009-12-16 19:34:11] rob at apgood dot com in php.ini: extension_dir = "C:\Program Files\PHP\ext" extension=php_fileinfo.dll dependencies: C:\Program Files\PHP\ext\php_fileinfo.dll (exists) output: fileinfo extension is not avaliable, please compile it. [2009-10-22 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-14 17:10:22] paj...@php.net Did you activate the extension via php.ini (see phpinfo();)? 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/49878 -- Edit this bug report at http://bugs.php.net/?id=49878&edit=1
Bug #52905 [Com]: Curl doesn't work in version 5.2.14
Edit report at http://bugs.php.net/bug.php?id=52905&edit=1 ID: 52905 Comment by: rob at robmacdonald dot com Reported by:lin dot sidney at gmail dot com Summary:Curl doesn't work in version 5.2.14 Status: Feedback Type: Bug Package:Scripting Engine problem Operating System: Windows 7 - 32 bit PHP Version:5.2.14 Block user comment: N New Comment: I am having the same problem. Our setup is Windows Server 2008, IIS7 PHP running through FastCGI. When I try to upgrade from PHP 5.2.13 to 5.2.14 curl is unable to initialise. I've copied the old 5.2.13 curl dll into my 5.2.14 extensions folder and this appears to fix the problem. I didn't need to copy libeay32.dll and ssleay32.dll. Am I missing something? Isn't just copying the 5.2.13 curl dll enough? Previous Comments: [2010-09-22 10:01:50] paj...@php.net Fetch it at http://windows.php.net. [2010-09-22 09:59:34] ahar...@php.net 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. [2010-09-22 09:58:48] lin dot sidney at gmail dot com Description: I tried everything to get version 5.2.14 to work with the built in curl. Nothing worked. I then tried taking the binaries of the 5.2.13 and copied over the php_curl.dll with the 5.2.13 version. Also took the 5.2.13 version of the libeay32.dll and ssleay32.dll and placed it in the Windows/System32 directory. Restarted Apache web server and voila.. curl was working. Actual result: -- I tried everything to get version 5.2.14 to work with the built in curl. Nothing worked. I then tried taking the binaries of the 5.2.13 and copied over the php_curl.dll with the 5.2.13 version. Also took the 5.2.13 version of the libeay32.dll and ssleay32.dll and placed it in the Windows/System32 directory. Restarted Apache web server and voila.. curl was working. -- Edit this bug report at http://bugs.php.net/bug.php?id=52905&edit=1
#36795 [Com]: Inappropriate "unterminated entity reference" in DOMElement->setAttribute
ID: 36795
Comment by: rob at electronicinsight dot com
Reported By: john at carney dot id dot au
Status: No Feedback
Bug Type: DOM XML related
Operating System: Windows/Linux
PHP Version: 5.1.2
New Comment:
A little hack to get around this bug:
function &safe_add_child(&$sxml, $name, $value) {
$safe_value = preg_replace('/&(?!\w+;)/', '&', $value);
return $sxml->addChild($name, $safe_value);
}
Previous Comments:
[2008-02-08 20:09:37] moshe at varien dot com
PHP 5.2.4
Looks like the problem appears when there's node already exists being
overwritten
// works ok, doesn't require encoding:
$a = simplexml_load_string('');
$a->b = "& < ' ";
// doesn't work, requires encoding:
$a = simplexml_load_string('test');
$a->b = "& < ' ";
// doesn't work, always requires encoding
$a->addChild('b', "& < '");
$a->addAttribute('b', "& < '");
// works ok, never requires encoding
$a['b'] = "& < '";
[2007-11-27 14:03:55] oscar at cdcovers dot to
I tried the workaround below and it seems to work:
$xml->addChild('element', '');
$xml->element = str_replace("&", "&", "value of the element");
[2007-09-28 06:40:20] ocus51 at gail dot com
Hi,
I'm still experiencing this problem :
- PHP Version 5.2.0-8+etch7
- DOM/XML API Version 20031129
- libxml Version 2.6.27
[2006-12-06 11:49:37] philippe dot levan_nospam at kitpages dot fr
Hi,
I have the same problem. My config is :
- PHP 5.2
- libxml Version 2.6.16
-
";
$xml = new SimpleXMLElement($xmlStr);
$xml->addChild("foo",utf8_encode("start < > end"));
echo "foo tag added ok";
$xml->addChild("bar",utf8_encode("start & end"));
echo "error on bar tag because of &";
$result = $xml->asXML();
echo "".htmlentities($result)."";
?>
-
you can run this script at :
http://www.kitpages.fr/test/bugSimpleXml.php
[2006-06-19 14:30:10] php dot net at jax dot be
In PHP 4.2.2 I have the same issue.
create_element("message");
$msg->set_attribute("type", "MT");
$doc->append_child($msg);
$auth = $doc->create_element("authentication");
$str = "abc < d & e > f";
$auth->set_content($str);
$msg->append_child($auth);
echo "";
echo $doc->dump_mem(true, "UTF-8");
echo "";
?>
It chokes on the &.
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/36795
--
Edit this bug report at http://bugs.php.net/?id=36795&edit=1
#35096 [NEW]: php 4.4.2-dev has still trouble with mod_rewrite/apache2
From: rob at burningsoda dot com Operating system: FreeBSD 6.0RC1 PHP version: 4CVS-2005-11-04 (snap) PHP Bug Type: Apache2 related Bug description: php 4.4.2-dev has still trouble with mod_rewrite/apache2 Description: I just downloaded Stable (4.4.x-dev) Built On: Nov 03, 2005 23:51 GMT and built it: PHP 4.4.2-dev (cli) (built: Nov 4 2005 02:17:10) But it seems like, the following bug is _not_ fixed in that snapshot: http://bugs.php.net/bug.php?id=35059 This happens with _any_ RewriteRule I use. Reproduce code: --- Try to use mod_rewrite on Apache 2.x to modify any URL. Small test case: index.php: RewriteRule: RewriteRule ^(.+)/$ index.php?myarg=$1 [L] URLs to try: 1. http://localhost/index.php?myarg=bla 2. http://localhost/blub/ 3. http://localhost/index.php/ Expected result: In all three cases a document should be delivered: 1. "bla" 2. "blub" 3. "index.php" Actual result: -- 1. Correctly delivers document. 2. No document is delivered. 3. Correctly delivers document. -- Edit bug report at http://bugs.php.net/?id=35096&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35096&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=35096&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=35096&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=35096&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=35096&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35096&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=35096&r=needscript Try newer version: http://bugs.php.net/fix.php?id=35096&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35096&r=support Expected behavior: http://bugs.php.net/fix.php?id=35096&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35096&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35096&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=35096&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35096&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=35096&r=dst IIS Stability: http://bugs.php.net/fix.php?id=35096&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35096&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35096&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35096&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=35096&r=mysqlcfg
#35096 [Fbk->Opn]: php 4.4.2-dev has still trouble with mod_rewrite/apache2
ID: 35096 User updated by: rob at burningsoda dot com Reported By: rob at burningsoda dot com -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: FreeBSD 6.0RC1 PHP Version: 4CVS-2005-11-04 (snap) New Comment: sniper, This problem occurs only when using PHP 4.4.1 and the PHP 4-snapshots _and_ apache 2.x. Why should I try a 5.x-snapshot? Do I misunderstand you? Previous Comments: [2005-11-04 09:25:24] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-11-04 02:49:53] rob at burningsoda dot com Description: I just downloaded Stable (4.4.x-dev) Built On: Nov 03, 2005 23:51 GMT and built it: PHP 4.4.2-dev (cli) (built: Nov 4 2005 02:17:10) But it seems like, the following bug is _not_ fixed in that snapshot: http://bugs.php.net/bug.php?id=35059 This happens with _any_ RewriteRule I use. Reproduce code: --- Try to use mod_rewrite on Apache 2.x to modify any URL. Small test case: index.php: RewriteRule: RewriteRule ^(.+)/$ index.php?myarg=$1 [L] URLs to try: 1. http://localhost/index.php?myarg=bla 2. http://localhost/blub/ 3. http://localhost/index.php/ Expected result: In all three cases a document should be delivered: 1. "bla" 2. "blub" 3. "index.php" Actual result: -- 1. Correctly delivers document. 2. No document is delivered. 3. Correctly delivers document. -- Edit this bug report at http://bugs.php.net/?id=35096&edit=1
#35096 [Fbk->Opn]: php 4.4.2-dev has still trouble with mod_rewrite/apache2
ID: 35096
User updated by: rob at burningsoda dot com
Reported By: rob at burningsoda dot com
-Status: Feedback
+Status: Open
Bug Type: Apache2 related
Operating System: FreeBSD 6.0RC1
PHP Version: 4CVS-2005-11-04 (snap)
New Comment:
doh!
PHP 5.1.0RC5-dev (cli) (built: Nov 6 2005 03:52:41)
I just tried a php5-snapshot. Same problem here. :(
Previous Comments:
[2005-11-06 00:16:33] sergeym at hoster dot ru
PHP 4.4.1 with patch from FreeBSD team works fine (seems to...). But,
if add some module(s) - it works again as described in bugreport. M'be
order of modules in list is important...
--- sapi/apache2handler/sapi_apache2.c.orig Thu Nov 3 10:13:33
2005
+++ sapi/apache2handler/sapi_apache2.c Thu Nov 3 10:14:41 2005
@@ -535,7 +535,7 @@
if (!parent_req) {
parent_req = ctx->r;
}
- if (parent_req && strcmp(parent_req->handler,
PHP_MAGIC_TYPE) && strcmp(parent_req->handler, PHP_SOURCE_MAGIC_TYPE)
&& strcmp(parent_req->h
andler, PHP_SCRIPT)) {
+ if (parent_req && parent_req->handler &&
strcmp(parent_req->handler, PHP_MAGIC_TYPE) &&
strcmp(parent_req->handler, PHP_SOURCE_MAGIC_TYPE)
&& strcmp(parent_req->handler, PHP_SCRIPT)) {
if (php_apache_request_ctor(r, ctx
TSRMLS_CC)!=SUCCESS) {
zend_bailout();
}
[2005-11-05 09:45:15] tmelzer at tomesoft dot de
Further analyzes have shown me that the fix in 4.4.x-dev was in
sapi/apache2handler/sapi_apache2.c in function php_handler to guard
against the member 'handler' on struct request_rec of beeing NULL and
then accessing it. This was fixed in only one case where around line
518
'if (parent_req && parent_req->handler && ...'. After I added an
r->handler && strcmp ... to the other places where the structure member
is used the crash went away but I got a 404 - file not found error. I
think this is related to the fact that I'm not sure what to do if
several of this if () statements are evalute false i.e. what to place
in the else block.
[2005-11-04 22:57:08] [EMAIL PROTECTED]
I want you to try the PHP 5 snapshot because I want to be sure this is
only happening with PHP 4. In which case we have better chance of
figuring out what fix to backport from PHP 5.
On the other hand, if this also happens with PHP 5, we really need to
know since we're about to release PHP 5.1 and it would be nice to fix
this kind of things before the release..
[2005-11-04 20:04:37] rob at burningsoda dot com
sniper,
This problem occurs only when using PHP 4.4.1 and the PHP 4-snapshots
_and_ apache 2.x. Why should I try a 5.x-snapshot? Do I misunderstand
you?
[2005-11-04 09:25:24] [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/35096
--
Edit this bug report at http://bugs.php.net/?id=35096&edit=1
#35096 [Fbk->Opn]: still trouble with mod_rewrite/apache2
ID: 35096
User updated by: rob at burningsoda dot com
Reported By: rob at burningsoda dot com
-Status: Feedback
+Status: Open
Bug Type: Apache2 related
Operating System: *
PHP Version: 5CVS, 4CVS (2005-11-04) (snap)
New Comment:
After rebuilding Apache2 and PHP5-dev on different machines the whole
weekend about 2 million times and wondering why some showed the bug,
some not, I eventually tracked it down to the following simple
configuration setting (*drum roll*):
*** output_buffering ***
To trigger the bug, set "output_buffering = On" or (e.g.)
"output_buffering = 4096", TO BYPASS THE BUG (listen up, bug plagued
Joomla!/Wordpress/etc. users) SET "output_buffering = Off" in your
php.ini. This bypass works for PHP 4 & 5.
Cheers,
rob.
PS: If I extend my testcase to
with "output_buffering = Off" that still does _not_ trigger the bug.
Maybe that helps.
Previous Comments:
[2005-11-07 08:11:59] scott at whitetigerphotography dot com
Having an identical problem on FreeBSD 4.11-release-p13 with the latest
version from ports (PHP 4.4.1 (cli) (built: Nov 6 2005 23:03:29))
(patched with the original CVS fix for this bug but that doesn't fix
it)
This too happens for any rewrite rule used for PHP. I use rewrite rules
for almost all of my production sites and they have all stopped working,
except for one which uses a CGI script instead. Affects software like
Mambo (Joomla) with SEF enabled and Gallery
Examples for rewrite reproduce code (from gallery):
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^\.\?/]+)/([0-9]+)$
/view_photo.php?set_albumName=$1&index=$2 [QSA]
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^\.\?/]+)/([A-Za-z_0-9\-]+)$
/view_photo.php?set_albumName=$1&id=$2 [QSA]
Result:
Blank pages most of the time but in the case of gallery... occasional
parts of pages for some reason. No errors found in PHP or Apache logs
[2005-11-07 07:30:34] tmelzer at tomesoft dot de
On SuSE 9.1
with apache 2.0.55
and php-4.4.x-dev with shared modules in this order
- cryptopp
- bz2
- imap
- exif
- mime_magic
- dba
- zlib
- gd
- sockets
- curl
- iconv
- xslt
- mysql
- interbase
- session
.htaccess
RewriteEngine On
RewriteBase /shop/
RewriteRule ^irw_(.*)\.html index.php?param=$1
[2005-11-06 22:41:36] free4cd at yahoo dot de
Same Problem with PHP 4.4.1 and 5.1 snapshots.
If rewrite is enabled you get a blank page. No error in log file or
else.
Problem with Joomla and vBulletin/vBSEO if rewrite engine is turned on.
If rewrite is disabled all works fine.
My .htaccess for Joomla:
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) index.php
[2005-11-06 19:47:49] remko at elvandar dot org
I had similiar problems with apache2+mod_rewrite and php
4.4.1. All sites that made use of mod_rewrite broke and gave
a white page (nothing in the error log though), all other
sites that use php but not mod_rewrite were working
perfectly.
my .htaccess:
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) index.php
[2005-11-06 16:29:08] brian dot white at foxfire74 dot com
I have a WordPress powerered blog and get it for ANY rewrite rule.
Here is a stripped down version of my .htaccess:
---
# BEGIN WordPress
RewriteEngine On
RewriteBase /blog/
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [S=75]
RewriteRule ^search/(.+)/?$ /blog/index.php?s=$1 [QSA,L]
RewriteRule ^category/(.+)/?$ /blog/index.php?category_name=$1 [QSA,L]
RewriteRule ^author/([^/]+)/?$ /blog/index.php?author_name=$1 [QSA,L]
RewriteRule ^([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/?$
/blog/index.php?year=$1&monthnum=$2&day=$3 [QSA,L]
RewriteRule ^([0-9]{4})/([0-9]{1,2})/?$
/blog/index.php?year=$1&monthnum=$2 [QSA,L]
RewriteRule ^([0-9]{4})/?$ /blog/index.php?year=$1 [QSA,L]
RewriteRule ^([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/([^/]+)(/[0-9]+)?/?$
/blog/index.php?year=$1&monthnum=$2&day=$3&name=$4&page=$5 [QSA,L]
# END WordPress
Here what was requested in the browser:
--
http://.../blog/2005/10/31/happy-halloween/
Here is what shows up in the logs:
-
[Mon Oct 31 23:25:42 2005] [error] PHP Warning:
main(./wp-blog-header.php): failed to open stream: No such file or
directory in C:\\...\\wordpress\\in
#35096 [Opn]: still trouble with mod_rewrite/apache2
ID: 35096
User updated by: rob at burningsoda dot com
Reported By: rob at burningsoda dot com
Status: Open
Bug Type: Apache2 related
Operating System: *
PHP Version: 5CVS, 4CVS (2005-11-04) (snap)
New Comment:
As a further note, $_SERVER['PHP_SELF'] contains "/phpbug/index.php/"
if URL-rewriting took place while $_SERVER['SCRIPT_NAME'] correctly
returns "/phpbug/index.php". This happens even with output buffering
disabled and leads to the conclusion, that the original bug is not in
the buffering code.
Beware! This fact (PHP_SELF != SCRIPT_NAME or PHP_SELF nonexistant) can
lead to extremely subtle bugs.
Previous Comments:
----
[2005-11-07 12:35:21] rob at burningsoda dot com
After rebuilding Apache2 and PHP5-dev on different machines the whole
weekend about 2 million times and wondering why some showed the bug,
some not, I eventually tracked it down to the following simple
configuration setting (*drum roll*):
*** output_buffering ***
To trigger the bug, set "output_buffering = On" or (e.g.)
"output_buffering = 4096", TO BYPASS THE BUG (listen up, bug plagued
Joomla!/Wordpress/etc. users) SET "output_buffering = Off" in your
php.ini. This bypass works for PHP 4 & 5.
Cheers,
rob.
PS: If I extend my testcase to
with "output_buffering = Off" that still does _not_ trigger the bug.
Maybe that helps.
[2005-11-07 08:11:59] scott at whitetigerphotography dot com
Having an identical problem on FreeBSD 4.11-release-p13 with the latest
version from ports (PHP 4.4.1 (cli) (built: Nov 6 2005 23:03:29))
(patched with the original CVS fix for this bug but that doesn't fix
it)
This too happens for any rewrite rule used for PHP. I use rewrite rules
for almost all of my production sites and they have all stopped working,
except for one which uses a CGI script instead. Affects software like
Mambo (Joomla) with SEF enabled and Gallery
Examples for rewrite reproduce code (from gallery):
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^\.\?/]+)/([0-9]+)$
/view_photo.php?set_albumName=$1&index=$2 [QSA]
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^\.\?/]+)/([A-Za-z_0-9\-]+)$
/view_photo.php?set_albumName=$1&id=$2 [QSA]
Result:
Blank pages most of the time but in the case of gallery... occasional
parts of pages for some reason. No errors found in PHP or Apache logs
[2005-11-07 07:30:34] tmelzer at tomesoft dot de
On SuSE 9.1
with apache 2.0.55
and php-4.4.x-dev with shared modules in this order
- cryptopp
- bz2
- imap
- exif
- mime_magic
- dba
- zlib
- gd
- sockets
- curl
- iconv
- xslt
- mysql
- interbase
- session
.htaccess
RewriteEngine On
RewriteBase /shop/
RewriteRule ^irw_(.*)\.html index.php?param=$1
[2005-11-06 22:41:36] free4cd at yahoo dot de
Same Problem with PHP 4.4.1 and 5.1 snapshots.
If rewrite is enabled you get a blank page. No error in log file or
else.
Problem with Joomla and vBulletin/vBSEO if rewrite engine is turned on.
If rewrite is disabled all works fine.
My .htaccess for Joomla:
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) index.php
[2005-11-06 19:47:49] remko at elvandar dot org
I had similiar problems with apache2+mod_rewrite and php
4.4.1. All sites that made use of mod_rewrite broke and gave
a white page (nothing in the error log though), all other
sites that use php but not mod_rewrite were working
perfectly.
my .htaccess:
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) index.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/35096
--
Edit this bug report at http://bugs.php.net/?id=35096&edit=1
#35096 [Fbk->Opn]: using mod_rewrite with apache2 crashes
ID: 35096 User updated by: rob at burningsoda dot com Reported By: rob at burningsoda dot com -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: * PHP Version: 5CVS, 4CVS (2005-11-04) (snap) New Comment: [EMAIL PROTECTED]:~/web/devel/phpbug> diff /usr/local/etc/php.ini-dist /usr/local/etc/php.ini 94c94 < output_buffering = Off --- > output_buffering = 4096 :) Previous Comments: [2005-11-07 15:42:09] [EMAIL PROTECTED] It isn't that setting. Everything works just fine for me even when I have output_buffering=4096 (default in php.ini-recommended) Try making a diff of your php.ini against the "base" php.ini-* found in the snapshot. [2005-11-07 12:35:21] rob at burningsoda dot com After rebuilding Apache2 and PHP5-dev on different machines the whole weekend about 2 million times and wondering why some showed the bug, some not, I eventually tracked it down to the following simple configuration setting (*drum roll*): *** output_buffering *** To trigger the bug, set "output_buffering = On" or (e.g.) "output_buffering = 4096", TO BYPASS THE BUG (listen up, bug plagued Joomla!/Wordpress/etc. users) SET "output_buffering = Off" in your php.ini. This bypass works for PHP 4 & 5. Cheers, rob. PS: If I extend my testcase to with "output_buffering = Off" that still does _not_ trigger the bug. Maybe that helps. [2005-11-06 15:52:48] [EMAIL PROTECTED] Exactly how can we reproduce this? It works just fine for me when I have this .htaccess file: RewriteEngine on RewriteRule ^(.+)/$ index.php?myarg=$1 [L] So what else do we need? ---- [2005-11-06 04:01:51] rob at burningsoda dot com doh! PHP 5.1.0RC5-dev (cli) (built: Nov 6 2005 03:52:41) I just tried a php5-snapshot. Same problem here. :( [2005-11-04 22:57:08] [EMAIL PROTECTED] I want you to try the PHP 5 snapshot because I want to be sure this is only happening with PHP 4. In which case we have better chance of figuring out what fix to backport from PHP 5. On the other hand, if this also happens with PHP 5, we really need to know since we're about to release PHP 5.1 and it would be nice to fix this kind of things before the release.. 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/35096 -- Edit this bug report at http://bugs.php.net/?id=35096&edit=1
#35096 [Fbk->Opn]: using mod_rewrite with apache2 crashes
ID: 35096 User updated by: rob at burningsoda dot com Reported By: rob at burningsoda dot com -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: * PHP Version: 5CVS, 4CVS (2005-11-04) (snap) New Comment: sniper, To quickly reproduce the bug on FreeBSD 6.0, I do the following: 1. Install Apache 2.0.55 using FreeBSD ports 2. Install PHP 5.0.5 using FreeBSD ports --> The bug does _not_ show up. (If I had installed 4.4.1 from ports, it would) 4. Get a 5-dev snapshot (the last one I got is of 2005-11-06) and do this: ./configure\ --enable-versioning\ --enable-memory-limit\ --with-layout=GNU\ --with-config-file-scan-dir=/usr/local/etc/php\ --disable-all\ --enable-libxml --with-libxml-dir=/usr/local\ --enable-spl\ --with-apxs2=/usr/local/sbin/apxs\ --prefix=/usr/local\ i386-portbld-freebsd6.0 &&\ make clean &&\ make &&\ cp libs/libphp5.so /usr/local/libexec/apache2 &&\ /usr/local/etc/rc.d/apache2.sh restart --> there it is. The configure arguments are the standard arguments of the FreeBSD build system, but I do _not_ apply any of the FreeBSD-specific patches, they deliver (and which got included in the build in step 2). So, either the bug was introduced after 5.0.5 or one of the patches (have a look at them here: http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/php5/files/) fixes it (which I personally don't think). Cheers, Rob. Previous Comments: [2005-11-08 01:26:50] Chris at Epler dot net FreeBSD 4.11, Apache 2.0.55 Immediately after upgrading the PHP package from ports I get blank pages from Gallery integrated into Drupal which is using mod_rewrite. 4.4.0 did not have this issue and no other config file changes were made. [2005-11-07 20:17:13] free4cd at yahoo dot de Same problem on SuSE 9.3 and Apache 2.0.55 and 4.x and 5.x snapshots on i386. I've compiled Apache by hand and used the SuSE rpm's but I get the same error (blank page). I've also tried the php.ini-recommended and php.ini-dist without changes and it don't work. With 4.4.0 all works fine but since release of 4.4.1 and later snapshots (4.x and 5.x) mod_rewrite fails. [2005-11-07 18:25:00] remko at elvandar dot org For the information/record: I used FreeBSD 5.4 and FreeBSD 6.0 on i386 hardware. [2005-11-07 17:18:49] jd at ods dot org I'm having issues on i386/FreeBSD 4.11 [2005-11-07 16:50:31] sergeym at hoster dot ru May be it's platform-depend bug? I have errors on AMD64/FreeBSD. 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/35096 -- Edit this bug report at http://bugs.php.net/?id=35096&edit=1
#38839 [NEW]: wddx_serialize_value() broken in 4.4.3 and greater.
From: rob at choralone dot org Operating system: Linux PHP version: 4.4.4 PHP Bug Type: WDDX related Bug description: wddx_serialize_value() broken in 4.4.3 and greater. Description: wddx_serialize_value() produces bad wddx data when serializing an associative array. This first started happening with PHP 4.4.3, so I suspect the fix for bug #37569 (WDDX incorrectly encodes high-ascii characters) probably broke it. Reproduce code: --- 'bar'); print(wddx_serialize_value($data)); ?> Expected result: bar run through xml tidy to make it readable: bar Actual result: -- bar run through xml tidy to make it readable: bar -- Edit bug report at http://bugs.php.net/?id=38839&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38839&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38839&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38839&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38839&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38839&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38839&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38839&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38839&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38839&r=support Expected behavior:http://bugs.php.net/fix.php?id=38839&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38839&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38839&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38839&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38839&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38839&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38839&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38839&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38839&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38839&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38839&r=mysqlcfg
#38839 [Fbk->Opn]: wddx_serialize_value() broken in 4.4.3 and greater.
ID: 38839
User updated by: rob at choralone dot org
Reported By: rob at choralone dot org
-Status: Feedback
+Status: Open
Bug Type: WDDX related
Operating System: Linux
PHP Version: 4.4.4
New Comment:
Yes, that's fixed it - thank you.
For anyone else interested, this is the patch I'm bundling in our
company RPM build of php 4.4.4 that fixes the issue:
--- php-4.4.4/ext/wddx/wddx.c 2006-05-26 02:55:26.0 +0100
+++ php-4.4.4/ext/wddx/wddx-new.c 2006-08-24 09:32:37.0
+0100
@@ -16,7 +16,7 @@
+--+
*/
-/* $Id: wddx.c,v 1.96.2.6.2.7 2006/05/26 01:55:26 iliaa Exp $ */
+/* $Id: wddx.c,v 1.96.2.6.2.8 2006/08/24 08:30:28 tony2001 Exp $ */
#ifdef HAVE_CONFIG_H
#include "config.h"
@@ -432,7 +432,7 @@
tmp = *var;
zval_copy_ctor(&tmp);
convert_to_string(&tmp);
- snprintf(tmp_buf, Z_STRLEN(tmp), WDDX_NUMBER, Z_STRVAL(tmp));
+ snprintf(tmp_buf, sizeof(tmp_buf), WDDX_NUMBER,
Z_STRVAL(tmp));
zval_dtor(&tmp);
php_wddx_add_chunk(packet, tmp_buf);
@@ -630,8 +630,8 @@
if (name) {
name_esc = php_escape_html_entities(name, name_len,
&name_esc_len, 0, ENT_QUOTES, NULL TSRMLS_CC);
- tmp_buf = emalloc(name_esc_len + 1);
- snprintf(tmp_buf, name_esc_len, WDDX_VAR_S, name_esc);
+ tmp_buf = emalloc(name_esc_len + sizeof(WDDX_VAR_S));
+ snprintf(tmp_buf, name_esc_len + sizeof(WDDX_VAR_S),
WDDX_VAR_S, name_esc);
php_wddx_add_chunk(packet, tmp_buf);
efree(tmp_buf);
efree(name_esc);
Previous Comments:
[2006-09-15 10:04:36] [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
----
[2006-09-15 09:56:43] rob at choralone dot org
Description:
wddx_serialize_value() produces bad wddx data when serializing an
associative array.
This first started happening with PHP 4.4.3, so I suspect the fix for
bug #37569 (WDDX incorrectly encodes high-ascii characters) probably
broke it.
Reproduce code:
---
'bar');
print(wddx_serialize_value($data));
?>
Expected result:
bar
run through xml tidy to make it readable:
bar
Actual result:
--
bar
run through xml tidy to make it readable:
bar
--
Edit this bug report at http://bugs.php.net/?id=38839&edit=1
#39368 [NEW]: Preset Dictionary support is missing
From: rob at wyrick dot org Operating system: Irrelevant PHP version: 5.2.0 PHP Bug Type: Zlib Related Bug description: Preset Dictionary support is missing Description: zlib allows you to specify dictionaries to be used while inflating or deflating. The php APIs are lacking this functionality. Properly picked dictionaries can VASTLY improve your compression ratio. My company is doing this, but I can't use PHP to access the database due to this missing feature in PHP's zlib API. -- Edit bug report at http://bugs.php.net/?id=39368&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39368&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39368&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39368&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39368&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39368&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39368&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39368&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39368&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39368&r=support Expected behavior:http://bugs.php.net/fix.php?id=39368&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39368&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39368&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39368&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39368&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39368&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39368&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39368&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39368&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39368&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39368&r=mysqlcfg
#39549 [NEW]: Cannot connect to remote databases
From: rob at beagrie dot com
Operating system: Windows Vista RC2
PHP version: 5.2.0
PHP Bug Type: MySQL related
Bug description: Cannot connect to remote databases
Description:
mysql_connect fails to connect to any remote MySQL databases under Vista
RC2 running PHP 5.2 and apache 2.2 (even with all firewalls etc turned
off), but the same script works on XP and will connect to localhost. Bug
also reported (by someone else) at the MySQL bug database:
http://bugs.mysql.com/bug.php?id=24212
Seems likely to be a security issue in vista but I thought I should flag
it up since it could become a problem once more people start to switch.
Reproduce code:
---
if ($sdbc = mysql_connect($host, $user, $pass)) {
echo "database selected";
} else {
echo"Could not connect to MySQL!MySQL Error: " . mysql_error();
}
Expected result:
database selected
Actual result:
--
Warning: mysql_connect() [function.mysql-connect]: Can't connect to MySQL
server on '' (10060) in on line 16
--
Edit bug report at http://bugs.php.net/?id=39549&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39549&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39549&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39549&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39549&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39549&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39549&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39549&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39549&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39549&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39549&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39549&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39549&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39549&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39549&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39549&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39549&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39549&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39549&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39549&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39549&r=mysqlcfg
#39549 [Bgs]: Cannot connect to remote databases
ID: 39549
User updated by: rob at beagrie dot com
Reported By: rob at beagrie dot com
Status: Bogus
Bug Type: MySQL related
Operating System: Windows Vista RC2
PHP Version: 5.2.0
New Comment:
It isn't a bug per se, but as I say I thought someone in development
should be notified that there is an issue here, so this seemed a more
appropriate venue than any of the ones listed on the support page.
Anyway if you're happy that this is a problem at the microsoft end
thats fine.
Previous Comments:
[2006-11-17 19:11:08] [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.
[2006-11-17 18:28:26] rob at beagrie dot com
Description:
mysql_connect fails to connect to any remote MySQL databases under
Vista RC2 running PHP 5.2 and apache 2.2 (even with all firewalls etc
turned off), but the same script works on XP and will connect to
localhost. Bug also reported (by someone else) at the MySQL bug
database: http://bugs.mysql.com/bug.php?id=24212
Seems likely to be a security issue in vista but I thought I should
flag it up since it could become a problem once more people start to
switch.
Reproduce code:
---
if ($sdbc = mysql_connect($host, $user, $pass)) {
echo "database selected";
} else {
echo"Could not connect to MySQL!MySQL Error: " . mysql_error();
}
Expected result:
database selected
Actual result:
--
Warning: mysql_connect() [function.mysql-connect]: Can't connect to
MySQL server on '' (10060) in on line 16
--
Edit this bug report at http://bugs.php.net/?id=39549&edit=1
#41823 [NEW]: Pattern causing crash
From: rob at gravityswitch dot com
Operating system: FreeBSD 6.2-RELEASE-p1
PHP version: 5.2.3
PHP Bug Type: PCRE related
Bug description: Pattern causing crash
Description:
This problem showed up after an upgrade to php 5.2.3 that was accompanied
by a pcre upgrade to ver 7.0. It works fine on my local system (php 5.2.3,
pcre 6.7)
The browser returns a download dialog rather than an error.
If I remove the "=" from the pattern, it works, but doesn't find
anything.
Reproduce code:
---
|(?:\/>)))";
$formHTML = "Nothing to see here:";
echo preg_replace("/" . $s . "/is", "muffin", $formHTML);
?>
Expected result:
I would expect this code to replace the input tag string with "muffin". I
would also expect it not to crash.
Actual result:
--
Download dialog box.
--
Edit bug report at http://bugs.php.net/?id=41823&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41823&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41823&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41823&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41823&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41823&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41823&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41823&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41823&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41823&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41823&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41823&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41823&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41823&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41823&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41823&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41823&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41823&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41823&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41823&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41823&r=mysqlcfg
#34047 [Com]: When compile php cannot generate libphp5.so
ID: 34047 Comment by: rob at silverarcher dot com Reported By: calvinscy at hotmail dot com Status: No Feedback Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 5.0.4 New Comment: The problem still seems to be occurring. php-5.0.4 and php- latest both will not compile the libphp5.so. I'm hoping sunfreeware.com can help... Previous Comments: [2005-08-17 01:00:03] 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-08-09 10:21:22] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-08-09 09:47:08] calvinscy at hotmail dot com Description: When compiling the php5.0.4 download from your site, it cannot generate a file called libphp5.so. But if I download php-5.0.4.tar.gz from sunfreeware.com it can. After "make install" completed I can see the libphp5.so created under apache2/modules directory. I try the php4 from your site as well, it cannot generate libphp5.so too! -- Edit this bug report at http://bugs.php.net/?id=34047&edit=1
#34047 [Com]: When compile php cannot generate libphp5.so
ID: 34047 Comment by: rob at silverarcher dot com Reported By: calvinscy at hotmail dot com Status: No Feedback Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 5.0.4 New Comment: sunfreeware doesn't work either. I'm using Fedora Core 4 and cannot get this one part to compile. Previous Comments: [2005-08-28 21:12:45] rob at silverarcher dot com The problem still seems to be occurring. php-5.0.4 and php- latest both will not compile the libphp5.so. I'm hoping sunfreeware.com can help... [2005-08-17 01:00:03] 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-08-09 10:21:22] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-08-09 09:47:08] calvinscy at hotmail dot com Description: When compiling the php5.0.4 download from your site, it cannot generate a file called libphp5.so. But if I download php-5.0.4.tar.gz from sunfreeware.com it can. After "make install" completed I can see the libphp5.so created under apache2/modules directory. I try the php4 from your site as well, it cannot generate libphp5.so too! -- Edit this bug report at http://bugs.php.net/?id=34047&edit=1
[PHP-BUG] Bug #64162 [NEW]: Extra characters added to base64_decode() output
From: rob at neovidamedia dot com
Operating system: Windows 7
PHP version: Irrelevant
Package: *Encryption and hash functions
Bug Type: Bug
Bug description:Extra characters added to base64_decode() output
Description:
---
>From manual page: http://www.php.net/function.base64-decode
---
Run this code, and notice the output for 'Decoded' -- it looks the same as
'Original', but it is not. Select it (the result), copy it, and paste it
into
notepad or something, and you will see a bonus character at the end.
It seems to be related to the string length of $a, and the fact that it
contains
a
number at its end, but I could be wrong. I ran about one hundred different
scenario tests, and got some funky results.
PS - I am running PHP 5.2.17, but that is what my host offers. Don't think
I
can upgrade on my own ...
Test script:
---
$a = "Proteussing88";
function randLetter()
{
$int = rand(0,61);
$a_z =
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890";
$rand_letter = $a_z[$int];
return $rand_letter;
}
$pass = randLetter() . base64_encode($a) . randLetter() . randLetter() .
randLetter();
$db_pass = base64_decode(substr($pass, 1, (strlen($pass) - 2)));
$final = substr($db_pass, 0, (strlen($db_pass) - 1));
echo 'Original: ' . $a . 'Encoded: ' . $pass . 'Decoded: ' .
$final;
Expected result:
The visual result is fine, but in the background a special character is
being
added to the final string variable.
Actual result:
--
The final string variable looks right, but only in a browser. Paste it
into
notepad or any other text editor, and you get an unexpected special
character at
its end.
--
Edit bug report at https://bugs.php.net/bug.php?id=64162&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64162&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64162&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64162&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64162&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64162&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64162&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64162&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64162&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64162&r=support
Expected behavior: https://bugs.php.net/fix.php?id=64162&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64162&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64162&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64162&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64162&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64162&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64162&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64162&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64162&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64162&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64162&r=mysqlcfg
Bug #64162 [Nab]: Extra characters added to base64_decode() output
Edit report at https://bugs.php.net/bug.php?id=64162&edit=1
ID: 64162
User updated by: rob at neovidamedia dot com
Reported by: rob at neovidamedia dot com
Summary:Extra characters added to base64_decode() output
Status: Not a bug
Type: Bug
Package:*Encryption and hash functions
Operating System: Windows 7
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Actually, the code I have written works in most instances. There are a handful
that don't work, such as the sample that I have provided ($a =
"Proteussing88";). As per substr(): strlen will give you the length of a
string
where the first character is character 1 -- in substr() positions start with
the
first character being in position 0 (like an array). Hence, I don't think that
I have to remove 2 characters, or 4. I could be wrong as I am not an expert
professional, but I have consulted a couple of other programmers, both of whom
are much better than I, and they can't solve this either.
Believe me, this code works 95%+ of the time. Please refer to this part of the
description:
"It seems to be related to the string length of $a, and the fact that it
contains a number at its end, but I could be wrong."
Also, I upgraded PHP to 5.3 and this piece of code still failed.
As far as I can tell this is still a bug.
Previous Comments:
[2013-02-06 16:02:34] ras...@php.net
You can't arbitrarily add random characters to the base64-encoded string and
expect to get sensible output. You are adding 1 char before and 3 after to your
encoded string, but then you do base64_decode(substr($pass, 1, (strlen($pass) -
2))) meaning you only remove 2 of those appended chars before you decode. Make
that strlen()-3 and your problems go away. The fact that it differs across
versions is irrelevant since you are not passing in a valid base64 encoded
string.
[2013-02-06 16:00:19] bobwei9 at hotmail dot com
But whatever; there is also an error in your script:
$final = base64_decode(substr($pass, 1, (strlen($pass) - 4)));
would be right.
However, somewhere between 5.3.15 and trunk, base64_decode()-handling of
invalid characters (after the last =) has changed...
[2013-02-06 15:52:17] bobwei9 at hotmail dot com
Effectively. On PHP 5.3 there is a byte with \x02 and on trunk \x07...
Alone this difference must be a bug...
--------
[2013-02-06 11:10:30] rob at neovidamedia dot com
Description:
---
>From manual page: http://www.php.net/function.base64-decode
---
Run this code, and notice the output for 'Decoded' -- it looks the same as
'Original', but it is not. Select it (the result), copy it, and paste it into
notepad or something, and you will see a bonus character at the end.
It seems to be related to the string length of $a, and the fact that it
contains
a
number at its end, but I could be wrong. I ran about one hundred different
scenario tests, and got some funky results.
PS - I am running PHP 5.2.17, but that is what my host offers. Don't think I
can upgrade on my own ...
Test script:
---
$a = "Proteussing88";
function randLetter()
{
$int = rand(0,61);
$a_z = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890";
$rand_letter = $a_z[$int];
return $rand_letter;
}
$pass = randLetter() . base64_encode($a) . randLetter() . randLetter() .
randLetter();
$db_pass = base64_decode(substr($pass, 1, (strlen($pass) - 2)));
$final = substr($db_pass, 0, (strlen($db_pass) - 1));
echo 'Original: ' . $a . 'Encoded: ' . $pass . 'Decoded: ' . $final;
Expected result:
The visual result is fine, but in the background a special character is being
added to the final string variable.
Actual result:
--
The final string variable looks right, but only in a browser. Paste it into
notepad or any other text editor, and you get an unexpected special character
at
its end.
--
Edit this bug report at https://bugs.php.net/bug.php?id=64162&edit=1
Bug #60462 [Com]: When APC is enabled segfault
Edit report at https://bugs.php.net/bug.php?id=60462&edit=1 ID: 60462 Comment by: un+phpbugs at rob dot mx Reported by:henrik at bjrnskov dot dk Summary:When APC is enabled segfault Status: Open Type: Bug Package:FPM related Operating System: Mac OS X 10.7 PHP Version:5.4.0RC2 Block user comment: N Private report: N New Comment: I can confirm the same issue on Mac OS X 10.7, APC 3.1.9 and PHP 5.4.0 . Installing from trunk helps, but the logging of the error persists. Previous Comments: [2012-01-12 20:04:04] josh at joshbutts dot com Happens also in 5.4RC5 with APC from pecl on OSX 10.7.3 [2011-12-28 15:50:26] henrik at bjrnskov dot dk Just tried compiling a 5.4RC4 manually and installing apc from svn and pecl. both php-fpm and apache2 module segfaults. OS X Lion 10.7.3 [2011-12-17 11:14:35] lolautruche at gmail dot com Here : http://svn.php.net/repository/pecl/apc/ [2011-12-17 11:10:53] henrik at bjrnskov dot dk Where is apc svn ? [2011-12-16 17:55:26] lolautruche at gmail dot com no more segfault with latest php 5.4 build and APC built from trunk 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=60462 -- Edit this bug report at https://bugs.php.net/bug.php?id=60462&edit=1
#42291 [Opn]: Uploaded file permissions vary depending on file system configuration
ID: 42291 User updated by: rob-phpbugs at tigertech dot com Reported By: rob-phpbugs at tigertech dot com Status: Open Bug Type: Filesystem function related Operating System: Linux -PHP Version: 4.4.7 +PHP Version: 5.2.4 New Comment: I fear this bug could be ignored because I tagged it as happening on PHP 4. Just to make sure it's clear, I'm retagging it as happening in PHP 5.2.4 -- it affects all versions. Previous Comments: [2007-11-04 17:16:19] marcel dot wiechmann at gmail dot com Same problem here. But not only under php 4.4.7 also under php 5.2.4 [2007-11-04 15:51:26] chh at innov8 dot ch I can confirm this behaviour. If "upload_tmp_dir" is on the same filesystem as the destination folder (normally the webspace of the customer(s) then the file permissions are set to 0600 - otherwise 0644 (umask at 0022), when using move_uploaded_file(). The temp file - before calling move_uploaded_file() - also has 0600 permissions. This leads to a problem when using suphp (suexec, fastcgi or whatever) and upload-functions in php applications which do not set the permissions after using move_uploaded_file() [Joomla seems to be such a candidate - Typo3 does it right..]. If you upload a static file which should be readable by the webserver but isn't because only PHP (and other user running applications) can access the file. All Upload functions should use a chmod() after move_uploded_file()... ---- [2007-08-14 03:50:47] rob-phpbugs at tigertech dot com Description: On all current PHP versions, move_uploaded_file() creates a destination file that is either mode 0600 or 0644 (on Linux, anyway), depending on whether move_uploaded_file() needed to copy the file across filesystems. If the file can be moved (renamed), then the resulting file is mode 0600, because the file was originally created with mkstemp. If the file needs to be copied, the resulting mode is 0644 instead (assuming a "normal" umask of 022). This behavior appears (to the script author who isn't familiar with how move_uploaded_file works internally) inconsistent and surprising, and is undocumented. Expected result: Permissions given to uploaded files should be consistent, depending only on the umask setting. In other words, if I pass move_uploaded_file() the same parameters with the same umask value, I would expect to see the same resulting permissions, regardless of whether PHP's temporary file location happens to be on the same file system as the final destination. One could argue that a script author should be aware of this behavior, and should therefore find out whether the temporary location is on the same file system and plan for the resulting behavior. However, that doesn't seem practical. First of all, the current behavior isn't documented, so few people are aware of it. Secondly, the file system that is used for temporary files may be out of the script author's control, and may change without his or her knowledge (especially in a shared hosting environment, etc.) This could have security implications: Uploaded files that used to be given mode 0600 and were therefore considered "secure" because the script author thought that's "just how PHP works" will suddenly start getting mode 0644 if the server admin moves /tmp to a dedicated partition, for example. Making the behavior consistent (one way or the other) would avoid confusion. If the behavior can't be made consistent, it would be good to document the current behavior so that authors know that relying on the mode is not safe. Actual result: -- Permissions are set to either 0600 or 0644 depending on filesystem configuration. -- Edit this bug report at http://bugs.php.net/?id=42291&edit=1
#48761 [Com]: php crashes on start - getaddrinfo could not be located
ID: 48761 Comment by: rob-sturgill at yahoo dot com Reported By: aheckmann at m-s dot de Status: To be documented Bug Type: Reproducible crash Operating System: win32 only - Windows 2000 SP4 PHP Version: 5.3.0 New Comment: "No, the solution is to use at least a 10 years old operating system. The idea solution is to use a recent one." Pierre, While I appreciate what your team does more than I can possibly express, I believe this is a shocking response. If 5.3.0 doesn't support Windows 2000, then simply drop support for Windows 2000 in the documentation. Fine, no problem. Like the prior comment from 'broth' it's agonizing to break a working installation, going to 5.3, when that version simply does not support the OS. Otherwise, users like myself are going to waste hours debugging this mess. I respectfully request a change to the 'Changes made to Windows Support' to correct the statement: "The minimum Windows version is now Windows 2000; Windows 98, ME, and NT4 are no longer supported." Previous Comments: [2009-12-16 23:08:06] paj...@php.net No, the solution is to use at least a 10 years old operating system. The idea solution is to use a recent one. [2009-12-16 22:39:14] joe dot at dot trends at gmail dot com So is the only solution to return to PHP 5.2.11? I would really like to see this fixed. [2009-09-19 07:25:58] broth at superp dot com I sure wish a notice was put on PHP 5.3.0 that is would not work with win2000 I had PHP working! After the load of V5.3.0 my previous V 5.1 version is corrupt! One simple Warning note would have saved me hours! Thanks for the concern. [2009-09-03 23:43:27] paj...@php.net PHP 5.2 works just fine in this configuration. So you can follow they lovely adage and keep using 5.2.x with the existing apps :) [2009-09-03 23:09:48] composer at singers dot org dot nz I run Small Business Server 2000 and need to set up PHP within IIS to support some services that I need to provide and right now am unable to do so so am "hog tied". Although only a small site being able to provide the services required for the organization is critical.. Win2K SBS has proved very stable and reliable and the owners do not wish to change.. The old adage here.. "If it ain't broke don't fix it and don't screw with it" is what they like. The current environment meets their needs perfectly and has been highly reliable. Now they wanna add an extra service that uses MYSQL and PHP. So installing PHP is critical. Therefore some fix for them is important or at least a practical workaround. So yep there are Win2K servers out there and YEP a "fix" of some sort would be good. 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 http://bugs.php.net/48761 -- Edit this bug report at http://bugs.php.net/?id=48761&edit=1
#42291 [NEW]: Uploaded file permissions vary depending on file system configuration
From: rob-phpbugs at tigertech dot com Operating system: Linux PHP version: 4.4.7 PHP Bug Type: Filesystem function related Bug description: Uploaded file permissions vary depending on file system configuration Description: On all current PHP versions, move_uploaded_file() creates a destination file that is either mode 0600 or 0644 (on Linux, anyway), depending on whether move_uploaded_file() needed to copy the file across filesystems. If the file can be moved (renamed), then the resulting file is mode 0600, because the file was originally created with mkstemp. If the file needs to be copied, the resulting mode is 0644 instead (assuming a "normal" umask of 022). This behavior appears (to the script author who isn't familiar with how move_uploaded_file works internally) inconsistent and surprising, and is undocumented. Expected result: Permissions given to uploaded files should be consistent, depending only on the umask setting. In other words, if I pass move_uploaded_file() the same parameters with the same umask value, I would expect to see the same resulting permissions, regardless of whether PHP's temporary file location happens to be on the same file system as the final destination. One could argue that a script author should be aware of this behavior, and should therefore find out whether the temporary location is on the same file system and plan for the resulting behavior. However, that doesn't seem practical. First of all, the current behavior isn't documented, so few people are aware of it. Secondly, the file system that is used for temporary files may be out of the script author's control, and may change without his or her knowledge (especially in a shared hosting environment, etc.) This could have security implications: Uploaded files that used to be given mode 0600 and were therefore considered "secure" because the script author thought that's "just how PHP works" will suddenly start getting mode 0644 if the server admin moves /tmp to a dedicated partition, for example. Making the behavior consistent (one way or the other) would avoid confusion. If the behavior can't be made consistent, it would be good to document the current behavior so that authors know that relying on the mode is not safe. Actual result: -- Permissions are set to either 0600 or 0644 depending on filesystem configuration. -- Edit bug report at http://bugs.php.net/?id=42291&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42291&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42291&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42291&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42291&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42291&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42291&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42291&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42291&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42291&r=support Expected behavior:http://bugs.php.net/fix.php?id=42291&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42291&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42291&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42291&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42291&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42291&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42291&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42291&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42291&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42291&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42291&r=mysqlcfg
#26641 [NEW]: PHP as ISAPI crashes without an error message
From: rob at thijssen dot co dot uk Operating system: Windows 2000 PHP version: 4.3.4 PHP Bug Type: IIS related Bug description: PHP as ISAPI crashes without an error message Description: PHP was working fine one moment (running phpMyAdmin) the next it would only return a blank page. No settings were changed to trigger the fault. No error message is returned (with or without error reporting on). The event log shows several new errors: The configuration information of the performance library "C:\WINNT\system32\w3ctrs.dll" for the "W3SVC" service does not match the trusted performance library information stored in the registry. The functions in this library will not be treated as trusted. The Collect Procedure for the "Tcpip" service in DLL "C:\WINNT\system32\Perfctrs.dll" generated an exception or returned an invalid status. Performance data returned by counter DLL will be not be returned in Perf Data Block. Exception or status code returned is data DWORD 0. I suspect the problem is actually with IIS although it happily serves up other (non-PHP) content. The strange bit is that some useless HTML is generated but I have no idea what process is responsible for that. The box is running W2K with all the updates, PHP4.3.4, It's a brand new P4 Xeon with a Gig of RAM. Reproduce code: --- phpinfo(); Expected result: not nothing! Actual result: -- View source yields: -- Edit bug report at http://bugs.php.net/?id=26641&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26641&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26641&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26641&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26641&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26641&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26641&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26641&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26641&r=support Expected behavior: http://bugs.php.net/fix.php?id=26641&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26641&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26641&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26641&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26641&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26641&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26641&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26641&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26641&r=float
#27078 [NEW]: Numeric Keys for session variables are lost
From: rob dot brenart at tradingtechnologies dot com Operating system: Windows XP PHP version: 4.3.4 PHP Bug Type: Session related Bug description: Numeric Keys for session variables are lost Description: Perhaps it's intentional as variables aren't supposed to be numeric, but seeing as it's the $_SESSION array, I figured this would be allowed. Reproduce code: --- '; print_r($_SESSION); echo ''; $_SESSION[167]='hi world'; print_r($_SESSION); echo 'Here ya go'; ?> Expected result: Array ( [167] => hi world )Array ( [167] => hi world ) Here ya go Actual result: -- Array ( ) Array ( [167] => hi world ) Here ya go -- Edit bug report at http://bugs.php.net/?id=27078&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27078&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27078&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27078&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27078&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27078&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27078&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27078&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27078&r=support Expected behavior: http://bugs.php.net/fix.php?id=27078&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27078&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27078&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27078&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27078&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27078&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27078&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27078&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27078&r=float
#27078 [Bgs]: Numeric Keys for session variables are lost
ID: 27078 User updated by: rob dot brenart at tradingtechnologies dot com Reported By: rob dot brenart at tradingtechnologies dot com Status: Bogus Bug Type: Session related Operating System: Windows XP PHP Version: 4.3.4 New Comment: My mistake, I looked and missed it. But then shouldn't this kick out a warning on the $_SESSION[167]='hi world'; line? Previous Comments: [2004-01-28 14:39:40] [EMAIL PROTECTED] No, they're not allowed, RTFM: "The keys in the $_SESSION associative array are subject to the same limitations as regular variable names in PHP, i.e. they cannot start with a number and must start with a letter or underscore. For more details see the section on variables in this manual." -------- [2004-01-28 14:30:27] rob dot brenart at tradingtechnologies dot com Description: Perhaps it's intentional as variables aren't supposed to be numeric, but seeing as it's the $_SESSION array, I figured this would be allowed. Reproduce code: --- '; print_r($_SESSION); echo ''; $_SESSION[167]='hi world'; print_r($_SESSION); echo 'Here ya go'; ?> Expected result: Array ( [167] => hi world )Array ( [167] => hi world ) Here ya go Actual result: -- Array ( ) Array ( [167] => hi world ) Here ya go -- Edit this bug report at http://bugs.php.net/?id=27078&edit=1
#33751 [NEW]: jpeg support
From: rob at tdd dot org dot uk Operating system: Debian GNU/Linux 3.0 PHP version: 5.0.4 PHP Bug Type: GD related Bug description: jpeg support Description: I upgraded from php-5.0.3 to php-5.0.4. I used EXACTLY the same configuration options as php-5.0.3 and jpeg support was removed from gd in php-5.0.4. Both versions of php build and install successfully. ./configure --with-gd --with-mysql=/usr/local/mysql --with-apxs2=/usr/local/apache2/bin/apxs --enable-track-vars --with-pspell --with-memcache --enable-soap --enable-exif --with-tidy --with-curl --with-png-dir=/usr/local --with-zlib-dir=/usr/lib --enable-force-cgi-redirect --with-gettext --with-freetype-dir=/usr/local --with-jpeg-dir=/usr/local -- Edit bug report at http://bugs.php.net/?id=33751&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33751&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33751&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33751&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33751&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33751&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33751&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33751&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33751&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33751&r=support Expected behavior: http://bugs.php.net/fix.php?id=33751&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33751&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33751&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33751&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33751&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33751&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33751&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33751&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33751&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33751&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33751&r=mysqlcfg
#33751 [Bgs]: jpeg support
ID: 33751 User updated by: rob at tdd dot org dot uk Reported By: rob at tdd dot org dot uk Status: Bogus Bug Type: GD related Operating System: Debian GNU/Linux 3.0 PHP Version: 5.0.4 New Comment: Okay I have compiled php-5.0.3 and php-5.0.4 with the configure options. ./configure --with-gd --with-mysql=/usr/local/mysql --with-apxs2=/usr/local/apache2/bin/apxs --enable-track-vars --with-pspell --with-memcache --enable-soap --enable-exif --with-tidy --with-curl --with-png-dir=/usr/local --with-zlib-dir=/usr --enable-force-cgi-redirect --with-gettext --with-freetype-dir=/usr/local --with-jpeg-dir=/usr/local I have tested the script below on the command line. # cat ../imagecheck.php With php-5.0.3 # ./sapi/cli/php ../imagecheck.php Function imagecreatefromjpeg exists With php-5.0.4 # ./sapi/cli/php ../imagecheck.php Function imagecreatefromjpeg does not exist If there was a problem with the system and nothing had changed between the versions then the same problem would occur in php-5.0.3 Previous Comments: [2005-07-18 18:23:51] [EMAIL PROTECTED] Works fine for me (and there weren't any changes between 5.0.3 and 5.0.4 which could have broken it). There's just something wrong with your system. (check config.log, there you most likely will find the reason the check failed) Also: paths like /usr/lib do NOT WORK! (they never did and they never will, drop the /lib part from those!) [2005-07-18 17:30:03] rob at tdd dot org dot uk Description: I upgraded from php-5.0.3 to php-5.0.4. I used EXACTLY the same configuration options as php-5.0.3 and jpeg support was removed from gd in php-5.0.4. Both versions of php build and install successfully. ./configure --with-gd --with-mysql=/usr/local/mysql --with-apxs2=/usr/local/apache2/bin/apxs --enable-track-vars --with-pspell --with-memcache --enable-soap --enable-exif --with-tidy --with-curl --with-png-dir=/usr/local --with-zlib-dir=/usr/lib --enable-force-cgi-redirect --with-gettext --with-freetype-dir=/usr/local --with-jpeg-dir=/usr/local -- Edit this bug report at http://bugs.php.net/?id=33751&edit=1
#33751 [Bgs->Csd]: jpeg support
ID: 33751 User updated by: rob at tdd dot org dot uk Reported By: rob at tdd dot org dot uk -Status: Bogus +Status: Closed Bug Type: GD related Operating System: Debian GNU/Linux 3.0 PHP Version: 5.0.4 New Comment: I downloaded the source again and did a difference check # diff -Naur php-5.0.4old php-5.0.4new > php.diff There were differences (apart from generated files by configure, make etc) so I compiled again with the newly downloaded source and everything has worked fine. Obviously not a problem with my system then! Previous Comments: [2005-07-18 19:55:41] rob at tdd dot org dot uk Okay I have compiled php-5.0.3 and php-5.0.4 with the configure options. ./configure --with-gd --with-mysql=/usr/local/mysql --with-apxs2=/usr/local/apache2/bin/apxs --enable-track-vars --with-pspell --with-memcache --enable-soap --enable-exif --with-tidy --with-curl --with-png-dir=/usr/local --with-zlib-dir=/usr --enable-force-cgi-redirect --with-gettext --with-freetype-dir=/usr/local --with-jpeg-dir=/usr/local I have tested the script below on the command line. # cat ../imagecheck.php With php-5.0.3 # ./sapi/cli/php ../imagecheck.php Function imagecreatefromjpeg exists With php-5.0.4 # ./sapi/cli/php ../imagecheck.php Function imagecreatefromjpeg does not exist If there was a problem with the system and nothing had changed between the versions then the same problem would occur in php-5.0.3 [2005-07-18 18:23:51] [EMAIL PROTECTED] Works fine for me (and there weren't any changes between 5.0.3 and 5.0.4 which could have broken it). There's just something wrong with your system. (check config.log, there you most likely will find the reason the check failed) Also: paths like /usr/lib do NOT WORK! (they never did and they never will, drop the /lib part from those!) [2005-07-18 17:30:03] rob at tdd dot org dot uk Description: I upgraded from php-5.0.3 to php-5.0.4. I used EXACTLY the same configuration options as php-5.0.3 and jpeg support was removed from gd in php-5.0.4. Both versions of php build and install successfully. ./configure --with-gd --with-mysql=/usr/local/mysql --with-apxs2=/usr/local/apache2/bin/apxs --enable-track-vars --with-pspell --with-memcache --enable-soap --enable-exif --with-tidy --with-curl --with-png-dir=/usr/local --with-zlib-dir=/usr/lib --enable-force-cgi-redirect --with-gettext --with-freetype-dir=/usr/local --with-jpeg-dir=/usr/local -- Edit this bug report at http://bugs.php.net/?id=33751&edit=1
#26737 [NoF->Opn]: unexpected __sleep() serialization behavior
ID: 26737 User updated by: rob dot wills at gmail dot com -Reported By: rob at cue dot cc +Reported By: rob dot wills at gmail dot com -Status: No Feedback +Status: Open Bug Type: Zend Engine 2 problem Operating System: * PHP Version: 5CVS New Comment: PHP5.0.0 still exhibits this behaviour. Is there anything else I can provide to help with this issue/bug? Thanks, Rob Previous Comments: [2004-07-13 00:10:35] trevorrowe at gmail dot com Last posting was made on feb 26, its now jul 12. Anyone have any more current news on this bug? The bug seems to still persist in php5 rc3. mastabog's suggestion of padding the variable name with nulls for private, padding the * for protected and nothing for public works, but seems like an ugly hack. My biggest fear is when the bug is patched, my variable names will be double padded and things will start to break. [2004-02-26 21:24:38] mastabog at hotmail dot com Complete info on this bug: To quote "rob at cue dot cc", you don't have to enclose only the class name with null characters. As far as I've seen you have to enclose with null chars ALL Php5 serialization identifiers of class properties types, the ones I figured out to be for now (let x be the property name): - class name if x is 'private' => "\0" . __CLASS__ . "\0x" - * if x is 'protected' => "\0*\0x" - nothing if x is 'public' => "x" Here's what I mean: Anything else in the return array of __sleep() and the property will come up empty after unserialization ... not nice. My hope is that this is a bug, cus forming those strings with null chars is just, well, ugly :) [2004-02-26 20:34:43] mastabog at hotmail dot com Same problem here. And I'm downloading the CVS php5 version daily since May 2003. I assumed this was to be solved in a much later stage seeing that all CVS releases (and all 4 betas of PHP5) had this bug. In all my php5 projects i haven't use any __sleep() methods at all because they weren't working. I use php5 mainly with win32 and about once a week with Linux. Both have this bug ... very irritating (I have some objects that make my session file go up to 100kb, because i cant use __sleep(), which would be large for a production site.) [2004-01-17 00:51:27] [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-12-30 20:11:12] [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/26737 -- Edit this bug report at http://bugs.php.net/?id=26737&edit=1
[PHP-BUG] Bug #64994 [NEW]: looks like /usr/local/pgsql/ hardwired
From: rob dot dickens at lafros dot com Operating system: Mac OS X 10.6.8 PHP version: 5.3.26 Package: *Compile Issues Bug Type: Bug Bug description:looks like /usr/local/pgsql/ hardwired Description: make fails at the `ext/phar/phar.php` target: Generating phar.php dyld: Library not loaded: libpq.5.dylib Referenced from: /Users/Shared/php-5.3.25/sapi/cli/php Reason: image not found make: *** [ext/phar/phar.php] Trace/BPT trap This was even though I'd used --with-pgsql=/Library/PostgreSQL/9.2 (installer's default location). After reading* that php uses /usr/local/pgsql by default, I created a symbolic link, /usr/local/pgsql/lib/libpq.5.dylib -> /Library/PostgreSQL/9.2/lib/libpq.5.5.dylib, and then it worked. Have actually built PHP 5.3.25 but assume from changelog that this bug hasn't been fixed in 5.3.26. * http://www.php.net/manual/en/pgsql.installation.php -- Edit bug report at https://bugs.php.net/bug.php?id=64994&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64994&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64994&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64994&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64994&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64994&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64994&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64994&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64994&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64994&r=support Expected behavior: https://bugs.php.net/fix.php?id=64994&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64994&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64994&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64994&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64994&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64994&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64994&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64994&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64994&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64994&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64994&r=mysqlcfg
#40452 [Com]: ODBC and SQL Server datetime parameter fields fail on insert
ID: 40452
Comment by: rob at tdd dot org dot uk
Reported By: aspen dot olmsted at alliance dot biz
Status: Assigned
Bug Type: PDO related
Operating System: Windows 2003, XP
PHP Version: 5.2.1
Assigned To: wez
New Comment:
I was experiencing the same problem with a stored procedure (SQL
SERVER), however I found that I was calling the parameters in a
different order in which they where expected, even though I was
specifying the parameter name.
-- replcate
CREATE PROC hello
@world VARCHAR(100),
@repeat INT
AS
SELECT 'hello ' + REPLICATE(@world, @repeat)
GO
-- both give same output
EXEC hello @world = 'world', @repeat = 5
EXEC hello @repeat = 5, @world = 'world'
If I was to call the first exec equivalent in php using bound
parameters then it works, however the php equivalent using bound
parameters it fails with a function sequence error.
Previous Comments:
[2007-10-11 14:22:29] jfdsmit at gmail dot com
I have a similar experience, running PHP 5.2.4 on Windows 2003. The
server /does/ accept values when they are formatted exactly -mm-dd
(as per the date() format Y-m-d) /or/ if the supplied value == NULL.
Empty strings and dates formatted otherwise (2007-3-12 for instance)
result in a HY010 SQLSTATE Sequence error. So contrary to what daniel
dot tams at gmail dot com says, the bug is formatting-dependant in my
experience
[2007-04-24 19:05:14] daniel dot tams at gmail dot com
Just wanted to clarify that the error is unrelated to the format of the
datetime.
[2007-04-24 19:00:09] daniel dot tams at gmail dot com
I can confirm this problem on PHP 5.2.1. The exact error is the
following:
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HY010]: Function sequence error: 0 [Microsoft][ODBC Driver
Manager] Function sequence error (SQLExecute[0] at
ext\pdo_odbc\odbc_stmt.c:133)' in C:\Program Files\Apache Software
Foundation\Apache2.2\htdocs\iptaa\lib\IPTAA_CRUD.class.php:135 Stack
trace: #0 C:\Program Files\Apache Software
Foundation\Apache2.2\htdocs\iptaa\lib\IPTAA_CRUD.class.php(135):
PDOStatement->execute() #1 C:\Program Files\Apache Software
Foundation\Apache2.2\htdocs\iptaa\lib\IPTAA_CRUD.class.php(414):
IPTAA_CRUD->create(Array) #2 C:\Program Files\Apache Software
Foundation\Apache2.2\htdocs\iptaa\users.php(15):
IPTAA_CRUD->handleHttpPost() #3 {main} thrown in C:\Program Files\Apache
Software Foundation\Apache2.2\htdocs\iptaa\lib\IPTAA_CRUD.class.php on
line 135
Fatal error: Exception thrown without a stack frame in Unknown on line
0
This is a pretty serious limitation of the PDO ODBC driver.
[2007-02-13 01:31:36] aspen dot olmsted at alliance dot biz
Yes. If you insert into sql other ways it works perfect. Including
through php
[2007-02-12 22:22:23] [EMAIL PROTECTED]
Are you sure "2007-02-12 14:5" is correct timestamp for MSSQL?
Doesn't it lack the last symbol?
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/40452
--
Edit this bug report at http://bugs.php.net/?id=40452&edit=1
#38805 [Com]: PDO Truncates Text from SQL Server Text Data Type Field
ID: 38805
Comment by: rob at tdd dot org dot uk
Reported By: gkrajci at arescorporation dot com
Status: Assigned
Bug Type: PDO related
Operating System: Windows NT PBMA-WB2 5.2 build 37
PHP Version: 5.1.6
Assigned To: wez
New Comment:
I have found that it doesn't get truncted with ODBC, however I have
found certain stored procedures don't work with ODBC. My solution is to
create a DAL class which has a factory method to create a PDO connection
based on driver selection. Then during my testing if I find it to work
in one and not in another then I switch the database connection over to
the one that works.
Previous Comments:
[2007-11-17 03:21:20] rockyjl at gmail dot com
why can't fix in php 5.2.5 this is very importance for developer
!
[2007-11-17 03:15:08] rockyjl at gmail dot com
why can't fix in php 5.2.5 this is very importance for developer
!
[2007-09-11 08:36:42] rockyjl at gmail dot com
ini_set('mssql.textlimit', '65536');
ini_set('mssql.textsize', '65536');
it is work for php_mssql.dll
but not work for php_pdo_mssql.dll
how can i get more than 4096 byte in TEXT with php_pdo_mssql.dll ???
[2007-08-13 19:22:32] jagwire16 at hotmail dot com
http://us3.php.net/manual/en/function.mssql-query.php#64470 reports how
to make it work and that solution worked for me.
[2007-02-14 16:16:49] matt at educause dot edu
I too can reproduce this problem ... a critical hurdle for us.
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/38805
--
Edit this bug report at http://bugs.php.net/?id=38805&edit=1
#43069 [Com]: SoapClient causes 505 HTTP Version not supported error message
ID: 43069
Comment by: rob dot smith at gmx dot de
Reported By: sebastian dot habeker at roli dot com
Status: Open
Bug Type: SOAP related
Operating System: Windows 2000
PHP Version: 5.2.4
New Comment:
Same problem here.
OS: Windows XP
PHP: 5.2.6
Previous Comments:
[2007-11-15 11:44:00] sebastian dot habeker at roli dot com
I downloaded
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi but still
got the same problem. Is there anything else to configure, in the
php.ini or as an option in the SoapClient constructor?
[2007-11-12 10:15:13] [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-10-22 16:33:43] sebastian dot habeker at roli dot com
Description:
I am trying to use PHP as a SOAP client with a MSSQL 2005 SOAP
endpoint. I can query the wsdl in my browser without a problem, but in
PHP I get the error:
Warning: SoapClient::SoapClient(http://myuri?wsdl)
[function.SoapClient-SoapClient]: failed to open stream: HTTP request
failed! HTTP/1.1 505 HTTP Version not supported in C:\scripts\test.php
on line 2
Warning: SoapClient::SoapClient() [function.SoapClient-SoapClient]: I/O
warning : failed to load external entity "http://myuri?wsdl"; in
C:\scripts\test.php on line 2
Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: Couldn't load from 'http://myuri?wsdl' in C:\scripts\test.php:2
Stack trace: #0 C:\scripts\test.php(2):
SoapClient->SoapClient('http://...', Array) #1 {main} thrown in
C:\scripts\test.php on line 2
A TCP trace shows the following:
GET /uri?wsdl HTTP/1.0
Host: 10.20.30.40
HTTP/1.1 505 HTTP Version not supported
Content-Length: 0
Server: Microsoft-SQL/9.0 Microsoft-HTTPAPI/1.0
Date: Mon, 22 Oct 2007 15:44:13 GMT
Connection: close
Reproduce code:
---
http://myuri?wsdl');
?>
Expected result:
It should be able to use HTTP/1.1 instead of HTTP/1.0 for the SOAP
client request.
--
Edit this bug report at http://bugs.php.net/?id=43069&edit=1
#46294 [NEW]: pg_send_query_params converts all elements in 'params' to strings
From: rob dot linton at donatgroup dot com Operating system: Windows XP PHP version: 5.2.6 PHP Bug Type: PostgreSQL related Bug description: pg_send_query_params converts all elements in 'params' to strings Description: This is just as described here: http://bugs.php.net/bug.php?id=43279 Variables passed into the $params array of pg_send_query_params() are converted to strings as if they were passed by reference. Reproduce code: --- $pg = pg_connect(); $int = null; $int2 = 99; echo '$int = '.var_export($int, true).''; echo '$int2 = '.var_export($int2, true).''; $q = 'INSERT INTO val (val_int, val_int2) VALUES($1, $2)'; pg_send_query_params($pg, $q, array($int,$int2)); $result = pg_get_result($pg); echo '$int = '.var_export($int, true).''; echo '$int2 = '.var_export($int2, true).''; Expected result: $int = NULL $int2 = 99 $int = NULL $int2 = 99 Actual result: -- $int = NULL $int2 = 99 $int = '' $int2 = '99' -- Edit bug report at http://bugs.php.net/?id=46294&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46294&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46294&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46294&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46294&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=46294&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46294&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=46294&r=needscript Try newer version:http://bugs.php.net/fix.php?id=46294&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46294&r=support Expected behavior:http://bugs.php.net/fix.php?id=46294&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46294&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46294&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46294&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46294&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=46294&r=dst IIS Stability:http://bugs.php.net/fix.php?id=46294&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46294&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46294&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46294&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=46294&r=mysqlcfg
#46294 [Fbk->Opn]: pg_send_query_params converts all elements in 'params' to strings
ID: 46294 User updated by: rob dot linton at donatgroup dot com Reported By: rob dot linton at donatgroup dot com -Status: Feedback +Status: Open Bug Type: PostgreSQL related Operating System: Windows XP PHP Version: 5.2.6 New Comment: This has been fixed in 5.3.0alpha3-dev. Sorry for the noise. Previous Comments: [2008-10-15 13:42:07] [EMAIL PROTECTED] I can't reproduce it. [2008-10-14 22:41:25] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2008-10-14 22:32:00] rob dot linton at donatgroup dot com Description: This is just as described here: http://bugs.php.net/bug.php?id=43279 Variables passed into the $params array of pg_send_query_params() are converted to strings as if they were passed by reference. Reproduce code: --- $pg = pg_connect(); $int = null; $int2 = 99; echo '$int = '.var_export($int, true).''; echo '$int2 = '.var_export($int2, true).''; $q = 'INSERT INTO val (val_int, val_int2) VALUES($1, $2)'; pg_send_query_params($pg, $q, array($int,$int2)); $result = pg_get_result($pg); echo '$int = '.var_export($int, true).''; echo '$int2 = '.var_export($int2, true).''; Expected result: $int = NULL $int2 = 99 $int = NULL $int2 = 99 Actual result: -- $int = NULL $int2 = 99 $int = '' $int2 = '99' -- Edit this bug report at http://bugs.php.net/?id=46294&edit=1
#46294 [Opn->Csd]: pg_send_query_params converts all elements in 'params' to strings
ID: 46294 User updated by: rob dot linton at donatgroup dot com Reported By: rob dot linton at donatgroup dot com -Status: Open +Status: Closed Bug Type: PostgreSQL related Operating System: Windows XP PHP Version: 5.2.6 New Comment: closing. Previous Comments: [2008-10-15 17:59:40] rob dot linton at donatgroup dot com This has been fixed in 5.3.0alpha3-dev. Sorry for the noise. [2008-10-15 13:42:07] [EMAIL PROTECTED] I can't reproduce it. [2008-10-14 22:41:25] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2008-10-14 22:32:00] rob dot linton at donatgroup dot com Description: This is just as described here: http://bugs.php.net/bug.php?id=43279 Variables passed into the $params array of pg_send_query_params() are converted to strings as if they were passed by reference. Reproduce code: --- $pg = pg_connect(); $int = null; $int2 = 99; echo '$int = '.var_export($int, true).''; echo '$int2 = '.var_export($int2, true).''; $q = 'INSERT INTO val (val_int, val_int2) VALUES($1, $2)'; pg_send_query_params($pg, $q, array($int,$int2)); $result = pg_get_result($pg); echo '$int = '.var_export($int, true).''; echo '$int2 = '.var_export($int2, true).''; Expected result: $int = NULL $int2 = 99 $int = NULL $int2 = 99 Actual result: -- $int = NULL $int2 = 99 $int = '' $int2 = '99' -- Edit this bug report at http://bugs.php.net/?id=46294&edit=1
#50756 [NEW]: CURLOPT_FTP_SKIP_PASV_IP does not exist
From: rob dot apodaca at gmail dot com Operating system: any PHP version: 5.3.1 PHP Bug Type: Feature/Change Request Bug description: CURLOPT_FTP_SKIP_PASV_IP does not exist Description: The CURLOPT_FTP_SKIP_PASV_IP option is part of libcurl (see http://curl.haxx.se/libcurl/c/curl_easy_setopt.html ) but no predefined constant exists for use with curl_setopt(). -- Edit bug report at http://bugs.php.net/?id=50756&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50756&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50756&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50756&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50756&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50756&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50756&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50756&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50756&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50756&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50756&r=support Expected behavior: http://bugs.php.net/fix.php?id=50756&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50756&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50756&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50756&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50756&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50756&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50756&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50756&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50756&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50756&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50756&r=mysqlcfg
#29935 [Com]: array_filter crashes Apache 2
ID: 29935
Comment by: rob at sharp dot id dot au
Reported By: webmaster at martialartsmovies dot net
Status: No Feedback
Bug Type: Arrays related
Operating System: Windows XP
PHP Version: 5.0.1
New Comment:
I am seeing the same error using version 4.4.1, and was able to remove
the error by explicitly allocating arrays using
$variable = Array();
$variable[] = $object;
Instead of allocating data using
$variable[] = $object;
Previous Comments:
[2005-05-06 17:26:28] hans at velum dot net
FYI, I'm using PHP 5.0.4.
[2005-05-06 17:22:48] hans at velum dot net
I am also getting segfaults using array_filter on Apache 2 (on Gentoo
Linux).
My backtrace looks like:
#0 0x4070246e in zif_array_filter () from
/etc/apache/modules/libphp5.so
#1 0xbfff3f0c in ?? ()
#2 0xbfff3f10 in ?? ()
#3 0xbfff3f14 in ?? ()
I'm not sure what more I can get from that backtrace.
My array filter code looks like:
$discs =
array_filter(Bb_DiscussionPeer::doSelectUnreadForUserByClique($cliqueId,
$uid), array($this, 'hasPerms'));
Where the first param to array_filter is an array of objects
(verified). And the hasPerms method is a method in parent class that
looks like this:
protected function hasPerms($obj) {
return ($obj->canUser(Perms::READ));
}
(Changing that to be a 'public' method doesn't help.)
I can't seem to narrow down the bug any more than that. It doesn't
seem to happen *all* the time either, but if I have two such similar
calls on a page it will segfault. Sometimes it will segfault if
there's only one, but sometimes it works without segfaulting.
[2004-09-17 01:00:03] 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-09-02 08:17:57] [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
Your code works fine for me, please try a snapshot.
[2004-09-01 20:10:27] webmaster at martialartsmovies dot net
Description:
I have PHP 5.0.1 installed together with the latest stable Apache 2 on
Windows XP SP2. I used the example on the array_filter page on php.net
an all I got was a window telling me that apache caused a problem and
it needed to reboot.
Reproduce code:
---
1, "b"=>2, "c"=>3, "d"=>4, "e"=>5);
$array2 = array(6, 7, 8, 9, 10, 11, 12);
echo "Odd :\n";
print_r(array_filter($array1, "odd"));
echo "Even:\n";
print_r(array_filter($array2, "even"));
?>
Expected result:
the array_filter function applied to the 2 arrays
Actual result:
--
apache 2 crashed.
error.log:
[Wed Sep 01 19:47:14 2004] [notice] Child 2412: Child process is
running
[Wed Sep 01 19:47:14 2004] [notice] Child 2412: Acquired the start
mutex.
[Wed Sep 01 19:47:14 2004] [notice] Child 2412: Starting 250 worker
threads.
[Wed Sep 01 19:50:15 2004] [notice] Parent: child process exited with
status 3221225477 -- Restarting.
--
Edit this bug report at http://bugs.php.net/?id=29935&edit=1
#37091 [NEW]: Unable to call static php class functions from xsl
From: rob dot eyre at gmail dot com
Operating system: Linux
PHP version: 5.1.2
PHP Bug Type: XSLT related
Bug description: Unable to call static php class functions from xsl
Description:
After calling registerPHPFunctions() and including the php namespace on an
XSL stylesheet, I can call global functions (eg date()), but not static
class functions (ie testClass::testMethod()).
Reproduce code:
---
class testClass {
function testMethod() {
return 'testValue';
}
}
$xslt = new XSLTProcessor;
$xslt->registerPHPFunctions();
$xmlDoc = DOMDocument::loadXML('');
$xslDoc = DOMDocument::loadXML('
http://www.w3.org/1999/XSL/Transform";
xmlns:php="http://php.net/xsl";>
');
$xslt->importStylesheet($xslDoc);
echo $xslt->transformToXML($xmlDoc);
Expected result:
testValue
Actual result:
--
Warning: XSLTProcessor::transformToXml() [function.transformToXml]: Unable
to call handler testClass::testMethod() in
/home/rob/Projects/sandbox/index.php on line 19
Warning: XSLTProcessor::transformToXml() [function.transformToXml]:
xmlXPathCompiledEval: evaluation failed in
/home/rob/Projects/sandbox/index.php on line 19
Warning: XSLTProcessor::transformToXml() [function.transformToXml]:
runtime error: file /home/rob/Projects/sandbox/ line 4 element value-of in
/home/rob/Projects/sandbox/index.php on line 19
Warning: XSLTProcessor::transformToXml() [function.transformToXml]:
xsltValueOf: text copy failed in /home/rob/Projects/sandbox/index.php on
line 19
--
Edit bug report at http://bugs.php.net/?id=37091&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37091&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=37091&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37091&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37091&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37091&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37091&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37091&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37091&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37091&r=support
Expected behavior:http://bugs.php.net/fix.php?id=37091&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37091&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37091&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37091&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37091&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37091&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37091&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37091&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37091&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37091&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37091&r=mysqlcfg
Bug #40479 [Com]: zend_mm_heap corrupted
Edit report at https://bugs.php.net/bug.php?id=40479&edit=1
ID: 40479
Comment by: rob dot spekschoor at gmail dot com
Reported by:rrossi at maggioli dot it
Summary:zend_mm_heap corrupted
Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: Suse Linux 9.0
PHP Version:5.2.1
Block user comment: N
Private report: N
New Comment:
I can also reproduce with script from 'f dot ardelian at gmail dot com' this
error on:
php --version
PHP 5.3.8-pl0-gentoo (cli) (built: Oct 4 2011 10:42:38)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
Previous Comments:
[2011-09-26 08:00:03] laacz at laacz dot lv
Second this by running code, provided by "f dot ardelian at gmail dot com" at
2011-08-31 07:49 UTC:
# php -q zend_mm_heap_corrupted.php
If you see this, try to increase OBJECT_COUNT to 100,000zend_mm_heap corrupted
# php --version
PHP 5.3.8 (cli) (built: Aug 29 2011 14:48:33)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
with eAccelerator v0.9.6.1, Copyright (c) 2004-2010 eAccelerator, by
eAccelerator
with Xdebug v2.1.2, Copyright (c) 2002-2011, by Derick Rethans
[2011-09-02 11:28:40] christoffer at westart dot se
I must agree with Florin, we are experiencing the same kinds of issues, both
with
CLI and mod_php, su_php and across 5.2.* and 5.3.*. We really need this to be
fixed. Any updates?
[2011-08-31 07:49:32] f dot ardelian at gmail dot com
The cause is pretty clear to me: when the script ends, the garbage collector
starts to destroy the objects and the `unset()` in the destructor probably
invokes the garbage collector again. The error message doesn't always appear on
the screen nor in the error log (sometimes it does). The "Segmentation fault"
always appears in the error log. Breaks if PHP is installed using apt-get or
yum or comes with your Linux distro. Seems to work fine on Windows and codepads
(custom compiled PHPs). Definitely breaks on Debian. Don't forget to set
memory_limit to have enough room in memory to create all the objects (128M
seems to be enough on Debian to create 150,000 objects).
_guid = self::$maxGuid++] = $this;
}
public function __destruct() {
unset(self::$world[$this->_guid]);
}
}
for ($i = 0; $i < OBJECT_COUNT; ++$i) {
new Object();
}
// You probably won't see this because of the "zend_mm_heap corrupted"
echo 'If you see this, try to increase OBJECT_COUNT to 100,000';
?>
If this code pinpoints the four and a half years-old issue, email me a beer.
Florin Ardelian
[2010-10-16 00:06:47] fel...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2010-09-16 13:23:05] michael202 at gmx dot de
The problem is still in 5.3.3 on Suse 11.2, but it is not reproducible :-(
Sometimes it is twice a day sometimes every few days.
Apache starts giving these messages:
"child pid x exit signal Segmentation fault (11)"
And if your are lucky, the scripts still return xml-results.
If you get a no result from the script (i.a. white page in browser),
you'll need a apache stop and start (graceful does not help)
and the error_log says:
"seg fault or similar nasty error detected in the parent process"
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=40479
--
Edit this bug report at https://bugs.php.net/bug.php?id=40479&edit=1
Bug #40479 [Com]: zend_mm_heap corrupted
Edit report at https://bugs.php.net/bug.php?id=40479&edit=1
ID: 40479
Comment by: rob dot spekschoor at gmail dot com
Reported by:rrossi at maggioli dot it
Summary:zend_mm_heap corrupted
Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: Suse Linux 9.0
PHP Version:5.2.1
Block user comment: N
Private report: N
New Comment:
problem solved by compiling apache with prefork. Somehow Apache worker MPM +
PHP 5.2 works fine but Apache worker MPM + PHP 5.3 fails terribly. Prefork
seems stable
Previous Comments:
[2011-10-05 20:08:42] rob dot spekschoor at gmail dot com
I can also reproduce with script from 'f dot ardelian at gmail dot com' this
error on:
php --version
PHP 5.3.8-pl0-gentoo (cli) (built: Oct 4 2011 10:42:38)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
[2011-09-26 08:00:03] laacz at laacz dot lv
Second this by running code, provided by "f dot ardelian at gmail dot com" at
2011-08-31 07:49 UTC:
# php -q zend_mm_heap_corrupted.php
If you see this, try to increase OBJECT_COUNT to 100,000zend_mm_heap corrupted
# php --version
PHP 5.3.8 (cli) (built: Aug 29 2011 14:48:33)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
with eAccelerator v0.9.6.1, Copyright (c) 2004-2010 eAccelerator, by
eAccelerator
with Xdebug v2.1.2, Copyright (c) 2002-2011, by Derick Rethans
[2011-09-02 11:28:40] christoffer at westart dot se
I must agree with Florin, we are experiencing the same kinds of issues, both
with
CLI and mod_php, su_php and across 5.2.* and 5.3.*. We really need this to be
fixed. Any updates?
[2011-08-31 07:49:32] f dot ardelian at gmail dot com
The cause is pretty clear to me: when the script ends, the garbage collector
starts to destroy the objects and the `unset()` in the destructor probably
invokes the garbage collector again. The error message doesn't always appear on
the screen nor in the error log (sometimes it does). The "Segmentation fault"
always appears in the error log. Breaks if PHP is installed using apt-get or
yum or comes with your Linux distro. Seems to work fine on Windows and codepads
(custom compiled PHPs). Definitely breaks on Debian. Don't forget to set
memory_limit to have enough room in memory to create all the objects (128M
seems to be enough on Debian to create 150,000 objects).
_guid = self::$maxGuid++] = $this;
}
public function __destruct() {
unset(self::$world[$this->_guid]);
}
}
for ($i = 0; $i < OBJECT_COUNT; ++$i) {
new Object();
}
// You probably won't see this because of the "zend_mm_heap corrupted"
echo 'If you see this, try to increase OBJECT_COUNT to 100,000';
?>
If this code pinpoints the four and a half years-old issue, email me a beer.
Florin Ardelian
[2010-10-16 00:06:47] fel...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
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=40479
--
Edit this bug report at https://bugs.php.net/bug.php?id=40479&edit=1
Bug #63311 [Com]: DateTime::add() adds wrong interval when switching from summer to winter time
Edit report at https://bugs.php.net/bug.php?id=63311&edit=1
ID: 63311
Comment by: rob dot norman at infinity-tracking dot com
Reported by:thomas dot mayer at 2bis10 dot de
Summary:DateTime::add() adds wrong interval when switching
from summer to winter time
Status: Open
Type: Bug
Package:Date/time related
Operating System: Windows 7, debian 6
PHP Version:5.4.8
Block user comment: N
Private report: N
New Comment:
I'm seeing similar behaviour across daylight boundaries with CentOS 5.9, PHP
5.4.13
Test script:
$tzLon = new DateTimeZone( 'Europe/London' );
$tzUtc = new DateTimeZone( 'UTC' );
$interval = new DateInterval( 'PT24H' );
// Before change from GMT to BST.
$strDt = '2013-04-31 12:00:00';
// Adding the interval in UTC behaves as expected.
$dt = new DateTime( $strDt, $tzUtc );
$dt->add( $interval );
echo $dt->format( 'Y-m-d H:i:s' ) . "\n";
// Adding the interval in Europe/London does not.
$dt = new DateTime( $strDt, $tzLon );
$dt->add( $interval );
// Convert to UTC for comparison.
$dt->setTimeZone( $tzUtc );
echo $dt->format( 'Y-m-d H:i:s' ) . "\n";
Expected result:
2013-05-02 12:00:00
2013-05-02 12:00:00
Actual result:
--
2013-05-02 12:00:00
2013-05-02 11:00:00
Previous Comments:
[2012-10-19 12:33:35] paj...@php.net
Fix category, tak #2.
[2012-10-19 12:32:30] thomas dot mayer at 2bis10 dot de
I switched Expected result and actual result.
Expected result:
--
2013-10-27T01:45:00+02:00
1382831100
2013-10-27T02:00:00+02:00
1382832000
900
Actual result:
2013-10-27T01:45:00+02:00
1382831100
2013-10-27T02:00:00+01:00
1382835600
4500
[2012-10-19 12:31:20] paj...@php.net
Fix cat
[2012-10-19 12:30:18] thomas dot mayer at 2bis10 dot de
Description:
When adding an interval to a DateTime object in european summer time and the
resulting date is in european winter time, an additional hour is added.
Please note that we stay in summer time(+2) until 3:00:00 and then the clock is
set to 02:00:00 winter time(+1).
Test script:
---
$date = new DateTime(
'2013-10-27 01:45:00',
new DateTimeZone('Europe/Berlin')
);
$oldStamp=$date->getTimeStamp();
$interval=new DateInterval('PT15M');
echo $date->format('c')."\n";
echo $date->getTimeStamp()."\n";
$date->add($interval);
echo $date->format('c')."\n";
echo $date->getTimeStamp()."\n";
echo $date->getTimeStamp()-$oldStamp;
Expected result:
2013-10-27T01:45:00+02:00
1382831100
2013-10-27T02:00:00+01:00
1382835600
4500
Actual result:
--
2013-10-27T01:45:00+02:00
1382831100
2013-10-27T02:00:00+02:00
1382832000
900
--
Edit this bug report at https://bugs.php.net/bug.php?id=63311&edit=1
Bug #62331 [Com]: DateTime::add() produces inconsistent resultst
Edit report at https://bugs.php.net/bug.php?id=62331&edit=1
ID: 62331
Comment by: rob dot norman at infinity-tracking dot com
Reported by:ruesche at fka dot de
Summary:DateTime::add() produces inconsistent resultst
Status: Assigned
Type: Bug
Package:Date/time related
Operating System: Windows, Linux
PHP Version:Irrelevant
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
Looks like this has been duplicated a few times.
https://bugs.php.net/bug.php?id=61530
https://bugs.php.net/bug.php?id=63953
https://bugs.php.net/bug.php?id=63311
I just added a comment & test case to the last one, still seeing this on PHP
5.4.13
Previous Comments:
[2013-03-20 20:38:53] kavi at postpro dot net
This is also affecting DateTime->modify() in PHP 5.3.21.
This appears to only affect DateTime objects with timezone_type of 1, and maybe
2.
Of course, it's impossible to directly query a DateTime object's timezone_type,
so you have to get the string representation from print_r and inspect that in
order to code around this bug.
Unbelievable.
[2012-06-15 09:02:31] sala...@php.net
This looks like a side-effect of the changes made against bug #55253.
[2012-06-15 08:48:06] ruesche at fka dot de
typo fixed.
[2012-06-15 08:46:43] ruesche at fka dot de
Description:
When you use a timezone with daylight saving time (like Europe/Berlin) and the
date of the system running the PHP script is in this daylight saving time (like
2012-06-15), DateTime::add() will produce results that are off by 1 hour.
When the date on the local machine is not in the daylight saving time, the same
computation will yield the expceted results.
This bug also only appears, when the DateTime instance was created using a
timestamp, so a workaround would be the following: Instead of
$date = new DateTime(gmmktime(0, 0, 0, 1, 1, 2012));
use
$date = new DateTime('2012-01-01');
The script was tested with the following systems, all having the same problem:
- Windows XP, PHP 5.3.10
- Windows XP, PHP 5.3.13
- Windows 7, PHP 5.3.10
- Arch Linux (x86_64), PHP 5.4.3
- Debian Squeeze, PHP 5.3.10
Test script:
---
format('Y-m-d H:i:s')."\n";
$date->add($oneMonth);
echo $date->format('Y-m-d H:i:s')."\n";
Expected result:
2012-01-01 00:00:00
2012-02-01 00:00:00
Actual result:
--
2012-01-01 00:00:00
2012-02-01 01:00:00
--
Edit this bug report at https://bugs.php.net/bug.php?id=62331&edit=1
#43272 [NEW]: getElementsByTagNameNS doen't find nodes
From: jose dot rob dot jr at gmail dot com
Operating system: Gentoo Linux
PHP version: 5.2.5
PHP Bug Type: DOM XML related
Bug description: getElementsByTagNameNS doen't find nodes
Description:
When I use a prefix, getElementsByTagNameNS doesn't find it until I save
and load again.
Reproduce code:
---
createElementNS('example','ex:root');
$xml->appendChild($root);
for($i=1;$i<=3;$i++){
$child=$xml->createElement("ex:child$i");
$root->appendChild($child);
}
for($i=0;$i<=1;$i++){
if($i){
echo "* reloading";
$XML=$xml->saveXML();
$xml->loadXML($XML);
}
$ns=$xml->getElementsByTagNameNS('example','*');
foreach($ns as $ex){
echo $ex->nodeName."";
}
}
?>
Expected result:
ex:root
ex:child1
ex:child2
ex:child3
* reloading
ex:root
ex:child1
ex:child2
ex:child3
Actual result:
--
ex:root
* reloading
ex:root
ex:child1
ex:child2
ex:child3
--
Edit bug report at http://bugs.php.net/?id=43272&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43272&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43272&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43272&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43272&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43272&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43272&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43272&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43272&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43272&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43272&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43272&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43272&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43272&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43272&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43272&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43272&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43272&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43272&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43272&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43272&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43272&r=mysqlcfg
#43273 [NEW]: getElementsByTagNameNS doen't find nodes
From: jose dot rob dot jr at gmail dot com
Operating system: Gentoo Linux
PHP version: 5.2.5
PHP Bug Type: DOM XML related
Bug description: getElementsByTagNameNS doen't find nodes
Description:
When I use a prefix, getElementsByTagNameNS doesn't find it until I save
and load again.
Reproduce code:
---
createElementNS('example','ex:root');
$xml->appendChild($root);
for($i=1;$i<=3;$i++){
$child=$xml->createElement("ex:child$i");
$root->appendChild($child);
}
for($i=0;$i<=1;$i++){
if($i){
echo "* reloading";
$XML=$xml->saveXML();
$xml->loadXML($XML);
}
$ns=$xml->getElementsByTagNameNS('example','*');
foreach($ns as $ex){
echo $ex->nodeName."";
}
}
?>
Expected result:
ex:root
ex:child1
ex:child2
ex:child3
* reloading
ex:root
ex:child1
ex:child2
ex:child3
Actual result:
--
ex:root
* reloading
ex:root
ex:child1
ex:child2
ex:child3
--
Edit bug report at http://bugs.php.net/?id=43273&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43273&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43273&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43273&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43273&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43273&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43273&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43273&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43273&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43273&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43273&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43273&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43273&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43273&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43273&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43273&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43273&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43273&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43273&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43273&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43273&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43273&r=mysqlcfg
#48080 [NEW]: Add support for forcing DOM to validate a DOMDocument with a DTD
From: jose dot rob dot jr at gmail dot com Operating system: PHP version: 5.2.9 PHP Bug Type: Feature/Change Request Bug description: Add support for forcing DOM to validate a DOMDocument with a DTD Description: I need to validate XML files before loading them, then I created a DTD and hosted it. With python I can distribute the DTD file with the program and validate the XML file locally. A python example: --- from lxml import etree from StringIO import StringIO xmlstart=""" http://example.com/mydtd.dtd'>""" xmlok=xmlstart+"The XML file"; xmlinvalid=xmlstart+"testThe XML file"; dtddata=""; f=StringIO(dtddata); dtd=etree.DTD(f); print "Valid XML:"; xml1=etree.XML(xmlok); validation=dtd.validate(xml1); print validation; print dtd.error_log.filter_from_errors(); print "Invalid XML:"; xml2=etree.XML(xmlinvalid); validation=dtd.validate(xml2); print validation; print dtd.error_log.filter_from_errors(); The only way I find to port this stript is using DOMDocument::validate() but this method will get the DTD from http://example.com/mydtd.dtd and be slower, generate traffic, and fail when example.com is off-line... I suggest adding an attribute like DOMDocument::validate($source) where $source is a string with DTD source to avoid situations like this... Reproduce code: --- http://example.com/mydtd.dtd'> XML; $xmlok=$xmlstart."The XML file"; $xmlinvalid=$xmlstart."testThe XML file"; $dtddata=""; print "Valid XML:"; $xml1=DOMDocument::loadXML($xmlok); $validation=(int)$xml1->validate($dtddata); //Example that would work print "$validation"; print "Invalid XML:"; $xml1=DOMDocument::loadXML($xmlinvalid); $validation=(int)$xml1->validate($dtddata); //Example that would work print "$validation"; ?> Expected result: Valid XML: 1 Invalid XML: Warning: DOMDocument::validate() [function.DOMDocument-validate]: Element example was declared #PCDATA but contains non text nodes in /script/path/xml.php on line 19 Warning: DOMDocument::validate() [function.DOMDocument-validate]: No declaration for element a in /script/path/xml.php on line 19 0 Actual result: -- When no argument is passed to validate and DTD server is off-line: Valid XML: Warning: DOMDocument::validate(http://example.com/mydtd.dtd) [function.DOMDocument-validate]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /script/path/xml.php on line 14 Warning: DOMDocument::validate() [function.DOMDocument-validate]: I/O warning : failed to load external entity "http://example.com/mydtd.dtd"; in /script/path/xml.php on line 14 Warning: DOMDocument::validate() [function.DOMDocument-validate]: Could not load the external subset "http://example.com/mydtd.dtd"; in /script/path/xml.php on line 14 0 Invalid XML: Warning: DOMDocument::validate(http://example.com/mydtd.dtd) [function.DOMDocument-validate]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /script/path/xml.php on line 19 Warning: DOMDocument::validate() [function.DOMDocument-validate]: I/O warning : failed to load external entity "http://example.com/mydtd.dtd"; in /script/path/xml.php on line 19 Warning: DOMDocument::validate() [function.DOMDocument-validate]: Could not load the external subset "http://example.com/mydtd.dtd"; in /script/path/xml.php on line 19 0 -- Edit bug report at http://bugs.php.net/?id=48080&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48080&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48080&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48080&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48080&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48080&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48080&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48080&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48080&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48080&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48080&r=support Expected behavior: http://bugs.php.net/fix.php?id=48080&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48080&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48080&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48080&r=globals PHP 4 support discontinued: http://bugs.php
