#41344 [NEW]: Error returning long values in the headers
From: zeta2ste2000 at yahoo dot it
Operating system: HP-UX 11.11
PHP version: 5.2.2
PHP Bug Type: SOAP related
Bug description: Error returning long values in the headers
Description:
When I have to manage a long number in the header, the __soapCall function
returns a float number in exponential format. The original sent value can't
be retrieved and the returned one is different.
Reproduce code:
---
A Java server sends a sessionID in the header with the following value :
339051398236687110
This is the client code :
$soapclient-__soapCall('beginSession',$parameters, null, null,
$header);
echo $header[sessionID]; // returns 3.3905139823669E+17 , an
// invalid value for the next call
// and with less digits than required
$strNum = number_format($header[sessionID], 0, , );
echo $strNum; // returns the rounded value
// 339051398236687050 , that is
// different from the original
// 339051398236687110
Expected result:
The header has to contain 339051398236687110
Actual result:
--
The header contain 3.3905139823669E+17
--
Edit bug report at http://bugs.php.net/?id=41344edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41344r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41344r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41344r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41344r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41344r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41344r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41344r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41344r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41344r=support
Expected behavior:http://bugs.php.net/fix.php?id=41344r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41344r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41344r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41344r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41344r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41344r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41344r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41344r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41344r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41344r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41344r=mysqlcfg
#41345 [NEW]: ibase_blob_get bug
From: peaktop at inbox dot ru
Operating system: WinServer 2003 SP1
PHP version: 5.2.2
PHP Bug Type: InterBase related
Bug description: ibase_blob_get bug
Description:
I have problem with Firebird API function ibase_blob_get when trying to
megre from PHP5.2.1 into PHP5.2.2.
What I did do:
1) Download PHP5.2.2
2) Stopping Apache.
3) Rename folder with PHP5.2.1-engine
4) Place PHP5.2.2-engine into folder, where was PHP5.2.1-engine.
5) Copy php.ini from PHP5.2.1 engine to PHP5.2.2
6) Start Apache
The block of code (listed bellow) is not working.
Reproduce code:
---
$db = ibase_connect('127.0.0.1:DB', 'SYSDBA', 'masterkey');
if($db != 0){
$sql = 'SELECT FIRST 1 * FROM TABL$W_MENU_LEFT M WHERE (M.ID = 1)';
$qr = ibase_query($db, $sql);
if($qr != 0){
$row = ibase_fetch_object($qr);
$blob_inf= ibase_blob_info($row-BODY);
$blob_handle = ibase_blob_open($row-BODY);
$out_str.= ibase_blob_get($blob_handle, $blob_inf[0]);
ibase_blob_close($blob_handle);
ibase_free_result($qr);
}
ibase_close($db);
}
Expected result:
In PHP5.2.1-engine I had text in browser, which is stored in Firebird
database.
Actual result:
--
Invalid Blob-handle
--
Edit bug report at http://bugs.php.net/?id=41345edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41345r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41345r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41345r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41345r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41345r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41345r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41345r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41345r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41345r=support
Expected behavior:http://bugs.php.net/fix.php?id=41345r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41345r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41345r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41345r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41345r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41345r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41345r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41345r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41345r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41345r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41345r=mysqlcfg
#41346 [NEW]: segmentation fault on domxml_document_parser
From: wouter at widexs dot nl Operating system: Linux PHP version: 4.4.7 PHP Bug Type: *XML functions Bug description: segmentation fault on domxml_document_parser Description: PHP 4.4.7 as Apache 2.0.59 DSO module gives a segmentation fault when parsing specific xml code. I've been unable to locate the exact code as of yet that triggers this. (since multiple clients use the piece of code i found in the backtrace) A 'bt full' is also available, which might reveal more info for you. I've disabled any Zend + 3rd-party extensions, thus only PHP-only extensions built-in. Reproduce code: --- Don't have it, though it has to be something like this : #16 0xb75b8952 in domxml_document_parser (mode=144905360, loadtype=0, source=0x8ac77e4 !DOCTYPE html PUBLIC \-//W3C//DTD XHTML 1.0 Transitional//EN\ \http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\;\r\nhtml xmlns=\http://www.w3.org/1999/xhtml\;\r\nhead profile=\http://gmpg.org/x;..., data=0x0) at /opt/install/widexs_apache_2006_026/php-4.4.7/ext/domxml/php_domxml.c:4006 Which is used in WordPress CMS if I'm correct. Expected result: No segmentation fault :) Actual result: -- backtrace : (gdb) bt #0 0xb7a21df3 in free () from /lib/libc.so.6 #1 0xb6faf788 in xmlResetError__internal_alias (err=0xbfd65360) at error.c:871 #2 0xb6faeb94 in __xmlRaiseError (schannel=0, channel=0xb75b2ebc domxml_error_validate, data=0xbfd651e0, ctx=0xbfd651e0, nod=0x8ae0ee8, domain=23, code=504, level=XML_ERR_ERROR, file=0x0, line=-2147483636, str1=0x8b247f8 ul, str2=0x8b247f8 ul, str3=0xbfd62690 (), int1=35, col=1, msg=0xb70706a0 Element %s content does not follow the DTD, expecting %s, got %s\n) at error.c:534 #3 0xb6fda6f8 in xmlErrValidNode (ctxt=0x23, node=0x8ae0ee8, error=XML_DTD_CONTENT_MODEL, msg=0xb70706a0 Element %s content does not follow the DTD, expecting %s, got %s\n, str1=0xb7adc4a4 , str2=0xbfd63a20 (li)+, str3=0xbfd62690 ()) at valid.c:152 #4 0xb6fe0763 in xmlValidateElementContent (ctxt=0x8a314fc, child=0x8ae0f38, elemDecl=0xbfd62690, warn=1, parent=0x8ae0ee8) at valid.c:5366 #5 0xb6fe15f6 in xmlValidateOneElement__internal_alias (ctxt=0x8a314fc, doc=0x8ae0f38, elem=0x8ae0ee8) at valid.c:6052 #6 0xb705b5d4 in xmlSAX2EndElementNs__internal_alias (ctx=0x8a31490, localname=0x8b06f4a ul, prefix=0x0, URI=0x8b06ddf http://www.w3.org/1999/xhtml;) at SAX2.c:2315 #7 0xb6fbf56e in xmlParseEndTag2 (ctxt=0x8a31490, prefix=0x0, URI=0x8b06ddf http://www.w3.org/1999/xhtml;, line=28, nsNr=0, tlen=0) at parser.c:8207 #8 0xb6fbff9d in xmlParseElement__internal_alias (ctxt=0x8a31490) at parser.c:8542 #9 0xb6fbfcef in xmlParseContent__internal_alias (ctxt=0x8a31490) at parser.c:8361 #10 0xb6fbff56 in xmlParseElement__internal_alias (ctxt=0x8a31490) at parser.c:8521 #11 0xb6fbfcef in xmlParseContent__internal_alias (ctxt=0x8a31490) at parser.c:8361 #12 0xb6fbff56 in xmlParseElement__internal_alias (ctxt=0x8a31490) at parser.c:8521 #13 0xb6fbfcef in xmlParseContent__internal_alias (ctxt=0x8a31490) at parser.c:8361 #14 0xb6fbff56 in xmlParseElement__internal_alias (ctxt=0x8a31490) at parser.c:8521 #15 0xb6fc1133 in xmlParseDocument__internal_alias (ctxt=0x8a31490) at parser.c:9129 #16 0xb75b8952 in domxml_document_parser (mode=144905360, loadtype=0, source=0x8ac77e4 !DOCTYPE html PUBLIC \-//W3C//DTD XHTML 1.0 Transitional//EN\ \http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\;\r\nhtml xmlns=\http://www.w3.org/1999/xhtml\;\r\nhead profile=\http://gmpg.org/x;..., data=0x0) at /opt/install/widexs_apache_2006_026/php-4.4.7/ext/domxml/php_domxml.c:4006 #17 0xb75b8a46 in zif_xmldoc (ht=2, return_value=0x8a31264, this_ptr=0x0, return_value_used=1) at /opt/install/widexs_apache_2006_026/php-4.4.7/ext/domxml/php_domxml.c:4042 #18 0xb76d576a in execute (op_array=0x8a9ee10) at /opt/install/widexs_apache_2006_026/php-4.4.7/Zend/zend_execute.c:1681 #19 0xb76d551c in execute (op_array=0x8a40960) at /opt/install/widexs_apache_2006_026/php-4.4.7/Zend/zend_execute.c:1725 #20 0xb76d551c in execute (op_array=0x8984534) at /opt/install/widexs_apache_2006_026/php-4.4.7/Zend/zend_execute.c:1725 #21 0xb76c8fbf in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /opt/install/widexs_apache_2006_026/php-4.4.7/Zend/zend.c:939 #22 0xb76a4068 in php_execute_script (primary_file=0xbfd6ab70) at /opt/install/widexs_apache_2006_026/php-4.4.7/main/main.c:1757 #23 0xb76d96a7 in php_handler (r=0x8978608) at /opt/install/widexs_apache_2006_026/php-4.4.7/sapi/apache2handler/sapi_apache2.c:581 #24 0x080af902 in ap_run_handler () #25 0x080b0071 in ap_invoke_handler () #26 0x0809050d in ap_process_request () #27 0x0808a977 in ap_process_http_connection () #28 0x080bc422 in ap_run_process_connection () #29 0x080bc810 in ap_process_connection () #30 0x080ae19f in child_main () #31 0x080ae329 in make_child () #32 0x080ae39e in startup_children () #33 0x080ae7a7 in ap_mpm_run ()
#41183 [Bgs]: Problems with compiling with X86_64
ID: 41183 User updated by: joona at kide dot org Reported By: joona at kide dot org Status: Bogus Bug Type: Compile Failure Operating System: Linux Fedora core 6 PHP Version: 4.4.6 New Comment: I'm sorry but upgrading is not an option because incompatibility between 4.x and 5.x. So I take it is not a bug because options like --with-libdir are not SUPPORTED. Right. Where was my .net tutorial again... Previous Comments: [2007-04-25 07:19:56] [EMAIL PROTECTED] PHP 4.4 does not have --libdir, nor is anything else than /lib for the library directory supported in PHP 4.4. Please upgrade to PHP 5.2. [2007-04-25 06:57:20] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Use --with-libdir configure flag. And please use the search before reporting an issue - the same thing has just been reported yesterday. (#41181) [2007-04-25 06:49:40] joona at kide dot org Description: Hello! Configure scipt of PHP 4.6.6 do not take into account different location of library files on FC6 X86_64 platform. I had to manually hardcode the paths to right directories in configure-script before it runned properly. It either couldn't find header files or library files depending on where I pointed the --with-mysql option. No help changing --includedir or --libdir options either. Could you look at this because bad configure script is real pain in the ... -- Edit this bug report at http://bugs.php.net/?id=41183edit=1
#26004 [Com]: $_POST variables not set when using enctype=multipart/form-data
ID: 26004 Comment by: dlodhia at yahoo dot com Reported By: jacknorton101 at hotmail dot com Status: No Feedback Bug Type: *General Issues Operating System: RedHat Linux 9 PHP Version: 4.3.3 New Comment: hi, having same problem. This is working fine with FF, but not with IE. If its working fine with FF, it could not be problem with PHP.INI or HTTD.CONF. any suggestion what could be the reason? Previous Comments: [2006-08-10 06:25:06] cometfish at hotmail dot com Hi, I had this same problem. I spent hours searching the web, but found nothing except this: -- from http://www.php.net/manual/en/features.file-upload.php jason 09-Jan-2006 05:08 Regarding empty $_FILES and $_POST arrays when uploading files larger than post_max_size: Tucked away in http://us3.php.net/manual/en/ini.core.php#ini.post-max-size is this nugget: If the size of post data is greater than post_max_size, the $_POST and $_FILES superglobals are empty. This can be tracked in various ways, e.g. by passing the $_GET variable to the script processing the data, i.e. form action=edit.php?processed=1, and then checking if $_GET['processed'] is set. This may seem like a bug. You'd expect something like UPLOAD_ERR_FORM_SIZE to be set. But you just two empty superglobals. I've seen it submitted to bugs.php.net twice and it's been marked as bogus both times. I saw this, and realised that my MAX_FILE_SIZE hidden form element was missing. Inserting this fixed the problem immediately. My PHP version is 4.4.2. Hope this helps. [2006-05-11 21:24:50] hostgeekz at gmail dot com I am having this issue on PHP 5.0.4, and PHP 5.1.4 Exactly the same as stated above, enctype=multipart/form-data [2006-04-07 08:07:58] timecop at gmail dot com Yes this is still valid. whats worse, if enctype=multipart/form-data, NONE of the variables make it into $_POST. PHP 5.1.2 / linux [2003-11-03 14:06:54] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2003-10-27 10:51:37] [EMAIL PROTECTED] Check your httpd.conf (probably in /etc/httpd/conf) if there's some directive that limits the maximum length of incoming data. See bug #22138 for detail 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/26004 -- Edit this bug report at http://bugs.php.net/?id=26004edit=1
#22427 [Com]: Missing Form Post Data
ID: 22427
Comment by: tnieto at greenbit dot es
Reported By: jroland at uow dot edu dot au
Status: No Feedback
Bug Type: *General Issues
Operating System: Windows XP / 2000
PHP Version: 4.2.3
New Comment:
I have experienced this issue also.
My environment is:
- php 4.4.2 as a module
- Apache 1.3
- Windows 2000 Server
When I send a form with a text area using POST i don't receive any
data.
In my case, it was because I was sending de form using a Javascript
code:
function newitem(tipus)
{
var accion;
if (tipus == 1)
{
accion =
document.mailing.action=pre_mailingsmanuals.php;
}
else
{
accion =
document.mailing.action=env_mailingsmanuals.php;
}
document.mailing.action=accion;
document.mailing.submit();
}
The input was specified as a button: input type=button
onclick=newitem(1) ... instead of as a submit.
Also, I was using a Rich Text Area. This issue doesn't occurs with a
normal textarea.
The form get working when I change the button for a submit, without
use javascript code for send it.
I hope this message may be usefull for other users with the same
problem. There is an official response from the PHP team from this issue
?
Regards
Previous Comments:
[2007-04-07 14:12:52] linux at mccoull dot net
I have been having similar problems, i.e. a form which submits happily
in Firefox, but not in IE 7. I have found this (very old!) forum entry -
http://www.thescripts.com/forum/thread4451.html - which covers my issue,
and I have implemented the solution by checking for
(isset($_POST['submit']) || isset($_POST['submit_x'])) to check whether
my submit button has been clicked. Note that is an underscore, not a
'.'.
The solution works for GET method as well, if you are using that. If
you submit a form with a 'submit' image button using GET, the browser
URL shows submit.x=aasubmit.y=bb where aa and bb are the coordinates
within the button image of where you clicked, but you should still check
for $_GET['submit_x'] NOT $_GET['submit.x'].
As discussed in the above referred forum log this is an issue affecting
Internet Explorer, Netscape and Opera, and maybe other browsers, and
seems to be a simple failure to conform to the HTML standard for
handling forms.
Hope this helps someone.
Andy
[2007-03-12 19:53:16] jpsoren at gmail dot com
I experience this problem as well.
* Happens both with and without enctype set for form
* Happens in IE6 and IE7, NOT in Firefox 1.5/2
* Changing form to GET works flawlessly
* Input can range from a few text fields (1-6) or a mix of text fields
and file fields, or just file fields (enctype set when file fields
exist) and POST data will come up empty
* Often times hitting reload and selecting to resubmit the form data
will have the POST data show up
* NO POST data will show up - I don't just lose some early fields
PHP 5.2.x (module), Apache 2.2.x, Windows XP SP2
This is a serious issue. Doesn't seem like anyone in this thread has
found any sort of solution. Please post (or GET, ha) if you have any
insight.
[2007-02-22 15:25:15] elio at tondo dot it
I am experiencing the same problem reported on 29 Aug 2006 by egil at
egil dot net. I can add some more details:
- I confirm that it happens only with IE;
- it is triggered when a character between 0x80 and 0x9f is used in a
form field (e.g. the Word quotation marks, but also the Euro symbol)
-- please note that these are the transposition in the high half part
of extended ASCII of the 32 control characters of ASCII (0x00 -
0x1f);
- it has some relationship with character encoding;
- I can reproduce it on Linux with Apache 2 on Fedora 4 - 6 if I don't
force AddDefaultCharset UTF-8 in httpd.conf (the default in Fedora);
with this directive the problem dies not happen, but the strange
characters are interpreted incorrectly (because the file is not UTF8);
- I cannot reproduce it on Linux Mandrake 10 / Apache 2;
- I cannot reproduce it on Windows XP / XAMPP (Apache 2).
A further interesting detail: it happens only if the file containing
the form has the .php extension; if it has the .htm extension it does
not happen! (please note that I am using plain HTML for the form and
some PHP to show the results).
From all of the above, it looks like it is not a PHP bug, but instead a
IE6 bug that is triggered by some combination of MIME types and
character encodings.
I am going to prepare a simpler test case (I am currently using a
#41347 [NEW]: checkdnsrr() segfaults on empty hostname
From: [EMAIL PROTECTED] Operating system: Mac OS X 10.4.9 PHP version: 5.2.2 PHP Bug Type: Network related Bug description: checkdnsrr() segfaults on empty hostname Description: checkdnsrr() should return FALSE on error, but it segfaults if host argument is an empty string. Reproduce code: --- php -r 'var_dump(checkdnsrr(, A));' Expected result: bool(false) Actual result: -- zsh: bus error php -r 'var_dump(checkdnsrr(, A));' --- (gdb) run -r 'var_dump(checkdnsrr(, A));' Starting program: /usr/local/bin/php -r 'var_dump(checkdnsrr(, A));' Reading symbols for shared libraries .+++..+.... done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x 0x901174ed in res_send () -- Edit bug report at http://bugs.php.net/?id=41347edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41347r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41347r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41347r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41347r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41347r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41347r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41347r=needscript Try newer version:http://bugs.php.net/fix.php?id=41347r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41347r=support Expected behavior:http://bugs.php.net/fix.php?id=41347r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41347r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41347r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41347r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41347r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41347r=dst IIS Stability:http://bugs.php.net/fix.php?id=41347r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41347r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41347r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41347r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41347r=mysqlcfg
#41151 [NoF-Opn]: SOAP request is wrong when using subclass
ID: 41151
User updated by: m dot necib at akrobat dot fr
Reported By: m dot necib at akrobat dot fr
-Status: No Feedback
+Status: Open
Bug Type: SOAP related
Operating System: Windows XP
PHP Version: 5.2.1
Assigned To: dmitry
New Comment:
Hello Dmitry,
Our situation is a bit different than what you have tested.
Here is the link to the WSDL :
http://213.41.94.84/wsPricing/services/PricingSNC?wsdl
Look at the complexType named WSParameters.
It contains an element loan which type is WSLoan.
But two types extend WSLoan : WSLoanClassic and WSLoanPerso.
The Web Service expects us to send either of the inherited type.
WSLoan is an abstract type.
So in our case the correct type is not directly defined like in your
test case.
We are using SoapVar to specify the correct type of our object.
Then the generated SOAP request references the correct type.
But the fields are in the wrong order.
As you can see the WSDL file is generated by Apache Axis.
Previous Comments:
[2007-05-10 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2007-05-02 08:40:33] [EMAIL PROTECTED]
I just committed test file ext/soap/tests/schema/schema085.phpt, that
demonstrates proper element ordering. In your example you probably do
somthing wrong. I cannot say that exactly is wrong as you didn't provide
full reproduce case, probably you object isn't encoded using WSDL.
In case if you like me to look into problem please provide full example
(without ...) including full WSDL file.
[2007-04-20 16:55:19] m dot necib at akrobat dot fr
WSDL :
complexType name=A
sequence
element name=a type=xsd:int/
/sequence
/complexType
complexType name=B
complexContent
extension base=impl:A
sequence
element name=b type=xsd:int/
/sequence
/extension
/complexContent
/complexType
[2007-04-20 16:47:37] m dot necib at akrobat dot fr
Description:
When using subclass as a value in WSDL mode,
the properties are written in the wrong order :
the child class properties are written _before_
the parent properties.
Reproduce code:
---
PHP:
class A
{
public $a ;
}
class B extends A
{
public $b ;
}
$client = new SoapClient(...) ;
$var = new SoapVar( new B(), SOAP_ENC_OBJECT, 'B', 'http://myns/' ) ;
$client-foo($var) ;
Expected result:
SOAP request :
parametres xsi:type=B
a/a
b/b
/parametres
Actual result:
--
SOAP request :
parametres xsi:type=B
b/b
a/a
/parametres
--
Edit this bug report at http://bugs.php.net/?id=41151edit=1
#41348 [NEW]: Compilation failure with oci8 support
From: clement dot demonchy at bsocom dot com Operating system: Debian Linux Sarge PHP version: 5.2.2 PHP Bug Type: Compile Failure Bug description: Compilation failure with oci8 support Description: Hello, I get a compilation failure when I try to compile php with oci8 support. The configuration line : ./configure --with-apache=../apache_1.3.37 --with-mysql=/usr/local/mysql --enable-track-vars --enable-inline-optimization --enable-memory-limit --enable-ftp --with-zlib-dir=/usr --with-zlib --with-gd --with-png-dir=/usr --with-jpeg-dir=/usr --with-xml --with-gettext --disable-ipv6 --with-ttf --with-freetype-dir=/usr --with-xml2 --with-libxml2 --with-dom --with-dom-xslt --with-pspell --with-openssl --with-oci8=/home/oracle/product/8.1.7 --with-oracle=/home/oracle/product/8.1.7 --enable-sigchild --with-oci8-instant-client --with-curl The error message during make : /bin/sh /usr/src/php-5.2.2/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/oci8/ -I/usr/src/php-5.2.2/ext/oci8/ -DPHP_ATOM_INC -I/usr/src/php-5.2.2/include -I/usr/src/php-5.2.2/main -I/usr/src/php-5.2.2 -I/usr/include/libxml2 -I/usr/src/php-5.2.2/ext/date/lib -I/usr/include/freetype2 -I/usr/local/mysql/include -I/home/oracle/product/8.1.7/rdbms/public -I/home/oracle/product/8.1.7/rdbms/demo -I/usr/include/pspell -I/usr/src/php-5.2.2/TSRM -I/usr/src/php-5.2.2/Zend-I/usr/include -O3 -c /usr/src/php-5.2.2/ext/oci8/oci8_lob.c -o ext/oci8/oci8_lob.lo /usr/src/php-5.2.2/ext/oci8/oci8_lob.c: In function `php_oci_lob_read': /usr/src/php-5.2.2/ext/oci8/oci8_lob.c:304: error: `OCI_NLS_CHARSET_MAXBYTESZ' undeclared (first use in this function) /usr/src/php-5.2.2/ext/oci8/oci8_lob.c:304: error: (Each undeclared identifier is reported only once /usr/src/php-5.2.2/ext/oci8/oci8_lob.c:304: error: for each function it appears in.) make: *** [ext/oci8/oci8_lob.lo] Error 1 I'm currently using oracle version 8.1.7. Best regards. -- Edit bug report at http://bugs.php.net/?id=41348edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41348r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41348r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41348r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41348r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41348r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41348r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41348r=needscript Try newer version:http://bugs.php.net/fix.php?id=41348r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41348r=support Expected behavior:http://bugs.php.net/fix.php?id=41348r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41348r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41348r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41348r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41348r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41348r=dst IIS Stability:http://bugs.php.net/fix.php?id=41348r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41348r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41348r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41348r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41348r=mysqlcfg
#41349 [NEW]: $_POST not filled, altough raw POST is available
From: php at bitrockers dot de
Operating system: Linux Debian Etch
PHP version: 5.2.2
PHP Bug Type: HTTP related
Bug description: $_POST not filled, altough raw POST is available
Description:
Maybe this bug is related to Bugs 31417 and 41293. But I'm not sure,
because this bug occurs in 5.2.0 and 5.2.2.
The problem is:
When sending POST requests via the XmlHttpRequest active-x, on some IE6
installations this won't work properly. The POST request is successfully
sent to our webserver, and the raw http post data is filled correctly, but
the $_POST array is not filled with any information.
I can only guess that the error has something to do with some special
headers/encoding (Content-Length?) which is done by the
XmlHttpRequest-ActiveX on some IE6 installations.
And: Yes, I know that it's hard to find the reason for this behaviour. And
it's not easy to reproduce this bug ( because on most IE6 installations
everything works fine).
But I guess it's worth to take a look at the php-source, so that someone
may get an idea which could cause this bug.
I'm trying to help you as much as possible. Unfortunately I cannot
reproduce the error by myself, so I have to ask the affected customers
each time we 'possibly' fixed the bug.
There must be a bug in php, because the raw-http request is filled
correctly (and we don't touch the $_POST var anywhere else in our code).
Reproduce code:
---
var_export($_POST);
$rawPost = file_get_contents('php://input');
echo \n$rawPost;
Expected result:
array('postVar1' = 'postValue1',
'postVar2' = 'postValue2')
postVar1=postValue1postVar2=postValue2
Actual result:
--
array()
postVar1=postValue1postVar2=postValue2
--
Edit bug report at http://bugs.php.net/?id=41349edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41349r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41349r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41349r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41349r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41349r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41349r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41349r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41349r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41349r=support
Expected behavior:http://bugs.php.net/fix.php?id=41349r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41349r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41349r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41349r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41349r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41349r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41349r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41349r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41349r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41349r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41349r=mysqlcfg
#41350 [NEW]: Error in my_thread_global_end()
From: graham at directhostinguk dot com Operating system: Windows 2003 PHP version: 5.2.2 PHP Bug Type: MySQL related Bug description: Error in my_thread_global_end() Description: This closed PHP bug: http://bugs.php.net/bug.php?id=41316 MySQL Bug: http://bugs.mysql.com/bug.php?id=25621 Error in my_thread_global_end(): 1 threads didn't exit I have the same issue even when the script doesn't call any MySQL, but this error only happens when using fast-cgi If I run php 5.2.2 ISAPI the problem goes away. I think this is a php bug It seems to me that the problem lies in the PHP dll php_mysql.dll as it is opening the threads but not telling MySql to close them. -- Edit bug report at http://bugs.php.net/?id=41350edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41350r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41350r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41350r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41350r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41350r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41350r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41350r=needscript Try newer version:http://bugs.php.net/fix.php?id=41350r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41350r=support Expected behavior:http://bugs.php.net/fix.php?id=41350r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41350r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41350r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41350r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41350r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41350r=dst IIS Stability:http://bugs.php.net/fix.php?id=41350r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41350r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41350r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41350r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41350r=mysqlcfg
#41347 [Opn-Fbk]: checkdnsrr() segfaults on empty hostname
ID: 41347 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Network related Operating System: Mac OS X 10.4.9 PHP Version: 5.2.2 New Comment: Can you try the patch at http://server.macvicar.net/downloads/php/bug41347.patch.txt Also does dns_get_mx segfault too? Previous Comments: [2007-05-10 09:35:01] [EMAIL PROTECTED] Description: checkdnsrr() should return FALSE on error, but it segfaults if host argument is an empty string. Reproduce code: --- php -r 'var_dump(checkdnsrr(, A));' Expected result: bool(false) Actual result: -- zsh: bus error php -r 'var_dump(checkdnsrr(, A));' --- (gdb) run -r 'var_dump(checkdnsrr(, A));' Starting program: /usr/local/bin/php -r 'var_dump(checkdnsrr(, A));' Reading symbols for shared libraries .+++..+.... done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x 0x901174ed in res_send () -- Edit this bug report at http://bugs.php.net/?id=41347edit=1
#41351 [NEW]: Fatal error: Invalid opcode 81/16/8
From: jonathan dot de dot berdt at howest dot be
Operating system: linux
PHP version: 5.2.2
PHP Bug Type: *General Issues
Bug description: Fatal error: Invalid opcode 81/16/8
Description:
error thrown on the first 'foreach' command.
server using: php 5.2.1
Reproduce code:
---
$query = array ('table', 'room');
$criteria = array ('table' = array ('subjects', 'teachers', 'groups',
'rooms', 'tableparts'),
'room' = array ('rooms', 'roomtypes', 'roomcapacity',
'roomcomputercapacity', 'roomotherkeywords', 'tableparts'));
foreach ($query[] as $qry)
{
foreach($criteria[$qry][] as $crit)
{
if (isset($_GET['leer_' . $qry . 'query_' . $crit.
'_removekeyword']))
{
unset ($_SESSION['leer_' . $qry . 'query_' . $crit .
'_selectedkeywords']
[$_GET['leer_' . $qry . 'query_' . $crit.
'_removekeyword']]);
}
}
}
Expected result:
this code should process a number of session variables. These variables
have a structured name, and thus the changing parts have been put in these
small arrays.
Actual result:
--
Fatal error: Invalid opcode 81/16/8. in
/var/www/html/dokeos/main/leer/leer.php on line 198
--
Edit bug report at http://bugs.php.net/?id=41351edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41351r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41351r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41351r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41351r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41351r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41351r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41351r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41351r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41351r=support
Expected behavior:http://bugs.php.net/fix.php?id=41351r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41351r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41351r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41351r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41351r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41351r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41351r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41351r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41351r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41351r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41351r=mysqlcfg
#41352 [NEW]: Warning: ftp_get() PORT command successful
From: guy dot vleugels at kaneka dot be
Operating system: RH9
PHP version: 5.2.2
PHP Bug Type: FTP related
Bug description: Warning: ftp_get() PORT command successful
Description:
After upgrading to PHP 5.2.2 on my RH9-machine the following error warning
occurs on post-script files using ftp_get:
Warning: ftp_get() [function.ftp-get]: PORT command successful
As a result, the post-script file won't be downloaded to my machine.
If I do a downgrade to PHP5.2.2, everything works perfectly.
Reproduce code:
---
$ftpcnn = ftp_connect(ftp-server, 4559);
// login with username and password
$ftprs = ftp_login($ftpcnn, user, passwd);
// check connection
if( (!$ftpcnn) || (!$ftprs) )
{
echo FTP connection has failed!br /;
exit;
}
// Firstly download txt-file
ftp_get( $ftpcnn, /mydir/txtfile, /ftpdir/txtfileonftp, FTP_BINARY
);
// Do some extra stuff ---
// Get the name of the postscript-file
$lines = file( mydir/txtfile );
foreach( $lines as $line )
{
if( strstr($line, !postscript) !== FALSE )// ea. $line =
!postscript:0::docq/doc1764.ps
{
$temp = explode( :, $line );
$psfile = $temp[3];
}
}
// --- End some extra stuff ---
// Code which causes the warning:
// Warning: ftp_get() [function.ftp-get]: PORT command successful.
// Download the ps file
ftp_get( $ftpcnn, /mydir/psfile, $psfile, FTP_BINARY );
// close the connection
ftp_close( $ftpcnn );
Expected result:
// Downloading of a file specified by arguments in ftp_get()
Actual result:
--
Warning: ftp_get() [function.ftp-get]: PORT command successful
File won't be downloaded
--
Edit bug report at http://bugs.php.net/?id=41352edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41352r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41352r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41352r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41352r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41352r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41352r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41352r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41352r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41352r=support
Expected behavior:http://bugs.php.net/fix.php?id=41352r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41352r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41352r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41352r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41352r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41352r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41352r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41352r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41352r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41352r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41352r=mysqlcfg
#41347 [Fbk]: checkdnsrr() segfaults on empty hostname
ID: 41347 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Network related Operating System: Mac OS X 10.4.9 PHP Version: 5.2.2 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Previous Comments: [2007-05-10 12:18:49] [EMAIL PROTECTED] Can you try the patch at http://server.macvicar.net/downloads/php/bug41347.patch.txt Also does dns_get_mx segfault too? [2007-05-10 09:35:01] [EMAIL PROTECTED] Description: checkdnsrr() should return FALSE on error, but it segfaults if host argument is an empty string. Reproduce code: --- php -r 'var_dump(checkdnsrr(, A));' Expected result: bool(false) Actual result: -- zsh: bus error php -r 'var_dump(checkdnsrr(, A));' --- (gdb) run -r 'var_dump(checkdnsrr(, A));' Starting program: /usr/local/bin/php -r 'var_dump(checkdnsrr(, A));' Reading symbols for shared libraries .+++..+.... done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x 0x901174ed in res_send () -- Edit this bug report at http://bugs.php.net/?id=41347edit=1
#41346 [Opn-Fbk]: segmentation fault on domxml_document_parser
ID: 41346 Updated by: [EMAIL PROTECTED] Reported By: wouter at widexs dot nl -Status: Open +Status: Feedback Bug Type: *XML functions Operating System: Linux PHP Version: 4.4.7 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. You might want to try a newer libxml2 version as it looks like the crash might be caused there. (cant be sure without a reproduceable case though) Previous Comments: [2007-05-10 07:53:07] wouter at widexs dot nl Description: PHP 4.4.7 as Apache 2.0.59 DSO module gives a segmentation fault when parsing specific xml code. I've been unable to locate the exact code as of yet that triggers this. (since multiple clients use the piece of code i found in the backtrace) A 'bt full' is also available, which might reveal more info for you. I've disabled any Zend + 3rd-party extensions, thus only PHP-only extensions built-in. Reproduce code: --- Don't have it, though it has to be something like this : #16 0xb75b8952 in domxml_document_parser (mode=144905360, loadtype=0, source=0x8ac77e4 !DOCTYPE html PUBLIC \-//W3C//DTD XHTML 1.0 Transitional//EN\ \http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\;\r\nhtml xmlns=\http://www.w3.org/1999/xhtml\;\r\nhead profile=\http://gmpg.org/x;..., data=0x0) at /opt/install/widexs_apache_2006_026/php-4.4.7/ext/domxml/php_domxml.c:4006 Which is used in WordPress CMS if I'm correct. Expected result: No segmentation fault :) Actual result: -- backtrace : (gdb) bt #0 0xb7a21df3 in free () from /lib/libc.so.6 #1 0xb6faf788 in xmlResetError__internal_alias (err=0xbfd65360) at error.c:871 #2 0xb6faeb94 in __xmlRaiseError (schannel=0, channel=0xb75b2ebc domxml_error_validate, data=0xbfd651e0, ctx=0xbfd651e0, nod=0x8ae0ee8, domain=23, code=504, level=XML_ERR_ERROR, file=0x0, line=-2147483636, str1=0x8b247f8 ul, str2=0x8b247f8 ul, str3=0xbfd62690 (), int1=35, col=1, msg=0xb70706a0 Element %s content does not follow the DTD, expecting %s, got %s\n) at error.c:534 #3 0xb6fda6f8 in xmlErrValidNode (ctxt=0x23, node=0x8ae0ee8, error=XML_DTD_CONTENT_MODEL, msg=0xb70706a0 Element %s content does not follow the DTD, expecting %s, got %s\n, str1=0xb7adc4a4 , str2=0xbfd63a20 (li)+, str3=0xbfd62690 ()) at valid.c:152 #4 0xb6fe0763 in xmlValidateElementContent (ctxt=0x8a314fc, child=0x8ae0f38, elemDecl=0xbfd62690, warn=1, parent=0x8ae0ee8) at valid.c:5366 #5 0xb6fe15f6 in xmlValidateOneElement__internal_alias (ctxt=0x8a314fc, doc=0x8ae0f38, elem=0x8ae0ee8) at valid.c:6052 #6 0xb705b5d4 in xmlSAX2EndElementNs__internal_alias (ctx=0x8a31490, localname=0x8b06f4a ul, prefix=0x0, URI=0x8b06ddf http://www.w3.org/1999/xhtml;) at SAX2.c:2315 #7 0xb6fbf56e in xmlParseEndTag2 (ctxt=0x8a31490, prefix=0x0, URI=0x8b06ddf http://www.w3.org/1999/xhtml;, line=28, nsNr=0, tlen=0) at parser.c:8207 #8 0xb6fbff9d in xmlParseElement__internal_alias (ctxt=0x8a31490) at parser.c:8542 #9 0xb6fbfcef in xmlParseContent__internal_alias (ctxt=0x8a31490) at parser.c:8361 #10 0xb6fbff56 in xmlParseElement__internal_alias (ctxt=0x8a31490) at parser.c:8521 #11 0xb6fbfcef in xmlParseContent__internal_alias (ctxt=0x8a31490) at parser.c:8361 #12 0xb6fbff56 in xmlParseElement__internal_alias (ctxt=0x8a31490) at parser.c:8521 #13 0xb6fbfcef in xmlParseContent__internal_alias (ctxt=0x8a31490) at parser.c:8361 #14 0xb6fbff56 in xmlParseElement__internal_alias (ctxt=0x8a31490) at parser.c:8521 #15 0xb6fc1133 in xmlParseDocument__internal_alias (ctxt=0x8a31490) at parser.c:9129 #16 0xb75b8952 in domxml_document_parser (mode=144905360, loadtype=0, source=0x8ac77e4 !DOCTYPE html PUBLIC \-//W3C//DTD XHTML 1.0 Transitional//EN\ \http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\;\r\nhtml xmlns=\http://www.w3.org/1999/xhtml\;\r\nhead profile=\http://gmpg.org/x;..., data=0x0) at /opt/install/widexs_apache_2006_026/php-4.4.7/ext/domxml/php_domxml.c:4006 #17 0xb75b8a46 in zif_xmldoc (ht=2, return_value=0x8a31264, this_ptr=0x0, return_value_used=1) at /opt/install/widexs_apache_2006_026/php-4.4.7/ext/domxml/php_domxml.c:4042 #18 0xb76d576a in execute (op_array=0x8a9ee10) at /opt/install/widexs_apache_2006_026/php-4.4.7/Zend/zend_execute.c:1681 #19 0xb76d551c in execute (op_array=0x8a40960) at /opt/install/widexs_apache_2006_026/php-4.4.7/Zend/zend_execute.c:1725 #20 0xb76d551c in execute (op_array=0x8984534)
#41353 [NEW]: openssl_pkcs12_read() does not verify the type of the first arg
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 5CVS-2007-05-10 (CVS) PHP Bug Type: OpenSSL related Bug description: openssl_pkcs12_read() does not verify the type of the first arg Description: Function openssl_pkcs12_read() does not check the type of the first argument and uses it as a string in the call to BIO_write(). So if you pass a number as the first parameter, BIO_write() is called with a garbage params and segfaults. Reproduce code: --- $a = 2; openssl_pkcs12_read(1, $a, 1); Actual result: -- (gdb) r -r '$a = 2; openssl_pkcs12_read(1, $a, 1);' Starting program: /home/tony/php-src_5_2/sapi/cli/php -r '$a = 1; openssl_pkcs12_read(1, $a, 1);' [Thread debugging using libthread_db enabled] [New Thread 182900459904 (LWP 1209)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 182900459904 (LWP 1209)] 0x0031aef70bc0 in memcpy () from /lib64/tls/libc.so.6 (gdb) bt #0 0x0031aef70bc0 in memcpy () from /lib64/tls/libc.so.6 #1 0x00ac9f4b in mem_write () #2 0x00ac9136 in BIO_write () #3 0x00499009 in zif_openssl_pkcs12_read (ht=3, return_value=0x2a95b92fe8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0, tsrm_ls=0x1080450) at /home/tony/php-src_5_2/ext/openssl/openssl.c:1565 #4 0x00a1693e in zend_do_fcall_common_helper_SPEC (execute_data=0x7fb1b0, tsrm_ls=0x1080450) at zend_vm_execute.h:200 #5 0x00a1c49a in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x7fb1b0, tsrm_ls=0x1080450) at zend_vm_execute.h:1681 #6 0x00a16246 in execute (op_array=0x2a95b928a0, tsrm_ls=0x1080450) at zend_vm_execute.h:92 #7 0x009cc67e in zend_eval_string (str=0x7fbbf9 $a = 1; openssl_pkcs12_read(1, $a, 1);, retval_ptr=0x0, string_name=0xdfa8fc Command line code, tsrm_ls=0x1080450) at /home/tony/php-src_5_2/Zend/zend_execute_API.c:1148 #8 0x009cc8ca in zend_eval_string_ex (str=0x7fbbf9 $a = 1; openssl_pkcs12_read(1, $a, 1);, retval_ptr=0x0, string_name=0xdfa8fc Command line code, handle_exceptions=1, tsrm_ls=0x1080450) at /home/tony/php-src_5_2/Zend/zend_execute_API.c:1182 #9 0x00a92527 in main (argc=3, argv=0x7fb9e8) at /home/tony/php-src_5_2/sapi/cli/php_cli.c:1177 -- Edit bug report at http://bugs.php.net/?id=41353edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41353r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41353r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41353r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41353r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41353r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41353r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41353r=needscript Try newer version:http://bugs.php.net/fix.php?id=41353r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41353r=support Expected behavior:http://bugs.php.net/fix.php?id=41353r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41353r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41353r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41353r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41353r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41353r=dst IIS Stability:http://bugs.php.net/fix.php?id=41353r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41353r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41353r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41353r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41353r=mysqlcfg
#41353 [Opn-Asn]: openssl_pkcs12_read() does not verify the type of the first arg
ID: 41353 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: OpenSSL related Operating System: Linux PHP Version: 5CVS-2007-05-10 (CVS) -Assigned To: +Assigned To: pajoye Previous Comments: [2007-05-10 13:23:27] [EMAIL PROTECTED] Description: Function openssl_pkcs12_read() does not check the type of the first argument and uses it as a string in the call to BIO_write(). So if you pass a number as the first parameter, BIO_write() is called with a garbage params and segfaults. Reproduce code: --- $a = 2; openssl_pkcs12_read(1, $a, 1); Actual result: -- (gdb) r -r '$a = 2; openssl_pkcs12_read(1, $a, 1);' Starting program: /home/tony/php-src_5_2/sapi/cli/php -r '$a = 1; openssl_pkcs12_read(1, $a, 1);' [Thread debugging using libthread_db enabled] [New Thread 182900459904 (LWP 1209)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 182900459904 (LWP 1209)] 0x0031aef70bc0 in memcpy () from /lib64/tls/libc.so.6 (gdb) bt #0 0x0031aef70bc0 in memcpy () from /lib64/tls/libc.so.6 #1 0x00ac9f4b in mem_write () #2 0x00ac9136 in BIO_write () #3 0x00499009 in zif_openssl_pkcs12_read (ht=3, return_value=0x2a95b92fe8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0, tsrm_ls=0x1080450) at /home/tony/php-src_5_2/ext/openssl/openssl.c:1565 #4 0x00a1693e in zend_do_fcall_common_helper_SPEC (execute_data=0x7fb1b0, tsrm_ls=0x1080450) at zend_vm_execute.h:200 #5 0x00a1c49a in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x7fb1b0, tsrm_ls=0x1080450) at zend_vm_execute.h:1681 #6 0x00a16246 in execute (op_array=0x2a95b928a0, tsrm_ls=0x1080450) at zend_vm_execute.h:92 #7 0x009cc67e in zend_eval_string (str=0x7fbbf9 $a = 1; openssl_pkcs12_read(1, $a, 1);, retval_ptr=0x0, string_name=0xdfa8fc Command line code, tsrm_ls=0x1080450) at /home/tony/php-src_5_2/Zend/zend_execute_API.c:1148 #8 0x009cc8ca in zend_eval_string_ex (str=0x7fbbf9 $a = 1; openssl_pkcs12_read(1, $a, 1);, retval_ptr=0x0, string_name=0xdfa8fc Command line code, handle_exceptions=1, tsrm_ls=0x1080450) at /home/tony/php-src_5_2/Zend/zend_execute_API.c:1182 #9 0x00a92527 in main (argc=3, argv=0x7fb9e8) at /home/tony/php-src_5_2/sapi/cli/php_cli.c:1177 -- Edit this bug report at http://bugs.php.net/?id=41353edit=1
#41354 [NEW]: rename() file not found error message is ambigous
From: cbutler at technophobia dot co dot uk Operating system: Debian GNU/Linux PHP version: 5.2.2 PHP Bug Type: Filesystem function related Bug description: rename() file not found error message is ambigous Description: The error message given by rename() when one of its arguments doesn't exist does not distinguish which argument is at fault. This can make tracking down problems more difficult. Reproduce code: --- fclose(fopen(testfile, w)); echo bad 1st arg; rename(nonexistantfile, test); echo bad 2nd arg; rename(testfile, non/existant/dir); Expected result: bad 1st arg Warning: rename(nonexistantfile,test): nonexistantfile: No such file or directory in Command line code on line 3 bad 2nd arg Warning: rename(testfile,non/existant/dir): non/existant/dir: No such file or directory in Command line code on line 5 Actual result: -- bad 1st arg Warning: rename(nonexistantfile,test): No such file or directory in Command line code on line 3 bad 2nd arg Warning: rename(testfile,non/existant/dir): No such file or directory in Command line code on line 5 -- Edit bug report at http://bugs.php.net/?id=41354edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41354r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41354r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41354r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41354r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41354r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41354r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41354r=needscript Try newer version:http://bugs.php.net/fix.php?id=41354r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41354r=support Expected behavior:http://bugs.php.net/fix.php?id=41354r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41354r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41354r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41354r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41354r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41354r=dst IIS Stability:http://bugs.php.net/fix.php?id=41354r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41354r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41354r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41354r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41354r=mysqlcfg
#41151 [Opn-Bgs]: SOAP request is wrong when using subclass
ID: 41151
Updated by: [EMAIL PROTECTED]
Reported By: m dot necib at akrobat dot fr
-Status: Open
+Status: Bogus
Bug Type: SOAP related
Operating System: Windows XP
PHP Version: 5.2.1
Assigned To: dmitry
New Comment:
Not reprodusable.
Reproduce code:
---
?php
class Loan {
public $startingDate = 01-Jan-2007;
public $amount;
public $duration;
}
class LoanPersoItem {
public $year;
public $amount;
}
class LoanPerso extends Loan {
public $loans;
}
$client = new
SoapClient(http://213.41.94.84/wsPricing/services/PricingSNC?wsdl;,
array(
location = test://,
trace = 1,
exceptions = 0,
)
) ;
$v = new LoanPerso();
$v-loans = new LoanPersoItem();
$var = new SoapVar($v , SOAP_ENC_OBJECT, 'WSLoanPerso',
'http://pricing.aigvienet/gb/snc/' ) ;
$client-processPricingSNC(
array(
insured = array(
name = Aaa,
firstname = Bbb,
birthdate = 01-Jan-2006
),
premiumMode = 0,
loan = $var,
option = array(),
productCode = XXX
)
) ;
echo $client-__getLastRequest();
?
Output:
---
?xml version=1.0 encoding=UTF-8?
SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:ns1=http://pricing.aigvienet/gb/snc/;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;SOAP-ENV:Bodyns1:processPricingSNCparametresns1:insuredns1:nameAaa/ns1:namens1:firstnameBbb/ns1:firstnamens1:birthdate01-Jan-2006/ns1:birthdatens1:profession
xsi:nil=true//ns1:insuredns1:premiumMode0/ns1:premiumModens1:loan
xsi:type=ns1:WSLoanPersons1:startingDate01-Jan-2007/ns1:startingDatens1:amount
xsi:nil=true/ns1:duration xsi:nil=true/ns1:loansns1:year
xsi:nil=true/ns1:amount
xsi:nil=true//ns1:loans/ns1:loanns1:option/ns1:promotional
xsi:nil=true/ns1:quotity xsi:nil=true/ns1:couple
xsi:nil=true/ns1:smoker xsi:nil=true/ns1:ds
xsi:nil=true/ns1:productCodeXXX/ns1:productCode/parametres/ns1:processPricingSNC/SOAP-ENV:Body/SOAP-ENV:Envelope
Previous Comments:
[2007-05-10 10:24:07] m dot necib at akrobat dot fr
Hello Dmitry,
Our situation is a bit different than what you have tested.
Here is the link to the WSDL :
http://213.41.94.84/wsPricing/services/PricingSNC?wsdl
Look at the complexType named WSParameters.
It contains an element loan which type is WSLoan.
But two types extend WSLoan : WSLoanClassic and WSLoanPerso.
The Web Service expects us to send either of the inherited type.
WSLoan is an abstract type.
So in our case the correct type is not directly defined like in your
test case.
We are using SoapVar to specify the correct type of our object.
Then the generated SOAP request references the correct type.
But the fields are in the wrong order.
As you can see the WSDL file is generated by Apache Axis.
[2007-05-10 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2007-05-02 08:40:33] [EMAIL PROTECTED]
I just committed test file ext/soap/tests/schema/schema085.phpt, that
demonstrates proper element ordering. In your example you probably do
somthing wrong. I cannot say that exactly is wrong as you didn't provide
full reproduce case, probably you object isn't encoded using WSDL.
In case if you like me to look into problem please provide full example
(without ...) including full WSDL file.
[2007-04-20 16:55:19] m dot necib at akrobat dot fr
WSDL :
complexType name=A
sequence
element name=a type=xsd:int/
/sequence
/complexType
complexType name=B
complexContent
extension base=impl:A
sequence
element name=b type=xsd:int/
/sequence
/extension
/complexContent
/complexType
[2007-04-20 16:47:37] m dot necib at akrobat dot fr
Description:
When using subclass as a value in WSDL mode,
the properties are written in the wrong order :
the child class properties are written _before_
the parent properties.
Reproduce code:
---
PHP:
class A
{
public $a ;
}
class B extends A
{
public $b ;
}
$client = new SoapClient(...) ;
$var = new SoapVar( new B(), SOAP_ENC_OBJECT, 'B', 'http://myns/' ) ;
$client-foo($var) ;
Expected result:
SOAP request :
parametres xsi:type=B
a/a
b/b
/parametres
#41349 [Opn-Fbk]: $_POST not filled, altough raw POST is available
ID: 41349
Updated by: [EMAIL PROTECTED]
Reported By: php at bitrockers dot de
-Status: Open
+Status: Feedback
Bug Type: HTTP related
Operating System: Linux Debian Etch
PHP Version: 5.2.2
New Comment:
What is the content type of the request?
Previous Comments:
[2007-05-10 11:41:28] php at bitrockers dot de
Description:
Maybe this bug is related to Bugs 31417 and 41293. But I'm not sure,
because this bug occurs in 5.2.0 and 5.2.2.
The problem is:
When sending POST requests via the XmlHttpRequest active-x, on some IE6
installations this won't work properly. The POST request is successfully
sent to our webserver, and the raw http post data is filled correctly,
but the $_POST array is not filled with any information.
I can only guess that the error has something to do with some special
headers/encoding (Content-Length?) which is done by the
XmlHttpRequest-ActiveX on some IE6 installations.
And: Yes, I know that it's hard to find the reason for this behaviour.
And it's not easy to reproduce this bug ( because on most IE6
installations everything works fine).
But I guess it's worth to take a look at the php-source, so that
someone may get an idea which could cause this bug.
I'm trying to help you as much as possible. Unfortunately I cannot
reproduce the error by myself, so I have to ask the affected customers
each time we 'possibly' fixed the bug.
There must be a bug in php, because the raw-http request is filled
correctly (and we don't touch the $_POST var anywhere else in our code).
Reproduce code:
---
var_export($_POST);
$rawPost = file_get_contents('php://input');
echo \n$rawPost;
Expected result:
array('postVar1' = 'postValue1',
'postVar2' = 'postValue2')
postVar1=postValue1postVar2=postValue2
Actual result:
--
array()
postVar1=postValue1postVar2=postValue2
--
Edit this bug report at http://bugs.php.net/?id=41349edit=1
#41337 [Asn-Csd]: WSDL parsing doesn't ignore non soap bindings
ID: 41337
Updated by: [EMAIL PROTECTED]
Reported By: ahayes at emersion dot com dot au
-Status: Assigned
+Status: Closed
Bug Type: SOAP related
Operating System: Fedora Core 5
PHP Version: 5.2.2
Assigned To: dmitry
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2007-05-09 08:24:07] ahayes at emersion dot com dot au
Description:
Firstly let me just say, I'm am not sure if this is a bug in PHP or
Oracle SOA Suite (Oracle seem to think it is PHP however).
I am using Oracle's SOA Suite, and we have a problem every time we try
to call WSDL files generated by Oracle's ESB.
The problem occurs when PHP's SoapClient tries to parse the WSDL. I get
the following error:
Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: No address associated with port in
...
...
To fix this problem, all I have to do is remove offending port
definition in the WSDL, which does not have an address defined. Once
removed, SoapClient can parse the WSDL and call the service. We have
many ESB's to call and as such I would like to avoid this if possible.
Should PHP's SoapClient even be looking at this port type as it does no
have a SOAP binding?
Reproduce code:
---
?php
$client = new
SoapClient('https://amcms.org/soap/GetHandlerTypeByServiceId.wsdl');
Expected result:
It parses the WSDL file successfully then allowing calling the service.
Actual result:
--
PHP Fatal error: SOAP-ERROR: Parsing WSDL: No address associated with
port in /path/to/GetHandlerTypeByServiceId.php on line 10
PHP Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR:
Parsing WSDL: No address associated with port in
/path/to/GetHandlerTypeByServiceId.php:10
Stack trace:
#0 /path/to/GetHandlerTypeByServiceId.php(10):
SoapClient-SoapClient('GetHandlerTypeB...', Array)
#1 {main}
thrown in /path/to/GetHandlerTypeByServiceId.php on line 10
--
Edit this bug report at http://bugs.php.net/?id=41337edit=1
#41349 [Fbk-Opn]: $_POST not filled, altough raw POST is available
ID: 41349
User updated by: php at bitrockers dot de
Reported By: php at bitrockers dot de
-Status: Feedback
+Status: Open
Bug Type: HTTP related
Operating System: Linux Debian Etch
PHP Version: 5.2.2
New Comment:
The Content-Type is
application/x-www-form-urlencoded; charset=utf-8
At least that is the content-type from what I see when I do the request
in my browsers. Due to the fact that this problem occurs only at a few
IE6 installations I'm not absolutely sure that there is something on the
client-side which in some way modifies that header before sending it
to our server.
Is there a way to log the Content-Type of the request in PHP or apache,
to make sure that this is not the problem?
Previous Comments:
[2007-05-10 14:56:05] [EMAIL PROTECTED]
What is the content type of the request?
[2007-05-10 11:41:28] php at bitrockers dot de
Description:
Maybe this bug is related to Bugs 31417 and 41293. But I'm not sure,
because this bug occurs in 5.2.0 and 5.2.2.
The problem is:
When sending POST requests via the XmlHttpRequest active-x, on some IE6
installations this won't work properly. The POST request is successfully
sent to our webserver, and the raw http post data is filled correctly,
but the $_POST array is not filled with any information.
I can only guess that the error has something to do with some special
headers/encoding (Content-Length?) which is done by the
XmlHttpRequest-ActiveX on some IE6 installations.
And: Yes, I know that it's hard to find the reason for this behaviour.
And it's not easy to reproduce this bug ( because on most IE6
installations everything works fine).
But I guess it's worth to take a look at the php-source, so that
someone may get an idea which could cause this bug.
I'm trying to help you as much as possible. Unfortunately I cannot
reproduce the error by myself, so I have to ask the affected customers
each time we 'possibly' fixed the bug.
There must be a bug in php, because the raw-http request is filled
correctly (and we don't touch the $_POST var anywhere else in our code).
Reproduce code:
---
var_export($_POST);
$rawPost = file_get_contents('php://input');
echo \n$rawPost;
Expected result:
array('postVar1' = 'postValue1',
'postVar2' = 'postValue2')
postVar1=postValue1postVar2=postValue2
Actual result:
--
array()
postVar1=postValue1postVar2=postValue2
--
Edit this bug report at http://bugs.php.net/?id=41349edit=1
#41291 [Asn-Csd]: FastCGI does not set SO_REUSEADDR
ID: 41291
Updated by: [EMAIL PROTECTED]
Reported By: fmajid at kefta dot com
-Status: Assigned
+Status: Closed
Bug Type: CGI related
Operating System: Solaris
PHP Version: 5.2.2
Assigned To: dmitry
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2007-05-04 19:13:18] fmajid at kefta dot com
Description:
The CGI/FastCGI SAPI does not set the SO_REUSEADDR option. This can
prevent the FastCGI server from being restarted if it exits with sockets
in the TIME_WAIT state.
The patch below fixes this.
That said, a much better option would be to refactor the fastcgi.c code
to use php_network_bind_socket_to_local_addr instead of reinventing the
square wheel.
*** php-5.2.1/sapi/cgi/fastcgi.c~ Mon Jan 1 01:36:12 2007
--- php-5.2.1/sapi/cgi/fastcgi.cFri May 4 11:45:39 2007
***
*** 253,258
--- 253,261
int listen_socket;
sa_t sa;
socklen_t sock_len;
+ #ifdef SO_REUSEADDR
+ int val = 1;
+ #endif
if ((s = strchr(path, ':'))) {
port = atoi(s+1);
***
*** 308,313
--- 311,319
/* Create, bind socket and start listen on it */
if ((listen_socket = socket(sa.sa.sa_family, SOCK_STREAM, 0))
0 ||
+ #ifdef SO_REUSEADDR
+ setsockopt(listen_socket, SOL_SOCKET, SO_REUSEADDR,
(char*)val, sizeof(val)) 0 ||
+ #endif
bind(listen_socket, (struct sockaddr *) sa, sock_len) 0
||
listen(listen_socket, backlog) 0) {
Reproduce code:
---
Run a FastCGI web server and start the FastCGI SAPI using php -b.
Kill the FastCGI process.
Attempt to restart it.
Expected result:
FastCGI server restarting normally
Actual result:
--
alamut ~php-cgi -b 127.0.0.1: -c /home/majid/web/conf
Cannot bind/listen socket - [125] Address already in use.
Couldn't create FastCGI listen socket on port 127.0.0.1:
--
Edit this bug report at http://bugs.php.net/?id=41291edit=1
#41349 [Opn]: Waiting for customers reponse...
ID: 41349
User updated by: php at bitrockers dot de
-Summary: $_POST not filled, altough raw POST is available
Reported By: php at bitrockers dot de
Status: Open
Bug Type: HTTP related
Operating System: Linux Debian Etch
PHP Version: 5.2.2
New Comment:
I've actually activated the logging of Content-Type and Content-Length.
Now I have to ask the customers, which are having the problems, to try
again.
As soon as I get the response, I will post the Content-Type of their
requests.
Previous Comments:
[2007-05-10 15:07:19] php at bitrockers dot de
The Content-Type is
application/x-www-form-urlencoded; charset=utf-8
At least that is the content-type from what I see when I do the request
in my browsers. Due to the fact that this problem occurs only at a few
IE6 installations I'm not absolutely sure that there is something on the
client-side which in some way modifies that header before sending it
to our server.
Is there a way to log the Content-Type of the request in PHP or apache,
to make sure that this is not the problem?
[2007-05-10 14:56:05] [EMAIL PROTECTED]
What is the content type of the request?
[2007-05-10 11:41:28] php at bitrockers dot de
Description:
Maybe this bug is related to Bugs 31417 and 41293. But I'm not sure,
because this bug occurs in 5.2.0 and 5.2.2.
The problem is:
When sending POST requests via the XmlHttpRequest active-x, on some IE6
installations this won't work properly. The POST request is successfully
sent to our webserver, and the raw http post data is filled correctly,
but the $_POST array is not filled with any information.
I can only guess that the error has something to do with some special
headers/encoding (Content-Length?) which is done by the
XmlHttpRequest-ActiveX on some IE6 installations.
And: Yes, I know that it's hard to find the reason for this behaviour.
And it's not easy to reproduce this bug ( because on most IE6
installations everything works fine).
But I guess it's worth to take a look at the php-source, so that
someone may get an idea which could cause this bug.
I'm trying to help you as much as possible. Unfortunately I cannot
reproduce the error by myself, so I have to ask the affected customers
each time we 'possibly' fixed the bug.
There must be a bug in php, because the raw-http request is filled
correctly (and we don't touch the $_POST var anywhere else in our code).
Reproduce code:
---
var_export($_POST);
$rawPost = file_get_contents('php://input');
echo \n$rawPost;
Expected result:
array('postVar1' = 'postValue1',
'postVar2' = 'postValue2')
postVar1=postValue1postVar2=postValue2
Actual result:
--
array()
postVar1=postValue1postVar2=postValue2
--
Edit this bug report at http://bugs.php.net/?id=41349edit=1
#41349 [Opn]: $_POST not filled, altough raw POST is available
ID: 41349
User updated by: php at bitrockers dot de
-Summary: Waiting for customers reponse...
Reported By: php at bitrockers dot de
Status: Open
Bug Type: HTTP related
Operating System: Linux Debian Etch
PHP Version: 5.2.2
New Comment:
(damn, destroyed the Summary) :)
Previous Comments:
[2007-05-10 15:27:13] php at bitrockers dot de
I've actually activated the logging of Content-Type and Content-Length.
Now I have to ask the customers, which are having the problems, to try
again.
As soon as I get the response, I will post the Content-Type of their
requests.
[2007-05-10 15:07:19] php at bitrockers dot de
The Content-Type is
application/x-www-form-urlencoded; charset=utf-8
At least that is the content-type from what I see when I do the request
in my browsers. Due to the fact that this problem occurs only at a few
IE6 installations I'm not absolutely sure that there is something on the
client-side which in some way modifies that header before sending it
to our server.
Is there a way to log the Content-Type of the request in PHP or apache,
to make sure that this is not the problem?
[2007-05-10 14:56:05] [EMAIL PROTECTED]
What is the content type of the request?
[2007-05-10 11:41:28] php at bitrockers dot de
Description:
Maybe this bug is related to Bugs 31417 and 41293. But I'm not sure,
because this bug occurs in 5.2.0 and 5.2.2.
The problem is:
When sending POST requests via the XmlHttpRequest active-x, on some IE6
installations this won't work properly. The POST request is successfully
sent to our webserver, and the raw http post data is filled correctly,
but the $_POST array is not filled with any information.
I can only guess that the error has something to do with some special
headers/encoding (Content-Length?) which is done by the
XmlHttpRequest-ActiveX on some IE6 installations.
And: Yes, I know that it's hard to find the reason for this behaviour.
And it's not easy to reproduce this bug ( because on most IE6
installations everything works fine).
But I guess it's worth to take a look at the php-source, so that
someone may get an idea which could cause this bug.
I'm trying to help you as much as possible. Unfortunately I cannot
reproduce the error by myself, so I have to ask the affected customers
each time we 'possibly' fixed the bug.
There must be a bug in php, because the raw-http request is filled
correctly (and we don't touch the $_POST var anywhere else in our code).
Reproduce code:
---
var_export($_POST);
$rawPost = file_get_contents('php://input');
echo \n$rawPost;
Expected result:
array('postVar1' = 'postValue1',
'postVar2' = 'postValue2')
postVar1=postValue1postVar2=postValue2
Actual result:
--
array()
postVar1=postValue1postVar2=postValue2
--
Edit this bug report at http://bugs.php.net/?id=41349edit=1
#38111 [Com]: PHP crashes IIS worker process and application pool
ID: 38111 Comment by: roger dot weiss at gmail dot com Reported By: svendavidh at hotmail dot com Status: No Feedback Bug Type: IIS related Operating System: Windows Server 2003 Std. Ed. R2 PHP Version: 5.1.4 New Comment: I am also getting these. This only start happening after we installed 5.2.1.1. I will install 5.2.2 and let you know if the problem persists. faulting module php5isapi.dll, version 5.2.1.1, fault address 0x23d7 Previous Comments: [2007-04-09 13:09:36] whereismys4 at yahoo dot com Similar problem with IIS 6.0, PHP 5.2.1. IIS worker terminated. This is a problem for me since i have a firm developing a commerce website in PHP, this is happening on a test server which has the following software installed: Windows 2K3 Server R2 sp2 PHP 5.2.1 MySQL 5,0,37 IIS 6.0 I've googled this error and all threads point to PHP. Please provide an update to this bug. Thanks Mike [2007-03-20 14:32:57] dev at e-concept dot org I've got the same problem with php 5.2.1.1 windows vista pro II7 [2006-11-03 09:18:05] albert at siprep dot org Same problem with PHP 5.1.6. [2006-07-27 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2006-07-24 16:08:30] cyberchrist at futura dot net svendavidh: MSVC6 is Microsoft Visual C++ 6.0. Presumably, one could accomplish the same task on later versions of Microsoft Visual Studio. How, I don't know, nor could I recommend installing a development studio on a live production server. Looks like someone needs to set up a Win2K3 R2 server offline, load up visual studio, and run the backtrace. I have neither the equipment nor the software to do this. Here's hoping you do, I just realized that I'm suffering from this same bug myself. 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/38111 -- Edit this bug report at http://bugs.php.net/?id=38111edit=1
#36708 [Csd-Opn]: PDO Extension fails to configure proper makefile
ID: 36708 User updated by: jerome at macsaresexy dot com Reported By: jerome at macsaresexy dot com -Status: Closed +Status: Open Bug Type: Compile Failure -Operating System: Mac OS X 10.4.5 +Operating System: Mac OS X 10.4.9 -PHP Version: 5.1.2 +PHP Version: 5.2.1 Assigned To: wez New Comment: After some looking into, I reopened this bug after discussing this with mac developers and the fact being stated that OS X has dlopen and friends just like linux. ALso the fact that MOST of the php extensions build fine on OS X except for PDO and maybe one or 2 others. This doesn't seem reasonable to not be able to do, if other extensions can be compiled loaded, why can't PDO. it really limits options like considering Zend Core when you can't install PDO via pecl. Previous Comments: [2006-08-24 16:01:46] [EMAIL PROTECTED] Due to the way that loadable modules work on OSX/Darwin, you need to compile the PDO package statically into the PHP core. I've fixed the configure, so it will fail if you try to compile PDO dynamically. [2006-07-18 17:12:21] jerome at macsaresexy dot com I just grabbed PHP 5.2 CVS 200607181630 snapshot and attempted to compile it, PHP itself compiled fine, but PDO still does not generate a proper makefile on Mac OS X. after running the php5.2cvs's phpize on ext/pdo, i did configure then make, and it just immediately thinks it's done like it always has been doing. [2006-07-18 15:43:57] [EMAIL PROTECTED] The next snapshot should be ok. Thanks for the alert. [2006-07-18 15:36:05] jerome at macsaresexy dot com I was unable to try cvs since it failed compiling PHP part way through with: /Users/jerome/Downloads/php5.2-200607181430/Zend/ zend_alloc.c: In function zend_mm_mem_mmap_realloc: /Users/jerome/Downloads/php5.2-200607181430/Zend/ zend_alloc.c:117: error: ret undeclared (first use in this function) /Users/jerome/Downloads/php5.2-200607181430/Zend/ zend_alloc.c:117: error: (Each undeclared identifier is reported only once /Users/jerome/Downloads/php5.2-200607181430/Zend/ zend_alloc.c:117: error: for each function it appears in.) make: *** [Zend/zend_alloc.lo] Error 1 [2006-06-20 15:27:28] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/36708 -- Edit this bug report at http://bugs.php.net/?id=36708edit=1
#28165 [Com]: Missing implicit object to integer conversion
ID: 28165
Comment by: john at pinesoft dot co dot uk
Reported By: daniel at rozsnyo dot com
Status: Suspended
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 5.0.*
New Comment:
problem still evident in 5.2.1
?php
$obj = new stdClass;
var_dump($obj == 1);
?
Previous Comments:
[2005-12-16 17:52:43] php at jort dot net
I updated form 5.0.4 to 5.1.1 and encountered this problem.
I use == and try to compare a DOM node value with a class property.
What's the difference between these versions?
[2004-04-29 21:07:49] daniel at rozsnyo dot com
OK, I have a temporary solution (because i wanted to compare the
object references):
Instead of this:
echo (in_array($x,$a)) ? 'There' : 'NOT there';
I must use this:
echo (in_array($x,$a,TRUE)) ? 'There' : 'NOT there';
This way the PHP uses the '===' operator which is OK for me.
ad the '==' operator)
The notice of Notice: Object of class A could not be converted to
integer in... is a bit ambiguous - I spent a day searching how to make
an integer from an object. Anyway, the '==' works in PHP, but generates
these notices - what if I really want to compare the objects by value?
[2004-04-29 20:53:29] hans at velum dot net
Using '===' instead of '==' will work, but is semantically different,
right?
$a === $b : are object references the same? i.e. are $a and $b the same
instance.
$a == $b : do the contents match? i.e. do all the variables in object
$a have the same values as the vars in object $b.
If '==' is going to be changed to mean something else, then I think
PHP5 needs an __equals() method so that object contents comparison can
be accomplished.
[2004-04-26 21:11:55] rozsnyo at kn dot vutbr dot cz
The notices are also generated on comparison operator (==)
This code:
?php
class A {
public $p;
function __construct($ip) { $this-p = $ip; }
}
$x = new A(1);
$y = $z = new A(2);
echo '$x,$y is ' , ( ($x == $y) ? 'equal': 'not
equal[right]' ), 'br';
echo '$x,$y is ' , ( ($x === $y) ? 'identical': 'not
identical[right]' ), 'br';
echo '$z,$y is ' , ( ($z == $y) ? 'equal[right]' : 'not equal'
), 'br';
echo '$z,$y is ' , ( ($z === $y) ? 'identical[right]' : 'not
identical'), 'br';
?
Produces:
$x,$y is
Notice: Object of class A could not be converted to integer in
C:\www\default\test\index.php on line 11
Notice: Object of class A could not be converted to integer in
C:\www\default\test\index.php on line 11
not equal[right]
$x,$y is not identical[right]
$z,$y is
Notice: Object of class A could not be converted to integer in
C:\www\default\test\index.php on line 13
Notice: Object of class A could not be converted to integer in
C:\www\default\test\index.php on line 13
equal[right]
$z,$y is identical[right]
At least, please remove the notification and fix the in_array and also
the array_search function (seems that both share the same algorithm -
always two notices as two objects are compared) - the right solution
would be to use the === operator in these functions when the needle is
an object.
This bug is still about:
http://www.php.net/ChangeLog-5.php
Changed array_search() to accept also objects as a needle. (Moriyoshi)
[2004-04-26 20:39:34] [EMAIL PROTECTED]
There are no plans for this. Maybe in PHP 6.
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/28165
--
Edit this bug report at http://bugs.php.net/?id=28165edit=1
#28165 [Com]: Missing implicit object to integer conversion
ID: 28165
Comment by: john at pinesoft dot co dot uk
Reported By: daniel at rozsnyo dot com
Status: Suspended
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 5.0.*
New Comment:
correction to previous comment.. version 5.2.2
Previous Comments:
[2007-05-10 16:26:43] john at pinesoft dot co dot uk
problem still evident in 5.2.1
?php
$obj = new stdClass;
var_dump($obj == 1);
?
[2005-12-16 17:52:43] php at jort dot net
I updated form 5.0.4 to 5.1.1 and encountered this problem.
I use == and try to compare a DOM node value with a class property.
What's the difference between these versions?
[2004-04-29 21:07:49] daniel at rozsnyo dot com
OK, I have a temporary solution (because i wanted to compare the
object references):
Instead of this:
echo (in_array($x,$a)) ? 'There' : 'NOT there';
I must use this:
echo (in_array($x,$a,TRUE)) ? 'There' : 'NOT there';
This way the PHP uses the '===' operator which is OK for me.
ad the '==' operator)
The notice of Notice: Object of class A could not be converted to
integer in... is a bit ambiguous - I spent a day searching how to make
an integer from an object. Anyway, the '==' works in PHP, but generates
these notices - what if I really want to compare the objects by value?
[2004-04-29 20:53:29] hans at velum dot net
Using '===' instead of '==' will work, but is semantically different,
right?
$a === $b : are object references the same? i.e. are $a and $b the same
instance.
$a == $b : do the contents match? i.e. do all the variables in object
$a have the same values as the vars in object $b.
If '==' is going to be changed to mean something else, then I think
PHP5 needs an __equals() method so that object contents comparison can
be accomplished.
[2004-04-26 21:11:55] rozsnyo at kn dot vutbr dot cz
The notices are also generated on comparison operator (==)
This code:
?php
class A {
public $p;
function __construct($ip) { $this-p = $ip; }
}
$x = new A(1);
$y = $z = new A(2);
echo '$x,$y is ' , ( ($x == $y) ? 'equal': 'not
equal[right]' ), 'br';
echo '$x,$y is ' , ( ($x === $y) ? 'identical': 'not
identical[right]' ), 'br';
echo '$z,$y is ' , ( ($z == $y) ? 'equal[right]' : 'not equal'
), 'br';
echo '$z,$y is ' , ( ($z === $y) ? 'identical[right]' : 'not
identical'), 'br';
?
Produces:
$x,$y is
Notice: Object of class A could not be converted to integer in
C:\www\default\test\index.php on line 11
Notice: Object of class A could not be converted to integer in
C:\www\default\test\index.php on line 11
not equal[right]
$x,$y is not identical[right]
$z,$y is
Notice: Object of class A could not be converted to integer in
C:\www\default\test\index.php on line 13
Notice: Object of class A could not be converted to integer in
C:\www\default\test\index.php on line 13
equal[right]
$z,$y is identical[right]
At least, please remove the notification and fix the in_array and also
the array_search function (seems that both share the same algorithm -
always two notices as two objects are compared) - the right solution
would be to use the === operator in these functions when the needle is
an object.
This bug is still about:
http://www.php.net/ChangeLog-5.php
Changed array_search() to accept also objects as a needle. (Moriyoshi)
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/28165
--
Edit this bug report at http://bugs.php.net/?id=28165edit=1
#41343 [Com]: FastCGI Server (Internal Server Error)
ID: 41343
Comment by: philip dot iezzi at onlime dot ch
Reported By: trustpunk at gmail dot com
Status: Open
Bug Type: CGI related
Operating System: Windows XP
PHP Version: 5.2.2
New Comment:
Same problem here, PHP 5.2.2 as CGI crashes all the time.
I have encountered the problem under the following configurations:
Debian Linux (sarge)
PHP/CGI 5.2.2 4.4.7, compiled from sources
web application: SPIP 1.9 CMS
Debian Linux (etch)
PHP/FastCGI(fcgid) 5.2.2, compiled from sources
web application: Roundcube webmail (latest SVN checkout)
Downgrading back to PHP 5.2.1 solved all the issues.
I definitely need to get 5.2.2 running as a serious bug with FastCGI
was fixed (#40286). The current situation is pretty ugly, both versions
of PHP are buggy in their own way under CGI/FastCGI.
Thx!
Philip
Previous Comments:
[2007-05-10 01:33:11] trustpunk at gmail dot com
Description:
I run the FastCGI server
C:\PHP5\php-cgi.exe -b 127.0.0.1:2700
When it becomes under too much load, it displays an Internal Server
Error.
Reproduce code:
---
This code will cause the FastCGI Server to show an Internal Server
Error.
?php
if (class_exists(COM)) {
$wmi = new COM(WinMgmts:.);
$cpus = $wmi-InstancesOf(Win32_Processor);
$i = 1;
// Use the while loop on PHP 4 and foreach on PHP 5
// while ($cpu = $cpus-Next()) {
foreach ($cpus as $cpu) {
echo pProcessor $i : . $cpu-Name . @ ;
$clockSpeed = $cpu-CurrentClockSpeed;
$cpuLoad = $cpu-LoadPercentage;
echo $clockSpeed . MHz (Load= . $cpuLoad .%)/p;
$i++;
}
$uptime = 0;
$systems = $wmi-InstancesOf(Win32_PerfRawData_PerfOS_System);
// Use the while loop on PHP 4 and foreach on PHP 5
// while ($system = $systems-Next()) {
foreach ($systems as $system) {
$PerfTimeStamp = $system-Timestamp_Object ;
$PerfTimeFreq = $system-Frequency_Object ;
$Counter = $system-SystemUpTime ;
$UptimeInSec = ($PerfTimeStamp - $Counter)/$PerfTimeFreq ;
$uptime = max($uptime, $UptimeInSec);
}
}
else {
return pYour system does not support WMI!/p;
}
?
Expected result:
I expect to see my Processors listed with some useful information.
Actual result:
--
Internal Server Error (500)
--
Edit this bug report at http://bugs.php.net/?id=41343edit=1
#41349 [Opn]: $_POST not filled, altough raw POST is available
ID: 41349
User updated by: php at bitrockers dot de
Reported By: php at bitrockers dot de
Status: Open
Bug Type: HTTP related
Operating System: Linux Debian Etch
PHP Version: 5.2.2
New Comment:
Could it be a problem that the POST request comes as post. Here an
excerpt of our logfile:
Customers (not working) request:
post /ajax/mypageProfileEdit/? HTTP/1.1 200 99
application/x-www-form-urlencoded; charset=utf-8 148
Request (my IE6, working):
POST /ajax/mypageProfileEdit/? HTTP/1.1 200 123
application/x-www-form-urlencoded; charset=utf-8 148
Does it make a difference for PHP if the POST request is lowercase?
Apache doesn't seem to have a problem with that. I don't know why the
customers IE6 sends XmlHttpRequest as lowercase post?
Previous Comments:
[2007-05-10 15:28:45] php at bitrockers dot de
(damn, destroyed the Summary) :)
[2007-05-10 15:27:13] php at bitrockers dot de
I've actually activated the logging of Content-Type and Content-Length.
Now I have to ask the customers, which are having the problems, to try
again.
As soon as I get the response, I will post the Content-Type of their
requests.
[2007-05-10 15:07:19] php at bitrockers dot de
The Content-Type is
application/x-www-form-urlencoded; charset=utf-8
At least that is the content-type from what I see when I do the request
in my browsers. Due to the fact that this problem occurs only at a few
IE6 installations I'm not absolutely sure that there is something on the
client-side which in some way modifies that header before sending it
to our server.
Is there a way to log the Content-Type of the request in PHP or apache,
to make sure that this is not the problem?
[2007-05-10 14:56:05] [EMAIL PROTECTED]
What is the content type of the request?
[2007-05-10 11:41:28] php at bitrockers dot de
Description:
Maybe this bug is related to Bugs 31417 and 41293. But I'm not sure,
because this bug occurs in 5.2.0 and 5.2.2.
The problem is:
When sending POST requests via the XmlHttpRequest active-x, on some IE6
installations this won't work properly. The POST request is successfully
sent to our webserver, and the raw http post data is filled correctly,
but the $_POST array is not filled with any information.
I can only guess that the error has something to do with some special
headers/encoding (Content-Length?) which is done by the
XmlHttpRequest-ActiveX on some IE6 installations.
And: Yes, I know that it's hard to find the reason for this behaviour.
And it's not easy to reproduce this bug ( because on most IE6
installations everything works fine).
But I guess it's worth to take a look at the php-source, so that
someone may get an idea which could cause this bug.
I'm trying to help you as much as possible. Unfortunately I cannot
reproduce the error by myself, so I have to ask the affected customers
each time we 'possibly' fixed the bug.
There must be a bug in php, because the raw-http request is filled
correctly (and we don't touch the $_POST var anywhere else in our code).
Reproduce code:
---
var_export($_POST);
$rawPost = file_get_contents('php://input');
echo \n$rawPost;
Expected result:
array('postVar1' = 'postValue1',
'postVar2' = 'postValue2')
postVar1=postValue1postVar2=postValue2
Actual result:
--
array()
postVar1=postValue1postVar2=postValue2
--
Edit this bug report at http://bugs.php.net/?id=41349edit=1
#41356 [NEW]: Cannot retrieve global from a class in a soap server
From: simon at connexon dot com
Operating system: Windows
PHP version: 5.2.2
PHP Bug Type: SOAP related
Bug description: Cannot retrieve global from a class in a soap server
Description:
For our application we use a $db which represents the database connection
object.
In the class, instead of creating a new object every time, we do : global
$db, which retrieves the database connection from outside the class.
That works good!
However, when we call that class from a soap server, for some reason it
does not get the $db variable (its blank)...
Reproduce code:
---
// Code
$db = new MySQL();
// class
class X extends A
{
public function __construct($params)
{
global $db;
$this-db = $db;
$this-init($params);
}
Expected result:
that the global $db; in the constructor contains the db connection
Actual result:
--
blank variable
--
Edit bug report at http://bugs.php.net/?id=41356edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41356r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41356r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41356r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41356r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41356r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41356r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41356r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41356r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41356r=support
Expected behavior:http://bugs.php.net/fix.php?id=41356r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41356r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41356r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41356r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41356r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41356r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41356r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41356r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41356r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41356r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41356r=mysqlcfg
#41356 [Opn-Csd]: Cannot retrieve global from a class in a soap server
ID: 41356
User updated by: simon at connexon dot com
Reported By: simon at connexon dot com
-Status: Open
+Status: Closed
Bug Type: SOAP related
Operating System: Windows
PHP Version: 5.2.2
New Comment:
using $GLOBALS instead of global seems to fix the problem
Previous Comments:
[2007-05-10 17:18:22] simon at connexon dot com
Description:
For our application we use a $db which represents the database
connection object.
In the class, instead of creating a new object every time, we do :
global $db, which retrieves the database connection from outside the
class.
That works good!
However, when we call that class from a soap server, for some reason it
does not get the $db variable (its blank)...
Reproduce code:
---
// Code
$db = new MySQL();
// class
class X extends A
{
public function __construct($params)
{
global $db;
$this-db = $db;
$this-init($params);
}
Expected result:
that the global $db; in the constructor contains the db connection
Actual result:
--
blank variable
--
Edit this bug report at http://bugs.php.net/?id=41356edit=1
#41357 [NEW]: substract integer part of a float value is not working well
From: gonzalolarralde at gmail dot com Operating system: Ubuntu Linux PHP version: 5.2.2 PHP Bug Type: *Math Functions Bug description: substract integer part of a float value is not working well Description: When you try to get decimal part of a float number, if you substract integer number to float one, it returns the decimal part plus 0.01. Reproduce code: --- ?php var_dump(214.16569 - 214); ? Expected result: 0.16569 Actual result: -- 0.165691 -- Edit bug report at http://bugs.php.net/?id=41357edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41357r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41357r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41357r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41357r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41357r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41357r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41357r=needscript Try newer version:http://bugs.php.net/fix.php?id=41357r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41357r=support Expected behavior:http://bugs.php.net/fix.php?id=41357r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41357r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41357r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41357r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41357r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41357r=dst IIS Stability:http://bugs.php.net/fix.php?id=41357r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41357r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41357r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41357r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41357r=mysqlcfg
#41358 [NEW]: configure cannot determine libcurl's SSL lib as of v7.16.2
From: [EMAIL PROTECTED] Operating system: PHP version: 5CVS-2007-05-10 (CVS) PHP Bug Type: *Compile Issues Bug description: configure cannot determine libcurl's SSL lib as of v7.16.2 Description: ext/curl (ZTS) probably needs a runtime check for libcurl's SSL lib. -- Edit bug report at http://bugs.php.net/?id=41358edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41358r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41358r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41358r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41358r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41358r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41358r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41358r=needscript Try newer version:http://bugs.php.net/fix.php?id=41358r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41358r=support Expected behavior:http://bugs.php.net/fix.php?id=41358r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41358r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41358r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41358r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41358r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41358r=dst IIS Stability:http://bugs.php.net/fix.php?id=41358r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41358r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41358r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41358r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41358r=mysqlcfg
#41358 [Opn-Asn]: configure cannot determine libcurl's SSL lib as of v7.16.2
ID: 41358 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type:*Compile Issues PHP Version: 5CVS-2007-05-10 (CVS) -Assigned To: +Assigned To: mike Previous Comments: [2007-05-10 18:21:32] [EMAIL PROTECTED] Description: ext/curl (ZTS) probably needs a runtime check for libcurl's SSL lib. -- Edit this bug report at http://bugs.php.net/?id=41358edit=1
#41357 [Opn-Bgs]: substract integer part of a float value is not working well
ID: 41357 Updated by: [EMAIL PROTECTED] Reported By: gonzalolarralde at gmail dot com -Status: Open +Status: Bogus Bug Type: *Math Functions Operating System: Ubuntu Linux PHP Version: 5.2.2 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. If you would like to know more about floats and what IEEE 754 is read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. . Previous Comments: [2007-05-10 18:01:46] gonzalolarralde at gmail dot com Description: When you try to get decimal part of a float number, if you substract integer number to float one, it returns the decimal part plus 0.01. Reproduce code: --- ?php var_dump(214.16569 - 214); ? Expected result: 0.16569 Actual result: -- 0.165691 -- Edit this bug report at http://bugs.php.net/?id=41357edit=1
#32806 [Com]: fgets() function is slow
ID: 32806
Comment by: scottij at arbor dot net
Reported By: peoned at yahoo dot com
Status: No Feedback
Bug Type: Performance problem
Operating System: Linux
PHP Version: 5.0.4
Assigned To: wez
New Comment:
I'm getting similar behavior with php 5.2.1.
I am reading about 5,000 lines over a tcp socket to another program on
the localhost (NOT over a network). Initially, it takes about 500 us
per line of text (where the lines are 20 characters long). Here is
the code snippet and output:
while (/* some eof and timeout checks here */) {
$rstart = microtime(TRUE);
$str = fgets($this-dataSocket, 8096);
$rstop = microtime(TRUE);
$rdiff = $rstop - $rstart;
print(read took $rdiff secs.br\n);
print(str = $strbr\n);
}
This yields, for example:
str = 16549|Item2250||3|2|
read took 0.00049185752868652 secs.
str = 16550|Item2251||3|2|
read took 0.00049495697021484 secs.
str = 16551|Blob2252||3|2|
read took 0.00049018859863281 secs.
I run that over a full dump of my text (5000 lines).
If I then close the socket, open a new one, and do the same operation,
about halfway through the fgets() times start increasing dramatically:
str = 16645|Item2346||3|2|
read took 0.0019731521606445 secs.
str = 16646|Item2347||3|2|
read took 0.0019690990447998 secs.
str = 16647|Item2348||3|2|
read took 0.0020229816436768 secs.
2 ms to read each short line?? Again, this is just over a local
socket, nothing over the network.
This is reproducible every time on my system.
Thanks.
Previous Comments:
[2005-11-11 01:00:23] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2005-11-03 22:45:44] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-05-04 23:24:07] peoned at yahoo dot com
without fwrite() it is significantly faster, gives about 5-6 seconds.
But in Perl without print OUT $_; it gives around 1-2 seconds. So it is
still slower in PHP because of fgets().
[2005-05-02 14:25:11] [EMAIL PROTECTED]
Can you try your tests with the fwrite() line commented out?
[2005-04-28 07:30:31] peoned at yahoo dot com
I did an
`echo strlen($line).,;`
Here are the lengths for some of the first few lines:
42,7,18,11,71,13,8,7,42,7,20,11,73,70,68,63,13,8,7
It looks pretty much like this for the rest of the file. Lines between
1 and 100 chars in length.
Note: It isn't the start up cost for sure because I measured the time
just around the while loop with the same results.
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/32806
--
Edit this bug report at http://bugs.php.net/?id=32806edit=1
#41359 [NEW]: wddx_deserialize does not deserialize char codes = 192
From: tim at whiteinteractive dot com Operating system: Mac OS X 10.4 PHP version: 4.4.7 PHP Bug Type: WDDX related Bug description: wddx_deserialize does not deserialize char codes = 192 Description: wddx_deserialize does not deserialize characters above and including decimal 192 correctly. As follows: \xC0 - \x00 \xC1 - \x40 \xC2 - \x80 \xC3 - \xC0 \xC4 - \x3F \xC5 - \x3F .. \xFF - \x3F I have reported this before and it is still not fixed. Reproduce code: --- $x = wddxPacket version='1.0'header/datastringchar code='FF'//string/data/wddxPacket; $s = wddx_deserialize( $x ); var_dump( ord($s) ); Expected result: (int)255 Actual result: -- (int)64 -- Edit bug report at http://bugs.php.net/?id=41359edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41359r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41359r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41359r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41359r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41359r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41359r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41359r=needscript Try newer version:http://bugs.php.net/fix.php?id=41359r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41359r=support Expected behavior:http://bugs.php.net/fix.php?id=41359r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41359r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41359r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41359r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41359r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41359r=dst IIS Stability:http://bugs.php.net/fix.php?id=41359r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41359r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41359r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41359r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41359r=mysqlcfg
#41344 [Opn-Bgs]: Error returning long values in the headers
ID: 41344
Updated by: [EMAIL PROTECTED]
Reported By: zeta2ste2000 at yahoo dot it
-Status: Open
+Status: Bogus
Bug Type: SOAP related
Operating System: HP-UX 11.11
PHP Version: 5.2.2
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.
If you would like to know more about floats and what IEEE
754 is read this:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
Thank you for your interest in PHP.
Previous Comments:
[2007-05-10 07:07:10] zeta2ste2000 at yahoo dot it
Description:
When I have to manage a long number in the header, the __soapCall
function returns a float number in exponential format. The original sent
value can't be retrieved and the returned one is different.
Reproduce code:
---
A Java server sends a sessionID in the header with the following value
: 339051398236687110
This is the client code :
$soapclient-__soapCall('beginSession',$parameters, null, null,
$header);
echo $header[sessionID]; // returns 3.3905139823669E+17 , an
// invalid value for the next call
// and with less digits than required
$strNum = number_format($header[sessionID], 0, , );
echo $strNum; // returns the rounded value
// 339051398236687050 , that is
// different from the original
// 339051398236687110
Expected result:
The header has to contain 339051398236687110
Actual result:
--
The header contain 3.3905139823669E+17
--
Edit this bug report at http://bugs.php.net/?id=41344edit=1
#41345 [Opn-Fbk]: ibase_blob_get bug
ID: 41345
Updated by: [EMAIL PROTECTED]
Reported By: peaktop at inbox dot ru
-Status: Open
+Status: Feedback
Bug Type: InterBase related
Operating System: WinServer 2003 SP1
PHP Version: 5.2.2
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Previous Comments:
[2007-05-10 07:30:43] peaktop at inbox dot ru
Description:
I have problem with Firebird API function ibase_blob_get when trying to
megre from PHP5.2.1 into PHP5.2.2.
What I did do:
1) Download PHP5.2.2
2) Stopping Apache.
3) Rename folder with PHP5.2.1-engine
4) Place PHP5.2.2-engine into folder, where was PHP5.2.1-engine.
5) Copy php.ini from PHP5.2.1 engine to PHP5.2.2
6) Start Apache
The block of code (listed bellow) is not working.
Reproduce code:
---
$db = ibase_connect('127.0.0.1:DB', 'SYSDBA', 'masterkey');
if($db != 0){
$sql = 'SELECT FIRST 1 * FROM TABL$W_MENU_LEFT M WHERE (M.ID =
1)';
$qr = ibase_query($db, $sql);
if($qr != 0){
$row = ibase_fetch_object($qr);
$blob_inf= ibase_blob_info($row-BODY);
$blob_handle = ibase_blob_open($row-BODY);
$out_str.= ibase_blob_get($blob_handle, $blob_inf[0]);
ibase_blob_close($blob_handle);
ibase_free_result($qr);
}
ibase_close($db);
}
Expected result:
In PHP5.2.1-engine I had text in browser, which is stored in Firebird
database.
Actual result:
--
Invalid Blob-handle
--
Edit this bug report at http://bugs.php.net/?id=41345edit=1
#41348 [Opn-Bgs]: Compilation failure with oci8 support
ID: 41348 Updated by: [EMAIL PROTECTED] Reported By: clement dot demonchy at bsocom dot com -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Debian Linux Sarge PHP Version: 5.2.2 New Comment: Upgrade to newer Oracle version. Previous Comments: [2007-05-10 11:23:12] clement dot demonchy at bsocom dot com Description: Hello, I get a compilation failure when I try to compile php with oci8 support. The configuration line : ./configure --with-apache=../apache_1.3.37 --with-mysql=/usr/local/mysql --enable-track-vars --enable-inline-optimization --enable-memory-limit --enable-ftp --with-zlib-dir=/usr --with-zlib --with-gd --with-png-dir=/usr --with-jpeg-dir=/usr --with-xml --with-gettext --disable-ipv6 --with-ttf --with-freetype-dir=/usr --with-xml2 --with-libxml2 --with-dom --with-dom-xslt --with-pspell --with-openssl --with-oci8=/home/oracle/product/8.1.7 --with-oracle=/home/oracle/product/8.1.7 --enable-sigchild --with-oci8-instant-client --with-curl The error message during make : /bin/sh /usr/src/php-5.2.2/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/oci8/ -I/usr/src/php-5.2.2/ext/oci8/ -DPHP_ATOM_INC -I/usr/src/php-5.2.2/include -I/usr/src/php-5.2.2/main -I/usr/src/php-5.2.2 -I/usr/include/libxml2 -I/usr/src/php-5.2.2/ext/date/lib -I/usr/include/freetype2 -I/usr/local/mysql/include -I/home/oracle/product/8.1.7/rdbms/public -I/home/oracle/product/8.1.7/rdbms/demo -I/usr/include/pspell -I/usr/src/php-5.2.2/TSRM -I/usr/src/php-5.2.2/Zend-I/usr/include -O3 -c /usr/src/php-5.2.2/ext/oci8/oci8_lob.c -o ext/oci8/oci8_lob.lo /usr/src/php-5.2.2/ext/oci8/oci8_lob.c: In function `php_oci_lob_read': /usr/src/php-5.2.2/ext/oci8/oci8_lob.c:304: error: `OCI_NLS_CHARSET_MAXBYTESZ' undeclared (first use in this function) /usr/src/php-5.2.2/ext/oci8/oci8_lob.c:304: error: (Each undeclared identifier is reported only once /usr/src/php-5.2.2/ext/oci8/oci8_lob.c:304: error: for each function it appears in.) make: *** [ext/oci8/oci8_lob.lo] Error 1 I'm currently using oracle version 8.1.7. Best regards. -- Edit this bug report at http://bugs.php.net/?id=41348edit=1
#41350 [Opn-Asn]: Error in my_thread_global_end()
ID: 41350 Updated by: [EMAIL PROTECTED] Reported By: graham at directhostinguk dot com -Status: Open +Status: Assigned Bug Type: MySQL related Operating System: Windows 2003 PHP Version: 5.2.2 -Assigned To: +Assigned To: georg Previous Comments: [2007-05-10 12:12:10] graham at directhostinguk dot com Description: This closed PHP bug: http://bugs.php.net/bug.php?id=41316 MySQL Bug: http://bugs.mysql.com/bug.php?id=25621 Error in my_thread_global_end(): 1 threads didn't exit I have the same issue even when the script doesn't call any MySQL, but this error only happens when using fast-cgi If I run php 5.2.2 ISAPI the problem goes away. I think this is a php bug It seems to me that the problem lies in the PHP dll php_mysql.dll as it is opening the threads but not telling MySql to close them. -- Edit this bug report at http://bugs.php.net/?id=41350edit=1
#41352 [Opn-Fbk]: Warning: ftp_get() PORT command successful
ID: 41352
Updated by: [EMAIL PROTECTED]
Reported By: guy dot vleugels at kaneka dot be
-Status: Open
+Status: Feedback
Bug Type: FTP related
Operating System: RH9
PHP Version: 5.2.2
New Comment:
Where can we reproduce it?
Previous Comments:
[2007-05-10 13:06:26] guy dot vleugels at kaneka dot be
Description:
After upgrading to PHP 5.2.2 on my RH9-machine the following error
warning occurs on post-script files using ftp_get:
Warning: ftp_get() [function.ftp-get]: PORT command successful
As a result, the post-script file won't be downloaded to my machine.
If I do a downgrade to PHP5.2.2, everything works perfectly.
Reproduce code:
---
$ftpcnn = ftp_connect(ftp-server, 4559);
// login with username and password
$ftprs = ftp_login($ftpcnn, user, passwd);
// check connection
if( (!$ftpcnn) || (!$ftprs) )
{
echo FTP connection has failed!br /;
exit;
}
// Firstly download txt-file
ftp_get( $ftpcnn, /mydir/txtfile, /ftpdir/txtfileonftp, FTP_BINARY
);
// Do some extra stuff ---
// Get the name of the postscript-file
$lines = file( mydir/txtfile );
foreach( $lines as $line )
{
if( strstr($line, !postscript) !== FALSE )// ea. $line =
!postscript:0::docq/doc1764.ps
{
$temp = explode( :, $line );
$psfile = $temp[3];
}
}
// --- End some extra stuff ---
// Code which causes the warning:
// Warning: ftp_get() [function.ftp-get]: PORT command successful.
// Download the ps file
ftp_get( $ftpcnn, /mydir/psfile, $psfile, FTP_BINARY );
// close the connection
ftp_close( $ftpcnn );
Expected result:
// Downloading of a file specified by arguments in ftp_get()
Actual result:
--
Warning: ftp_get() [function.ftp-get]: PORT command successful
File won't be downloaded
--
Edit this bug report at http://bugs.php.net/?id=41352edit=1
#41358 [Asn]: configure cannot determine libcurl's SSL lib as of v7.16.2
ID: 41358 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type:Compile Failure PHP Version: 5CVS-2007-05-10 (CVS) Assigned To: mike New Comment: curl-config? Previous Comments: [2007-05-10 18:21:32] [EMAIL PROTECTED] Description: ext/curl (ZTS) probably needs a runtime check for libcurl's SSL lib. -- Edit this bug report at http://bugs.php.net/?id=41358edit=1
#41343 [Opn-Fbk]: FastCGI Server (Internal Server Error)
ID: 41343
Updated by: [EMAIL PROTECTED]
Reported By: trustpunk at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: CGI related
Operating System: Windows XP
PHP Version: 5.2.2
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
Previous Comments:
[2007-05-10 16:43:39] philip dot iezzi at onlime dot ch
Same problem here, PHP 5.2.2 as CGI crashes all the time.
I have encountered the problem under the following configurations:
Debian Linux (sarge)
PHP/CGI 5.2.2 4.4.7, compiled from sources
web application: SPIP 1.9 CMS
Debian Linux (etch)
PHP/FastCGI(fcgid) 5.2.2, compiled from sources
web application: Roundcube webmail (latest SVN checkout)
Downgrading back to PHP 5.2.1 solved all the issues.
I definitely need to get 5.2.2 running as a serious bug with FastCGI
was fixed (#40286). The current situation is pretty ugly, both versions
of PHP are buggy in their own way under CGI/FastCGI.
Thx!
Philip
[2007-05-10 01:33:11] trustpunk at gmail dot com
Description:
I run the FastCGI server
C:\PHP5\php-cgi.exe -b 127.0.0.1:2700
When it becomes under too much load, it displays an Internal Server
Error.
Reproduce code:
---
This code will cause the FastCGI Server to show an Internal Server
Error.
?php
if (class_exists(COM)) {
$wmi = new COM(WinMgmts:.);
$cpus = $wmi-InstancesOf(Win32_Processor);
$i = 1;
// Use the while loop on PHP 4 and foreach on PHP 5
// while ($cpu = $cpus-Next()) {
foreach ($cpus as $cpu) {
echo pProcessor $i : . $cpu-Name . @ ;
$clockSpeed = $cpu-CurrentClockSpeed;
$cpuLoad = $cpu-LoadPercentage;
echo $clockSpeed . MHz (Load= . $cpuLoad .%)/p;
$i++;
}
$uptime = 0;
$systems = $wmi-InstancesOf(Win32_PerfRawData_PerfOS_System);
// Use the while loop on PHP 4 and foreach on PHP 5
// while ($system = $systems-Next()) {
foreach ($systems as $system) {
$PerfTimeStamp = $system-Timestamp_Object ;
$PerfTimeFreq = $system-Frequency_Object ;
$Counter = $system-SystemUpTime ;
$UptimeInSec = ($PerfTimeStamp - $Counter)/$PerfTimeFreq ;
$uptime = max($uptime, $UptimeInSec);
}
}
else {
return pYour system does not support WMI!/p;
}
?
Expected result:
I expect to see my Processors listed with some useful information.
Actual result:
--
Internal Server Error (500)
--
Edit this bug report at http://bugs.php.net/?id=41343edit=1
#41349 [Opn-Fbk]: $_POST not filled, altough raw POST is available
ID: 41349 Updated by: [EMAIL PROTECTED] Reported By: php at bitrockers dot de -Status: Open +Status: Feedback Bug Type: HTTP related Operating System: Linux Debian Etch PHP Version: 5.2.2 New Comment: From what I can see, it makes difference for Apache. Previous Comments: [2007-05-10 16:44:50] php at bitrockers dot de Could it be a problem that the POST request comes as post. Here an excerpt of our logfile: Customers (not working) request: post /ajax/mypageProfileEdit/? HTTP/1.1 200 99 application/x-www-form-urlencoded; charset=utf-8 148 Request (my IE6, working): POST /ajax/mypageProfileEdit/? HTTP/1.1 200 123 application/x-www-form-urlencoded; charset=utf-8 148 Does it make a difference for PHP if the POST request is lowercase? Apache doesn't seem to have a problem with that. I don't know why the customers IE6 sends XmlHttpRequest as lowercase post? [2007-05-10 15:28:45] php at bitrockers dot de (damn, destroyed the Summary) :) [2007-05-10 15:27:13] php at bitrockers dot de I've actually activated the logging of Content-Type and Content-Length. Now I have to ask the customers, which are having the problems, to try again. As soon as I get the response, I will post the Content-Type of their requests. [2007-05-10 15:07:19] php at bitrockers dot de The Content-Type is application/x-www-form-urlencoded; charset=utf-8 At least that is the content-type from what I see when I do the request in my browsers. Due to the fact that this problem occurs only at a few IE6 installations I'm not absolutely sure that there is something on the client-side which in some way modifies that header before sending it to our server. Is there a way to log the Content-Type of the request in PHP or apache, to make sure that this is not the problem? [2007-05-10 14:56:05] [EMAIL PROTECTED] What is the content type of the request? 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/41349 -- Edit this bug report at http://bugs.php.net/?id=41349edit=1
#41351 [Opn-Fbk]: Fatal error: Invalid opcode 81/16/8
ID: 41351
Updated by: [EMAIL PROTECTED]
Reported By: jonathan dot de dot berdt at howest dot be
-Status: Open
+Status: Feedback
Bug Type: *General Issues
Operating System: linux
PHP Version: 5.2.2
New Comment:
How about you remove those []'s from this:
foreach ($query[] as $qry)
Might actually work..and same for the other foreach.
Previous Comments:
[2007-05-10 12:40:02] jonathan dot de dot berdt at howest dot be
Description:
error thrown on the first 'foreach' command.
server using: php 5.2.1
Reproduce code:
---
$query = array ('table', 'room');
$criteria = array ('table' = array ('subjects', 'teachers', 'groups',
'rooms', 'tableparts'),
'room' = array ('rooms', 'roomtypes', 'roomcapacity',
'roomcomputercapacity', 'roomotherkeywords', 'tableparts'));
foreach ($query[] as $qry)
{
foreach($criteria[$qry][] as $crit)
{
if (isset($_GET['leer_' . $qry . 'query_' . $crit.
'_removekeyword']))
{
unset ($_SESSION['leer_' . $qry . 'query_' . $crit .
'_selectedkeywords']
[$_GET['leer_' . $qry . 'query_' . $crit.
'_removekeyword']]);
}
}
}
Expected result:
this code should process a number of session variables. These variables
have a structured name, and thus the changing parts have been put in
these small arrays.
Actual result:
--
Fatal error: Invalid opcode 81/16/8. in
/var/www/html/dokeos/main/leer/leer.php on line 198
--
Edit this bug report at http://bugs.php.net/?id=41351edit=1
#41236 [Opn-Asn]: regression with SSL connections since fix for #39571
ID: 41236
Updated by: [EMAIL PROTECTED]
Reported By: judas dot iscariote at gmail dot com
-Status: Open
+Status: Assigned
Bug Type: Streams related
Operating System: linux 32/64bit, Win32
PHP Version: 5CVS-2007-04-30 (CVS)
Assigned To: iliaa
Previous Comments:
[2007-05-10 01:08:17] judas dot iscariote at gmail dot com
Ilia sorry, but I dont see why this bug is bogus..
1. there is no way to determine if the stream has gone away, nor it if
is has timeout (socket starts with a 10sec timeout and then I set
socket_set_timeout($j, 5).. but it loops forever..
2. and if is bogus.. why this code works in every single other PHP
version ? it broke only in 5.2.1 !!
did you actually read and try the code above ? :?
[2007-05-09 23:15:35] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
The thing is that the original SSL code was working in an identical
manner.
Adding var_dump() shows that the return value of the
stream_get_meta_data() or feof() did not change.
[2007-04-30 07:20:11] judas dot iscariote at gmail dot com
Description:
Since PHP 5.2.1, our application that has jabber stopped working.all
previuos PHP version works fine, this regression is caused by the fix
for bug #39571,reverting xp_ssl.c to the version shipped with 5.2.0
solves the problem.
Reproduce code:
---
./configure --with-openssl
?php
error_reporting(E_ALL);
$j = fsockopen('ssl://jabber.org', 5223, $errorno, $errorstr, 10);
socket_set_blocking($j, 0);
socket_set_timeout($j, 5);
fwrite($j,?xml version='1.0' encoding='UTF-8' ?);
fwrite($j, stream:stream to='jabber.org' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' version='1.0');
$data = '';
// Wait for a response until timeout is reached
$start = time();
$data = '';
$timeout = 10;
$wait = false;
do {
$read = trim(fread($j, 4096));
$data .= $read;
// ok.. this check aint part of the original code
// that breaks,but check if we timed out of reached eof..anyway..
$foo = stream_get_meta_data($j);
if(feof($j) || $foo['timed_out'] || $foo['eof']) break;
// yeah, we know aint nice, but works in **any** other PHP version.
} while (time() = $start + $timeout ($wait || $data == '' || $read
!= '' || (substr(rtrim($data), -1) != '')));
fclose($j);
var_dump($data);
?
Expected result:
response from the server var_dump'ed as in (all) previous versions
Actual result:
--
Fatal error: Maximum execution time of **30** seconds exceeded...an
xdebug session reveals that the script hang, in a **single** fread()
call
an strace shows something hangs permanently with EAGAIN signal..
(probably the loop in xp_ssl.c from line 398 to 410), note that checking
if has reached EOF or if the stream times out does not help either.
--
Edit this bug report at http://bugs.php.net/?id=41236edit=1
#41359 [Opn-Bgs]: wddx_deserialize does not deserialize char codes = 192
ID: 41359 Updated by: [EMAIL PROTECTED] Reported By: tim at whiteinteractive dot com -Status: Open +Status: Bogus Bug Type: WDDX related Operating System: Mac OS X 10.4 PHP Version: 4.4.7 New Comment: Duplicate of #40080. I have reported this before and it is still not fixed. There is no maintainer for wddx and he/she won't magically appear if you report your problem twice. Previous Comments: [2007-05-10 18:52:47] tim at whiteinteractive dot com Description: wddx_deserialize does not deserialize characters above and including decimal 192 correctly. As follows: \xC0 - \x00 \xC1 - \x40 \xC2 - \x80 \xC3 - \xC0 \xC4 - \x3F \xC5 - \x3F .. \xFF - \x3F I have reported this before and it is still not fixed. Reproduce code: --- $x = wddxPacket version='1.0'header/datastringchar code='FF'//string/data/wddxPacket; $s = wddx_deserialize( $x ); var_dump( ord($s) ); Expected result: (int)255 Actual result: -- (int)64 -- Edit this bug report at http://bugs.php.net/?id=41359edit=1
#41345 [Fbk-Bgs]: ibase_blob_get bug
ID: 41345
Updated by: [EMAIL PROTECTED]
Reported By: peaktop at inbox dot ru
-Status: Feedback
+Status: Bogus
Bug Type: InterBase related
Operating System: WinServer 2003 SP1
PHP Version: 5.2.2
New Comment:
.
Previous Comments:
[2007-05-10 20:04:31] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
[2007-05-10 07:30:43] peaktop at inbox dot ru
Description:
I have problem with Firebird API function ibase_blob_get when trying to
megre from PHP5.2.1 into PHP5.2.2.
What I did do:
1) Download PHP5.2.2
2) Stopping Apache.
3) Rename folder with PHP5.2.1-engine
4) Place PHP5.2.2-engine into folder, where was PHP5.2.1-engine.
5) Copy php.ini from PHP5.2.1 engine to PHP5.2.2
6) Start Apache
The block of code (listed bellow) is not working.
Reproduce code:
---
$db = ibase_connect('127.0.0.1:DB', 'SYSDBA', 'masterkey');
if($db != 0){
$sql = 'SELECT FIRST 1 * FROM TABL$W_MENU_LEFT M WHERE (M.ID =
1)';
$qr = ibase_query($db, $sql);
if($qr != 0){
$row = ibase_fetch_object($qr);
$blob_inf= ibase_blob_info($row-BODY);
$blob_handle = ibase_blob_open($row-BODY);
$out_str.= ibase_blob_get($blob_handle, $blob_inf[0]);
ibase_blob_close($blob_handle);
ibase_free_result($qr);
}
ibase_close($db);
}
Expected result:
In PHP5.2.1-engine I had text in browser, which is stored in Firebird
database.
Actual result:
--
Invalid Blob-handle
--
Edit this bug report at http://bugs.php.net/?id=41345edit=1
#36708 [Opn-Asn]: PDO Extension fails to configure proper makefile
ID: 36708 Updated by: [EMAIL PROTECTED] Reported By: jerome at macsaresexy dot com -Status: Open +Status: Assigned Bug Type: Compile Failure Operating System: Mac OS X 10.4.9 PHP Version: 5.2.1 Assigned To: wez Previous Comments: [2007-05-10 16:21:33] jerome at macsaresexy dot com After some looking into, I reopened this bug after discussing this with mac developers and the fact being stated that OS X has dlopen and friends just like linux. ALso the fact that MOST of the php extensions build fine on OS X except for PDO and maybe one or 2 others. This doesn't seem reasonable to not be able to do, if other extensions can be compiled loaded, why can't PDO. it really limits options like considering Zend Core when you can't install PDO via pecl. [2006-08-24 16:01:46] [EMAIL PROTECTED] Due to the way that loadable modules work on OSX/Darwin, you need to compile the PDO package statically into the PHP core. I've fixed the configure, so it will fail if you try to compile PDO dynamically. [2006-07-18 17:12:21] jerome at macsaresexy dot com I just grabbed PHP 5.2 CVS 200607181630 snapshot and attempted to compile it, PHP itself compiled fine, but PDO still does not generate a proper makefile on Mac OS X. after running the php5.2cvs's phpize on ext/pdo, i did configure then make, and it just immediately thinks it's done like it always has been doing. [2006-07-18 15:43:57] [EMAIL PROTECTED] The next snapshot should be ok. Thanks for the alert. [2006-07-18 15:36:05] jerome at macsaresexy dot com I was unable to try cvs since it failed compiling PHP part way through with: /Users/jerome/Downloads/php5.2-200607181430/Zend/ zend_alloc.c: In function zend_mm_mem_mmap_realloc: /Users/jerome/Downloads/php5.2-200607181430/Zend/ zend_alloc.c:117: error: ret undeclared (first use in this function) /Users/jerome/Downloads/php5.2-200607181430/Zend/ zend_alloc.c:117: error: (Each undeclared identifier is reported only once /Users/jerome/Downloads/php5.2-200607181430/Zend/ zend_alloc.c:117: error: for each function it appears in.) make: *** [Zend/zend_alloc.lo] Error 1 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/36708 -- Edit this bug report at http://bugs.php.net/?id=36708edit=1
#36708 [Asn]: PDO Extension fails to configure proper makefile
ID: 36708 User updated by: jerome at macsaresexy dot com Reported By: jerome at macsaresexy dot com Status: Assigned Bug Type: Compile Failure Operating System: Mac OS X 10.4.9 PHP Version: 5.2.1 Assigned To: wez New Comment: Quick comment, clarification of dlopen() if that applies to this. OS X 10.3.x supposedly has a dl compat layer, where 10.4.x actually has native support for dlopen() and friends. Previous Comments: [2007-05-10 16:21:33] jerome at macsaresexy dot com After some looking into, I reopened this bug after discussing this with mac developers and the fact being stated that OS X has dlopen and friends just like linux. ALso the fact that MOST of the php extensions build fine on OS X except for PDO and maybe one or 2 others. This doesn't seem reasonable to not be able to do, if other extensions can be compiled loaded, why can't PDO. it really limits options like considering Zend Core when you can't install PDO via pecl. [2006-08-24 16:01:46] [EMAIL PROTECTED] Due to the way that loadable modules work on OSX/Darwin, you need to compile the PDO package statically into the PHP core. I've fixed the configure, so it will fail if you try to compile PDO dynamically. [2006-07-18 17:12:21] jerome at macsaresexy dot com I just grabbed PHP 5.2 CVS 200607181630 snapshot and attempted to compile it, PHP itself compiled fine, but PDO still does not generate a proper makefile on Mac OS X. after running the php5.2cvs's phpize on ext/pdo, i did configure then make, and it just immediately thinks it's done like it always has been doing. [2006-07-18 15:43:57] [EMAIL PROTECTED] The next snapshot should be ok. Thanks for the alert. [2006-07-18 15:36:05] jerome at macsaresexy dot com I was unable to try cvs since it failed compiling PHP part way through with: /Users/jerome/Downloads/php5.2-200607181430/Zend/ zend_alloc.c: In function zend_mm_mem_mmap_realloc: /Users/jerome/Downloads/php5.2-200607181430/Zend/ zend_alloc.c:117: error: ret undeclared (first use in this function) /Users/jerome/Downloads/php5.2-200607181430/Zend/ zend_alloc.c:117: error: (Each undeclared identifier is reported only once /Users/jerome/Downloads/php5.2-200607181430/Zend/ zend_alloc.c:117: error: for each function it appears in.) make: *** [Zend/zend_alloc.lo] Error 1 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/36708 -- Edit this bug report at http://bugs.php.net/?id=36708edit=1
#41360 [Opn-Bgs]: always generate new SID
ID: 41360
Updated by: [EMAIL PROTECTED]
Reported By: barton dot tomas at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: windows
PHP Version: 5.2.2
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Your browser does not accept session cookie.
Previous Comments:
[2007-05-10 21:29:36] barton dot tomas at gmail dot com
Description:
After calling session_start() generates two session files, $_SESSION
variable is strored in which SID is forgotten.
Reproduce code:
---
?php
session_start();
echo 'SID:'.session_id();
$_SESSION['a'] = 3;?
plook on a href=another_page.phpnext/a/p
another_page.php
---
?php
session_start();
if (isset($_SESSION['a'])){
echo 'Session var a = ',$_SESSION['a'].'br /';
}else {
echo 'Session is not registered.br /';}
echo 'SID:'.session_id(); ?
Expected result:
SID:gahug37g6ga2e4qjuoo8988d62
look on next
Session is not registered.
SID:5elroalaf46hc4muhle5c18896
--
Edit this bug report at http://bugs.php.net/?id=41360edit=1
#41349 [Opn-Bgs]: $_POST not filled, altough raw POST is available
ID: 41349 Updated by: [EMAIL PROTECTED] Reported By: php at bitrockers dot de -Status: Open +Status: Bogus Bug Type: HTTP related Operating System: Linux Debian Etch PHP Version: 5.2.2 New Comment: Ok, so what's the difference for Apache? I can see it maintains a registry of methods in upper case. Maybe that would save a lot of developers Even if it's really can be worked around in PHP, you still would not be able to use it since it takes a lot of time for a new version to get installed on all servers on this planet. Previous Comments: [2007-05-10 21:58:08] php at bitrockers dot de Ok, so what's the difference for Apache? However... today I discovered that our javascript library calls the XmlHttpRequest with lowercase 'post', and because some weird reasons some IE6 installations doesn't translate that into uppercase 'POST'. So maybe it's not PHP to blame for this, but unfortunately there are a couple of javascript libraries which indeed use 'post' instead of POST (e.g. mootools, prototype). There even were a post on the Webkit-mailinglist about that: http://lists.macosforge.org/pipermail/webkit-unassigned/2006-March/006858.html Therefore, if it's not too much work it would be a good idea to also populate the $_POST variable when the request is 'post'. Maybe that would save a lot of developers which rely on so popular javascript-frameworks like prototype or mootools a lot of headaches. In the end, of course, it's microsoft bug ( IE6 should have translated post to POST or at least throw an error about that). [2007-05-10 20:23:00] [EMAIL PROTECTED] From what I can see, it makes difference for Apache. [2007-05-10 16:44:50] php at bitrockers dot de Could it be a problem that the POST request comes as post. Here an excerpt of our logfile: Customers (not working) request: post /ajax/mypageProfileEdit/? HTTP/1.1 200 99 application/x-www-form-urlencoded; charset=utf-8 148 Request (my IE6, working): POST /ajax/mypageProfileEdit/? HTTP/1.1 200 123 application/x-www-form-urlencoded; charset=utf-8 148 Does it make a difference for PHP if the POST request is lowercase? Apache doesn't seem to have a problem with that. I don't know why the customers IE6 sends XmlHttpRequest as lowercase post? [2007-05-10 15:28:45] php at bitrockers dot de (damn, destroyed the Summary) :) [2007-05-10 15:27:13] php at bitrockers dot de I've actually activated the logging of Content-Type and Content-Length. Now I have to ask the customers, which are having the problems, to try again. As soon as I get the response, I will post the Content-Type of their requests. 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/41349 -- Edit this bug report at http://bugs.php.net/?id=41349edit=1
#41339 [Bgs]: DomDocument-loadHTML eats HTML without error with multiple meta information
ID: 41339
User updated by: rasch at raschnet dot com
Reported By: rasch at raschnet dot com
Status: Bogus
Bug Type: DOM XML related
Operating System: Ubuntu Linux
PHP Version: 5.2.2
New Comment:
If you can, please take another look at this.
I think parsing the HTML would be above and beyond the bug here.. In
fact, the parser _is_ parsing some of the HTML to get the charset out of
the content-type meta tag. Unfortunately, it seems if the content-type
isn't in the expected format, it's returning nothing. It's not
returning the ill-formed HTML back, but nothing.
If one alters the content-type meta tag to include just one
content-type value it will happily return the html.
Previous Comments:
[2007-05-09 23:40:56] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The parser provided by libXML is not an HTML tag validator, it only
cares about the syntax of tags being valid.
[2007-05-09 15:58:57] rasch at raschnet dot com
Description:
In usage of symfony, our code was mistakenly producing a meta tag with
two content types. However, from what I understand it's not invalid,
but either way PHP falls on this, the DOM parser should return an error.
The current behavior is that PHP returns an empty string when calling
'$dom-saveHTML()' in the code sample below.
Reproduce code:
---
$dom = new DomDocument(1.0, utf-8);
$val =$dom-loadHTML('
html
head
meta http-equiv=Content-Type content=text/html; charset=utf-8,
text/html; charset=utf-8
/head
bodyHello/body/html');
var_dump($val);
print $dom-saveHTML();
print \n^^^ empty string\n;
Expected result:
html
head
meta http-equiv=Content-Type content=text/html; charset=utf-8,
text/html; charset=utf-8
/head
bodypHello/p/body/html
Actual result:
--
bool(true)
// ^^^ empty string
--
Edit this bug report at http://bugs.php.net/?id=41339edit=1
#41343 [Fbk-Opn]: FastCGI Server (Internal Server Error)
ID: 41343
User updated by: trustpunk at gmail dot com
Reported By: trustpunk at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: CGI related
Operating System: Windows XP
PHP Version: 5.2.2
New Comment:
I really do apologize for this but it seems that I'm longer having this
problem. I downloaded PHP 5.2.2 again and now the problem went away. I
don't have any backtrace created but if the problem happens again, I
will let you know.
Kind regards, Josh
Previous Comments:
[2007-05-10 20:20:19] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
[2007-05-10 16:43:39] philip dot iezzi at onlime dot ch
Same problem here, PHP 5.2.2 as CGI crashes all the time.
I have encountered the problem under the following configurations:
Debian Linux (sarge)
PHP/CGI 5.2.2 4.4.7, compiled from sources
web application: SPIP 1.9 CMS
Debian Linux (etch)
PHP/FastCGI(fcgid) 5.2.2, compiled from sources
web application: Roundcube webmail (latest SVN checkout)
Downgrading back to PHP 5.2.1 solved all the issues.
I definitely need to get 5.2.2 running as a serious bug with FastCGI
was fixed (#40286). The current situation is pretty ugly, both versions
of PHP are buggy in their own way under CGI/FastCGI.
Thx!
Philip
[2007-05-10 01:33:11] trustpunk at gmail dot com
Description:
I run the FastCGI server
C:\PHP5\php-cgi.exe -b 127.0.0.1:2700
When it becomes under too much load, it displays an Internal Server
Error.
Reproduce code:
---
This code will cause the FastCGI Server to show an Internal Server
Error.
?php
if (class_exists(COM)) {
$wmi = new COM(WinMgmts:.);
$cpus = $wmi-InstancesOf(Win32_Processor);
$i = 1;
// Use the while loop on PHP 4 and foreach on PHP 5
// while ($cpu = $cpus-Next()) {
foreach ($cpus as $cpu) {
echo pProcessor $i : . $cpu-Name . @ ;
$clockSpeed = $cpu-CurrentClockSpeed;
$cpuLoad = $cpu-LoadPercentage;
echo $clockSpeed . MHz (Load= . $cpuLoad .%)/p;
$i++;
}
$uptime = 0;
$systems = $wmi-InstancesOf(Win32_PerfRawData_PerfOS_System);
// Use the while loop on PHP 4 and foreach on PHP 5
// while ($system = $systems-Next()) {
foreach ($systems as $system) {
$PerfTimeStamp = $system-Timestamp_Object ;
$PerfTimeFreq = $system-Frequency_Object ;
$Counter = $system-SystemUpTime ;
$UptimeInSec = ($PerfTimeStamp - $Counter)/$PerfTimeFreq ;
$uptime = max($uptime, $UptimeInSec);
}
}
else {
return pYour system does not support WMI!/p;
}
?
Expected result:
I expect to see my Processors listed with some useful information.
Actual result:
--
Internal Server Error (500)
--
Edit this bug report at http://bugs.php.net/?id=41343edit=1
#26004 [Com]: $_POST variables not set when using enctype=multipart/form-data
ID: 26004 Comment by: no_patience at hotmail dot com Reported By: jacknorton101 at hotmail dot com Status: No Feedback Bug Type: *General Issues Operating System: RedHat Linux 9 PHP Version: 4.3.3 New Comment: I worked around this injecting the values I wanted into the forms action statement and using $_GET to extract these values, the file uploading part then extracts its informaion from the POST part. I was also seeing this happening with both IE and FF Previous Comments: [2007-05-10 08:47:07] dlodhia at yahoo dot com hi, having same problem. This is working fine with FF, but not with IE. If its working fine with FF, it could not be problem with PHP.INI or HTTD.CONF. any suggestion what could be the reason? [2006-08-10 06:25:06] cometfish at hotmail dot com Hi, I had this same problem. I spent hours searching the web, but found nothing except this: -- from http://www.php.net/manual/en/features.file-upload.php jason 09-Jan-2006 05:08 Regarding empty $_FILES and $_POST arrays when uploading files larger than post_max_size: Tucked away in http://us3.php.net/manual/en/ini.core.php#ini.post-max-size is this nugget: If the size of post data is greater than post_max_size, the $_POST and $_FILES superglobals are empty. This can be tracked in various ways, e.g. by passing the $_GET variable to the script processing the data, i.e. form action=edit.php?processed=1, and then checking if $_GET['processed'] is set. This may seem like a bug. You'd expect something like UPLOAD_ERR_FORM_SIZE to be set. But you just two empty superglobals. I've seen it submitted to bugs.php.net twice and it's been marked as bogus both times. I saw this, and realised that my MAX_FILE_SIZE hidden form element was missing. Inserting this fixed the problem immediately. My PHP version is 4.4.2. Hope this helps. [2006-05-11 21:24:50] hostgeekz at gmail dot com I am having this issue on PHP 5.0.4, and PHP 5.1.4 Exactly the same as stated above, enctype=multipart/form-data [2006-04-07 08:07:58] timecop at gmail dot com Yes this is still valid. whats worse, if enctype=multipart/form-data, NONE of the variables make it into $_POST. PHP 5.1.2 / linux [2003-11-03 14:06:54] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/26004 -- Edit this bug report at http://bugs.php.net/?id=26004edit=1
#41361 [NEW]: shell_exec() does not find binaries
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 5CVS-2007-05-11 (CVS) PHP Bug Type: Program Execution Bug description: shell_exec() does not find binaries Description: [EMAIL PROTECTED] ~ % cat test.php ?php shell_exec(php -v); [EMAIL PROTECTED] ~ % which php /usr/local/php-5.2/bin/php [EMAIL PROTECTED] ~ % php -v PHP 5.2.3-dev (cli) (built: May 11 2007 05:52:31) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with Xdebug v2.0.0RC4-dev, Copyright (c) 2002, 2003, 2004, 2005, 2006, 2007, by Derick Rethans [EMAIL PROTECTED] ~ % php test.php sh: php: not found [EMAIL PROTECTED] ~ % vim test.php [EMAIL PROTECTED] ~ % cat test.php ?php shell_exec(/usr/local/php-5.2/bin/php -v); [EMAIL PROTECTED] ~ % php test.php Reproduce code: --- ?php shell_exec(php -v); Expected result: No output. Actual result: -- sh: php: not found -- Edit bug report at http://bugs.php.net/?id=41361edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41361r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41361r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41361r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41361r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41361r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41361r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41361r=needscript Try newer version:http://bugs.php.net/fix.php?id=41361r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41361r=support Expected behavior:http://bugs.php.net/fix.php?id=41361r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41361r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41361r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41361r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41361r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41361r=dst IIS Stability:http://bugs.php.net/fix.php?id=41361r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41361r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41361r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41361r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41361r=mysqlcfg
