#23220 [Com]: IIS does not cleanly close SSL connections (SSL: fatal protocol error)
ID: 23220
Comment by: jon at latchkey dot com
Reported By: storozhilov at mail dot ru
Status: Closed
Bug Type: OpenSSL related
Operating System: *
PHP Version: 4CVS
New Comment:
I'm seeing this in 5.0.2 using HTTP_Client-1.0.0 and
HTTP_Request-1.2.3, Net_Socket-1.0.2.
require_once 'HTTP/Client.php';
$url = 'https://wipcore.t-mobile.com/login';
$data = array(
txtMSISDN=>'myphonenumber',
txtPassword=>'mypassword',
tmobile=>'true',
chkRemember=>'chkRemember',
hdnAOL=>'');
$client = new HTTP_Client();
$response = $client->post($url, $data);
$response = $client->currentResponse();
print_r($response);
?>
Warning: fread() [function.fread]: SSL: fatal protocol error in
/usr/local/lib/php/Net/Socket.php on line 262
Array ( [code] => 200 [headers] => Array ( [Date] => Tue, 05 Oct 2004
06:58:40 GMT [date] => Tue, 05 Oct 2004 06:58:40 GMT [X-Powered-By] =>
ASP.NET [x-powered-by] => ASP.NET [cache-control] => private [pragma]
=> no-cache [x-rim-content-location] =>
"/appdata/rim/idlescreen/carrier/brand" [X-ContentSig] =>
"iQA/AwUAjc1EX/glq1oAoLnzxyr1/ldOXKnENFEa88tQ+IIE" [x-contentsig] =>
"iQA/AwUAjc1EX/glq1oAoLnzxyr1/ldOXKnENFEa88tQ+IIE" [Connection] =>
close [connection] => close [Content-Type] => text/html [content-type]
=> text/html [Cache-control] => private [Content-Encoding] => gzip
[content-encoding] => gzip [Transfer-Encoding] => chunked
[transfer-encoding] => chunked [Expires] => Wed, 01 Jan 1997 12:00:00
GMT [expires] => Wed, 01 Jan 1997 12:00:00 GMT [Vary] =>
Accept-Encoding [vary] => Accept-Encoding ) [body] =>
Previous Comments:
[2004-08-24 20:54:36] robert at osuosl dot org
I've noticed we've all dismissed this as a Microsoft IIS error, but
we've been receiving the same warning using Apache 1.3.31 and PHP 5.0.0
and PHP 5.0.1, configured with the following options:
./configure --with-mysql=shared,/usr --prefix=/usr
--with-apxs=/usr/bin/apxs-ssl --disable-rpath --with-layout=GNU
--with-pear=/usr/share/php --enable-ftp --with-gettext --enable-sockets
--with-zlib --with-kerberos=/usr --with-openssl
--with-exec-dir=/usr/lib/php5/libexec --with-dom=shared,/usr --with-xsl
--with-gettext
Have any apache users had this error and corrected it?
[2004-05-23 13:04:06] [EMAIL PROTECTED]
Stupid bug system...
The will be in the next snapshot from http://snaps.php.net.
[2004-05-23 13:02:46] [EMAIL PROTECTED]
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation
better.
This has just been fixed in CVS.
Note that due to the nature of the problem (eg: IIS being at fault),
there is no way for PHP to determine the difference between a
legitimate problem and a bogus IIS unless you are using the built-in
HTTP wrapper: we inspect the headers to determine if we should show the
warning or not.
So, if you are manually opening an SSL stream, you still need to
suppress the warning yourself based on the presence of "Server:
Microsoft-IIS" in the headers that you read.
[2004-05-03 17:56:01] grizu1 at gmx dot info
Hi,
this bug still exists on php4-STABLE-200405031430. ;-(
System:
- Linux (RedHat 8) 2.4.20-28.8 #1 Thu Dec 18 12:53:39 EST 2003 i686
i686 i386 GNU/Linux
- php4-STABLE-200405031430
- OpenSSL 0.9.6b
Configure command:
'./configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-mysql'
'--with-openssl' '--with-sapdb=/opt/sapdb/interfaces/odbc/'
php-script:
https://foo.bar";;
file_get_contents($url);
?>
Output:
Warning: file_get_contents(): SSL: fatal protocol error in
/www/www.default.de/html/https2.php on line 3
Any help for me?
Greetings
grizu
[2004-04-30 15:03:05] obercik at poczta dot onet dot pl
PHP Version 5.0.0RC2
Configure Command './configure' '--with-openssl' ...
if ( $fp = fopen("https://, "r") ) {
while ( $row = fgets($fp, 1024) ) {
print($row);
}
fclose($fp);
}
Warning: fgets() [function.fgets]: SSL: fatal protocol error in
xxx.php on line xx
however it GETS the data...
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/23220
--
Edit this bug report at http://bugs.php.net/?id=23220&edit=1
#29878 [Opn->Bgs]: ImageCreateFromJpeg returns 'not a valid jpeg file'
ID: 29878 Updated by: [EMAIL PROTECTED] Reported By: cyleriggs at kc dot rr dot com -Status: Open +Status: Bogus Bug Type: GD related Operating System: Linux 2.6.8.1 PHP Version: 5.0.1 Assigned To: pajoye New Comment: PHP only reads non-coprrupted files - there is no bug here. Previous Comments: [2004-10-05 04:34:39] cyleriggs at kc dot rr dot com After playing around with the images themselves i have found that converting them from jpeg to png then back to jpeg fixed the problem and yielded no quality loss. I used the linux tool set called ImageMagick to do this. I wrote a short perl script to go through all my images and fix them. Other than this i have found no other way of stopping this. one interesting fact though is that while converting the images with the imagemagick utility it complained about some corruptions, however it was still able to open them fine and convert them. Maybe PHP is being too picky about the images that it opens as despite a few corrupted bytes EVERYthing was able to open these images except for PHP. [2004-09-30 21:05:50] paul at gslip dot com I disagree. I have used my code successfully on montypics.com until the upgrade to php 5.0.1. I now get exactly the same results as the original poster. Images that worked fine on previous versions now do not. I have a sample image that can be provided. I also have code I can share with the PHP team although I cannot post it here as it is lengthy and copyrighted. [2004-08-29 12:22:14] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Your jpeg file is not valid. PHP could not take care of each possible failures in image files. Desktop softwares could. Fix your image and replace it. --Pierre [2004-08-28 23:00:25] cyleriggs at kc dot rr dot com Description: When calling ImageCreateFromJPEG() on a valid jpeg file it fails and i get errors such as the following in my php error log: [28-Aug-2004 05:21:29] PHP Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: '/usr/local/apache2/htdocs/pictures/Before Dad Went to Iraq/IMGP0008.JPG' is not a valid JPEG file in /home/www/pictures/index.php on line 43 however as can be seen through this link the file is a valid jpeg file: http://cyle.dyndns.org/pictures/Before Dad Went to Iraq/IMGP0008.JPG Also i have a memory_limit of 25mb so this cannot be the issue. Something that might help: http://cyle.dyndns.org/phpinfo.php I am writing this code for a picture gallery browser, while most pictures load, about 10% of my pictures cannot be opened through ImageCreateFromJpeg(), however it is always the same pictures that cannot be opened. The only trend i can see is that this does not appear to be happening on small jpegs. The page that I am having problems with is http://cyle.dyndns.org/pictures/index.php. The source code for this is at http://cyle.dyndns.org/pictures/index.phps. Expected result: The image would be loaded and code continue to execute and i get the error message described above. Actual result: -- Sometimes images load sometimes images cannot be opened. -- Edit this bug report at http://bugs.php.net/?id=29878&edit=1
#30322 [Csd->Bgs]: mssql_fetch_field(result)->column_source same as ->name
ID: 30322
Updated by: [EMAIL PROTECTED]
Reported By: erik at xpand dot nl
-Status: Closed
+Status: Bogus
Bug Type: MSSQL related
Operating System: Windows Server 2003
PHP Version: 5.0.2
New Comment:
No bug in PHP -> bogus.
Previous Comments:
[2004-10-05 08:44:08] erik at xpand dot nl
It wasn't a support request. I was sure it is a bug, but I didn't
realize it could be a bug in the mssql-lib.
Thanks for your reply
[2004-10-04 22:34:39] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
The data you are seeing is returned directly from mssql library without
any modifications. So, the bug (valid bug btw) is not a PHP one, but a
bug in the mssql library you are using.
[2004-10-04 16:22:18] erik at xpand dot nl
Description:
I executed this query with 2 columns which have the same name:
SELECT tbl1.n_MatchID, tbl2.n_MatchID FROM tbl1,tbl2 WHERE (etc)
When I request the fields, the column_source and the name are the
same...
Reproduce code:
---
$query = "SELECT Infostrada.tFootballMatch.n_MatchID as a,
Infostrada.tFootballMatchDetail.n_MatchID as b FROM
Infostrada.tFootballMatchDetail, Infostrada.tFootballMatch WHERE
Infostrada.tFootballMatch.n_MatchID =
Infostrada.tFootballMatchDetail.n_MatchID";
$result = mssql_query($query) or die();
while($obj = mssql_fetch_field($result)) {
echo $obj->column_source . "." . $obj->name . "";
}
Expected result:
tFootballMatch.n_MatchID
tFootballMatchDetail.n_MatchID
($obj->column_source.$obj->name)
Actual result:
--
n_MatchID.n_MatchID
n_MatchID.n_MatchID
--
Edit this bug report at http://bugs.php.net/?id=30322&edit=1
#27336 [Com]: inconsistency of unserializing references
ID: 27336
Comment by: jan at bestbytes dot de
Reported By: hawcue at yahoo dot com
Status: Wont fix
Bug Type: Class/Object related
Operating System: Windows XP
PHP Version: 4.3.4
New Comment:
value = $value;
global $load;
$this->load = $load;
}
function setParent(&$parent)
{
$this->parent = &$parent;
}
function setChild(&$child)
{
$this->child = &$child;
}
/**
* @return void
* @desc fake __destroy from a php 4 point of view
*/
function __destroy()
{
$props = get_object_vars($this);
foreach($props as $propName => $propValue) {
unset($propValue);
if(is_object($this->$propName)) {
if(method_exists($this->$propName, '__destroy') AND
$this->$propName->__destroyed !== false) {
$this->$propName->__destroy();
}
}
if(isset($this->$propName)) {
unset($this->$propName);
}
}
}
}
header('Content-type: text/plain');
// small load to check the serialized string
$loadSize = 4;
// big load to check leaking
//$loadSize = 32 * 1024;
$load = str_repeat('.', $loadSize);
for($i = 0;$i<10;$i++) {
echo ' '.(memory_get_usage()/1024).'
-'.chr(10);
$serMe = array();
$serMe['parent'] =& new Node('parent');
$serMe['child'] =& new Node('child');
/*
* this will work too !!
* $serMe['parent'] = new Node('parent');
* $serMe['child'] = new Node('child');
*/
$serMe['parent']->setChild($serMe['child']);
$serMe['child']->setParent($serMe['parent']);
$str = serialize($serMe);
/*
* 1.Problem:
*
* You have 2 or more objects with circular references to one
another.
* Serializing these objects will result in unexpected behaviour
when
* unserializing them:
*
* Former references will become copies.
*
* This is because the php serialize handler can not handle
references,
* unless all involved objects, variables ... are within an array(),
* that will be serialized.
*
* This should be selfexplaining (just take a look at the length
...):
* echo serialize($serMe['parent']);
* echo serialize($serMe);
* results in:
*
O:4:"node":5:{s:5:"value";s:6:"parent";s:5:"child";O:4:"node":5:{s:5:"value";s:5:"child";s:5:"child";N;s:6:"parent";O:4:"node":5:{s:5:"value";s:6:"parent";s:5:"child";R:3;s:6:"parent";N;s:4:"load";s:4:"";s:11:"__destroyed";b:0;}s:4:"load";s:4:"";s:11:"__destroyed";b:0;}s:6:"parent";N;s:4:"load";s:4:"";s:11:"__destroyed";b:0;}
*
a:2:{s:6:"parent";O:4:"node":5:{s:5:"value";s:6:"parent";s:5:"child";O:4:"node":5:{s:5:"value";s:5:"child";s:5:"child";N;s:6:"parent";R:2;s:4:"load";s:4:"";s:11:"__destroyed";b:0;}s:6:"parent";N;s:4:"load";s:4:"";s:11:"__destroyed";b:0;}s:5:"child";R:4;}
*
* PLEASE GIVE THE WORLD PROPER DOCUMENTATION ON THIS (or prove us
wrong)
*
* 2.Problem:
*
* The loop below will result in extensive leaking (use the big
$loadsize ...),
* unless you help yourself and unset all the properties manually
* see Node::__destroy()
*
*/
$serMe['parent']->__destroy();
$serMe['child']->__destroy();
$serMe = unserialize($str);
unset($str);
$serMe['parent']->value = 'new parent';
echo '-->'.$serMe['parent']->child->parent->value.chr(10);
echo '-->'.$serMe['parent']->value.chr(10);
$serMe['parent']->__destroy();
$serMe['child']->__destroy();
unset($serMe);
}
?>
Previous Comments:
[2004-02-21 11:55:54] hawcue at yahoo dot com
I believe this is a bug. It is related with
how PHP determines recursion levels. From
what we have observed, I think PHP determines
the recursion level by comparing the physical
addresses of two references. This is why
serialize(&$parentNode) works as expected
because the address is passed in.
[2004-02-21 03:12:20] [EMAIL PROTECTED]
Don't mess with references and serializing. That doesn't work and it
won't work.
[2004-02-20 16:22:53] hawcue at yahoo dot com
Description:
Please read the codes first.
The actual output shows two copies of $parentNode are
generated by unserialize(). However, this is not
what I expect because I am using reference and
$newParent->child->parent and $newParent should
refer to the same storage if serialize/unserialize
works correctly.
The problem can be partially solved by using
the following line to do serialize:
$str = serialize(&$parentNode); // an ampersand is used
This will generate a compiling warning (depreciation
of using ampersand in function parameters).
Reproduce code:
---
class Node {
var $value;
var $child;
var $parent;
function Node($value) {
$this->value = $value;
}
function setParent(&$pa
#10383 [Com]: Receiving an HTTP PUT, rather than sending one
ID: 10383
Comment by: alienmind at gmx dot net
Reported By: matt at kurzweiltech dot com
Status: Bogus
Bug Type: HTTP related
Operating System: RH Linux
PHP Version: 4.0.3pl1
New Comment:
same problem here. don't know what to do.
supposedly, in version 4.x, I am using, put's can be received by using
fopen("php://stdin", "r");
but there comes nothing. all is right and the put itself looks like:
PUT http://x.x.x/xbel.xml HTTP/1.1
Host: x.x.x
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3)
Gecko/20041001 Firefox/0.10.1
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Content-Length: 18516
Content-Type: text/xml; charset=UTF-8
http://www.php.net/downloads.php
If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.
[2001-04-18 15:22:09] matt at kurzweiltech dot com
I have been trying to use PUT method support, as described in the PHP
manual in the section "Handling File Uploads." The documentation says
that when the request type is PUT, the body of the request is saved in
a temporary file (in the directory specified in php.ini), and the name
of the file is saved in a variable called $PHP_PUT_FILENAME (I tried
$PHP_UPLOAD_FILE_NAME too, there is an inconsistency in the
documentation, but neither worked anyway).
As the documentation says, I put a line in httpd.conf (I am using
apache 1.3.12) that says:
Script PUT /path/to/myscript.php
This works great...all PUT requests are getting redirected to my
script. I know this, because the other parts that don't deal with the
file are getting executed, and I was able to send HTML back to the
client in an "echo" statement.
Now, the value of the variable $PHP_PUT_FILENAME is empty. I looked at
various other bugs alluding to this issue, and made sure of a couple
things: in php.ini, register_globals is on, and the temporary file
directory for uploads is also set (to /tmp). I also tried
$PHP_UPLOADED_FILE_NAME (which is in the documentation example), to no
avail. I am using an HTTP/1.1 PUT, not HTTP/1.0 as someone else did in
an earlier bug.
Next, I searched through all of the most recent sources for PHP_PUT,
PHP_UPLOAD, and other such things, and came up with nothing. Nowhere
in the PHP source is there any mention of such a variable.
In one of the other bugs mentioning this problem, somebody mentioned
cURL as an alternative. cURL, as far as I understand, is a set of
functions that allow you to *make* PUT requests (and many other types
of requests), but do not allow you to *receive* PUT requests, which is
what I am trying to do.
I next tried to get at the raw data of the PUT directly, figuring
perhaps the $HTTP_RAW_POST_DATA would have the data or
fopen("php://stdin","rb") would, but neither worked. For the latter,
PHP already reads all of stdin, so nothing is left over to read, and
for the former, I'm not sure that the variable ever gets set (I read a
couple of mailing list posts about trouble with the HTTP_RAW_POST_DATA
variable, I don't think it exists anymore). Is there a published
workaround somewhere?
For simplicity's sake, I'm not including my php_info() dump in this
submission, but I'll be happy to give you one if you want it.
Any insight into this would be much appreciated. If receiving PUT
requests is no longer supported, at what point was that support
dropped? It would be cool to have the documentation in that section
updated if it was in fact dropped. I know this is kind of an obscure
problem from the perspective of the WWW, as only a couple browsers use
PUT, but when developing applications it's a lot easier to use PUT
because no encoding is involved.
Please let me know if there is any more information you need from me.
-Matt
--
Edit this bug report at http://bugs.php.net/?id=10383&edit=1
#29868 [Com]: Linking fails when using --enable-debug
ID: 29868 Comment by: saju dot pillai at gmail dot com Reported By: Volker dot Weinberger at pharma dot novartis dot com Status: Open Bug Type: Compile Failure Operating System: Solaris 5.8 PHP Version: 5.0.1 New Comment: -L/u01/home/oracle/product/9.2.0/lib your problem is that line ... shouldn't that be -L/u01/home/oracle/product/9.2.0/lib32 ? You could be trying to link against 64 bit stubs ? Previous Comments: [2004-08-27 15:35:53] Volker dot Weinberger at pharma dot novartis dot com Description: Compilation/Linkings works OK without --enable-debug. As followup of another bug report was was asked to compile with --enable-debug. This fails consistently during linking phase of sapi/cli/php with a wierd error message: ild: (argument error) can't find library arguments :: -lresolv -ldl -ldl -lpthread *** Error code 8 make: Fatal error: Command failed for target `sapi/cli/php' Same on freshly extracted PHP distribution. == Full message: /bin/sh /bioinfnv/software/biobench/apache/build/tmp/php-5.0.1/libtool --preserve-dup-deps --mode=link cc -export-dynamic -xO2 -g -L/usr/ucblib -L/bioinfnv/software/lib -L/bioinfnv/software/mysql/current/lib -L/u01/home/oracle/product/9.2.0/lib -R /usr/ucblib -R /bioinfnv/software/lib -R /bioinfnv/software/mysql/current/lib -R /u01/home/oracle/product/9.2.0/lib ext/libxml/libxml.lo ext/openssl/openssl.lo ext/openssl/xp_ssl.lo ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext/ctype/ctype.lo ext/dom/php_dom.lo ext/dom/attr.lo ext/dom/document.lo ext/dom/domerrorhandler.lo ext/dom/domstringlist.lo ext/dom/domexception.lo ext/dom/namelist.lo ext/dom/processinginstruction.lo ext/dom/cdatasection.lo ext/dom/documentfragment.lo ext/dom/domimplementation.lo ext/dom/element.lo ext/dom/node.lo ext/dom/string_extend.lo ext/dom/characterdata.lo ext/dom/documenttype.lo ext/dom/domimplementationlist.lo ext/dom/entity.lo ext/dom/nodelist.lo ext/dom/text.lo ext/dom/comment.lo ext/dom/domconfiguration.lo ext/dom/domimplementationsource.lo ext/dom/entityreference.lo ext/dom/notation.lo ext/dom/xpath.lo ext/dom/dom_iterators.lo ext/dom/typeinfo.lo ext/dom/domerror.lo ext/dom/domlocator.lo ext/dom/namednodemap.lo ext/dom/userdatahandler.lo ext/gd/gd.lo ext/gd/gdttf.lo ext/gd/gdcache.lo ext/iconv/iconv.lo ext/mysql/php_mysql.lo ext/oci8/oci8.lo ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo ext/posix/posix.lo ext/session/session.lo ext/session/mod_files.lo ext/session/mod_mm.lo ext/session/mod_user.lo ext/simplexml/simplexml.lo ext/spl/php_spl.lo ext/spl/spl_functions.lo ext/spl/spl_engine.lo ext/spl/spl_iterators.lo ext/spl/spl_array.lo ext/spl/spl_directory.lo ext/spl/spl_sxe.lo ext/sqlite/sqlite.lo ext/sqlite/sess_sqlite.lo ext/sqlite/libsqlite/src/opcodes.lo ext/sqlite/libsqlite/src/parse.lo ext/sqlite/libsqlite/src/encode.lo ext/sqlite/libsqlite/src/auth.lo ext/sqlite/libsqlite/src/btree.lo ext/sqlite/libsqlite/src/build.lo ext/sqlite/libsqlite/src/delete.lo ext/sqlite/libsqlite/src/expr.lo ext/sqlite/libsqlite/src/func.lo ext/sqlite/libsqlite/src/hash.lo ext/sqlite/libsqlite/src/insert.lo ext/sqlite/libsqlite/src/main.lo ext/sqlite/libsqlite/src/os.lo ext/sqlite/libsqlite/src/pager.lo ext/sqlite/libsqlite/src/printf.lo ext/sqlite/libsqlite/src/random.lo ext/sqlite/libsqlite/src/select.lo ext/sqlite/libsqlite/src/table.lo ext/sqlite/libsqlite/src/tokenize.lo ext/sqlite/libsqlite/src/update.lo ext/sqlite/libsqlite/src/util.lo ext/sqlite/libsqlite/src/vdbe.lo ext/sqlite/libsqlite/src/attach.lo ext/sqlite/libsqlite/src/btree_rb.lo ext/sqlite/libsqlite/src/pragma.lo ext/sqlite/libsqlite/src/vacuum.lo ext/sqlite/libsqlite/src/copy.lo ext/sqlite/libsqlite/src/vdbeaux.lo ext/sqlite/libsqlite/src/date.lo ext/sqlite/libsqlite/src/where.lo ext/sqlite/libsqlite/src/trigger.lo regex/regcomp.lo regex/regexec.lo regex/regerror.lo regex/regfree.lo ext/standard/array.lo ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo ext/standard/formatted_print.lo ext/standard/fsock.lo ext/standard/head.lo ext/standard/html.lo ext/standard/image.lo ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo ext/standard/link.lo ext/standard/mail.lo ext/standard/math.lo ext/standard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo ext/standard/pack.lo ext/standard/pageinfo.lo ext/standard/parsedate.lo ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/reg.lo ext/standard/soundex.lo ext/standard/string.lo ext/standard/scanf.lo ext/standard/syslog.lo ext/standar
#29868 [Com]: Linking fails when using --enable-debug
ID: 29868 Comment by: karthik_80s at yahoo dot com Reported By: Volker dot Weinberger at pharma dot novartis dot com Status: Open Bug Type: Compile Failure Operating System: Solaris 5.8 PHP Version: 5.0.1 New Comment: Got this error with 4.3.9 also - solaris 2.8, SUNWspro6.1 cc. One common thing i've noticed: oci8. I was using it with oracle 10g, which ships with both 32bit and 64 bit libs. The 32bit libs are in lib32 instead of lib. Once I changed the link line to use lib32, it worked. So it's probably due to wrong dependencies. Previous Comments: [2004-10-05 11:14:53] saju dot pillai at gmail dot com -L/u01/home/oracle/product/9.2.0/lib your problem is that line ... shouldn't that be -L/u01/home/oracle/product/9.2.0/lib32 ? You could be trying to link against 64 bit stubs ? [2004-08-27 15:35:53] Volker dot Weinberger at pharma dot novartis dot com Description: Compilation/Linkings works OK without --enable-debug. As followup of another bug report was was asked to compile with --enable-debug. This fails consistently during linking phase of sapi/cli/php with a wierd error message: ild: (argument error) can't find library arguments :: -lresolv -ldl -ldl -lpthread *** Error code 8 make: Fatal error: Command failed for target `sapi/cli/php' Same on freshly extracted PHP distribution. == Full message: /bin/sh /bioinfnv/software/biobench/apache/build/tmp/php-5.0.1/libtool --preserve-dup-deps --mode=link cc -export-dynamic -xO2 -g -L/usr/ucblib -L/bioinfnv/software/lib -L/bioinfnv/software/mysql/current/lib -L/u01/home/oracle/product/9.2.0/lib -R /usr/ucblib -R /bioinfnv/software/lib -R /bioinfnv/software/mysql/current/lib -R /u01/home/oracle/product/9.2.0/lib ext/libxml/libxml.lo ext/openssl/openssl.lo ext/openssl/xp_ssl.lo ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext/ctype/ctype.lo ext/dom/php_dom.lo ext/dom/attr.lo ext/dom/document.lo ext/dom/domerrorhandler.lo ext/dom/domstringlist.lo ext/dom/domexception.lo ext/dom/namelist.lo ext/dom/processinginstruction.lo ext/dom/cdatasection.lo ext/dom/documentfragment.lo ext/dom/domimplementation.lo ext/dom/element.lo ext/dom/node.lo ext/dom/string_extend.lo ext/dom/characterdata.lo ext/dom/documenttype.lo ext/dom/domimplementationlist.lo ext/dom/entity.lo ext/dom/nodelist.lo ext/dom/text.lo ext/dom/comment.lo ext/dom/domconfiguration.lo ext/dom/domimplementationsource.lo ext/dom/entityreference.lo ext/dom/notation.lo ext/dom/xpath.lo ext/dom/dom_iterators.lo ext/dom/typeinfo.lo ext/dom/domerror.lo ext/dom/domlocator.lo ext/dom/namednodemap.lo ext/dom/userdatahandler.lo ext/gd/gd.lo ext/gd/gdttf.lo ext/gd/gdcache.lo ext/iconv/iconv.lo ext/mysql/php_mysql.lo ext/oci8/oci8.lo ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo ext/posix/posix.lo ext/session/session.lo ext/session/mod_files.lo ext/session/mod_mm.lo ext/session/mod_user.lo ext/simplexml/simplexml.lo ext/spl/php_spl.lo ext/spl/spl_functions.lo ext/spl/spl_engine.lo ext/spl/spl_iterators.lo ext/spl/spl_array.lo ext/spl/spl_directory.lo ext/spl/spl_sxe.lo ext/sqlite/sqlite.lo ext/sqlite/sess_sqlite.lo ext/sqlite/libsqlite/src/opcodes.lo ext/sqlite/libsqlite/src/parse.lo ext/sqlite/libsqlite/src/encode.lo ext/sqlite/libsqlite/src/auth.lo ext/sqlite/libsqlite/src/btree.lo ext/sqlite/libsqlite/src/build.lo ext/sqlite/libsqlite/src/delete.lo ext/sqlite/libsqlite/src/expr.lo ext/sqlite/libsqlite/src/func.lo ext/sqlite/libsqlite/src/hash.lo ext/sqlite/libsqlite/src/insert.lo ext/sqlite/libsqlite/src/main.lo ext/sqlite/libsqlite/src/os.lo ext/sqlite/libsqlite/src/pager.lo ext/sqlite/libsqlite/src/printf.lo ext/sqlite/libsqlite/src/random.lo ext/sqlite/libsqlite/src/select.lo ext/sqlite/libsqlite/src/table.lo ext/sqlite/libsqlite/src/tokenize.lo ext/sqlite/libsqlite/src/update.lo ext/sqlite/libsqlite/src/util.lo ext/sqlite/libsqlite/src/vdbe.lo ext/sqlite/libsqlite/src/attach.lo ext/sqlite/libsqlite/src/btree_rb.lo ext/sqlite/libsqlite/src/pragma.lo ext/sqlite/libsqlite/src/vacuum.lo ext/sqlite/libsqlite/src/copy.lo ext/sqlite/libsqlite/src/vdbeaux.lo ext/sqlite/libsqlite/src/date.lo ext/sqlite/libsqlite/src/where.lo ext/sqlite/libsqlite/src/trigger.lo regex/regcomp.lo regex/regexec.lo regex/regerror.lo regex/regfree.lo ext/standard/array.lo ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo ext/standard/formatted_print.lo ext/standard/fsock.lo ext/standard/head.lo ext/standard/html.lo ext/standard/imag
#29868 [Opn->Fbk]: Linking fails when using --enable-debug
ID: 29868 Updated by: [EMAIL PROTECTED] Reported By: Volker dot Weinberger at pharma dot novartis dot com -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Solaris 5.8 PHP Version: 5.0.1 New Comment: This issue should be fixed in HEAD. Please, test 5.1 snapshots. I'll probably backport it to 5.0.x if it works fine for you. Previous Comments: [2004-10-05 11:52:59] karthik_80s at yahoo dot com Got this error with 4.3.9 also - solaris 2.8, SUNWspro6.1 cc. One common thing i've noticed: oci8. I was using it with oracle 10g, which ships with both 32bit and 64 bit libs. The 32bit libs are in lib32 instead of lib. Once I changed the link line to use lib32, it worked. So it's probably due to wrong dependencies. [2004-10-05 11:14:53] saju dot pillai at gmail dot com -L/u01/home/oracle/product/9.2.0/lib your problem is that line ... shouldn't that be -L/u01/home/oracle/product/9.2.0/lib32 ? You could be trying to link against 64 bit stubs ? [2004-08-27 15:35:53] Volker dot Weinberger at pharma dot novartis dot com Description: Compilation/Linkings works OK without --enable-debug. As followup of another bug report was was asked to compile with --enable-debug. This fails consistently during linking phase of sapi/cli/php with a wierd error message: ild: (argument error) can't find library arguments :: -lresolv -ldl -ldl -lpthread *** Error code 8 make: Fatal error: Command failed for target `sapi/cli/php' Same on freshly extracted PHP distribution. == Full message: /bin/sh /bioinfnv/software/biobench/apache/build/tmp/php-5.0.1/libtool --preserve-dup-deps --mode=link cc -export-dynamic -xO2 -g -L/usr/ucblib -L/bioinfnv/software/lib -L/bioinfnv/software/mysql/current/lib -L/u01/home/oracle/product/9.2.0/lib -R /usr/ucblib -R /bioinfnv/software/lib -R /bioinfnv/software/mysql/current/lib -R /u01/home/oracle/product/9.2.0/lib ext/libxml/libxml.lo ext/openssl/openssl.lo ext/openssl/xp_ssl.lo ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext/ctype/ctype.lo ext/dom/php_dom.lo ext/dom/attr.lo ext/dom/document.lo ext/dom/domerrorhandler.lo ext/dom/domstringlist.lo ext/dom/domexception.lo ext/dom/namelist.lo ext/dom/processinginstruction.lo ext/dom/cdatasection.lo ext/dom/documentfragment.lo ext/dom/domimplementation.lo ext/dom/element.lo ext/dom/node.lo ext/dom/string_extend.lo ext/dom/characterdata.lo ext/dom/documenttype.lo ext/dom/domimplementationlist.lo ext/dom/entity.lo ext/dom/nodelist.lo ext/dom/text.lo ext/dom/comment.lo ext/dom/domconfiguration.lo ext/dom/domimplementationsource.lo ext/dom/entityreference.lo ext/dom/notation.lo ext/dom/xpath.lo ext/dom/dom_iterators.lo ext/dom/typeinfo.lo ext/dom/domerror.lo ext/dom/domlocator.lo ext/dom/namednodemap.lo ext/dom/userdatahandler.lo ext/gd/gd.lo ext/gd/gdttf.lo ext/gd/gdcache.lo ext/iconv/iconv.lo ext/mysql/php_mysql.lo ext/oci8/oci8.lo ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo ext/posix/posix.lo ext/session/session.lo ext/session/mod_files.lo ext/session/mod_mm.lo ext/session/mod_user.lo ext/simplexml/simplexml.lo ext/spl/php_spl.lo ext/spl/spl_functions.lo ext/spl/spl_engine.lo ext/spl/spl_iterators.lo ext/spl/spl_array.lo ext/spl/spl_directory.lo ext/spl/spl_sxe.lo ext/sqlite/sqlite.lo ext/sqlite/sess_sqlite.lo ext/sqlite/libsqlite/src/opcodes.lo ext/sqlite/libsqlite/src/parse.lo ext/sqlite/libsqlite/src/encode.lo ext/sqlite/libsqlite/src/auth.lo ext/sqlite/libsqlite/src/btree.lo ext/sqlite/libsqlite/src/build.lo ext/sqlite/libsqlite/src/delete.lo ext/sqlite/libsqlite/src/expr.lo ext/sqlite/libsqlite/src/func.lo ext/sqlite/libsqlite/src/hash.lo ext/sqlite/libsqlite/src/insert.lo ext/sqlite/libsqlite/src/main.lo ext/sqlite/libsqlite/src/os.lo ext/sqlite/libsqlite/src/pager.lo ext/sqlite/libsqlite/src/printf.lo ext/sqlite/libsqlite/src/random.lo ext/sqlite/libsqlite/src/select.lo ext/sqlite/libsqlite/src/table.lo ext/sqlite/libsqlite/src/tokenize.lo ext/sqlite/libsqlite/src/update.lo ext/sqlite/libsqlite/src/util.lo ext/sqlite/libsqlite/src/vdbe.lo ext/sqlite/libsqlite/src/attach.lo ext/sqlite/libsqlite/src/btree_rb.lo ext/sqlite/libsqlite/src/pragma.lo ext/sqlite/libsqlite/src/vacuum.lo ext/sqlite/libsqlite/src/copy.lo ext/sqlite/libsqlite/src/vdbeaux.lo ext/sqlite/libsqlite/src/date.lo ext/sqlite/libsqlite/src/where.lo ext/sqlite/libsqlite/src/trigger.lo regex/regcomp.lo regex/regexec.lo regex/regerror.lo regex/regfree.lo ext/standard/array.lo ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo ext/standard/datetime.lo
#30328 [NEW]: Crash when passing undefned variable to __get() and return its name
From: flying at dom dot natm dot ru Operating system: windows 2000 PHP version: 5.0.2 PHP Bug Type: Reproducible crash Bug description: Crash when passing undefned variable to __get() and return its name Description: PHP 5.0.2 on Windows 2000 SP4. There is reproducible crash happens when one tries to pass undefined variable to a class with defined __get() function. Example code: $testvar; ?> Running this code from under Apache results in HTTP 500 error, running it from shell results to some garbage to be shown on screen and program exit. However running it as: php.exe test.php >log results in following text appearing in log: Notice: Undefined variable: testvar in C:\web\test.php on line 13 __get() called: Moreover changing return($name); inside __get() to returning anything else (either static value or some other variable) results in crash disappearing. -- Edit bug report at http://bugs.php.net/?id=30328&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30328&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30328&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30328&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30328&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30328&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30328&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30328&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30328&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30328&r=support Expected behavior: http://bugs.php.net/fix.php?id=30328&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30328&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30328&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30328&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30328&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30328&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30328&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30328&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30328&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30328&r=mysqlcfg
#29868 [Fbk->Opn]: Linking fails when using --enable-debug
ID: 29868 User updated by: Volker dot Weinberger at pharma dot novartis dot com Reported By: Volker dot Weinberger at pharma dot novartis dot com -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Solaris 5.8 PHP Version: 5.0.1 New Comment: You're probably right about the lib, however I still think there's something wrong, since things work fine (automatically) without --enable-debug (standard case), and fail with --enable-debug (everything else unchanged). Previous Comments: [2004-10-05 11:59:14] [EMAIL PROTECTED] This issue should be fixed in HEAD. Please, test 5.1 snapshots. I'll probably backport it to 5.0.x if it works fine for you. [2004-10-05 11:52:59] karthik_80s at yahoo dot com Got this error with 4.3.9 also - solaris 2.8, SUNWspro6.1 cc. One common thing i've noticed: oci8. I was using it with oracle 10g, which ships with both 32bit and 64 bit libs. The 32bit libs are in lib32 instead of lib. Once I changed the link line to use lib32, it worked. So it's probably due to wrong dependencies. [2004-10-05 11:14:53] saju dot pillai at gmail dot com -L/u01/home/oracle/product/9.2.0/lib your problem is that line ... shouldn't that be -L/u01/home/oracle/product/9.2.0/lib32 ? You could be trying to link against 64 bit stubs ? [2004-08-27 15:35:53] Volker dot Weinberger at pharma dot novartis dot com Description: Compilation/Linkings works OK without --enable-debug. As followup of another bug report was was asked to compile with --enable-debug. This fails consistently during linking phase of sapi/cli/php with a wierd error message: ild: (argument error) can't find library arguments :: -lresolv -ldl -ldl -lpthread *** Error code 8 make: Fatal error: Command failed for target `sapi/cli/php' Same on freshly extracted PHP distribution. == Full message: /bin/sh /bioinfnv/software/biobench/apache/build/tmp/php-5.0.1/libtool --preserve-dup-deps --mode=link cc -export-dynamic -xO2 -g -L/usr/ucblib -L/bioinfnv/software/lib -L/bioinfnv/software/mysql/current/lib -L/u01/home/oracle/product/9.2.0/lib -R /usr/ucblib -R /bioinfnv/software/lib -R /bioinfnv/software/mysql/current/lib -R /u01/home/oracle/product/9.2.0/lib ext/libxml/libxml.lo ext/openssl/openssl.lo ext/openssl/xp_ssl.lo ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext/ctype/ctype.lo ext/dom/php_dom.lo ext/dom/attr.lo ext/dom/document.lo ext/dom/domerrorhandler.lo ext/dom/domstringlist.lo ext/dom/domexception.lo ext/dom/namelist.lo ext/dom/processinginstruction.lo ext/dom/cdatasection.lo ext/dom/documentfragment.lo ext/dom/domimplementation.lo ext/dom/element.lo ext/dom/node.lo ext/dom/string_extend.lo ext/dom/characterdata.lo ext/dom/documenttype.lo ext/dom/domimplementationlist.lo ext/dom/entity.lo ext/dom/nodelist.lo ext/dom/text.lo ext/dom/comment.lo ext/dom/domconfiguration.lo ext/dom/domimplementationsource.lo ext/dom/entityreference.lo ext/dom/notation.lo ext/dom/xpath.lo ext/dom/dom_iterators.lo ext/dom/typeinfo.lo ext/dom/domerror.lo ext/dom/domlocator.lo ext/dom/namednodemap.lo ext/dom/userdatahandler.lo ext/gd/gd.lo ext/gd/gdttf.lo ext/gd/gdcache.lo ext/iconv/iconv.lo ext/mysql/php_mysql.lo ext/oci8/oci8.lo ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo ext/posix/posix.lo ext/session/session.lo ext/session/mod_files.lo ext/session/mod_mm.lo ext/session/mod_user.lo ext/simplexml/simplexml.lo ext/spl/php_spl.lo ext/spl/spl_functions.lo ext/spl/spl_engine.lo ext/spl/spl_iterators.lo ext/spl/spl_array.lo ext/spl/spl_directory.lo ext/spl/spl_sxe.lo ext/sqlite/sqlite.lo ext/sqlite/sess_sqlite.lo ext/sqlite/libsqlite/src/opcodes.lo ext/sqlite/libsqlite/src/parse.lo ext/sqlite/libsqlite/src/encode.lo ext/sqlite/libsqlite/src/auth.lo ext/sqlite/libsqlite/src/btree.lo ext/sqlite/libsqlite/src/build.lo ext/sqlite/libsqlite/src/delete.lo ext/sqlite/libsqlite/src/expr.lo ext/sqlite/libsqlite/src/func.lo ext/sqlite/libsqlite/src/hash.lo ext/sqlite/libsqlite/src/insert.lo ext/sqlite/libsqlite/src/main.lo ext/sqlite/libsqlite/src/os.lo ext/sqlite/libsqlite/src/pager.lo ext/sqlite/libsqlite/src/printf.lo ext/sqlite/libsqlite/src/random.lo ext/sqlite/libsqlite/src/select.lo ext/sqlite/libsqlite/src/table.lo ext/sqlite/libsqlite/src/tokenize.lo ext/sqlite/libsqlite/src/update.lo ext/sqlite/libsqlite/src/util.lo ext/sqlite/libsqlite/src/vdbe.lo ext/sqlite/libsqlite/src/attach.lo ext/sqlite/libsqlite/src/btree_rb.lo ext/sqlite/libsqlite/src/pragma.lo ext/sqlite/libsqlite/src/vacuum.lo ext/sqlite/libsqlite/src/copy.lo ext/sqlite/libsqlite/src/vdbeaux.l
#30314 [Opn]: php.ini documentation about E_All/E_Strict confusing.
ID: 30314 Updated by: [EMAIL PROTECTED] Reported By: empx at gmx dot de Status: Open -Bug Type: Documentation problem +Bug Type: Unknown/Other Function Operating System: Windows PHP Version: 5.0.2 New Comment: The documentation is right (E_ALL doesn't include E_STRICT). Now its up with the developers if they want to change the php.ini file or not. Nuno Previous Comments: [2004-10-03 00:20:28] empx at gmx dot de Description: While the online documentation says E_ALL does not include E_STRICT, (which is probably correct :), when you read the docs/examples about error-reporting in the php.ini(-dist/-recommended), you get the impression that E_ALL does include E_STRICT too. Examples: ; E_ALL - All errors and warnings should get updated to something like: ; E_ALL - All errors and warnings, except E_Strict ; - Show all errors, except for notices and coding standards warnings ; ;error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT If E_ALL does not include E_STRICT, then " & ~E_STRICT" shouldn't be needed here, right? regards, Mike -- Edit this bug report at http://bugs.php.net/?id=30314&edit=1
#29860 [Com]: Cannot compile with mysql and mysqli extensions
ID: 29860 Comment by: php at kilimajer dot net Reported By: rjanson at msn dot com Status: Open Bug Type: Compile Failure Operating System: Redhat 9 PHP Version: 5.0.1 New Comment: This is caused by -lmysqlclient being supplied twice to the linker (at least it was my case). Previous Comments: [2004-09-24 19:59:01] rjanson at msn dot com I've tried the same steps with php-5.02 and still the same results. [2004-09-21 01:12:32] rjanson at msn dot com I tried backing up and completely uninstalling, then reinstalling Mysql-4.1.4-0 from RPM, and still get the same result. Others out there are having this issue as well. Is there nothing to be done? --Rich [2004-09-13 20:44:01] rjanson at msn dot com I installed mysql via the RPMs provided on the MySQL site. I unsinstalled the MySQL-shared-compat-4.1.4-0 rpm and tried building agin with the same result. These are the RPMs I have installed currently: MySQL-devel-4.1.4-0 MySQL-client-4.1.4-0 MySQL-Max-4.1.4-0 MySQL-bench-4.1.3-1 MySQL-server-4.1.4-0 MySQL-shared-4.1.4-0 Is it possible something with the RPMs is causing the failure? [2004-09-13 19:38:30] nathansquires at pacbell dot net I had the same linking problem with php 5.0.1 and mysql 4.1.4a-gamma. I was able to compile with mysql and mysqli by rebuilding mysql with shared libraries (i.e. don't use --without-shared or --*flags=--all-static). If you only have static mysql libraries, trying to build php with mysql and mysqli will cause this error. [2004-09-08 08:18:54] rjanson at msn dot com I should have mentioned before that I have tried the configuration you suggest as well. In between each failed 'make' I have done a 'make clean' to be sure I am not using any leftover configuration options. No matter what path I use for mysql and mysqli, if the configuration passes, the make fails. I've seen this issue mentioned in various places, but never a resolution. 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/29860 -- Edit this bug report at http://bugs.php.net/?id=29860&edit=1
#30329 [NEW]: Error Fetching http body, No Content-Length, connection closed or chunked data
From: [EMAIL PROTECTED]
Operating system: Solaris 9
PHP version: 5.0.2
PHP Bug Type: SOAP related
Bug description: Error Fetching http body, No Content-Length, connection closed or
chunked data
Description:
I get the error message "Error Fetching http body, No Content-Length,
connection closed or chunked data [faultcode]" when try to communicate
with Sybase EAServer via SOAP.
When redirecting the web services via a Proxy-Plugin in an iPlanet
webserver everything works ok.
It seems that EAServer sends some bad encoded HTTP body.
When changing the SOAP extension code to only support HTTP/1.0, everything
works.
How about introducing an additional option to SoapClient named
"http_version" that can be set to 1.1 or 1.0 (default 1.1). At this time
"1.1" is hardcoded into php_http.c.
When 1.0 is on, "Connection:" should be assumed as "close".
Something other:
If the extension CURL is used, why not use CURL for sending SOAP requests?
Reproduce code:
---
SOAP Test
http://ws.pangaea.de:8084/ws/services/WebServices?wsdl",array('trace'=>TRUE));
try {
$res=$ws->metadata("10.1594/PANGAEA/206854");
} catch (SoapFault $sf) {
echo "".print_r($sf)."";
}
echo
"Request".htmlspecialchars($ws->__getLastRequest())."Response".htmlspecialchars($ws->__getLastResponse())."";
echo "Decoded";
print_r($res);
?>
Expected result:
no SoapFault
--
Edit bug report at http://bugs.php.net/?id=30329&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30329&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30329&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30329&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30329&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30329&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30329&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30329&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30329&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30329&r=support
Expected behavior: http://bugs.php.net/fix.php?id=30329&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30329&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30329&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30329&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30329&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30329&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30329&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30329&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30329&r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30329&r=mysqlcfg
#30156 [Com]: linker issue
ID: 30156
Comment by: rgski at hotmail dot com
Reported By: jtaisto at iocenter dot net
Status: Open
Bug Type: PHP options/info functions
Operating System: Solaris 9
PHP Version: 5.0.1
New Comment:
I have this exact issue with trying to compile 64bit PHP on Soalris9.
All other components have been compiled 64bit as well, however, finding
this error may lead me to believe that this may not be a php issue.
Why? I am trying to compile php5.0.2 and get the exact error at the
same exact location. It still could be a php issue though, I am not
sure. I'm still digging into the issue here.
Sol9 w/ most recent patch cluster
gcc 3.4.2
libtool 1.5.10 (I know it's not tested via php team. ;-)
libxml2 2.6.14
libxml 1.8.17
php 5.0.2
apache-ssl 1.3.31 (1.55 ssl)
Previous Comments:
[2004-09-22 14:36:58] jtaisto at iocenter dot net
configure exits with this:
Configuring extensions
checking whether to enable LIBXML support... yes
checking libxml2 install dir... /u1/xml/libxml2-2.6.13/sparcv9
checking whether libxml build works... no
configure: error: build test failed. Please check the config.log for
details.
The last lines in the config.log say:
configure:17846: checking whether to enable LIBXML support
configure:17893: checking libxml2 install dir
configure:18053: checking whether libxml build works
configure:18080: gcc -o conftest -O2 -m64 -mcpu=ultrasparc
-mtune=ultrasparc -pthreads -D_POSIX_PTHREAD_SEMANTICS
-D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -R/usr/ucblib -L/usr/ucblib
-R/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.2
-L/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.2
-R/u1/xml/libxml2-2.6.13/sparcv9/lib
-L/u1/xml/libxml2-2.6.13/sparcv9/lib conftest.c
-lresolv -lm -ldl -lnsl -lsocket -lgcc -lxml2 -lz -lm
-lsocket -lnsl 1>&5
configure: failed program was:
#line 18069 "configure"
#include "confdefs.h"
char xmlInitParser();
int main() {
xmlInitParser();
return 0;
}
[2004-09-19 17:58:00] [EMAIL PROTECTED]
What does config.log say about the reason for the failure?
[2004-09-19 17:45:46] jtaisto at iocenter dot net
Description:
Linker dies when trying to build with xml2 support.
Reproduce code:
---
export CC="gcc"
export CXX="gcc"
export CFLAGS="-O2 -m64 -mcpu=ultrasparc -mtune=ultrasparc"
export CXXFLAGS="-O2 -m64 -mcpu=ultrasparc -mtune=ultrasparc"
libxml2 build:./configure --prefix=/u1/xml/libxml2-2.6.13 \
--exec-prefix /u1/xml/libxml2-2.6.13/sparcv9 \
--with-xml2=/u1/xml/libxml2-2.6.13 \
--with-threads
./configure --with-libxml-dir=/u1/xml/libxml2-2.6.13/sparcv9 \
linker (/usr/ccs/bin/ld ) dies on this: configure:18080: gcc -o
conftest -O2 -m64 -mcpu=ultrasparc -mtune=ultrasparc -pthreads
-D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT
-R/usr/ucblib -L/usr/ucblib
-R/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.2
-L/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.2
-R/u1/xml/libxml2-2.6.13/sparcv9/lib
-L/u1/xml/libxml2-2.6.13/sparcv9/lib conftest.c
-lresolv -lm -ldl -lnsl -lsocket -lgcc -lxml2 -lz -lm -lsocket -lnsl
1>&5
configure: failed program was:
#line 18069 "configure"
#include "confdefs.h"
char xmlInitParser();
int main() {xmlInitParser();return 0;}
Expected result:
Not to see a fatal ld from the configure script. Configure able to use
xml2 library that is most recent stable. I've tried this even with just
32-bit using different version with no avail. Can't seem to get a
64-bit version supporting xml2 on Solaris 9 to work.
--
Edit this bug report at http://bugs.php.net/?id=30156&edit=1
#23220 [Csd]: IIS does not cleanly close SSL connections (SSL: fatal protocol error)
ID: 23220 Updated by: [EMAIL PROTECTED] Reported By: storozhilov at mail dot ru Status: Closed Bug Type: OpenSSL related Operating System: * PHP Version: 4CVS New Comment: jon at latchkey dot com: ask the authors of those packages to read this report and fix their code. It is not a PHP bug. Previous Comments: [2004-10-05 09:19:03] jon at latchkey dot com I'm seeing this in 5.0.2 using HTTP_Client-1.0.0 and HTTP_Request-1.2.3, Net_Socket-1.0.2. require_once 'HTTP/Client.php'; $url = 'https://wipcore.t-mobile.com/login'; $data = array( txtMSISDN=>'myphonenumber', txtPassword=>'mypassword', tmobile=>'true', chkRemember=>'chkRemember', hdnAOL=>''); $client = new HTTP_Client(); $response = $client->post($url, $data); $response = $client->currentResponse(); print_r($response); ?> Warning: fread() [function.fread]: SSL: fatal protocol error in /usr/local/lib/php/Net/Socket.php on line 262 Array ( [code] => 200 [headers] => Array ( [Date] => Tue, 05 Oct 2004 06:58:40 GMT [date] => Tue, 05 Oct 2004 06:58:40 GMT [X-Powered-By] => ASP.NET [x-powered-by] => ASP.NET [cache-control] => private [pragma] => no-cache [x-rim-content-location] => "/appdata/rim/idlescreen/carrier/brand" [X-ContentSig] => "iQA/AwUAjc1EX/glq1oAoLnzxyr1/ldOXKnENFEa88tQ+IIE" [x-contentsig] => "iQA/AwUAjc1EX/glq1oAoLnzxyr1/ldOXKnENFEa88tQ+IIE" [Connection] => close [connection] => close [Content-Type] => text/html [content-type] => text/html [Cache-control] => private [Content-Encoding] => gzip [content-encoding] => gzip [Transfer-Encoding] => chunked [transfer-encoding] => chunked [Expires] => Wed, 01 Jan 1997 12:00:00 GMT [expires] => Wed, 01 Jan 1997 12:00:00 GMT [Vary] => Accept-Encoding [vary] => Accept-Encoding ) [body] => [2004-08-24 20:54:36] robert at osuosl dot org I've noticed we've all dismissed this as a Microsoft IIS error, but we've been receiving the same warning using Apache 1.3.31 and PHP 5.0.0 and PHP 5.0.1, configured with the following options: ./configure --with-mysql=shared,/usr --prefix=/usr --with-apxs=/usr/bin/apxs-ssl --disable-rpath --with-layout=GNU --with-pear=/usr/share/php --enable-ftp --with-gettext --enable-sockets --with-zlib --with-kerberos=/usr --with-openssl --with-exec-dir=/usr/lib/php5/libexec --with-dom=shared,/usr --with-xsl --with-gettext Have any apache users had this error and corrected it? [2004-05-23 13:04:06] [EMAIL PROTECTED] Stupid bug system... The will be in the next snapshot from http://snaps.php.net. [2004-05-23 13:02:46] [EMAIL PROTECTED] This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. This has just been fixed in CVS. Note that due to the nature of the problem (eg: IIS being at fault), there is no way for PHP to determine the difference between a legitimate problem and a bogus IIS unless you are using the built-in HTTP wrapper: we inspect the headers to determine if we should show the warning or not. So, if you are manually opening an SSL stream, you still need to suppress the warning yourself based on the presence of "Server: Microsoft-IIS" in the headers that you read. [2004-05-03 17:56:01] grizu1 at gmx dot info Hi, this bug still exists on php4-STABLE-200405031430. ;-( System: - Linux (RedHat 8) 2.4.20-28.8 #1 Thu Dec 18 12:53:39 EST 2003 i686 i686 i386 GNU/Linux - php4-STABLE-200405031430 - OpenSSL 0.9.6b Configure command: './configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-mysql' '--with-openssl' '--with-sapdb=/opt/sapdb/interfaces/odbc/' php-script: https://foo.bar";; file_get_contents($url); ?> Output: Warning: file_get_contents(): SSL: fatal protocol error in /www/www.default.de/html/https2.php on line 3 Any help for me? Greetings grizu 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/23220 -- Edit this bug report at http://bugs.php.net/?id=23220&edit=1
#30315 [Opn]: big integers don't overflow
ID: 30315 Updated by: [EMAIL PROTECTED] Reported By: tokul at users dot sourceforge dot net Status: Open Bug Type: Variables related Operating System: Linux PHP Version: 5.0.2 New Comment: PHP never guaranteed that integers larger than 2^31 wrap negative. It has never been true on a 64-bit platform, for example; there, your code will have always printed "3725722773". I don't think this is a PHP bug. Previous Comments: [2004-10-04 10:03:43] [EMAIL PROTECTED] You didn't mention that before ;-) So no, then this is ofcourse a bug. [2004-10-04 08:58:11] tokul at users dot sourceforge dot net Have you checked php behaviour in other php versions? I have also tested 4.1.2, 4.3.9 and 5.0.1. This happens only on 5.0.2. I just need to know, if this is a bug or default behaviour in future php versions. [2004-10-04 08:39:49] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. . [2004-10-03 21:35:01] tokul at users dot sourceforge dot net Description: If big number (2500072158) is converted to integer, php 5.0.2 does not overflow and uses max integer value (2147483647). OS details: Linux Debian Sarge PHP compilation details (vanilla php-5.0.2.tar.bz2): ./configure --disable-debug --with-apxs=/somepath/apache/bin/apxs --prefix=/somepath/php --with-config-file-path=/somepath/ --with-pcre-regex --enable-mbstring --enable-session --disable-all --with-gettext=shared,/usr php.ini details: error_reporting=E_ALL display_errors=on register_globals=off asp_tags=on short_tags=off Is this standard future php behaviour or just some error in my config? Reproduce code: --- echo (int)0xde120495; Expected result: -569244523 Actual result: -- 2147483647 -- Edit this bug report at http://bugs.php.net/?id=30315&edit=1
#30329 [Opn]: Error Fetching http body, No Content-Length, connection closed or chunked data
ID: 30329
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: SOAP related
Operating System: Solaris 9
PHP Version: 5.0.2
New Comment:
The problem also sometimes occurs even with HTTP/1.0. After checking
this, it seems that EAServer does not send a Content-Length! Can we
change this in a way that get_http_body also accepts a zero
content-length?
Previous Comments:
[2004-10-05 13:57:07] [EMAIL PROTECTED]
Description:
I get the error message "Error Fetching http body, No Content-Length,
connection closed or chunked data [faultcode]" when try to communicate
with Sybase EAServer via SOAP.
When redirecting the web services via a Proxy-Plugin in an iPlanet
webserver everything works ok.
It seems that EAServer sends some bad encoded HTTP body.
When changing the SOAP extension code to only support HTTP/1.0,
everything works.
How about introducing an additional option to SoapClient named
"http_version" that can be set to 1.1 or 1.0 (default 1.1). At this
time "1.1" is hardcoded into php_http.c.
When 1.0 is on, "Connection:" should be assumed as "close".
Something other:
If the extension CURL is used, why not use CURL for sending SOAP
requests?
Reproduce code:
---
SOAP Test
http://ws.pangaea.de:8084/ws/services/WebServices?wsdl",array('trace'=>TRUE));
try {
$res=$ws->metadata("10.1594/PANGAEA/206854");
} catch (SoapFault $sf) {
echo "".print_r($sf)."";
}
echo
"Request".htmlspecialchars($ws->__getLastRequest())."Response".htmlspecialchars($ws->__getLastResponse())."";
echo "Decoded";
print_r($res);
?>
Expected result:
no SoapFault
--
Edit this bug report at http://bugs.php.net/?id=30329&edit=1
#30315 [Opn]: big integers don't overflow
ID: 30315 Updated by: [EMAIL PROTECTED] Reported By: tokul at users dot sourceforge dot net Status: Open Bug Type: Variables related Operating System: Linux PHP Version: 5.0.2 New Comment: But it's still breaking backward compatibility, and that is also important. IMO this should just work like it did before. Previous Comments: [2004-10-05 14:43:30] [EMAIL PROTECTED] PHP never guaranteed that integers larger than 2^31 wrap negative. It has never been true on a 64-bit platform, for example; there, your code will have always printed "3725722773". I don't think this is a PHP bug. [2004-10-04 10:03:43] [EMAIL PROTECTED] You didn't mention that before ;-) So no, then this is ofcourse a bug. [2004-10-04 08:58:11] tokul at users dot sourceforge dot net Have you checked php behaviour in other php versions? I have also tested 4.1.2, 4.3.9 and 5.0.1. This happens only on 5.0.2. I just need to know, if this is a bug or default behaviour in future php versions. [2004-10-04 08:39:49] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. . [2004-10-03 21:35:01] tokul at users dot sourceforge dot net Description: If big number (2500072158) is converted to integer, php 5.0.2 does not overflow and uses max integer value (2147483647). OS details: Linux Debian Sarge PHP compilation details (vanilla php-5.0.2.tar.bz2): ./configure --disable-debug --with-apxs=/somepath/apache/bin/apxs --prefix=/somepath/php --with-config-file-path=/somepath/ --with-pcre-regex --enable-mbstring --enable-session --disable-all --with-gettext=shared,/usr php.ini details: error_reporting=E_ALL display_errors=on register_globals=off asp_tags=on short_tags=off Is this standard future php behaviour or just some error in my config? Reproduce code: --- echo (int)0xde120495; Expected result: -569244523 Actual result: -- 2147483647 -- Edit this bug report at http://bugs.php.net/?id=30315&edit=1
#30027 [Com]: segmentation fault in ftp_get/memchr()
ID: 30027
Comment by: cfield at affinitysolutions dot com
Reported By: sbrown at truckstuffusa dot com
Status: Open
Bug Type: FTP related
Operating System: Redhat 9
PHP Version: 4.3.8
New Comment:
The following patch fixes this bug(also avaliable at
http://beta.affinitysolutions.com/bug30027.patch) :
Index: ext/ftp/ftp.c
===
RCS file: /repository/php-src/ext/ftp/ftp.c,v
retrieving revision 1.68.2.17
diff -u -r1.68.2.17 ftp.c
--- ext/ftp/ftp.c 31 Mar 2004 20:44:04 - 1.68.2.17
+++ ext/ftp/ftp.c 5 Oct 2004 12:41:18 -
@@ -727,12 +727,12 @@
ptr = s;
}
#else
- while ((s = memchr(ptr, '\r', (e - ptr {
+ while ((e>ptr) && (s = memchr(ptr, '\r', (e -
ptr {
php_stream_write(outstream, ptr, (s -
ptr));
if (*(s + 1) == '\n') {
s++;
+ php_stream_putc(outstream,
'\n');
}
- php_stream_putc(outstream, '\n');
ptr = s + 1;
}
#endif
Previous Comments:
[2004-09-21 23:31:32] cfield at affinitysolutions dot com
I have the same problem on an SMP redhat 9 system, i can get it to stop
the segmentation faults by adding "((e-ptr)>0) &&" to the while loop
condition on line 732 of ftp.c, however now i am getting sporadic extra
newlines (always in the same places in the file,see below for line
numbers etc. ) however, if i slowly step through the interaction it
does not put the extra new line in
line number written bytes total bytes
504 126475 126475
689 46333 172808
2589474698 647506
3088105999 753505
3766145320 898825
5005304503 1203328
516340804 1244132
522112232 1256364
558791208 1347572
7454424119 1771691
779080126 1851817
10501 686879 2538696
10680 42243 2580939
12103 361663 2942602
13382 311479 3254081
13921 137267 3391348
16803 724748 4116096
18468 414953 4531049
18654 43412 4574461
18934 63798 4638259
18988 13696 4651955
20429 349357 5001312
21981 390490 5391802
25524 906947 6298749
27445 448641 6747390
29239 497920 7245310
30083 220342 7465652
30274 46327 7511979
31340 270732 7782711
32882 353352 8136063
33421 123803 8259866
34365 224338 8484204
36254 449849 8934053
[2004-09-17 16:25:50] sbrown at truckstuffusa dot com
Downloaded CVS last night, still get the seg fault:
# php --version
PHP 4.3.9RC4-dev (cgi) (built: Sep 17 2004 09:19:39) (DEBUG)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
# gdb php
(gdb) run script-backup
Starting program: /usr/local/bin/php script-backup
...
Program received signal SIGSEGV, Segmentation fault.
0x4207bb01 in memchr () from /lib/tls/libc.so.6
(gdb) bt
#0 0x4207bb01 in memchr () from /lib/tls/libc.so.6
#1 0x0805eaa8 in ftp_get (ftp=0x81828ac, outstream=0x81a6afc,
path=0x81a6604 "/x-stuff/php/dashboard_projectmgmt.php",
type=FTPTYPE_ASCII, resumepos=0)
at /usr/local/src/php-src/ext/ftp/ftp.c:730
#2 0x0805c141 in zif_ftp_get (ht=4, return_value=0x81a6184,
this_ptr=0x0, return_value_used=1) at
/usr/local/src/php-src/ext/ftp/php_ftp.c:637
#3 0x0811cb8f in execute (op_array=0x81885b8) at
/usr/local/src/php-src/Zend/zend_execute.c:1640
#4 0x0811cdbb in execute (op_array=0x8189310) at
/usr/local/src/php-src/Zend/zend_execute.c:1684
#5 0x0811cdbb in execute (op_array=0x81827d4) at
/usr/local/src/php-src/Zend/zend_execute.c:1684
#6 0x0810ac19 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/local/src/php-src/Zend/zend.c:891
#7 0x080d6795 in php_execute_script (primary_file=0xb0e0) at
/usr/local/src/php-src/main/main.c:1735
#8 0x081238cc in main (argc=2, argv=0xb184) at
/usr/local/src/php-src/sapi/cgi/cgi_main.c:1592
(gdb) up
#1 0x0805eaa8 in ftp_get (ftp=0x81828ac, outstream=0x81a6afc,
path=0x81a6604 "/x-stuff/php/dashboard_projectmgmt.php",
type=FTPTYPE_ASCII, resumepos=0)
at /usr/local/src/php-src/ext/ftp/ftp.c:730
730 while ((s = memchr(ptr, '\r', (e -
ptr {
(gdb) p s
$1 = 0x81a6e57 "\n var contacts_win = "
(gdb) p ptr
$2 = 0x81a6e58 " var contacts_win = "
(gdb) p e
$3 = 0x81a6c4a "\n\r\n\r\n';\r\n elseif (isset($_GET['s"...
(gdb)
[2004-09-16 10:48:10] [EMAIL PROTECTED]
Get the latest stable CVS snapshot of PHP 4 and configure it with this
line:
# ./configure --disable-all --enable-ftp --enable-d
#30329 [Opn]: Error Fetching http body, No Content-Length, connection closed or chunked data
ID: 30329
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: SOAP related
Operating System: Solaris 9
PHP Version: 5.0.2
New Comment:
I don't think we should add workarounds around other buggy products.
This is violating the RFC iirc.
Previous Comments:
[2004-10-05 14:45:17] [EMAIL PROTECTED]
The problem also sometimes occurs even with HTTP/1.0. After checking
this, it seems that EAServer does not send a Content-Length! Can we
change this in a way that get_http_body also accepts a zero
content-length?
[2004-10-05 13:57:07] [EMAIL PROTECTED]
Description:
I get the error message "Error Fetching http body, No Content-Length,
connection closed or chunked data [faultcode]" when try to communicate
with Sybase EAServer via SOAP.
When redirecting the web services via a Proxy-Plugin in an iPlanet
webserver everything works ok.
It seems that EAServer sends some bad encoded HTTP body.
When changing the SOAP extension code to only support HTTP/1.0,
everything works.
How about introducing an additional option to SoapClient named
"http_version" that can be set to 1.1 or 1.0 (default 1.1). At this
time "1.1" is hardcoded into php_http.c.
When 1.0 is on, "Connection:" should be assumed as "close".
Something other:
If the extension CURL is used, why not use CURL for sending SOAP
requests?
Reproduce code:
---
SOAP Test
http://ws.pangaea.de:8084/ws/services/WebServices?wsdl",array('trace'=>TRUE));
try {
$res=$ws->metadata("10.1594/PANGAEA/206854");
} catch (SoapFault $sf) {
echo "".print_r($sf)."";
}
echo
"Request".htmlspecialchars($ws->__getLastRequest())."Response".htmlspecialchars($ws->__getLastResponse())."";
echo "Decoded";
print_r($res);
?>
Expected result:
no SoapFault
--
Edit this bug report at http://bugs.php.net/?id=30329&edit=1
#30329 [Opn]: Error Fetching http body, No Content-Length, connection closed or chunked data
ID: 30329
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: SOAP related
Operating System: Solaris 9
PHP Version: 5.0.2
New Comment:
incorrect. The EAServer does respond with HTTP/1.0. And in HTTP/1.0 you
can leave out the Content-Length (if unknown), because chunked encoding
cannot be used with 1.0
Previous Comments:
[2004-10-05 14:50:22] [EMAIL PROTECTED]
I don't think we should add workarounds around other buggy products.
This is violating the RFC iirc.
[2004-10-05 14:45:17] [EMAIL PROTECTED]
The problem also sometimes occurs even with HTTP/1.0. After checking
this, it seems that EAServer does not send a Content-Length! Can we
change this in a way that get_http_body also accepts a zero
content-length?
[2004-10-05 13:57:07] [EMAIL PROTECTED]
Description:
I get the error message "Error Fetching http body, No Content-Length,
connection closed or chunked data [faultcode]" when try to communicate
with Sybase EAServer via SOAP.
When redirecting the web services via a Proxy-Plugin in an iPlanet
webserver everything works ok.
It seems that EAServer sends some bad encoded HTTP body.
When changing the SOAP extension code to only support HTTP/1.0,
everything works.
How about introducing an additional option to SoapClient named
"http_version" that can be set to 1.1 or 1.0 (default 1.1). At this
time "1.1" is hardcoded into php_http.c.
When 1.0 is on, "Connection:" should be assumed as "close".
Something other:
If the extension CURL is used, why not use CURL for sending SOAP
requests?
Reproduce code:
---
SOAP Test
http://ws.pangaea.de:8084/ws/services/WebServices?wsdl",array('trace'=>TRUE));
try {
$res=$ws->metadata("10.1594/PANGAEA/206854");
} catch (SoapFault $sf) {
echo "".print_r($sf)."";
}
echo
"Request".htmlspecialchars($ws->__getLastRequest())."Response".htmlspecialchars($ws->__getLastResponse())."";
echo "Decoded";
print_r($res);
?>
Expected result:
no SoapFault
--
Edit this bug report at http://bugs.php.net/?id=30329&edit=1
#30315 [Opn]: big integers don't overflow
ID: 30315 Updated by: [EMAIL PROTECTED] Reported By: tokul at users dot sourceforge dot net Status: Open Bug Type: Variables related Operating System: Linux PHP Version: 5.0.2 New Comment: I would argue that backwards compatibility is about making guarantees and not breaking them. It's not about simply ensuring that all behaviour remains exactly the same forever, otherwise you can't change anything at all. But no guarantee was broken in this change. Previous Comments: [2004-10-05 14:48:28] [EMAIL PROTECTED] But it's still breaking backward compatibility, and that is also important. IMO this should just work like it did before. [2004-10-05 14:43:30] [EMAIL PROTECTED] PHP never guaranteed that integers larger than 2^31 wrap negative. It has never been true on a 64-bit platform, for example; there, your code will have always printed "3725722773". I don't think this is a PHP bug. [2004-10-04 10:03:43] [EMAIL PROTECTED] You didn't mention that before ;-) So no, then this is ofcourse a bug. [2004-10-04 08:58:11] tokul at users dot sourceforge dot net Have you checked php behaviour in other php versions? I have also tested 4.1.2, 4.3.9 and 5.0.1. This happens only on 5.0.2. I just need to know, if this is a bug or default behaviour in future php versions. [2004-10-04 08:39:49] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. . 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/30315 -- Edit this bug report at http://bugs.php.net/?id=30315&edit=1
#30156 [Com]: linker issue
ID: 30156
Comment by: rgski at hotmail dot com
Reported By: jtaisto at iocenter dot net
Status: Open
Bug Type: PHP options/info functions
Operating System: Solaris 9
PHP Version: 5.0.1
New Comment:
Problem Fixed:
At first going through the configure script, the finding was:
(around line 18071)
LIBS="
$LIBXML_SHARED_LIBADD
$LIBS"
Which we thought could have been the issue, (returns/spaces)
but we knew better that it shouldn't matter. We changed it
to:
LIBS="$LIBXML_SHARED_LIBADD $LIBS"
And of course we still got the error. After coping out the
small source and running the gcc (found in the config.log)
it compiled fine, but wasn't finding the correct library.
We added /usr/local/lib/sparcv9 to the LD_LIBRARY_PATH and
the configure ran fine. I am not sure why the CFLAGS or LDFLAGS were
not picked up properly for only this instance.
(-m64 and -mcpu=v9 should automatically source the sparcv9 libs)
But reguardless of that, it works and it's time to move on.
Good luck.
Rob
Previous Comments:
[2004-10-05 14:16:32] rgski at hotmail dot com
I have this exact issue with trying to compile 64bit PHP on Soalris9.
All other components have been compiled 64bit as well, however, finding
this error may lead me to believe that this may not be a php issue.
Why? I am trying to compile php5.0.2 and get the exact error at the
same exact location. It still could be a php issue though, I am not
sure. I'm still digging into the issue here.
Sol9 w/ most recent patch cluster
gcc 3.4.2
libtool 1.5.10 (I know it's not tested via php team. ;-)
libxml2 2.6.14
libxml 1.8.17
php 5.0.2
apache-ssl 1.3.31 (1.55 ssl)
[2004-09-22 14:36:58] jtaisto at iocenter dot net
configure exits with this:
Configuring extensions
checking whether to enable LIBXML support... yes
checking libxml2 install dir... /u1/xml/libxml2-2.6.13/sparcv9
checking whether libxml build works... no
configure: error: build test failed. Please check the config.log for
details.
The last lines in the config.log say:
configure:17846: checking whether to enable LIBXML support
configure:17893: checking libxml2 install dir
configure:18053: checking whether libxml build works
configure:18080: gcc -o conftest -O2 -m64 -mcpu=ultrasparc
-mtune=ultrasparc -pthreads -D_POSIX_PTHREAD_SEMANTICS
-D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -R/usr/ucblib -L/usr/ucblib
-R/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.2
-L/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.2
-R/u1/xml/libxml2-2.6.13/sparcv9/lib
-L/u1/xml/libxml2-2.6.13/sparcv9/lib conftest.c
-lresolv -lm -ldl -lnsl -lsocket -lgcc -lxml2 -lz -lm
-lsocket -lnsl 1>&5
configure: failed program was:
#line 18069 "configure"
#include "confdefs.h"
char xmlInitParser();
int main() {
xmlInitParser();
return 0;
}
[2004-09-19 17:58:00] [EMAIL PROTECTED]
What does config.log say about the reason for the failure?
[2004-09-19 17:45:46] jtaisto at iocenter dot net
Description:
Linker dies when trying to build with xml2 support.
Reproduce code:
---
export CC="gcc"
export CXX="gcc"
export CFLAGS="-O2 -m64 -mcpu=ultrasparc -mtune=ultrasparc"
export CXXFLAGS="-O2 -m64 -mcpu=ultrasparc -mtune=ultrasparc"
libxml2 build:./configure --prefix=/u1/xml/libxml2-2.6.13 \
--exec-prefix /u1/xml/libxml2-2.6.13/sparcv9 \
--with-xml2=/u1/xml/libxml2-2.6.13 \
--with-threads
./configure --with-libxml-dir=/u1/xml/libxml2-2.6.13/sparcv9 \
linker (/usr/ccs/bin/ld ) dies on this: configure:18080: gcc -o
conftest -O2 -m64 -mcpu=ultrasparc -mtune=ultrasparc -pthreads
-D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT
-R/usr/ucblib -L/usr/ucblib
-R/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.2
-L/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.2
-R/u1/xml/libxml2-2.6.13/sparcv9/lib
-L/u1/xml/libxml2-2.6.13/sparcv9/lib conftest.c
-lresolv -lm -ldl -lnsl -lsocket -lgcc -lxml2 -lz -lm -lsocket -lnsl
1>&5
configure: failed program was:
#line 18069 "configure"
#include "confdefs.h"
char xmlInitParser();
int main() {xmlInitParser();return 0;}
Expected result:
Not to see a fatal ld from the configure script. Configure able to use
xml2 library that is most recent stable. I've tried this even with just
32-bit using different version with no avail. Can't seem to get a
64-bit version supporting xml2 on Solaris 9 to work.
--
Edit this bug report at http://bugs.php.net/?id=30156&edit=1
#30328 [Opn]: Crash when passing undefned variable to __get() and return its name
ID: 30328 Updated by: [EMAIL PROTECTED] Reported By: flying at dom dot natm dot ru Status: Open Bug Type: Reproducible crash Operating System: windows 2000 PHP Version: 5.0.2 New Comment: Seems to be 5.0.x specific - I can't reproduce it with 5.1-dev. Notice: Undefined variable: testvar in /www/index.php on line 13 __get() called: Program received signal SIGSEGV, Segmentation fault. 0x4207c0dc in mempcpy () from /lib/tls/libc.so.6 (gdb) bt #0 0x4207c0dc in mempcpy () from /lib/tls/libc.so.6 #1 0x4206e660 in _IO_file_xsputn () from /lib/tls/libc.so.6 #2 0x42062e32 in fwrite () from /lib/tls/libc.so.6 #3 0x081c601a in sapi_cli_single_write (str=0x0, str_length=136509472) at /home/dev/php-src_PHP_5_0/sapi/cli/php_cli.c:192 #4 0x081c4692 in sapi_cli_ub_write (str=0x0, str_length=136509472) at /home/dev/php-src_PHP_5_0/sapi/cli/php_cli.c:205 #5 0x0815d563 in php_ub_body_write_no_header (str=0x0, str_length=136509472) at /home/dev/php-src_PHP_5_0/main/output.c:684 #6 0x0815c1aa in php_body_write (str=0x0, str_length=136509472) at /home/dev/php-src_PHP_5_0/main/output.c:119 #7 0x0814da36 in php_body_write_wrapper (str=0x0, str_length=136509472) at /home/dev/php-src_PHP_5_0/main/main.c:1242 #8 0x0819251c in zend_print_zval_ex (write_func=0x814da15 , expr=0xbfffd2b0, indent=0) at /home/dev/php-src_PHP_5_0/Zend/zend.c:288 #9 0x0819249a in zend_print_zval (expr=0xbfffd300, indent=0) at /home/dev/php-src_PHP_5_0/Zend/zend.c:269 #10 0x08191c2f in zend_print_variable (var=0xbfffd300) at /home/dev/php-src_PHP_5_0/Zend/zend_variables.c:168 #11 0x081b9d2d in zend_echo_handler (execute_data=0xffd45008, opline=0x2ca910bf, op_array=0x2c641c08) at /home/dev/php-src_PHP_5_0/Zend/zend_execute.c:1989 Previous Comments: [2004-10-05 12:37:01] flying at dom dot natm dot ru Description: PHP 5.0.2 on Windows 2000 SP4. There is reproducible crash happens when one tries to pass undefined variable to a class with defined __get() function. Example code: $testvar; ?> Running this code from under Apache results in HTTP 500 error, running it from shell results to some garbage to be shown on screen and program exit. However running it as: php.exe test.php >log results in following text appearing in log: Notice: Undefined variable: testvar in C:\web\test.php on line 13 __get() called: Moreover changing return($name); inside __get() to returning anything else (either static value or some other variable) results in crash disappearing. -- Edit this bug report at http://bugs.php.net/?id=30328&edit=1
#30027 [Opn]: segmentation fault in ftp_get/memchr()
ID: 30027
User updated by: sbrown at truckstuffusa dot com
Reported By: sbrown at truckstuffusa dot com
Status: Open
Bug Type: FTP related
Operating System: Redhat 9
PHP Version: 4.3.8
New Comment:
A comment on cfield at affinitysolutions dot com's patch: He sent this
patch to me and I applied it to both CVS and php 4.3.8. The patch
seemed to resolve the segmentation fault without adding extra line
breaks to the files, however, gdb would throw some wierd errors when
the script was finished executing. I'm wondering if someone else can
interpret these results from gdb (or if this isn't anything to worry
about):
warning: Unexpected waitpid result 00 when waiting for vfork-done
[tcsetpgrp failed in terminal_inferior: Operation not permitted]
ptrace: No such process.
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
0x420ac7a8 in vfork () from /lib/tls/libc.so.6
Previous Comments:
[2004-10-05 14:49:52] cfield at affinitysolutions dot com
The following patch fixes this bug(also avaliable at
http://beta.affinitysolutions.com/bug30027.patch) :
Index: ext/ftp/ftp.c
===
RCS file: /repository/php-src/ext/ftp/ftp.c,v
retrieving revision 1.68.2.17
diff -u -r1.68.2.17 ftp.c
--- ext/ftp/ftp.c 31 Mar 2004 20:44:04 - 1.68.2.17
+++ ext/ftp/ftp.c 5 Oct 2004 12:41:18 -
@@ -727,12 +727,12 @@
ptr = s;
}
#else
- while ((s = memchr(ptr, '\r', (e - ptr {
+ while ((e>ptr) && (s = memchr(ptr, '\r', (e -
ptr {
php_stream_write(outstream, ptr, (s -
ptr));
if (*(s + 1) == '\n') {
s++;
+ php_stream_putc(outstream,
'\n');
}
- php_stream_putc(outstream, '\n');
ptr = s + 1;
}
#endif
[2004-09-21 23:31:32] cfield at affinitysolutions dot com
I have the same problem on an SMP redhat 9 system, i can get it to stop
the segmentation faults by adding "((e-ptr)>0) &&" to the while loop
condition on line 732 of ftp.c, however now i am getting sporadic extra
newlines (always in the same places in the file,see below for line
numbers etc. ) however, if i slowly step through the interaction it
does not put the extra new line in
line number written bytes total bytes
504 126475 126475
689 46333 172808
2589474698 647506
3088105999 753505
3766145320 898825
5005304503 1203328
516340804 1244132
522112232 1256364
558791208 1347572
7454424119 1771691
779080126 1851817
10501 686879 2538696
10680 42243 2580939
12103 361663 2942602
13382 311479 3254081
13921 137267 3391348
16803 724748 4116096
18468 414953 4531049
18654 43412 4574461
18934 63798 4638259
18988 13696 4651955
20429 349357 5001312
21981 390490 5391802
25524 906947 6298749
27445 448641 6747390
29239 497920 7245310
30083 220342 7465652
30274 46327 7511979
31340 270732 7782711
32882 353352 8136063
33421 123803 8259866
34365 224338 8484204
36254 449849 8934053
[2004-09-17 16:25:50] sbrown at truckstuffusa dot com
Downloaded CVS last night, still get the seg fault:
# php --version
PHP 4.3.9RC4-dev (cgi) (built: Sep 17 2004 09:19:39) (DEBUG)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
# gdb php
(gdb) run script-backup
Starting program: /usr/local/bin/php script-backup
...
Program received signal SIGSEGV, Segmentation fault.
0x4207bb01 in memchr () from /lib/tls/libc.so.6
(gdb) bt
#0 0x4207bb01 in memchr () from /lib/tls/libc.so.6
#1 0x0805eaa8 in ftp_get (ftp=0x81828ac, outstream=0x81a6afc,
path=0x81a6604 "/x-stuff/php/dashboard_projectmgmt.php",
type=FTPTYPE_ASCII, resumepos=0)
at /usr/local/src/php-src/ext/ftp/ftp.c:730
#2 0x0805c141 in zif_ftp_get (ht=4, return_value=0x81a6184,
this_ptr=0x0, return_value_used=1) at
/usr/local/src/php-src/ext/ftp/php_ftp.c:637
#3 0x0811cb8f in execute (op_array=0x81885b8) at
/usr/local/src/php-src/Zend/zend_execute.c:1640
#4 0x0811cdbb in execute (op_array=0x8189310) at
/usr/local/src/php-src/Zend/zend_execute.c:1684
#5 0x0811cdbb in execute (op_array=0x81827d4) at
/usr/local/src/php-src/Zend/zend_execute.c:1684
#6 0x0810ac19 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/local/src/php-src/Zend/zend.c:891
#7 0x0
#22355 [Com]: mail func strips linefeeds from subject
ID: 22355
Comment by: kawaiisteph at yahoo dot com
Reported By: jotta at mailbox dot hu
Status: Closed
Bug Type: Mail related
Operating System: Linux 2.2.20
PHP Version: 4.2.3
New Comment:
The subject line is in Japanese text and is extremely long, so that it
takes several minutes to open. It can not be deleted and also can not
be opened.
Previous Comments:
[2003-02-24 13:44:29] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Keep in mind that your code will still not work as is, RFC 822
specifies that the "separator" must be CRLF followed by atleast one \t
or a space.
This means you should use \r\n\t and not \n\t.
[2003-02-24 09:17:12] jotta at mailbox dot hu
It wasn't the sendmail binary, because after encountering the problem
I've moved to call sendmail directly via popen(), and e-mail sending
works this way properly (ofcourse I'm passing the same multiline
$subject
variable to sendmail through fputs).
I've found the part of the code I believe to cause the problem in
ext/standard/mail.c (in the source of the latest, 4.3.1 release, though
I encountered the bug itself in 4.2.3 first):
PHP_FUNCTION(mail)
{
/* ...cut... */
if (subject_len > 0) {
for (; subject_len; subject_len--) {
if (!isspace((unsigned char) subject[subject_len - 1])) {
break;
}
subject[subject_len - 1] = '\0';
}
for(i = 0; subject[i]; i++) {
if (iscntrl((unsigned char) subject[i])) {
subject[i] = ' ';
}
}
}
/* ...cut... */
The second 'for' cycle must be responsible for replacing all the new
line characters to spaces. I think it was used because the developers
wanted to avoid the extra leading/trailing linefeeds in the Subject:
line (that also leads to send incorrectly formatted (and displayed)
e-mails).
If you agree, I'd suggest replacing this part of code to another one
which is trimming only the leading/trailing control characters - or
even a more sophisticated one that would format the subject line to
conform to RFC 822,
part 3.1.1 "Long header fields", part 3.4.8 "Folding long header
fields".
[In fact, I'd suggest doing these modifications also to the recipient
address (the 'To:' field) for the same reason.]
[2003-02-23 21:50:15] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
I've tried the code & looked over the source and there is nothing that
would 'strip' newlines as you suggest. If they are still being stripped
in the new code I would say it is the doing of your sendmail binary.
[2003-02-21 09:09:22] jotta at mailbox dot hu
Before sending an email, first I'm using mb_encode_mimeheader() to
prepare the subject (it's very important because of the Central
European national characters)
$subject =
mb_encode_mimeheader(
trim($_POST['i_subject']),
'iso-8859-2',
'Q',
"\n\t"
);
\n\t is used, because e-mail RFCs state, that long lines should look be
broken like this:
Subject: very long subject etc. etc. and will
continue here
The problem exactly: mail() function strips the \n characters, this way
the e-mails are sent in a non-standard way (even 200+ characters long
subject lines), and therefore some servers and/or mail reading
softwares fail to transfer/display the email correctly.
--
Edit this bug report at http://bugs.php.net/?id=22355&edit=1
#30165 [Asn->Bgs]: SOAP FAULT upgrading from PEAR::SOAP to php5
ID: 30165
Updated by: [EMAIL PROTECTED]
Reported By: s dot tabacchiera at gruppocsf dot com
-Status: Assigned
+Status: Bogus
Bug Type: SOAP related
Operating System: Linux
PHP Version: 5.0.1
Assigned To: dmitry
New Comment:
Acording to WSDL 1.1 specification
(http://www.w3.org/TR/2001/NOTE-wsdl-20010315) the proper valu for HTTP
transport is "http://schemas.xmlsoap.org/soap/http";.
Previous Comments:
[2004-09-24 12:58:20] s dot tabacchiera at gruppocsf dot com
I think I found the bug.
In ext/soap/php_encoding.h there is a wrong define:
Bad:
#define WSDL_HTTP_TRANSPORT "http://schemas.xmlsoap.org/soap/http";
Good:
#define WSDL_HTTP_TRANSPORT "http://schemas.xmlsoap.org/soap/http/";
Diff is a missing trailing slash.
Hope this helps.
[2004-09-21 10:58:08] ante dot dfg at moj dot net
YesI have the same problem...nothing related to SOAP works in php
5.0.1..I tried some examples from zend.com(for php5) and all the time
php 5.0.1 crasches with the Uncaught SoapFault exception..Im on WinXP
sp1, Apache 1.3.31, php 5.0.1
[2004-09-20 12:51:55] s dot tabacchiera at gruppocsf dot com
Description:
Hi all, my server is running php4 and PEAR::SOAP 0.8RC2, whilst client
is running php5.
This code generates an error:
-
http://blablabla.com/soap_server.php?wsdl";;
$client1 = new SoapClient($wsdl1);
var_dump($client1->__getFunctions());
?>
The error:
Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL:PHP-SOAP doesn't support transport
'http://schemas.xmlsoap.org/soap/http/' in/root/soap.php:3
Stack trace:
#0 {main} thrown in /root/soap.php on line 3
Any clue?
--
Edit this bug report at http://bugs.php.net/?id=30165&edit=1
#29733 [Com]: printf handles repeated placeholders wrong
ID: 29733
Comment by: bugs dot php dot net at afdelingp dot dk
Reported By: bugs dot php dot net at bluetwanger dot de
Status: Open
Bug Type:Strings related
PHP Version: 5.0.1
New Comment:
The bug is also in PHP 4.3.
The problem is that the original check for too-few-arguments was left
in the code when I implemented argnum swapping. Your patch (moving the
check to the bottom instead of having two checks) fixes this, and
should be applied to PHP 4.3 too.
Embarrassing :-)
Previous Comments:
[2004-09-30 16:42:33] danielc at analysisandsolutions dot com
Note, the error only happens when mixing numbered and non-numberd
directives. Tweaking the example from the original bug report to use
only numbered directives eliminates the error:
printf('%1$s - %2$s %3$s %3$s %2$s', 1, 2, 3);
[2004-08-27 14:36:16] bugs dot php dot net at bluetwanger dot de
Here's a link:
http://www.bluetwanger.de/~mbertheau/formatted_print.c.patch
You make it really hard to submit a patch. This bug thing has no
provision for attaching a file and you have to strain a lot to get at
an email address of a developer mailing list.
[2004-08-27 14:30:33] bugs dot php dot net at bluetwanger dot de
Here's a patch:
--- ext/standard/formatted_print.c.orig 2004-07-18 19:28:04.0
+0200
+++ ext/standard/formatted_print.c 2004-08-27 14:23:07.580732341
+0200
@@ -537,12 +537,6 @@
php_sprintf_appendchar(&result, &outpos, &size,
'%' TSRMLS_CC);
inpos += 2;
} else {
- if (currarg >= argc && format[inpos + 1] !=
'%') {
- efree(result);
- efree(args);
- php_error_docref(NULL TSRMLS_CC,
E_WARNING, "Too few arguments");
- return NULL;
- }
/* starting a new format specifier, reset
variables */
alignment = ALIGN_RIGHT;
adjusting = 0;
@@ -574,13 +568,6 @@
argnum += format_offset;
- if (argnum >= argc) {
- efree(result);
- efree(args);
- php_error_docref(NULL
TSRMLS_CC, E_WARNING, "Too few arguments");
- return NULL;
- }
-
/* after argnum comes modifiers */
PRINTF_DEBUG(("sprintf: looking for
modifiers\n"
"sprintf: now
looking at '%c', inpos=%d\n",
@@ -635,6 +622,13 @@
argnum = currarg++ + format_offset;
}
+if (argnum >= argc) {
+efree(result);
+efree(args);
+php_error_docref(NULL TSRMLS_CC, E_WARNING, "Too few
arguments");
+return NULL;
+}
+
if (format[inpos] == 'l') {
inpos++;
}
Let's see if the line breaks survive.
It basically removes the bogus (format[inpos + 1] != '%' will always be
true there) arg number check and moves the right one outside the special
case for "complicated" format specifiers.
[2004-08-18 14:46:41] bugs dot php dot net at bluetwanger dot de
Description:
printf('%s - %s %s %3$s %2$s', 1, 2, 3);
complains:
Warning: printf(): Too few arguments in /home/bertheau/printf.php on
line 2
printf('%s - %s %s %3$s %2$s', 1, 2, 3, 4);
does not complain and prints:
1 - 2 3 3 2
I expect the first version to not complain and print what the second
version prints.
--
Edit this bug report at http://bugs.php.net/?id=29733&edit=1
#30315 [Com]: big integers don't overflow
ID: 30315 Comment by: php at botimer dot net Reported By: tokul at users dot sourceforge dot net Status: Open Bug Type: Variables related Operating System: Linux PHP Version: 5.0.2 New Comment: According to my quick tests, there are a couple of issues at work here. They are: 1) The interpretation of hex constants 2) The conversion of numbers larger than 32-bits to 32-bit integers I whipped together this test script to figure out exactly what's happening and ran it on PHP 4.1.2 and 5.0.2. I haven't had a chance to run it on a 4.3.x, but I don't think it actually makes a difference unless it is yet another variant. The first issue is that hex constants larger than 2^31 are truncated to 2^31. I haven't thoroughly searched the documentation, but my Vim syntax highlighting suggests that 8 characters is the limit for understood hex constants. The second issue is the actual sticky point. PHP 4 exhibits the behavior I would expect. When dealing with a number larger than a 32-bit integer can hold, casting to (int) returns the low byte of the value. PHP5, however, ``makes up'' 2^31 as the value. The last four lines of output are the most interesting. On my 4.1.2 test, the values were 0, 2^31, 1, 2^31, while on 5.0.2, they were 2^31, 2^31, 2^31, 2^31. Due to the behavior of the hex constant interpretation, I would expect the 2^31 in the second and fourth lines of that section, but I would not expect PHP to ``make up'' the other two. I would classify this as a numeric bug. If PHP5 were to truncate the values, it would return as does 4.1.2. It is sensible that, because the quantity is positive, the ``rounding to the nearest positive 32-bit integer'' would yield 2^31, but I feel that it is likely undesired behavior. %<=%< %<=%< PHP 4.1.2 results: int(2147483647) int(2147483647) float(2147483648) float(2147483648) float(4294967295) float(4294967295) float(4294967296) int(2147483647) float(4294967297) int(2147483647) 0 2147483647 1 2147483647 %<%< PHP 5.0.2 results: int(2147483647) int(2147483647) float(2147483648) float(2147483648) float(4294967295) float(4294967295) float(4294967296) int(2147483647) float(4294967297) int(2147483647) 2147483647 2147483647 2147483647 2147483647 Previous Comments: [2004-10-05 15:11:40] [EMAIL PROTECTED] I would argue that backwards compatibility is about making guarantees and not breaking them. It's not about simply ensuring that all behaviour remains exactly the same forever, otherwise you can't change anything at all. But no guarantee was broken in this change. [2004-10-05 14:48:28] [EMAIL PROTECTED] But it's still breaking backward compatibility, and that is also important. IMO this should just work like it did before. [2004-10-05 14:43:30] [EMAIL PROTECTED] PHP never guaranteed that integers larger than 2^31 wrap negative. It has never been true on a 64-bit platform, for example; there, your code will have always printed "3725722773". I don't think this is a PHP bug. [2004-10-04 10:03:43] [EMAIL PROTECTED] You didn't mention that before ;-) So no, then this is ofcourse a bug. [2004-10-04 08:58:11] tokul at users dot sourceforge dot net Have you checked php behaviour in other php versions? I have also tested 4.1.2, 4.3.9 and 5.0.1. This happens only on 5.0.2. I just need to know, if this is a bug or default behaviour in future php versions. 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/30315 -- Edit this bug report at http://bugs.php.net/?id=30315&edit=1
#30175 [Asn->Csd]: SOAP results aren't parsed correctly
ID: 30175
Updated by: [EMAIL PROTECTED]
Reported By: waboring at 3gstech dot com
-Status: Assigned
+Status: Closed
Bug Type: SOAP related
Operating System: linux
PHP Version: 5CVS-2004-09-21 (dev)
Assigned To: dmitry
New Comment:
Fixed in CVS HEAD and PHP_5_0.
But I am not sure about proper SOAP result.
>From my point of view it should contain
instead of .
Previous Comments:
[2004-09-21 01:45:23] waboring at 3gstech dot com
The entire response is
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:ns1="urn:qweb">http://schemas.xmlsoap.org/soap/encoding/";
id="_0">blah blah some name fieldThis is a description. more blah blah
blah127.0.0.1
[2004-09-21 01:39:36] waboring at 3gstech dot com
Description:
I have a complex type returned in a SOAP reply and I am getting an
array with null values back from the soap client.
The array that is return has the correct keys, but the values are
always null. The response has the values. I tried this with NuSOAP
and it works fine.
The NuSoap script that works is at
http://www.newsblob.com/nusoap/qweb.php
I don't have a publicly available php5 install, but here is the code
that fails.
Reproduce code:
---
\n";
print var_dump($var, TRUE);
echo "\n";
}
$client = new SoapClient('http://www.newsblob.com/qweb.wsdl',
array('trace' => 1,
'exceptions' => 1));
//ok try and get the host struct
$host = $client->qwebGetHostInfo();
xxx($host);
echo "Request : ".xxx($client->__getLastRequest(), TRUE);
echo "Response : ".xxx($client->__getLastResponse(), TRUE);
?>
Expected result:
I should see:
array(3) { ["name"]=> string(25) "blah blah some name field"
["shortDescription"]=> string(43) "This is a description. more blah
blah blah" ["ipAddress"]=> string(9) "127.0.0.1" }
Actual result:
--
array(3) { ["name"]=> NULL ["shortDescription"]=> NULL ["ipAddress"]=>
NULL }
--
Edit this bug report at http://bugs.php.net/?id=30175&edit=1
#12061 [Com]: CGI Error
ID: 12061 Comment by: Jammu dot Peltonen at Tuko dot se Reported By: peters at connection dot ca Status: Bogus Bug Type: IIS related Operating System: Win 2K PHP Version: 4.0.6 New Comment: Yeah, there is no Install.txt The similiar file Install. directs you to read the Documentation, and the documentation directs you to read the Install.txt Previous Comments: [2004-10-01 20:32:57] Robert dot Jalarvo at Helsinki dot Fi install. refers to documentation and documentation refers to install.txt [2001-07-11 14:19:47] [EMAIL PROTECTED] Your setup is just incorrectly configured. Please read the install.txt file for details of what you need to check. If you still have problems, post a query to the php-windows or php-install lists. [2001-07-11 13:42:23] peters at connection dot ca when using the simple script of : I get the following error: CGI Error The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: Noticed other are reporting same problems on the News Groups.. -- Edit this bug report at http://bugs.php.net/?id=12061&edit=1
#30330 [NEW]: fmod() does not return the correct value.
From: dbauleo at terra dot com dot br
Operating system: Windows 2000
PHP version: 4.3.9
PHP Bug Type: Math related
Bug description: fmod() does not return the correct value.
Description:
I used the fmod() function with float numbers, and it was an exact
division, so it was supposed to return 0, instead of it, the Y value was
returned.
Reproduce code:
---
Expected result:
fmod(396456.06, 56636.58) = 0
Actual result:
--
fmod(396456.06, 56636.58) = 56636.58
function f_mod($x,$y)
{
$i = floor($x / $y);
$a = $x - $i * $y;
return $a;
}
f_mod(396456.06, 56636.58) = 0
--
Edit bug report at http://bugs.php.net/?id=30330&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30330&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30330&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30330&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30330&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30330&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30330&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30330&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30330&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30330&r=support
Expected behavior: http://bugs.php.net/fix.php?id=30330&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30330&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30330&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30330&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30330&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30330&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30330&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30330&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30330&r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30330&r=mysqlcfg
#30058 [Opn->Fbk]: Yet Another Solaris compilation problem :-((
ID: 30058 Updated by: [EMAIL PROTECTED] Reported By: l_faillie at yahoo dot com -Status: Open +Status: Feedback Bug Type: FTP related Operating System: Solaris 8 PHP Version: 4.3.8 New Comment: This seems more like feature request (getting more info as an error message if the ftp_*() functions fail..) but anyway, are you sure this isn't some firewall issue..? (like I've had had to struggle with for last 6 months.. :) Previous Comments: [2004-10-02 17:01:21] l_faillie at yahoo dot com Ok, the result is : bool(false) [2004-10-02 16:09:39] [EMAIL PROTECTED] change the ftp_put() line in your script to this: $retval = ftp_put($con, basename($fch), basename($fch), FTP_BINARY); var_dump ($retval); And tell us what you get now.. [2004-10-01 18:16:14] l_faillie at yahoo dot com > You said you don't get any output. But ftp_put() doesn't > output anything at all..what do you expect it to output? Whell, as this function fails and rise the die() clause of 'ftp_put() or die()', I'm expecting an error message saying ... why ftp_put() fails. Like "remote host close the connexion" or something like that. > What does this output: > # php -r 'ftp_put();' $php -r 'ftp_put();' Warning: ftp_put() expects at least 4 parameters, 0 given in Command line code on line 1 [2004-09-30 16:13:40] [EMAIL PROTECTED] You said you don't get any output. But ftp_put() doesn't output anything at all..what do you expect it to output? What does this output: # php -r 'ftp_put();' [2004-09-29 00:08:00] l_faillie at yahoo dot com > add 'error_reporting(E_ALL);' as first line in your script > and also run > it on the CLI binary of PHP. Report here what error > messages you get. I have added this line but nothing is displayed. Also, I alway launch this script using the CLI binary ... because my script is a CLI tool. > Also, with what compiler did you compile PHP? (version!) $ gcc -v Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.8/3.4.1/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls --disable-libgcj --enable-languages=c,c++ Thread model: posix gcc version 3.4.1 It's the one from http://www.sunfreeware.com/ 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/30058 -- Edit this bug report at http://bugs.php.net/?id=30058&edit=1
#30330 [Opn->Bgs]: fmod() does not return the correct value.
ID: 30330
Updated by: [EMAIL PROTECTED]
Reported By: dbauleo at terra dot com dot br
-Status: Open
+Status: Bogus
Bug Type: Math related
Operating System: Windows 2000
PHP Version: 4.3.9
New Comment:
Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.
Thank you for your interest in PHP.
.
Previous Comments:
[2004-10-05 19:46:53] dbauleo at terra dot com dot br
Description:
I used the fmod() function with float numbers, and it was an exact
division, so it was supposed to return 0, instead of it, the Y value
was returned.
Reproduce code:
---
Expected result:
fmod(396456.06, 56636.58) = 0
Actual result:
--
fmod(396456.06, 56636.58) = 56636.58
function f_mod($x,$y)
{
$i = floor($x / $y);
$a = $x - $i * $y;
return $a;
}
f_mod(396456.06, 56636.58) = 0
--
Edit this bug report at http://bugs.php.net/?id=30330&edit=1
#30331 [NEW]: Function mktime returns wrong date
From: grumiche at powers dot com dot br Operating system: AIX 5.1 PHP version: 4.3.9 PHP Bug Type: Date/time related Bug description: Function mktime returns wrong date Description: Function mktime returns wrong date. Problem found when installing eGroupWare at AIX. Machine: IBM RISC 6000 e30 OS: AIX 5.1 Maintenance Level 6 PHP 4.3.9 Apache 1.3.29-1 Without changes on php.ini. Compiled modules: '/configure' '--with-apxs=/opt/freeware/apache/sbin/apxs' '--with-mysql' '--enable-trackvars' '--with-ldap' '--with-gettext=/opt/freeware' '--with-mbstring' '--with-pear' '--with-gd=/opt/freeware' '--with-zlib=/opt/freeware' '--with-freetype-dir=/opt/freeware' '--with-ttf=/opt/freeware' '--enable-mbstring' '--with-jpeg-dir=/opt/freeware' '--with-png-dir=/opt/freeware' '--with-zlib-dir=/opt/freeware' Same error apears on another installation: Machine: IBM RISC 6000 43P OS: AIX 5.1 Maintenance Level 3 PHP 4.3.8 Apache 1.3.29-1 Without changes on php.ini. Compiled modules: './configure' '--with-apxs=/opt/freeware/apache/sbin/apxs' '--with-mysql' '--enable-trackvars' '--with-ldap' '--with-gettext=/opt/freeware' '--with-mbstring' '--with-pear' '--with-openssl=/opt/freeware' '--with-gd=/opt/freeware' '--with-zlib=/opt/freeware' Reproduce code: --- mktime(2,0,0,10,1 - (5 - 1), 2004,1) Expected result: 1096261200 Actual result: -- 1096520400 -- Edit bug report at http://bugs.php.net/?id=30331&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30331&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30331&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30331&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30331&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30331&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30331&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30331&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30331&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30331&r=support Expected behavior: http://bugs.php.net/fix.php?id=30331&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30331&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30331&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30331&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30331&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30331&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30331&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30331&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30331&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30331&r=mysqlcfg
#16690 [Com]: Java support in PHP with Apache2 multithreaded server doesn't work
ID: 16690 Comment by: Supergurl11191 at aol dot com Reported By: cunha17 at uol dot com dot br Status: Wont fix Bug Type: Java related Operating System: any PHP Version: 4.3.2RC4-dev New Comment: jghjgjghjghj Previous Comments: [2004-07-27 15:36:05] engel_o at yahoo dot com Me too ! The interaction between Java and PHP is really important [2004-07-04 03:37:44] rustamabd at columbus dot rr dot com Without this fix, Java support is useless. recommend reopening with highest priority. [2003-11-17 22:38:08] [EMAIL PROTECTED] Java support in PHP 4 has been extremely experimental since it was introduced. And the support for it has been dropped. [2003-05-21 17:40:30] cunha17 at uol dot com dot br Why the status changed to SUSPENDED? Does it mean that it is not important? [2002-10-04 17:33:01] [EMAIL PROTECTED] This really falls inline with the numerous Java/Windows bugs that we have logged. My initial debugging of it shows that their problems are being caused by the non-multi-thread safe code. Havne't been able to fix it yet though. 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/16690 -- Edit this bug report at http://bugs.php.net/?id=16690&edit=1
#30058 [Fbk->Opn]: Yet Another Solaris compilation problem :-((
ID: 30058 User updated by: l_faillie at yahoo dot com Reported By: l_faillie at yahoo dot com -Status: Feedback +Status: Open Bug Type: FTP related Operating System: Solaris 8 PHP Version: 4.3.8 New Comment: > This seems more like feature request (getting more info > as an error message if the ftp_*() functions fail..) > but anyway, It should be better if we have better message in case of failure, but as I said previously, I put some tracing puts() in ext/ftp/php_ftp.c and it seems that PHP_FUNCTION(ftp_fput), line 768 is never called. So for me it's more an issue in the PHP parser than in ftp function themselfs. Unfortunatly, I'm not confident enough w/ PHP parser to trace deeply in the code. > are you sure this isn't some firewall issue..? (like > I've had had to struggle with for last 6 months.. :) Yes, because both machines are on the same networks and I can connect using the normal Solaris FTP client. Previous Comments: [2004-10-05 20:14:20] [EMAIL PROTECTED] This seems more like feature request (getting more info as an error message if the ftp_*() functions fail..) but anyway, are you sure this isn't some firewall issue..? (like I've had had to struggle with for last 6 months.. :) [2004-10-02 17:01:21] l_faillie at yahoo dot com Ok, the result is : bool(false) [2004-10-02 16:09:39] [EMAIL PROTECTED] change the ftp_put() line in your script to this: $retval = ftp_put($con, basename($fch), basename($fch), FTP_BINARY); var_dump ($retval); And tell us what you get now.. [2004-10-01 18:16:14] l_faillie at yahoo dot com > You said you don't get any output. But ftp_put() doesn't > output anything at all..what do you expect it to output? Whell, as this function fails and rise the die() clause of 'ftp_put() or die()', I'm expecting an error message saying ... why ftp_put() fails. Like "remote host close the connexion" or something like that. > What does this output: > # php -r 'ftp_put();' $php -r 'ftp_put();' Warning: ftp_put() expects at least 4 parameters, 0 given in Command line code on line 1 [2004-09-30 16:13:40] [EMAIL PROTECTED] You said you don't get any output. But ftp_put() doesn't output anything at all..what do you expect it to output? What does this output: # php -r 'ftp_put();' 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/30058 -- Edit this bug report at http://bugs.php.net/?id=30058&edit=1
#29860 [Com]: Cannot compile with mysql and mysqli extensions
ID: 29860 Comment by: php at kilimajer dot net Reported By: rjanson at msn dot com Status: Open Bug Type: Compile Failure Operating System: Redhat 9 PHP Version: 5.0.1 New Comment: Workaround is to execute the last failing command with one -lmysqlclient removed, then again make. This should be fixed in ext/mysqli/config.m4. Previous Comments: [2004-10-05 13:50:38] php at kilimajer dot net This is caused by -lmysqlclient being supplied twice to the linker (at least it was my case). [2004-09-24 19:59:01] rjanson at msn dot com I've tried the same steps with php-5.02 and still the same results. [2004-09-21 01:12:32] rjanson at msn dot com I tried backing up and completely uninstalling, then reinstalling Mysql-4.1.4-0 from RPM, and still get the same result. Others out there are having this issue as well. Is there nothing to be done? --Rich [2004-09-13 20:44:01] rjanson at msn dot com I installed mysql via the RPMs provided on the MySQL site. I unsinstalled the MySQL-shared-compat-4.1.4-0 rpm and tried building agin with the same result. These are the RPMs I have installed currently: MySQL-devel-4.1.4-0 MySQL-client-4.1.4-0 MySQL-Max-4.1.4-0 MySQL-bench-4.1.3-1 MySQL-server-4.1.4-0 MySQL-shared-4.1.4-0 Is it possible something with the RPMs is causing the failure? [2004-09-13 19:38:30] nathansquires at pacbell dot net I had the same linking problem with php 5.0.1 and mysql 4.1.4a-gamma. I was able to compile with mysql and mysqli by rebuilding mysql with shared libraries (i.e. don't use --without-shared or --*flags=--all-static). If you only have static mysql libraries, trying to build php with mysql and mysqli will cause this error. 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/29860 -- Edit this bug report at http://bugs.php.net/?id=29860&edit=1
#29860 [Opn]: Cannot compile with mysql and mysqli extensions
ID: 29860 User updated by: rjanson at msn dot com Reported By: rjanson at msn dot com Status: Open Bug Type: Compile Failure Operating System: Redhat 9 PHP Version: 5.0.1 New Comment: OK, finally an answer! I checked Makefile and found the following line: EXTRA_LIBS = -lcrypt -lcrypt -lmysqlclient -lpng -lz -lz -lresolv -lm -ldl -lnsl -lxml2 - lz -lm -lxml2 -lz -lm -lmysqlclient -lcrypt -lnsl -lm -lz -lnss_files -lnss_dns -lresolv -lnss_files -lnss_dns -lresolv -lxml2 -lz -lm -lcrypt -lxml2 -lz -lm -lcrypt By removing one of the -lmysqlclient entries on this line I was able to successfully make and make install with both mysql and mysqli. As confirmed by phpInfo(). I'm not sure why the other libs have multiple entries and don't cause make to crash. Previous Comments: [2004-10-05 22:52:00] php at kilimajer dot net Workaround is to execute the last failing command with one -lmysqlclient removed, then again make. This should be fixed in ext/mysqli/config.m4. [2004-10-05 13:50:38] php at kilimajer dot net This is caused by -lmysqlclient being supplied twice to the linker (at least it was my case). [2004-09-24 19:59:01] rjanson at msn dot com I've tried the same steps with php-5.02 and still the same results. [2004-09-21 01:12:32] rjanson at msn dot com I tried backing up and completely uninstalling, then reinstalling Mysql-4.1.4-0 from RPM, and still get the same result. Others out there are having this issue as well. Is there nothing to be done? --Rich [2004-09-13 20:44:01] rjanson at msn dot com I installed mysql via the RPMs provided on the MySQL site. I unsinstalled the MySQL-shared-compat-4.1.4-0 rpm and tried building agin with the same result. These are the RPMs I have installed currently: MySQL-devel-4.1.4-0 MySQL-client-4.1.4-0 MySQL-Max-4.1.4-0 MySQL-bench-4.1.3-1 MySQL-server-4.1.4-0 MySQL-shared-4.1.4-0 Is it possible something with the RPMs is causing the failure? 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/29860 -- Edit this bug report at http://bugs.php.net/?id=29860&edit=1
#30332 [NEW]: zend.ze1_compatibility_mode isnt fully compatable with array_push()
From: justmanj at msu dot edu Operating system: winxp PHP version: 5.0.2 PHP Bug Type: Zend Engine 2 problem Bug description: zend.ze1_compatibility_mode isnt fully compatable with array_push() Description: zend.ze1_compatibility_mode when turned on doesn't honor the same methodlogy as 4.x when passing a class for some parameters - it passes by reference in functions like array_push(); this behavior was not in 4.3.x, and the only workaround is the clone keyword, which should be added in the 4.3.x tree for backwards compatability. Reproduce code: --- first = " im in the first"; print_r($first); print_r($second); print_r($container); Expected result: x Object ( [first] => im in the first ) x Object ( ) Array ( [0] => x Object ( ) ) Actual result: -- x Object ( [first] => im in the first ) x Object ( ) Array ( [0] => x Object ( [first] => im in the first ) ) -- Edit bug report at http://bugs.php.net/?id=30332&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30332&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30332&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30332&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30332&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30332&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30332&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30332&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30332&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30332&r=support Expected behavior: http://bugs.php.net/fix.php?id=30332&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30332&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30332&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30332&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30332&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30332&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30332&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30332&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30332&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30332&r=mysqlcfg
#30326 [Opn->Fbk]: "zip_open" cannot open file
ID: 30326
Updated by: [EMAIL PROTECTED]
Reported By: adamsbarker at hotmail dot com
-Status: Open
+Status: Feedback
Bug Type: ZZiplib Related
Operating System: Windows XP
PHP Version: 5.0.2
New Comment:
Is the script being ran from the same directory as the one where the
zip file is?
Previous Comments:
[2004-10-05 02:45:02] adamsbarker at hotmail dot com
Description:
when using the following code:
zip_open('file_name.zip');
i get the following error:
Warning: zip_open() [function.zip-open]: Cannot open zip archive
file_name.zip in C:\test.php on line 1
the "zip file" and "php script" are in the same directory
when i put in the full directory of the zip file, such as
"C:\file_name.zip", the file is opened and everything works as
expected.
i don't think this should be how it works as all other functions (ie,
include()) don't need the full directory!
i am using the latest stable version 5.0.3-dev and PECL extensions
--
Edit this bug report at http://bugs.php.net/?id=30326&edit=1
#30144 [Fbk->NoF]: values used in __set() overload don't remain consistent.
ID: 30144
Updated by: [EMAIL PROTECTED]
Reported By: james at grickle dot org
-Status: Feedback
+Status: No Feedback
Bug Type: Zend Engine 2 problem
Operating System: Slackware Linux -current
PHP Version: 5CVS-2004-09-18 (dev)
New Comment:
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".
Previous Comments:
[2004-09-26 23:09:21] [EMAIL PROTECTED]
Please provide a short reproducing script without external includes.
[2004-09-18 21:42:41] james at grickle dot org
Description:
All the debugging output has been done on php-5.0.1, but it happens
from 5.0.1 to the 5.1 CVS tree.
The class I'm using is available here:
http://www.grickle.org/url.php.txt
I don't know what exactly is happening, but I think that php is using a
reference to a variable when it shouldn't be using a reference.
In the reproduce code, there is a var_dump in the set() function just
before it returns showing that in all scenarios that it did its job,
howevever the var_dump of the entire class afterwards shows that
something gets boched.
In the larger program that this is used in, it does survive the initial
urlencode() errors, however php segfaults after making only a few steps
further.
Here are my PHP compile flags (noting that this bug happens both
through apache2 and the cli, showing that it's not a problem with the
sapi):
./configure \
--prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var \
--with-zlib \
--enable-sigchild \
--with-openssl \
--enable-bcmath \
--enable-calendar \
--enable-exif \
--with-fam \
--enable-ftp \
--with-mysql \
--with-gd \
--enable-gd-native-ttf \
--enable-sysvmsg \
--enable-sysvsem \
--enable-sysvshm \
--with-tsrm-pthreads \
--enable-force-cgi-redirect \
--enable-debug \
--with-apxs2=/usr/local/apache/bin/apxs
I don't have any backtraces because segfaults only happen when you
continue running code after this bug gets hit. I hope you find this
useful and find a fix for it because I spent about 3 hours weeding down
the errors and crashes of a fairly large cms to get to this point :)
Thanks,
James Harr
Reproduce code:
---
$n = 1;
var_dump($u);
print "\n".$u->getURL()."\n";
?>
Everything works if instead of:
$u->$n = 1;
I call one of these:
$u->__set($n,1);
$u->page = 1;
$u->set($n,1);
Expected result:
Inside set(): page -> 1
array(1) {
[0]=>
array(2) {
[0]=>
string(4) "page"
[1]=>
int(1)
}
}
object(URL)#1 (2) {
["url:private"]=>
string(0) ""
["params:private"]=>
array(1) {
[0]=>
array(2) {
[0]=>
string(4) "page"
[1]=>
int(1)
}
}
}
showpages.php?page=1
Actual result:
--
Inside set(): page -> 1
array(1) {
[0]=>
array(2) {
[0]=>
string(4) "page"
[1]=>
int(1)
}
}
object(URL)#1 (2) {
["url:private"]=>
string(0) ""
["params:private"]=>
array(1) {
[0]=>
array(2) {
[0]=>
&UNKNOWN:0
[1]=>
int(1)
}
}
}
Warning: urlencode() expects parameter 1 to be string, unknown given in
url.php on line 111
showpages.php?=1
--
Edit this bug report at http://bugs.php.net/?id=30144&edit=1
#30027 [Opn->Csd]: segmentation fault in ftp_get/memchr()
ID: 30027
Updated by: [EMAIL PROTECTED]
Reported By: sbrown at truckstuffusa dot com
-Status: Open
+Status: Closed
Bug Type: FTP related
Operating System: Redhat 9
PHP Version: 4.3.8
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2004-10-05 15:50:17] sbrown at truckstuffusa dot com
A comment on cfield at affinitysolutions dot com's patch: He sent this
patch to me and I applied it to both CVS and php 4.3.8. The patch
seemed to resolve the segmentation fault without adding extra line
breaks to the files, however, gdb would throw some wierd errors when
the script was finished executing. I'm wondering if someone else can
interpret these results from gdb (or if this isn't anything to worry
about):
warning: Unexpected waitpid result 00 when waiting for vfork-done
[tcsetpgrp failed in terminal_inferior: Operation not permitted]
ptrace: No such process.
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
0x420ac7a8 in vfork () from /lib/tls/libc.so.6
[2004-10-05 14:49:52] cfield at affinitysolutions dot com
The following patch fixes this bug(also avaliable at
http://beta.affinitysolutions.com/bug30027.patch) :
Index: ext/ftp/ftp.c
===
RCS file: /repository/php-src/ext/ftp/ftp.c,v
retrieving revision 1.68.2.17
diff -u -r1.68.2.17 ftp.c
--- ext/ftp/ftp.c 31 Mar 2004 20:44:04 - 1.68.2.17
+++ ext/ftp/ftp.c 5 Oct 2004 12:41:18 -
@@ -727,12 +727,12 @@
ptr = s;
}
#else
- while ((s = memchr(ptr, '\r', (e - ptr {
+ while ((e>ptr) && (s = memchr(ptr, '\r', (e -
ptr {
php_stream_write(outstream, ptr, (s -
ptr));
if (*(s + 1) == '\n') {
s++;
+ php_stream_putc(outstream,
'\n');
}
- php_stream_putc(outstream, '\n');
ptr = s + 1;
}
#endif
[2004-09-21 23:31:32] cfield at affinitysolutions dot com
I have the same problem on an SMP redhat 9 system, i can get it to stop
the segmentation faults by adding "((e-ptr)>0) &&" to the while loop
condition on line 732 of ftp.c, however now i am getting sporadic extra
newlines (always in the same places in the file,see below for line
numbers etc. ) however, if i slowly step through the interaction it
does not put the extra new line in
line number written bytes total bytes
504 126475 126475
689 46333 172808
2589474698 647506
3088105999 753505
3766145320 898825
5005304503 1203328
516340804 1244132
522112232 1256364
558791208 1347572
7454424119 1771691
779080126 1851817
10501 686879 2538696
10680 42243 2580939
12103 361663 2942602
13382 311479 3254081
13921 137267 3391348
16803 724748 4116096
18468 414953 4531049
18654 43412 4574461
18934 63798 4638259
18988 13696 4651955
20429 349357 5001312
21981 390490 5391802
25524 906947 6298749
27445 448641 6747390
29239 497920 7245310
30083 220342 7465652
30274 46327 7511979
31340 270732 7782711
32882 353352 8136063
33421 123803 8259866
34365 224338 8484204
36254 449849 8934053
[2004-09-17 16:25:50] sbrown at truckstuffusa dot com
Downloaded CVS last night, still get the seg fault:
# php --version
PHP 4.3.9RC4-dev (cgi) (built: Sep 17 2004 09:19:39) (DEBUG)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
# gdb php
(gdb) run script-backup
Starting program: /usr/local/bin/php script-backup
...
Program received signal SIGSEGV, Segmentation fault.
0x4207bb01 in memchr () from /lib/tls/libc.so.6
(gdb) bt
#0 0x4207bb01 in memchr () from /lib/tls/libc.so.6
#1 0x0805eaa8 in ftp_get (ftp=0x81828ac, outstream=0x81a6afc,
path=0x81a6604 "/x-stuff/php/dashboard_projectmgmt.php",
type=FTPTYPE_ASCII, resumepos=0)
at /usr/local/src/php-src/ext/ftp/ftp.c:730
#2 0x0805c141 in zif_ftp_get (ht=4, return_value=0x81a6184,
this_ptr=0x0, return_value_used=1) at
/usr/local/src/php-src/ext/ftp/php_ftp.c:637
#3 0x0811cb8f in execute
#30000 [Opn->WFx]: in_array returns the wrong result with long strings
ID: 3 Updated by: [EMAIL PROTECTED] Reported By: rcnetto at yahoo dot com -Status: Open +Status: Wont fix Bug Type: Arrays related Operating System: Linux - Suse 9.1 PHP Version: 5.0.1 New Comment: Numeric strings get converted to integers when used as array keys. Because ints are limited to 32 bits (on x86) they end up being 0 on very large numbers. Previous Comments: [2004-09-06 17:02:15] rcnetto at yahoo dot com Description: I tried to check if a value existed in an array, but in_array did not return what I expected when I'm dealing with large strings (18 chars or longer). I have PHP 5.0.1 compiled with Apache 2.0.50 and DBG v2.11.26 running; Reproduce code: --- Expected result: bool(false) OBS: $needle does not exists in $arrayA (last number is different), that's why it should return FALSE. Actual result: -- bool(true) Notes: when the value of the variables are letters, in_array works fine with the same quantity of chars. i.e: -- Edit this bug report at http://bugs.php.net/?id=3&edit=1
#29764 [Opn->Fbk]: crash
ID: 29764 Updated by: [EMAIL PROTECTED] Reported By: marius at electricplus dot ro -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: win 9.x PHP Version: 5.0.0 New Comment: 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 Previous Comments: [2004-08-19 21:05:43] marius at electricplus dot ro Description: Reproduce code: --- Expected result: Array ( [0] => core [1] => http_core [2] => mod_so [3] => sapi_apache2 [4] => mod_mime [5] => mod_rewrite ) Actual result: -- crash witch close from apache when I hit close apache restarts. -- Edit this bug report at http://bugs.php.net/?id=29764&edit=1
#30333 [NEW]: fscanf() and() not working correctly with other then English language
From: altuhov at nm dot ru Operating system: WinXP SP2 PHP version: 5.0.2 PHP Bug Type: Filesystem function related Bug description: fscanf() and() not working correctly with other then English language Description: Functions fscanf() and sscanf() is not working correctly with other then English language in the handle. In my example was used Russian language. Reproduce code: --- Expected result: Array ( [0] => Ïðîâåðêà [1] => Òåñòèðóþ [2] => ÎäèíÄâàÒðè ) Actual result: -- Array ( [0] => Ïð [1] => âåð [2] => à ) -- Edit bug report at http://bugs.php.net/?id=30333&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30333&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30333&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30333&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30333&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30333&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30333&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30333&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30333&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30333&r=support Expected behavior: http://bugs.php.net/fix.php?id=30333&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30333&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30333&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30333&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30333&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30333&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30333&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30333&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30333&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30333&r=mysqlcfg
#29426 [Com]: Incomplete/inconsistent functionality
ID: 29426 Comment by: matt dot bevan at marginsoftware dot com Reported By: php at peterrobins dot co dot uk Status: Open Bug Type: SimpleXML related Operating System: Linux 2.4 PHP Version: 5.0.0 New Comment: I am also in the position where I need to be able to create and insert a SimpleXMLElement before or after an arbitrary SimpleXMLElement, then remove the previous instance. This is to move XML elements from one location in an XML file into another. I'll likely be switching to/from a DOM object to accomplish this, however. Previous Comments: [2004-09-19 17:40:18] phpbugs at ilibi dot com Either the documentation for simplexml should be clarified about exactly what can and can not be added/ edited. Or the ability to add nodes should be added to simplexml. [2004-08-08 01:18:36] cyberlot at cyberlot dot net Confirming this bug exists, Have the same problem, I need to add to a simplexml object on the fly and can't [2004-07-28 13:22:59] php at peterrobins dot co dot uk Description: According to the manual page, you can add a node with SimpleXML, but this does not seem to work, either as $xml->movie[0]->characters[0]->character[0]->age = '21'; nor as $xml->movie[0]->rating[2] = 'not bad'; Deletion works on attributes unset($xml->movie[0]->rating[1]['type']); but at node level, deletes all unset($xml->movie[0]->rating); This is inconsistent with reading where $xml->movie[0]->rating fetches the first node only. unset($xml->movie->rating); deletes all ratings for the 1st movie only. It does not appear possible to delete just 1 node unset($xml->movie[0]->rating[1]); Because objs are now refs not copies, can do this $rat = $xml->movie[0]->rating[0]; $rat['name'] = 'judge'; but not this $rat = 'new content'; nor this $rat->child[0] = 'new rating'; and if I try and do $rat->child = 'new rating'; I get 'Attempt to assign property of non-object' -- Edit this bug report at http://bugs.php.net/?id=29426&edit=1
