#36795 [Com]: Inappropriate unterminated entity reference in DOMElement-setAttribute
ID: 36795 Comment by: ocus51 at gail 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: Hi, I'm still experiencing this problem : - PHP Version 5.2.0-8+etch7 - DOM/XML API Version 20031129 - libxml Version 2.6.27 Previous Comments: [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 - ?php $xmlStr = ?xml version='1.0' encoding='UTF-8'?root/root; $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 amp;; $result = $xml-asXML(); echo pre.htmlentities($result)./pre; ? - 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. code ?php require_once(sms/messageRelay.class.php); $doc = domxml_new_doc(1.0); $msg = $doc-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 pre; echo $doc-dump_mem(true, UTF-8); echo /pre; ? /code It chokes on the . [2006-04-01 04:49:32] tamit at xmission dot com This is most definitely a bug. I've replicated by producing the following tree in my code: (This is well-formed XML so I have no idea why there would be a problem.) -BEGIN XML ?xml version=1.0 encoding=iso-8859-1? classes class classid=0 parentid= class_level=0Rootclass classid=1 parentid=0 class_level=1Adhesives /class class classid=3286 parentid=0 class_level=1Agricultural and Farming Products/class class classid=3283 parentid=0 class_level=1Architectural and Civil Engineering Products/class class classid=14 parentid=0 class_level=1Automatic ID/class class classid=45 parentid=0 class_level=1Chemical Processing /class class classid=124 parentid=0 class_level=1Cleaning Products /class class classid=148 parentid=0 class_level=1Communication Systems /class class classid=264 parentid=0 class_level=1Computer Hardware /class class classid=3281 parentid=0 class_level=1Construction Equipment and Supplies/class class classid=489 parentid=0 class_level=1Controls /class class classid=589 parentid=0 class_level=1Display /class class classid=612 parentid=0 class_level=1Electrical Equipment /class class classid=772 parentid=0 class_level=1Electronic Components /class class classid=3282 parentid=0 class_level=1Explosives, Armaments, and Weaponry/class class classid=920 parentid=0 class_level=1Fasteners /class class classid=954 parentid=0 class_level=1Fluid /class class classid=3461 parentid=0 class_level=1Food Processing /class class classid=3288 parentid=0 class_level=1Health, Medical, /class class classid=1029 parentid=0 class_level=1HVAC/class class classid=1068 parentid=0 class_level=1Labels Tags Signage /class class classid=3279 parentid=0 class_level=1Laboratory and Research Supplies and Equipment/class class classid=1083 parentid=0 class_level=1Lubricants/class class classid=1106 parentid=0 class_level=1Machinery /class class classid=1424 parentid=0 class_level=1Material Handling /class class classid=1303 parentid=0 class_level=1Materials /class class classid=3284 parentid=0 class_level=1Mechanical Components and Assemblies/class class classid=1620 parentid=0 class_level=1Mechanical Power Transmission/class class classid=3462 parentid=0 class_level=1Mining, Oil Drilling /class class classid=1728 parentid=0 class_level=1Mounting /class class classid=3285 parentid=0 class_level=1Non-Industrial Products/class class classid=1782 parentid=0 class_level=1Optics /class class classid=2054 parentid=0 class_level=1Packaging Equipment /class class classid=2151 parentid=0 class_level=1Paints /class class classid=2185 parentid=0 class_level=1Plant Furnishings
#42779 [Opn]: Non-standards-compliant change in 'Connection' HTTP response header
ID: 42779
User updated by: aya at eh dot org
Reported By: aya at eh dot org
Status: Open
Bug Type: Output Control
Operating System: Linux
-PHP Version: 5.2.4
+PHP Version: 5.2.1
New Comment:
After having done some more research, I think I've found the problem. I
believe it was introduced in PHP v5.2.1 in
sapi/apache2handler/sapi_apache2.c revision 1.57.2.10.2.8 as part of the
fix for bug #38602.
It's reasonable to downgrade the protocol version to HTTP/1.0 upon
receiving a header beginning with HTTP/1.0 , but upgrading the
protocol version to HTTP/1.1 upon receiving a header beginning with
HTTP/1.1 is wrong.
If an HTTP/1.1 webserver receives an HTTP/1.0 request, it should
respond with a header beginning with HTTP/1.1 to indicate to the
client that it is capable of processing HTTP/1.1 requests, BUT the
following response should still be an HTTP/1.0 response.
The section of the code which reads...
/* httpd requires that r-status_line is set to the first digit of
* the status-code: */
if (sline strlen(sline) 12 strncmp(sline, HTTP/1., 7) ==
0 sline[8] == ' ') {
ctx-r-status_line = apr_pstrdup(ctx-r-pool, sline + 9);
ctx-r-proto_num = 1000 + (sline[7]-'0');
if ((sline[7]-'0') == 0) {
apr_table_set(ctx-r-subprocess_env, force-response-1.0,
true);
} else {
apr_table_set(ctx-r-subprocess_env, force-response-1.1,
true);
}
}
...should have the 'else' clause removed.
Previous Comments:
[2007-09-27 16:40:58] aya at eh dot org
Description:
There seems to have been a change in the 'Connection' output header for
HTTP/1.0 requests somewhere between PHP v5.2.0 and PHP v5.2.3.
IIRC, according to the relevant RFCs, When processing an HTTP/1.0
request, the server should respond with an HTTP/1.1 response line if it
supports HTTP/1.1, but the entity headers should be compatible with
HTTP/1.0.
A simple GET / HTTP/1.0 to a PHP page in v5.2.0 returns...
HTTP/1.1 200 OK
Connection: close
...other stuff...
...and then closes the connections as soon as the entity has been
sent.
However, the same request in v5.2.3 returns...
HTTP/1.1 200 OK
...other stuff...
...and then waits for another request, without sending a Connection:
keep-alive header. This is the correct behaviour for an HTTP/1.1
request, but not an HTTP/1.0 request.
In practise, this change prevents apachebench from working correctly
against PHP scripts.
--
Edit this bug report at http://bugs.php.net/?id=42779edit=1
#42782 [Opn]: Failure On OCI8
ID: 42782 User updated by: dgrimes at scvl dot com Reported By: dgrimes at scvl dot com Status: Open Bug Type: Compile Failure Operating System: IA64 HPUX 11.23 PHP Version: 5.2.4 New Comment: If I change OCI8 in the configure statement to: --with-oci8=instantclient,$ORACLE_HOME/instantclient_10_2 I get the following after configure: ++ | *** ATTENTION ***| || | Something is likely to be messed up here, because the configure| | script was not able to detect a simple feature on your platform. | | This is often caused by incorrect configuration parameters. Please | | see the file debug.log for error messages. | || | If you are unable to fix this, send the file debug.log to the | | [EMAIL PROTECTED] mailing list and include appropiate | | information about your setup. | ++ This is what is in debug.log: gcc -o conftest -I/usr/local/include -g -O2 -D_XOPEN_SOURCE_EXTENDED -liconv -L /usr/local/lib -L/usr/local/lib -L/usr/local/lib -L/dc_user01/app/oracle/produc t/10.2/instantclient_10_2 -L/dc_user01/app/oracle/product/10.2/instantclient_10_ 2 conftest.c -liconv -lz -lm -lnsl -lxml2 -lz -liconv -lm -lxml2 -lz -liconv -l m -lclntsh -lnnz10 -lxml2 -lz -liconv -lm 15 conftest.c: In function 'main': conftest.c:3: warning: incompatible implicit declaration of built-in function 'e xit' ld: Mismatched ABI for -lclntsh, found /dc_user01/app/oracle/product/10.2/instan tclient_10_2/libclntsh.so Fatal error. collect2: ld returned 1 exit status Thanks, Dean Previous Comments: [2007-09-27 18:54:34] dgrimes at scvl dot com Description: Trying to compile PHP 5.2.4 with Oracle Instant Client 10.2 and I receive the following error: In file included from /dc_user01/dgrimes/cdev/php-5.2.4/ext/oci8/oci8.c:50: /dc_user01/dgrimes/cdev/php-5.2.4/ext/oci8/php_oci8_int.h:354: error: expected declaration specifiers or '...' before 'oraub8' /dc_user01/dgrimes/cdev/php-5.2.4/ext/oci8/php_oci8_int.h:354: error: expected declaration specifiers or '...' before 'oraub8' make: *** [ext/oci8/oci8.lo] Error 1 Reproduce code: --- Using GCC 4.2.1 GNU Make 3.81 configure \ --with-oci8=shared,instantclient,$ORACLE_HOME/instantclient_10_2 \ --with-zlib-dir=/usr/local \ --without-sqlite \ --without-pdo-sqlite \ --disable-reflection Expected result: A php executable with Oracle support Actual result: -- Compile failure. -- Edit this bug report at http://bugs.php.net/?id=42782edit=1
#42637 [Com]: SoapFault : Only http and https are allowed
ID: 42637
Comment by: wmoran at collaborativefusion dot com
Reported By: christof at sanmax dot be
Status: Assigned
Bug Type: SOAP related
Operating System: Linux
PHP Version: 5.2.4
Assigned To: dmitry
New Comment:
I have yet more information. The problem is related to HTTP redirect
codes (3XX). PHP attempts to follow the redirect, but if the -scheme
is not provided in the redirect URL, PHP leaves it NULL.
See the changes in php_http.c around line 921:
http://cvs.php.net/viewvc.cgi/php-src/ext/soap/php_http.c?view=diffr1=1.77.2.11.2.5%3Aphp_5_2_1tr1=1.109r2=1.77.2.11.2.12%3Aphp_5_2_4tr2=1.1diff_format=h
I'm unclear as to the logic in the 5.2.4 code, as the 5.2.1 version
seems to be correct, or at least:
new_url-scheme = phpurl-scheme ? estrdup(phpurl-scheme) : NULL;
would make more sense to me.
In particular, it's significant to note that you can not reproduce this
unless your soap server issues a 3XX response to your original request,
and does not include a scheme in the Location header of that response.
Previous Comments:
[2007-09-27 16:19:50] wmoran at collaborativefusion dot com
Correction to my last note:
It worked in 5.2.1. I have no testing history against 5.2.2 and 5.2.3.
[2007-09-27 16:04:16] wmoran at collaborativefusion dot com
I can narrow this down a bit further. We did not see this behavior
with 5.2.3, but it occurs with 5.2.4.
[2007-09-12 06:51:02] christof at sanmax dot be
Description:
When sending a request with the SoapClient, a SoapFault is produced :
Fatal error: Uncaught SoapFault exception: [HTTP] Unknown protocol.
Only http and https are allowed.
The probleem seems to be located in the php_url_parse_ex function. In
version 5.1.6 it works fine, in 5.2.4 is does not. The php scheme is
null instead of http according to our tests.
Reproduce code:
---
$base = 'http://some soap service url/service.asmx?WSDL';
$soap = new SoapClient($base, array('trace' = 1));
$login = new StdClass;
$login-userName = 'test';
$login-passWord = 'test';
$login-languageCode = 'NL';
$loginResult = $soap-Login($login);
Expected result:
no soapfault. In php 5.1.6 it works fine, no exception is thrown.
Actual result:
--
Fatal error: Uncaught SoapFault exception: [HTTP] Unknown protocol.
Only http and https are allowed in
/home/data/websites/www/phptest.php:10
Stack trace:
#0 [internal function]: SoapClient-__doRequest('?xml version=...',
'http://demobet5...', 'http://XServer', 1, 0)
#1 [internal function]: SoapClient-__call('Login', Array)
#2 /home/data/websites/www/phptest.php(10):
SoapClient-Login(Object(stdClass))
#3 {main}
thrown in /home/data/websites/www/phptest.php on line 10
--
Edit this bug report at http://bugs.php.net/?id=42637edit=1
#42779 [Opn]: Incorrect forcing from HTTP/1.0 request to HTTP/1.1 response
ID: 42779
User updated by: aya at eh dot org
-Summary: Non-standards-compliant change in 'Connection' HTTP
response header
Reported By: aya at eh dot org
Status: Open
-Bug Type: Output Control
+Bug Type: Apache2 related
-Operating System: Linux
+Operating System: Any
PHP Version: 5.2.1
New Comment:
Updated bug category, summary, and OS.
Previous Comments:
[2007-09-28 14:58:48] aya at eh dot org
After having done some more research, I think I've found the problem. I
believe it was introduced in PHP v5.2.1 in
sapi/apache2handler/sapi_apache2.c revision 1.57.2.10.2.8 as part of the
fix for bug #38602.
It's reasonable to downgrade the protocol version to HTTP/1.0 upon
receiving a header beginning with HTTP/1.0 , but upgrading the
protocol version to HTTP/1.1 upon receiving a header beginning with
HTTP/1.1 is wrong.
If an HTTP/1.1 webserver receives an HTTP/1.0 request, it should
respond with a header beginning with HTTP/1.1 to indicate to the
client that it is capable of processing HTTP/1.1 requests, BUT the
following response should still be an HTTP/1.0 response.
The section of the code which reads...
/* httpd requires that r-status_line is set to the first digit of
* the status-code: */
if (sline strlen(sline) 12 strncmp(sline, HTTP/1., 7) ==
0 sline[8] == ' ') {
ctx-r-status_line = apr_pstrdup(ctx-r-pool, sline + 9);
ctx-r-proto_num = 1000 + (sline[7]-'0');
if ((sline[7]-'0') == 0) {
apr_table_set(ctx-r-subprocess_env, force-response-1.0,
true);
} else {
apr_table_set(ctx-r-subprocess_env, force-response-1.1,
true);
}
}
...should have the 'else' clause removed.
[2007-09-27 16:40:58] aya at eh dot org
Description:
There seems to have been a change in the 'Connection' output header for
HTTP/1.0 requests somewhere between PHP v5.2.0 and PHP v5.2.3.
IIRC, according to the relevant RFCs, When processing an HTTP/1.0
request, the server should respond with an HTTP/1.1 response line if it
supports HTTP/1.1, but the entity headers should be compatible with
HTTP/1.0.
A simple GET / HTTP/1.0 to a PHP page in v5.2.0 returns...
HTTP/1.1 200 OK
Connection: close
...other stuff...
...and then closes the connections as soon as the entity has been
sent.
However, the same request in v5.2.3 returns...
HTTP/1.1 200 OK
...other stuff...
...and then waits for another request, without sending a Connection:
keep-alive header. This is the correct behaviour for an HTTP/1.1
request, but not an HTTP/1.0 request.
In practise, this change prevents apachebench from working correctly
against PHP scripts.
--
Edit this bug report at http://bugs.php.net/?id=42779edit=1
#41350 [Com]: Error in my_thread_global_end()
ID: 41350 Comment by: ricardo dot rodrigues at istimeless dot pt Reported By: graham at directhostinguk dot com Status: No Feedback Bug Type: MySQL related Operating System: Windows 2003 PHP Version: 5.2.3 Assigned To: scottmac New Comment: Error in my_thread_global_end(): 1 threads didn't exit I don't think it's a MySQL error, since i'm not using it at all. I have no active instances of MySQL running. I'm using PHPLIB Templates and the code is very simple: ?php include (Includes/template.inc); $index = new Template(Templates); $index-set_file(f_index, index.tpl); $index-set_var(page_title, INDEX); $index-parse(o_index, f_index); $index-p(o_index); ? I'm running PHP 5.4.2 with MySQL 5.0.45, under Windows XP Pro SP2 with IIS 5.1. Previous Comments: [2007-09-27 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. [2007-09-26 13:31:31] w dot ashcroft at redfoxuk dot com Confirmed on Windows 2003 with IIS6 using MS FastCGI; using libmysql.dll (v5.0.22) from PHP 5.2.1 fixes the problem and massively improves PHP speed globally. [2007-09-26 10:29:02] chris at crgs dot co dot uk Have just tried the latest PHP 5.2 snapshot from http://snaps.php.net/ - *still* doesn't work. I am reproducing this on the most basic machine I can, a Windows 2000 Professional VM (Virtual PC 2007) with all security updates. There is nothing else on the PC, not even a MySQL install, just PHP (see below for settings), but I am still getting the error. However the error *DOES NOT ALWAYS OCCUR*, especially when I just use 'php -v'. Sometimes I have to run this command quite a few times before the error occurs - it comes up maybe 2 times out of 10. When I run it on my main box, outside the virtual machine, 'php -v' doesn't seem to trigger the error much at all: however, using a slightly more complicated command like 'php-cgi test.php' where test.php contains '?php phpinfo(); ?' triggers the error more often, even outside the VM. Are we looking at a race condition? Can people post the specification of their boxes as well? Mine is an Intel Pentium D 3.4Ghz (dual core) w/ 2GB RAM. Of course inside the virtual machine there's only one processor, which might explain partly why the error occurs more often inside the VM, although I don't think it's a single/multi-processor issue at heart, as I can still repro the issue on a dual core PC, just less often. Perhaps it's only an issue on slower machines? Scott, what's your spec? Here is what I did: Download php5.2-win32-200709260830.zip from http://snaps.php.net/ Extract to C:\PHP Append ';C:\PHP' to the PATH environment variable Add PHPRC environment variable, set to 'C:\PHP\php.ini' Copy php.ini-recommended to php.ini Change the following settings: extension_dir = c:\php\ext\ extension=php_mysql.dll Run 'c:\PHP\php-cgi.exe -v' Returns (after a roughly 2 second pause): PHP 5.2.5-dev (cli) (built: Sep 26 2007 04:04:42) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies Error in my_thread_global_end(): 1 threads didn't exit By the way, I also tried setting mysql.allow_persistent = Off, as suggested in some of the comments, but it didn't help in either environment (VM or real). [2007-09-25 17:55:03] daniel dot gaddis at tlc dot state dot tx dot us php -v returned the error using PHP 5.2.5-dev (cli) (built: Sep 9 2007 12:04:32). See mysql and apache version info below. F:\phpphp -v PHP 5.2.5-dev (cli) (built: Sep 9 2007 12:04:32) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies Error in my_thread_global_end(): 1 threads didn't exit F:\MySQL\binmysqladmin --user= --password= version mysqladmin Ver 8.41 Distrib 5.0.45, for Win32 on ia32 Copyright (C) 2000-2006 MySQL AB This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to modify and redistribute it under the GPL license Server version 5.0.45-community-nt-log Protocol version10 Connection localhost via TCP/IP TCP port3306 Uptime: 9 min 57 sec Threads: 1 Questions: 4 Slow queries: 0 Opens: 12 Flush tables: 1 Open tabl es: 6 Queries per second avg: 0.007 F:\Program Files\Apache Group\Apacheapache.exe -v Server version: Apache/1.3.37 (Win32) Server built: Jul 27 2006 15:23:00
#42785 [NEW]: json_encode output numbers formated according the to locales instead of standar
From: gebura at evilkittens dot org
Operating system: Linux / Unix
PHP version: 5.2.4
PHP Bug Type: JSON related
Bug description: json_encode output numbers formated according the to locales
instead of standar
Description:
json_encode() output numbers formated according the to locales instead of
standard format.
For example, in french coma is used for separate decimals. (like 1,5)
But in json:
- numbers must use a point for separate decimals (like 1.5)
- coma is used as field separator. (like a,b)
So the result is not correct.
This bug is related with Bug #40360 ('current locale affects how
json_encode encodes floats') witch is closed.
Reproduce code:
---
?php
if (setlocale(LC_ALL,fr_FR.UTF-8) != fr_FR.UTF-8)
{
die(Could not change the locale!);
}
$foo = Array(100.10,bar);
echo json_encode($foo);
Class bar {}
$bar1 = new bar;
$bar1-a = 100.10;
$bar1-b = foo;
echo json_encode($bar1);
?
Expected result:
[100.1,bar]{a:100.1,b:foo}
Actual result:
--
[100,1,bar] // 2 fields = 3 fields
{a:100,1,b:foo} // the output couldn't be evaluated
--
Edit bug report at http://bugs.php.net/?id=42785edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42785r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42785r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42785r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42785r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42785r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42785r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42785r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42785r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42785r=support
Expected behavior:http://bugs.php.net/fix.php?id=42785r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42785r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42785r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42785r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42785r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42785r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42785r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42785r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42785r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42785r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42785r=mysqlcfg
#42789 [NEW]: join() warning messages are not proper different return value on php5/6
From: kraghuba at in dot ibm dot com Operating system: windows/linux PHP version: 5CVS-2007-09-28 (snap) PHP Bug Type: Strings related Bug description: join() warning messages are not proper different return value on php5/6 Description: join() function doesn't generate proper warning messages when following conditions occur: 1) when join() is called with less than expected no. of argument, the warning message generated refers to implode function. Here is the actual output that is generated(in other warning it doesn't refer to implode function): Warning: join(): Argument to implode must be an array. in %s on line %d NULL 2) When the value of pieces argument is given other than an array, warning message generated is not giving enough info. It should be changed to indicate right required input type. Currently error message that get generated is as follows: Warning: join(): Bad arguments in C:\workdir\ibm\php6\ext\standard\tests\strings\join_variation2.php on line 89 bool(false) 3) the return value of this function differ on php5 and php6 when it generates an warning message: on php5, the return value is NULL on php6, the reutrn value is bool(false) I think, it should be consistent. Reproduce code: --- ?php $glue = , ; var_dump( join($glue) ); // less than expected no. of args $pieces = 10; // not an array var_dump( join($glue, $pieces) ); ? Actual result: -- on php6: - Warning: join(): Argument to implode must be an array in %s on line %d bool(false) Warning: join(): Bad arguments in %s on line %d bool(false) on php5: Warning: join(): Argument to implode must be an array. in %s on line %d NULL Warning: join(): Bad arguments. in %s on line %d NULL -- Edit bug report at http://bugs.php.net/?id=42789edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42789r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42789r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42789r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42789r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42789r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42789r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42789r=needscript Try newer version:http://bugs.php.net/fix.php?id=42789r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42789r=support Expected behavior:http://bugs.php.net/fix.php?id=42789r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42789r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42789r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42789r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42789r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42789r=dst IIS Stability:http://bugs.php.net/fix.php?id=42789r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42789r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42789r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42789r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42789r=mysqlcfg
#42787 [NEW]: max_execution_time not working
From: th at domainbox dot de
Operating system: Debian Etch
PHP version: 4.4.7
PHP Bug Type: Performance problem
Bug description: max_execution_time not working
Description:
If i start the attached code via .so module in Apache or with php -f it
will run forever.
Reproduce code:
---
?
ini_set('max_execution_time','10');
while (true){
sleep(1);
}
?
Expected result:
max_execution_time exceeded
Actual result:
--
Script runs longer than max_excution_time and does not get killed.
--
Edit bug report at http://bugs.php.net/?id=42787edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42787r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42787r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42787r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42787r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42787r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42787r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42787r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42787r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42787r=support
Expected behavior:http://bugs.php.net/fix.php?id=42787r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42787r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42787r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42787r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42787r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42787r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42787r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42787r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42787r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42787r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42787r=mysqlcfg
#42791 [NEW]: HTML img src tag resets session variable
From: dron007 at yahoo dot com
Operating system: Linux
PHP version: 5.2.4
PHP Bug Type: Session related
Bug description: HTML img src tag resets session variable
Description:
There was the bug already posted: http://bugs.php.net/bug.php?id=25966
I also have the similar situation. IMG tag with empty src attribute
deletes session variable. Yes, it is incorrect IMG tag but I spent a lot
of time debugging this situation and I was very surprized that HTML code
have an influence on PHP variables.
Reproduce code:
---
File 1.php:
?
session_start();
$_SESSION[some_var] = null;
if (isset($done)) {
$_SESSION[some_var] = 1;
header(Location: 2.php);
die();
}
?
a href=1.php?done=1Goto 2/a
---
File 2.php:
?
session_start();
echo 'some_var='.$_SESSION[some_var].'br';
echo 'img src=';
?
Expected result:
I first load file 1.php, then go by link which sets session variable, then
I see some_var=1 which is correct.
If I reload 2.php I expect to see some_var=1
Actual result:
--
some_var=
Session variable is destroyed.
--
Edit bug report at http://bugs.php.net/?id=42791edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42791r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42791r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42791r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42791r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42791r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42791r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42791r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42791r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42791r=support
Expected behavior:http://bugs.php.net/fix.php?id=42791r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42791r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42791r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42791r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42791r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42791r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42791r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42791r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42791r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42791r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42791r=mysqlcfg
#42790 [NEW]: strrchr() doesn't work as expected with heredoc string containing blank line
From: mahesh dot vemula at in dot ibm dot com Operating system: RHEL 4, Windows XP PHP version: 5CVS-2007-09-28 (snap) PHP Bug Type: Strings related Bug description: strrchr() doesn't work as expected with heredoc string containing blank line Description: strrchr() function can't find the new line when an heredoc string containing only a blank line is given as input, whereas it works fine when the heredoc string containing regular string with new line. This is noticed on php5 and php6. Reproduce code: --- ?php $str1 = EOD EOD; $str2 = EOD hello hiii EOD; //doesn't work as expected var_dump( strrchr($str1, $str1) ); var_dump( strrchr($str1, \n) ); var_dump( strrchr($str1, ) ); //works as expected var_dump( strrchr($str2, \n) ); var_dump( strrchr($str2, ) ); ? Expected result: string(1) string(1) string(1) string(9) hiii string(9) hiii Actual result: -- bool(false) bool(false) bool(false) string(9) hiii string(9) hiii -- Edit bug report at http://bugs.php.net/?id=42790edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42790r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42790r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42790r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42790r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42790r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42790r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42790r=needscript Try newer version:http://bugs.php.net/fix.php?id=42790r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42790r=support Expected behavior:http://bugs.php.net/fix.php?id=42790r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42790r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42790r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42790r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42790r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42790r=dst IIS Stability:http://bugs.php.net/fix.php?id=42790r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42790r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42790r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42790r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42790r=mysqlcfg
#42637 [Com]: SoapFault : Only http and https are allowed
ID: 42637
Comment by: wmoran at collaborativefusion dot com
Reported By: christof at sanmax dot be
Status: Assigned
Bug Type: SOAP related
Operating System: Linux
PHP Version: 5.2.4
Assigned To: dmitry
New Comment:
In the file ext/soap/php_http.c, changing line 921 from
new_url-scheme = NULL;
to
new_url-scheme = phpurl-scheme ? estrdup(phpurl-scheme) : NULL;
Solves the problem for me.
Previous Comments:
[2007-09-28 15:45:47] wmoran at collaborativefusion dot com
I have yet more information. The problem is related to HTTP redirect
codes (3XX). PHP attempts to follow the redirect, but if the -scheme
is not provided in the redirect URL, PHP leaves it NULL.
See the changes in php_http.c around line 921:
http://cvs.php.net/viewvc.cgi/php-src/ext/soap/php_http.c?view=diffr1=1.77.2.11.2.5%3Aphp_5_2_1tr1=1.109r2=1.77.2.11.2.12%3Aphp_5_2_4tr2=1.1diff_format=h
I'm unclear as to the logic in the 5.2.4 code, as the 5.2.1 version
seems to be correct, or at least:
new_url-scheme = phpurl-scheme ? estrdup(phpurl-scheme) : NULL;
would make more sense to me.
In particular, it's significant to note that you can not reproduce this
unless your soap server issues a 3XX response to your original request,
and does not include a scheme in the Location header of that response.
[2007-09-27 16:19:50] wmoran at collaborativefusion dot com
Correction to my last note:
It worked in 5.2.1. I have no testing history against 5.2.2 and 5.2.3.
[2007-09-27 16:04:16] wmoran at collaborativefusion dot com
I can narrow this down a bit further. We did not see this behavior
with 5.2.3, but it occurs with 5.2.4.
[2007-09-12 06:51:02] christof at sanmax dot be
Description:
When sending a request with the SoapClient, a SoapFault is produced :
Fatal error: Uncaught SoapFault exception: [HTTP] Unknown protocol.
Only http and https are allowed.
The probleem seems to be located in the php_url_parse_ex function. In
version 5.1.6 it works fine, in 5.2.4 is does not. The php scheme is
null instead of http according to our tests.
Reproduce code:
---
$base = 'http://some soap service url/service.asmx?WSDL';
$soap = new SoapClient($base, array('trace' = 1));
$login = new StdClass;
$login-userName = 'test';
$login-passWord = 'test';
$login-languageCode = 'NL';
$loginResult = $soap-Login($login);
Expected result:
no soapfault. In php 5.1.6 it works fine, no exception is thrown.
Actual result:
--
Fatal error: Uncaught SoapFault exception: [HTTP] Unknown protocol.
Only http and https are allowed in
/home/data/websites/www/phptest.php:10
Stack trace:
#0 [internal function]: SoapClient-__doRequest('?xml version=...',
'http://demobet5...', 'http://XServer', 1, 0)
#1 [internal function]: SoapClient-__call('Login', Array)
#2 /home/data/websites/www/phptest.php(10):
SoapClient-Login(Object(stdClass))
#3 {main}
thrown in /home/data/websites/www/phptest.php on line 10
--
Edit this bug report at http://bugs.php.net/?id=42637edit=1
#40479 [Com]: zend_mm_heap corrupted
ID: 40479 Comment by: peter at ibuildings dot nl Reported By: rrossi at maggioli dot it Status: No Feedback Bug Type: Reproducible crash Operating System: Suse Linux 9.0 PHP Version: 5.2.1 New Comment: Same problem here on OS X 10.4.10, ZendCore 2.0.1, PHP 5.2.3. Previous Comments: [2007-09-08 02:03:44] danny at dannysplace dot net I have the same problem when trying to run a fresh version of Horde with Kronolith module. Php v5.2.3 on FreeBSD 6.2 nad apache 2.0.59. [2007-08-16 08:03:54] rz at lightwerk dot com I have the same error message in my apache logs with PHP 5.2.3 zend_mm_heap corupted. I tried to track it down to a specific code but it seems to be a problem with included files (classes) which exceeds a specific size. No matter which lines I delete in my script as long as they don´t excess about 700 lines they work. As soon as the overall lines exceed about 700 lines the error occurs again. Hope this will help you to fix the problem. [2007-07-03 23:32:55] giampaolo at tomassoni dot biz I'm experiencing the very same problem reported by rocker_pr. It seems to me that this problem is triggered by using PHP5 classes, but I can't provide a small testcase: no small code seems affected. [2007-04-26 14:11:47] christian dot kaps at imaxx21 dot com Hi I get the same message in my logs. I can reproduce the error in our system, but it is impossible to locate it. Sometimes I can reproduce the error by editing a comment. I add a character and the error occurs. I remove the character and the script runs perfectly. Each time I try to isolate the error I can reproduce it with an other action. That what i could isolate is: -load xml file with simplexml -add a node -clone the object -process xpath query -print the object with print_r -serialize the object -include a file (the error occurs) When I edit the included file. E.g. remove methods or properties the script runs without errors. That is funny(o; Version: 5.2.1 Os: ubuntu [2007-04-17 14:04:58] [EMAIL PROTECTED] We still don't have zero info on how to reproduce it. 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/40479 -- Edit this bug report at http://bugs.php.net/?id=40479edit=1
#42261 [Csd-Opn]: header wrong for date field
ID: 42261
User updated by: roberto at spadim dot com dot br
Reported By: roberto at spadim dot com dot br
-Status: Closed
+Status: Open
Bug Type: dBase related
Operating System: any
PHP Version: 5.2.4RC1
New Comment:
hello, the same error occur now for logic data (boolean)
[0] = Array
(
[name] = SUSPENSO
[type] = boolean
[length] = 34817 = should be 1
[precision] = 0
[format] = %34817s
[offset] = 1
)
[1] = Array
(
[name] = COD_CAD
[type] = number
[length] = 9
[precision] = 0
:
Previous Comments:
[2007-08-10 00:30:11] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2007-08-09 22:57:45] spadim at spadim dot com dot br
this could be the same problem of bug #27470
[2007-08-09 20:01:15] roberto at spadim dot com dot br
an dbf file could be get from here: www.spadim.com.br/dbf.dbf
[2007-08-09 19:26:14] roberto at spadim dot com dot br
an dbf file could be get from here: www.spadim.com.br/dbf.dbf
[2007-08-09 19:04:42] roberto at spadim dot com dot br
Description:
sometimes i get 520 size of date field, that's wrong since i can open
files on clipper
i changed source to set field length to 8 and precision to 0 when type
of field is 'D' and it's work, please checkit
Reproduce code:
---
some dbf files have problem
Expected result:
header information of date always be 8 length
Actual result:
--
520 length in some cases
check what i do: dbf_head.c
line ~160
switch (dbf-db_type) {
case 'N':
case 'F':
dbf-db_flen = dbfield.dbf_flen[0];
dbf-db_fdc = dbfield.dbf_flen[1];
break;
=case 'D':
=dbf-db_flen = 8;
=break;
default:
dbf-db_flen = get_short(dbfield.dbf_flen);
break;
}
--
Edit this bug report at http://bugs.php.net/?id=42261edit=1
#42792 [NEW]: bitwise bug
From: yy at jjxx dot com Operating system: FreeBSD 6.2 PHP version: 5.2.4 PHP Bug Type: *Math Functions Bug description: bitwise bug Description: ./configure --with-apxs=/usr/local/apache/sbin/apxs --disable-debug --with-xml --with-gd --with-iconv --prefix=/usr/local/php --with-jpeg-dir --with-png-dir --with-ttf --with-freetype-dir --enable-gd-native-ttf --disable-posix --enable-mbstring --with-pgsql --with-config-file-path=/usr/local/php/lib --with-curl --enable-bcmath Reproduce code: --- echo( -4738698913 ^ 43814 ); echo \n; echo decbin(-4738698913); Expected result: -443704711 1110010110001101001100010101 Actual result: -- -2147439834 1000 -- Edit bug report at http://bugs.php.net/?id=42792edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42792r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42792r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42792r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42792r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42792r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42792r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42792r=needscript Try newer version:http://bugs.php.net/fix.php?id=42792r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42792r=support Expected behavior:http://bugs.php.net/fix.php?id=42792r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42792r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42792r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42792r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42792r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42792r=dst IIS Stability:http://bugs.php.net/fix.php?id=42792r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42792r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42792r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42792r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42792r=mysqlcfg
#21649 [Com]: This this problem with fopen() function for windows
ID: 21649
Comment by: fkl at tfu dot jgfi
Reported By: lipinski7722 at rogers dot com
Status: No Feedback
Bug Type: Filesystem function related
Operating System: win2000 server
PHP Version: 4.3.0
New Comment:
http://www.meta-fx.com
forexÝÇÑÓ
Previous Comments:
[2007-06-08 08:00:06] manny dot ovena at dev dot com
In order to change the include_path in pear you must reinstall pear
after you have made the changes to the php.ini file. Install PHP,
change PHP.ini, and then use go-pear.bat.
[2003-02-25 02:05:13] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to Open. Thank you.
[2003-02-19 19:25:39] [EMAIL PROTECTED]
Using this script:
?php
error_reporting(E_ALL);
ini_set('include_path','.;c:\\');
$fp=fopen('autoexec.bat','r', 1);
echo ini_get('include_path');
?
I can't reproduce this (with PHP 4.3.2-dev) under Windows 2000. Please
try it out.
[2003-01-18 11:52:39] lipinski7722 at rogers dot com
User is administrator this is on localhost
where PHP4 is configured as Apache 1.3 module
What else I have to do in hppdcon for apache ?
Best Regards
W.J.Lipinski
[2003-01-17 21:15:33] [EMAIL PROTECTED]
Are you sure the webserver user has rights to access that path even?
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/21649
--
Edit this bug report at http://bugs.php.net/?id=21649edit=1
#42793 [NEW]: php function get_meta_tags()
From: webmaster at adriaportal dot com Operating system: Windows NT 5.2 build 3790 PHP version: 5.2.4 PHP Bug Type: Unknown/Other Function Bug description: php function get_meta_tags() Description: Hello, here is a piece of index.php of my site (www.adriaportal.com / www.adriaportal.eu), between opening and closing tag of head. head meta http-equiv=Content-Language content=cs meta http-equiv=Content-Type content=text/html; charset=windows-1250 titleAdria portal/title meta name=description content=Promotion of tourism and introduction to the culture of Czech and Croatian people. lang=en-US meta name=description content=Podpora rozvoje turizmu a vzájemné poznávání kultur Chorvatù a Èechù. lang=cs-CZ meta name=description content=Podrka razvoja turizma i uzajamnog upoznavanja kultura Èeha i Hrvata. lang=hr-HR meta name=keywords content=czech,republic,croatia,holiday,sea,adritic,links,portal,accomodation,connections,directory,dictionary,news lang=en-US meta name=keywords content=èechy,èeská,republika,chorvatská,chorvatsko,dovolená,moøe,jadran,odkazy,portál,ubytování,spojení,adresáø,slovník,novinky lang=cs-CZ meta name=keywords content=èeka,republika,hrvatska,odmor,more,jadran,linkovi,portal,smjetaj,veze,adresao,rijeènik,vijesti lang=hr-HR /head I'm test the function on my site index page. Reproduce code: --- Here is my code of testing: $myArr = get_meta_tags(http://www.adriaportal.com/;); print_r($myArr); Expected result: Expected is: Array ( [http-equiv][0] = Content-Language content=cs, [http-equiv][1] = Content-Type content=text/html; charset=windows-1250, [description][0] = Promotion of tourism and introduction to the culture of Czech and Croatian people., [description][1] = Podpora rozvoje turizmu a vzájemné poznávání kultur Chorvatù a Èechù., [description][2] = Podrka razvoja turizma i uzajamnog upoznavanja kultura Èeha i Hrvata., [keywords][0]= czech,republic,croatia,holiday,sea,adritic,links,portal,accomodation,connections,directory,dictionary,news, [keywords][1]= èechy,èeská,republika,chorvatská,chorvatsko,dovolená,moøe,jadran,odkazy,portál,ubytování,spojení,adresáø,slovník,novinky, [keywords][2]= èeka,republika,hrvatska,odmor,more,jadran,linkovi,portal,smjetaj,veze,adresao,rijeènik,vijesti, ) or better array structure with all attributes of adequate meta tag Actual result: -- And the result: Array ( [description] = Podrka razvoja turizma i uzajamnog upoznavanja kultura Èeha i Hrvata. [keywords] = èeka,republika,hrvatska,odmor,more,jadran,linkovi,portal,smjetaj,veze,adresao,rijeènik,vijesti ) I'm cannot see in result these tags: meta http-equiv=Content-Language content=cs meta http-equiv=Content-Type content=text/html; charset=windows-1250 and i'm see only the description and keywords meta tags, all the last rows in header, here in croatian language (owerrides the before parsed rows?). Is this a BUG or i'm make something false? Thank's for your response ;o) Djordje Zurovac P.S. Sorry for my english (?), i'm can active only czech, croatian and german languages. -- Edit bug report at http://bugs.php.net/?id=42793edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42793r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42793r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42793r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42793r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42793r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42793r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42793r=needscript Try newer version:http://bugs.php.net/fix.php?id=42793r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42793r=support Expected behavior:http://bugs.php.net/fix.php?id=42793r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42793r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42793r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42793r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42793r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42793r=dst IIS Stability:http://bugs.php.net/fix.php?id=42793r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42793r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42793r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42793r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42793r=mysqlcfg
#42663 [Opn]: gzinflate() try to allocate all memory with truncated $data
ID: 42663
User updated by: arnaud dot lb at gmail dot com
Reported By: arnaud dot lb at gmail dot com
Status: Open
Bug Type: Zlib Related
Operating System: Linux 2.6
PHP Version: 5.2.4
New Comment:
I wrote a testcase for this bug:
http://s3.amazonaws.com/arnaud.lb/gzinflate-bug42663.phpt.txt
Previous Comments:
[2007-09-16 17:43:11] arnaud dot lb at gmail dot com
It works with any compressed data if you truncate it.
The yuicompressor-1.0.zip file used for this example can be found
here:
http://www.julienlecomte.net/yuicompressor/yuicompressor-1.0.zip
[2007-09-16 14:52:47] [EMAIL PROTECTED]
Can you please provide a URL to the file with corrupted data.
[2007-09-13 18:33:23] arnaud dot lb at gmail dot com
Example code in a more readable format:
?php
ini_set('memory_limit', -1);
// compressing a ~1.6MB file with gzdeflate()
$data =
gzdeflate(file_get_contents(/home/noch/yuicompressor-1.0.zip), 9);
echo Compressed length: . strlen($data) . \n;
// gzinflate() works with original $data
gzinflate($data);
// Truncating compressed $data
$data = substr($data, 0, 65535);
echo Truncated length: . strlen($data) . \n;
// Bug is here:
gzinflate($data);
?
[2007-09-13 18:28:28] arnaud dot lb at gmail dot com
Description:
gzinflate() try to allocate all memory with truncated $data:
Fatal error: Out of memory (allocated 1074003968) (tried to allocate
2147450880 bytes) in Command line code on line 1
Zlib version: 1.2.3.3
Reproduce code:
---
/tmp/php-5.2.4$ ./configure --disable-all --enable-cli --with-zlib
make -j4
/tmp/php-5.2.4$ sapi/cli/php -d memory_limit=-1 -r '$data =
gzdeflate(file_get_contents(/tmp/yuicompressor-1.0.zip), 9); echo
Compressed length: . strlen($data) . \n; gzinflate($data); $data =
substr($data, 0, 65535); echo Truncated length: . strlen($data) .
\n; gzinflate($data);'
Expected result:
gzinflate() should return FALSE, without eating all memory
Actual result:
--
Fatal error: Out of memory (allocated 1074003968) (tried to allocate
2147450880 bytes) in Command line code on line 1
--
Edit this bug report at http://bugs.php.net/?id=42663edit=1
#42791 [Opn-Fbk]: HTML img src tag resets session variable
ID: 42791
Updated by: [EMAIL PROTECTED]
Reported By: dron007 at yahoo dot com
-Status: Open
+Status: Feedback
Bug Type: Session related
Operating System: Linux
PHP Version: 5.2.4
New Comment:
With what browser are you trying this with? IIRC, there was some issue
with IE and broken html and it not sending some headers then.
Previous Comments:
[2007-09-28 17:55:24] dron007 at yahoo dot com
Description:
There was the bug already posted: http://bugs.php.net/bug.php?id=25966
I also have the similar situation. IMG tag with empty src attribute
deletes session variable. Yes, it is incorrect IMG tag but I spent a
lot of time debugging this situation and I was very surprized that HTML
code have an influence on PHP variables.
Reproduce code:
---
File 1.php:
?
session_start();
$_SESSION[some_var] = null;
if (isset($done)) {
$_SESSION[some_var] = 1;
header(Location: 2.php);
die();
}
?
a href=1.php?done=1Goto 2/a
---
File 2.php:
?
session_start();
echo 'some_var='.$_SESSION[some_var].'br';
echo 'img src=';
?
Expected result:
I first load file 1.php, then go by link which sets session variable,
then I see some_var=1 which is correct.
If I reload 2.php I expect to see some_var=1
Actual result:
--
some_var=
Session variable is destroyed.
--
Edit this bug report at http://bugs.php.net/?id=42791edit=1
#42793 [Opn-Bgs]: php function get_meta_tags()
ID: 42793 Updated by: [EMAIL PROTECTED] Reported By: webmaster at adriaportal dot com -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows NT 5.2 build 3790 PHP Version: 5.2.4 New Comment: From the manual page: http://php.net/get_meta_tags you can find this: The value of the name property becomes the key, the value of the content property becomes the value of the returned array, so you can easily use standard array functions to traverse it or access single values. Special characters in the value of the name property are substituted with '_', the rest is converted to lower case. If two meta tags have the same name, only the last one is returned. So there is no bug here. Previous Comments: [2007-09-28 20:58:58] webmaster at adriaportal dot com Description: Hello, here is a piece of index.php of my site (www.adriaportal.com / www.adriaportal.eu), between opening and closing tag of head. head meta http-equiv=Content-Language content=cs meta http-equiv=Content-Type content=text/html; charset=windows-1250 titleAdria portal/title meta name=description content=Promotion of tourism and introduction to the culture of Czech and Croatian people. lang=en-US meta name=description content=Podpora rozvoje turizmu a vzájemné poznávání kultur Chorvatù a Èechù. lang=cs-CZ meta name=description content=Podrka razvoja turizma i uzajamnog upoznavanja kultura Èeha i Hrvata. lang=hr-HR meta name=keywords content=czech,republic,croatia,holiday,sea,adritic,links,portal,accomodation,connections,directory,dictionary,news lang=en-US meta name=keywords content=èechy,èeská,republika,chorvatská,chorvatsko,dovolená,moøe,jadran,odkazy,portál,ubytování,spojení,adresáø,slovník,novinky lang=cs-CZ meta name=keywords content=èeka,republika,hrvatska,odmor,more,jadran,linkovi,portal,smjetaj,veze,adresao,rijeènik,vijesti lang=hr-HR /head I'm test the function on my site index page. Reproduce code: --- Here is my code of testing: $myArr = get_meta_tags(http://www.adriaportal.com/;); print_r($myArr); Expected result: Expected is: Array ( [http-equiv][0] = Content-Language content=cs, [http-equiv][1] = Content-Type content=text/html; charset=windows-1250, [description][0] = Promotion of tourism and introduction to the culture of Czech and Croatian people., [description][1] = Podpora rozvoje turizmu a vzájemné poznávání kultur Chorvatù a Èechù., [description][2] = Podrka razvoja turizma i uzajamnog upoznavanja kultura Èeha i Hrvata., [keywords][0]= czech,republic,croatia,holiday,sea,adritic,links,portal,accomodation,connections,directory,dictionary,news, [keywords][1]= èechy,èeská,republika,chorvatská,chorvatsko,dovolená,moøe,jadran,odkazy,portál,ubytování,spojení,adresáø,slovník,novinky, [keywords][2]= èeka,republika,hrvatska,odmor,more,jadran,linkovi,portal,smjetaj,veze,adresao,rijeènik,vijesti, ) or better array structure with all attributes of adequate meta tag Actual result: -- And the result: Array ( [description] = Podrka razvoja turizma i uzajamnog upoznavanja kultura Èeha i Hrvata. [keywords] = èeka,republika,hrvatska,odmor,more,jadran,linkovi,portal,smjetaj,veze,adresao,rijeènik,vijesti ) I'm cannot see in result these tags: meta http-equiv=Content-Language content=cs meta http-equiv=Content-Type content=text/html; charset=windows-1250 and i'm see only the description and keywords meta tags, all the last rows in header, here in croatian language (owerrides the before parsed rows?). Is this a BUG or i'm make something false? Thank's for your response ;o) Djordje Zurovac P.S. Sorry for my english (?), i'm can active only czech, croatian and german languages. -- Edit this bug report at http://bugs.php.net/?id=42793edit=1
#42774 [Opn-Fbk]: $_SESSION data not written if var populated from function first
ID: 42774
Updated by: [EMAIL PROTECTED]
Reported By: johns582 at mail dot msu dot edu
-Status: Open
+Status: Feedback
Bug Type: Session related
Operating System: Debian 4.1.1; FreeBSD 4.8
PHP Version: 5.2.4
New Comment:
Can you please provide a short but complete reproduce script?
Previous Comments:
[2007-09-27 13:02:22] johns582 at mail dot msu dot edu
No, register globals is off. Added note: this code worked in versions
of PHP = 5.0.5
[2007-09-27 09:46:05] [EMAIL PROTECTED]
Is register_globals=On ?
[2007-09-27 04:10:26] johns582 at mail dot msu dot edu
Description:
We use a function (see below) to populate variables based on whether
there is a key present in the $_GET, $_POST, or $_SESSION arrays. After
this function is called and the result assigned to a variable, we save
the variable in a session with:
$_SESSION['var'] = $var;
The result of this statement is that the variable $var is successful
stored in $_SESSION but is not saved to the session file, which is what
we expect. We can correct the problem by taking the logic in the
function below out of the function and placing it into the body of the
main script. We've also noticed that even when the function is called by
the main script, but not used to assign a value to a variable we intend
to store in a session, this is enough to break the session in the
manner described above (e.g.,
//DOESN'T WORK TO MAKE $f_name and $l_name appear in the session file
//even though we aren't actually storing the value of $f_name_p or
//$l_name_p in the session. But works if lines 3 and 4 are removed.
$f_name = $_POST['f_name'];
$l_name = $_POST['l_name'];
$f_name_p = populate_rev (f_name, $_GET, $_POST, $_SESSION);
$l_name_p = populate_rev (l_name, $_GET, $_POST, $_SESSION);
$_SESSION['f_name'] = $f_name;
$_SESSION['l_name'] = $l_name;
One last point: This problem occurs with both the default files
session handler and a custom db-backed handler. Using the db-backed
handler, we can confirm that the overloaded write function received a
session key, but no data.
Reproduce code:
---
function populate_rev ($array_index, $_GET, $_POST, $_SESSION) {
if (isset($_GET[$array_index])) {
$var = $_GET[$array_index];
}
elseif (isset($_POST[$array_index])) {
$var = $_POST[$array_index];
}
elseif (isset($_SESSION[$array_index])) {
$var = $_SESSION[$array_index];
}
else {
$var = '';
}
return $var;
}
Expected result:
Expected to see the string f_name|s:7:Heather;l_name|s:7:Johnson;
present in the session file or in the database (depending on which
handler was currently being used), for example, following assignment of
$f_name and $l_name to the corresponding key in $_SESSION and
termination of the script.
Actual result:
--
Even though the $_SESSION array contains the expected key/value pairs,
the session file or database row (in the case of our custom handler)
doesn't contain them. No data is passed to the session write function in
the case of the custom handler. Moving the function's logic into the
main body of the script, or abandoning the function in favor of straight
assignment from the $_POST vars array is the only way to produce the
expected result. (e.g.,
$f_name = $_POST['f_name'];
$l_name = $_POST['l_name'];
--
Edit this bug report at http://bugs.php.net/?id=42774edit=1
#42770 [Opn-Bgs]: defined() not catching class lookup miss properly
ID: 42770
Updated by: [EMAIL PROTECTED]
Reported By: tautolog at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.2.4
New Comment:
We don't support any 3rd party extensions. This includes the Zend
Optimizer and such. (ask support for those at zend.com instead)
If you're able to reproduce this without any zend extensions enabled
(any extension enabled using zend_extension directive in php.ini is one
:) send me an email.
Otherwise this is bogus.
Previous Comments:
[2007-09-27 13:53:53] tautolog at gmail dot com
Hi again,
I built 5.2.4 to try to reproduce it myself, but I was unable to
reproduce it with the code I provided. I got the expected result, not
the error. I was thinking that perhaps the use of Zend Guard and Zend
Optimizer may have something to do with it. I am still investigating...
Thanks,
Ben
[2007-09-26 21:33:38] tautolog at gmail dot com
Description:
Hi,
It appears that defined() is not catching a class lookup miss properly,
and throwing a fatal error instead.
This is happening on a customer's 5.2.4 install. It works fine on my
5.2.3 install.
I haven't actually seen it for myself, but a customer told me that he
is on php 5.2.4 and that he got this error:
[Wed Sep 19 09:20:17 2007] [error] [client 85.178.73.32] PHP Fatal
error: Class '.. ' not found in
/var/www/html/mb5/lib-action/include/smarty/core/plugins/modifier.constant.php
on line 20
And that line is:
if (defined($string)) {
The values of $string at that point was probably this:
.. :: 1000 MB Webspace :: 100 GB Traffic :: ..
Thank you,
Ben
Reproduce code:
---
echo ?php echo (int) defined('.. :: 1000 MB Webspace :: 100 GB
Traffic :: ..'); | php
Expected result:
0
Actual result:
--
PHP Fatal error: Class '.. ' not found
--
Edit this bug report at http://bugs.php.net/?id=42770edit=1
#42305 [Opn-Fbk]: Segmentation fault after php script proccessing end
ID: 42305 Updated by: [EMAIL PROTECTED] Reported By: danil dot megrabjan at gmail dot com -Status: Open +Status: Feedback Bug Type: PDO related Operating System: SLES10 PHP Version: 5.2.4 New Comment: First of all you need to come up with the shortest possible script that can be used to reproduce this issue. Previous Comments: [2007-09-27 10:37:17] danil dot megrabjan at gmail dot com Yep, now i have only one crash situation. Maybe PDO_ODBC or unixODBC... Short bt, for you: #0 0xb785cbee in uodbc_update_stats (h=0x74656c, stats_type_mask=3, value=0x1) at __stats.c:379 #1 0xb7814c3f in __SQLAllocHandle (handle_type=3, input_handle=0x8335408, output_handle=0x847c608, requested_version=0) at SQLAllocHandle.c:1064 #2 0xb78159e4 in SQLAllocHandle (handle_type=21512, input_handle=0x8335408, output_handle=0x847c608) at SQLAllocHandle.c:1270 #3 0xb7a56487 in odbc_handle_preparer (dbh=0x825c6f4, sql=0x847c220 SELECT TPRTREE.PT_ID, TPRTREE.PT_PARENTID, TPRTREE.PT_CODE, TPRTREE.PT_ORDER, TASKCODE=(CASE WHEN PT_LEVEL1=0 THEN PT_CODE ELSE CONVERT(int,PT_LEVEL1) END), TPRTREE.PT_VISIBLENAME, TPRTREE.PT_LEVEL1, ..., sql_len=453, stmt=0x847b3f8, driver_options=0x847afd0) at /home/bagroff/distfiles/php5.2-200709251230/ext/pdo_odbc/odbc_driver.c:172 #4 0xb7a4a27d in zim_PDO_prepare (ht=2, return_value=0x847b954, return_value_ptr=0x0, this_ptr=0x82e2bac, return_value_used=1) at /home/bagroff/distfiles/php5.2-200709251230/ext/pdo/pdo_dbh.c:580 #5 0xb7c5abdc in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe41994) at /home/bagroff/distfiles/php5.2-200709251230/Zend/zend_vm_execute.h:200 #6 0xb7c5b829 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfe41994) at /home/bagroff/distfiles/php5.2-200709251230/Zend/zend_vm_execute.h:322 #7 0xb7c5a73d in execute (op_array=0x842c3a0) at /home/bagroff/distfiles/php5.2-200709251230/Zend/zend_vm_execute.h:92 #8 0xb7c5ad56 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe41da4) at /home/bagroff/distfiles/php5.2-200709251230/Zend/zend_vm_execute.h:234 #9 0xb7c5b829 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfe41da4) at /home/bagroff/distfiles/php5.2-200709251230/Zend/zend_vm_execute.h:322 #10 0xb7c5a73d in execute (op_array=0x8425e84) at /home/bagroff/distfiles/php5.2-200709251230/Zend/zend_vm_execute.h:92 #11 0xb7c5ad56 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe42494) at /home/bagroff/distfiles/php5.2-200709251230/Zend/zend_vm_execute.h:234 #12 0xb7c5b829 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfe42494) at /home/bagroff/distfiles/php5.2-200709251230/Zend/zend_vm_execute.h:322 #13 0xb7c5a73d in execute (op_array=0x8425084) at /home/bagroff/distfiles/php5.2-200709251230/Zend/zend_vm_execute.h:92 #14 0xb7c5ad56 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe43464) at /home/bagroff/distfiles/php5.2-200709251230/Zend/zend_vm_execute.h:234 #15 0xb7c5b829 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfe43464) at /home/bagroff/distfiles/php5.2-200709251230/Zend/zend_vm_execute.h:322 #16 0xb7c5a73d in execute (op_array=0x83a527c) at /home/bagroff/distfiles/php5.2-200709251230/Zend/zend_vm_execute.h:92 #17 0xb7c5ad56 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe43694) at /home/bagroff/distfiles/php5.2-200709251230/Zend/zend_vm_execute.h:234 #18 0xb7c5b829 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfe43694) at /home/bagroff/distfiles/php5.2-200709251230/Zend/zend_vm_execute.h:322 #19 0xb7c5a73d in execute (op_array=0x83a1a10) at /home/bagroff/distfiles/php5.2-200709251230/Zend/zend_vm_execute.h:92 #20 0xb7c5ad56 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe438d4) at /home/bagroff/distfiles/php5.2-200709251230/Zend/zend_vm_execute.h:234 #21 0xb7c5b829 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfe438d4) at /home/bagroff/distfiles/php5.2-200709251230/Zend/zend_vm_execute.h:322 #22 0xb7c5a73d in execute (op_array=0x82bcd74) at /home/bagroff/distfiles/php5.2-200709251230/Zend/zend_vm_execute.h:92 #23 0xb7c5ad56 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe43be4) at /home/bagroff/distfiles/php5.2-200709251230/Zend/zend_vm_execute.h:234 ---Type return to continue, or q return to quit--- #24 0xb7c5b829 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfe43be4) at /home/bagroff/distfiles/php5.2-200709251230/Zend/zend_vm_execute.h:322 #25 0xb7c5a73d in execute (op_array=0x83307d4) at /home/bagroff/distfiles/php5.2-200709251230/Zend/zend_vm_execute.h:92 #26 0xb7c5ad56 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe440b4) at /home/bagroff/distfiles/php5.2-200709251230/Zend/zend_vm_execute.h:234 #27 0xb7c5b829 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfe440b4) at
#42782 [Opn-Bgs]: Failure On OCI8
ID: 42782 Updated by: [EMAIL PROTECTED] Reported By: dgrimes at scvl dot com -Status: Open +Status: Bogus Bug Type: OCI8 related Operating System: IA64 HPUX 11.23 PHP Version: 5.2.4 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. - The oraub8 issue is an Oracle bug (#4901517) on AIX and HP-UX 64 bit. See http://forums.oracle.com/forums/thread.jspa?messageID=1929534 for the workaround. - Previous Comments: [2007-09-28 13:57:22] dgrimes at scvl dot com If I change OCI8 in the configure statement to: --with-oci8=instantclient,$ORACLE_HOME/instantclient_10_2 I get the following after configure: ++ | *** ATTENTION ***| || | Something is likely to be messed up here, because the configure| | script was not able to detect a simple feature on your platform. | | This is often caused by incorrect configuration parameters. Please | | see the file debug.log for error messages. | || | If you are unable to fix this, send the file debug.log to the | | [EMAIL PROTECTED] mailing list and include appropiate | | information about your setup. | ++ This is what is in debug.log: gcc -o conftest -I/usr/local/include -g -O2 -D_XOPEN_SOURCE_EXTENDED -liconv -L /usr/local/lib -L/usr/local/lib -L/usr/local/lib -L/dc_user01/app/oracle/produc t/10.2/instantclient_10_2 -L/dc_user01/app/oracle/product/10.2/instantclient_10_ 2 conftest.c -liconv -lz -lm -lnsl -lxml2 -lz -liconv -lm -lxml2 -lz -liconv -l m -lclntsh -lnnz10 -lxml2 -lz -liconv -lm 15 conftest.c: In function 'main': conftest.c:3: warning: incompatible implicit declaration of built-in function 'e xit' ld: Mismatched ABI for -lclntsh, found /dc_user01/app/oracle/product/10.2/instan tclient_10_2/libclntsh.so Fatal error. collect2: ld returned 1 exit status Thanks, Dean [2007-09-27 18:54:34] dgrimes at scvl dot com Description: Trying to compile PHP 5.2.4 with Oracle Instant Client 10.2 and I receive the following error: In file included from /dc_user01/dgrimes/cdev/php-5.2.4/ext/oci8/oci8.c:50: /dc_user01/dgrimes/cdev/php-5.2.4/ext/oci8/php_oci8_int.h:354: error: expected declaration specifiers or '...' before 'oraub8' /dc_user01/dgrimes/cdev/php-5.2.4/ext/oci8/php_oci8_int.h:354: error: expected declaration specifiers or '...' before 'oraub8' make: *** [ext/oci8/oci8.lo] Error 1 Reproduce code: --- Using GCC 4.2.1 GNU Make 3.81 configure \ --with-oci8=shared,instantclient,$ORACLE_HOME/instantclient_10_2 \ --with-zlib-dir=/usr/local \ --without-sqlite \ --without-pdo-sqlite \ --disable-reflection Expected result: A php executable with Oracle support Actual result: -- Compile failure. -- Edit this bug report at http://bugs.php.net/?id=42782edit=1
