#42505 [NEW]: new sendmail default breaks NetWare platform
From: gk at gknw dot de Operating system: NetWare PHP version: 5.2.4 PHP Bug Type: Mail related Bug description: new sendmail default breaks NetWare platform Description: The recent commit to ./main/main.c by johannes (Revision 1.640.2.23.2.43 and 1.640.2.23.2.50) breaks NetWare internal mail functionality; IMO the preprocessor ifdefs are totally bogus; I think this patch is a more accurate way to express it, and restores previous default for NetWare platform (+ adds a comment): --- main.c.orig Fri Aug 03 03:30:22 2007 +++ main.c Fri Aug 31 23:46:21 2007 @@ -333,10 +333,10 @@ # define PHP_SAFE_MODE_EXEC_DIR "" #endif -#if defined(PHP_PROG_SENDMAIL) && !defined(NETWARE) -# define DEFAULT_SENDMAIL_PATH PHP_PROG_SENDMAIL " -t -i " -#elif defined(PHP_WIN32) +#if defined(PHP_WIN32) || defined(NETWARE) /* Win32 and NetWare use internal mail */ # define DEFAULT_SENDMAIL_PATH NULL +#elif defined(PHP_PROG_SENDMAIL) +# define DEFAULT_SENDMAIL_PATH PHP_PROG_SENDMAIL " -t -i " #else # define DEFAULT_SENDMAIL_PATH "/usr/sbin/sendmail -t -i" #endif please fix that soon! Thanks! Reproduce code: --- Expected result: sendmail_path = no value Actual result: -- sendmail_path = sendmail -t -i -- Edit bug report at http://bugs.php.net/?id=42505&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42505&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42505&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42505&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42505&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42505&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42505&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42505&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42505&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42505&r=support Expected behavior:http://bugs.php.net/fix.php?id=42505&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42505&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42505&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42505&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42505&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42505&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42505&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42505&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42505&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42505&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42505&r=mysqlcfg
#42496 [Opn]: cursor is not closed when using 2 clobs in a select query
ID: 42496
User updated by: iddekingej at lycos dot com
Reported By: iddekingej at lycos dot com
Status: Open
Bug Type: OCI8 related
Operating System: win 2000
PHP Version: 5.2.4
New Comment:
Sorry "$l_cnt=0" is missing from the code. It should read:
$l_res=oci_new_connect("","","");
oci_execute($l_st);
$l_cnt=0;
while(1){
$l_cnt++;
$l_st=oci_parse($l_res,"select * from tblDocuments where
id=$l_cnt ");
oci_execute($l_st);
$l_row=oci_fetch_row($l_st);
oci_free_statement($l_st);
echo $l_cnt,':';print_r($l_row);
}
Previous Comments:
[2007-08-31 15:46:25] iddekingej at lycos dot com
Description:
When a query contains 2 clob fields then the cursor is not closed after
oci_free_statement.
I run the attached script with the following table
tblDocuments
(id number
,v1 clob
,v2 clob
)
After a while the script gives a ora-01000 (maximum number of open
cursors).
When tblDocuments contains only one clob field, the script keeps
running fine.
I can monitor opencursors with the following script:
select a.value, s.username, s.sid, s.serial#
from v$sesstat a, v$statname b, v$session s
where a.statistic# = b.statistic# and s.sid=a.sid
and b.name = 'opened cursors current
When I monitor the script and tblDocuments has 2 clobs, the opencursor
increases until maximum number of cursors is reached and the script
failes with a ora -0100.
When I momitor the script and tblDocument has 1 clob, the number of
script stays about the same.
The versions are
Windows 2000 server
Oracle 10.2.0.2 on the same machine
PHP 5.2.4 (File downloaded from php site)
Apache 2.2
Maximum number of cursors is 500
Version 5.2.2 and 5.2.3 has the same problem.
When I enable debug I get the following information
OCI8 DEBUG: OCIHandleAlloc at (ext\oci8\oci8_statement.c:61)
OCI8 DEBUG: OCIStmtPrepare2 at (ext\oci8\oci8_statement.c:77)
OCI8 DEBUG: OCIAttrSet at (ext\oci8\oci8_statement.c:135)
OCI8 DEBUG: OCIAttrSet at (ext\oci8\oci8_statement.c:144)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:418)
OCI8 DEBUG: OCIStmtExecute at (ext\oci8\oci8_statement.c:442)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:471)
OCI8 DEBUG: OCIParamGet at (ext\oci8\oci8_statement.c:491)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:500)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:510)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:520)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:530)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:543)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:553)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:563)
OCI8 DEBUG: OCIDescriptorFree at (ext\oci8\oci8_statement.c:571)
OCI8 DEBUG: OCIDefineByPos at (ext\oci8\oci8_statement.c:694)
OCI8 DEBUG: OCIParamGet at (ext\oci8\oci8_statement.c:491)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:500)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:510)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:520)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:530)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:543)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:553)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:563)
OCI8 DEBUG: OCIDescriptorFree at (ext\oci8\oci8_statement.c:571)
OCI8 DEBUG: OCIDefineByPos at (ext\oci8\oci8_statement.c:676)
OCI8 DEBUG: OCIDefineDynamic at (ext\oci8\oci8_statement.c:719)
OCI8 DEBUG: OCIParamGet at (ext\oci8\oci8_statement.c:491)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:500)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:510)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:520)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:530)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:543)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:553)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:563)
OCI8 DEBUG: OCIDescriptorFree at (ext\oci8\oci8_statement.c:571)
OCI8 DEBUG: OCIDefineByPos at (ext\oci8\oci8_statement.c:676)
OCI8 DEBUG: OCIDefineDynamic at (ext\oci8\oci8_statement.c:719)
OCI8 DEBUG: OCIStmtFetch at (ext\oci8\oci8_statement.c:168)
OCI8 DEBUG: OCIStmtRelease at (ext\oci8\oci8_statement.c:746)
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8_statement.c:757)
OCI8 DEBUG: OCISessionEnd at (ext\oci8\oci8.c:1523)
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:1527)
OCI8 DEBUG: OCIServerDetach at (ext\oci8\oci8.c:1531)
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:1535)
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:1539)
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:1543)
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:1547)
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:461)
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:466)
Reproduce code:
---
$l_res=oci_new_connect("","","");
oci_e
#42490 [Opn]: PHP will not compile with BIND 9 installed
ID: 42490 User updated by: jerry at scene-naturally dot dyndns dot org Reported By: jerry at scene-naturally dot dyndns dot org Status: Open Bug Type: Compile Failure Operating System: OS X 10.4.10 -PHP Version: 5.2.4RC3 +PHP Version: 5.2.4 New Comment: The same compile failure as noted in the previous comments about 5.2.4RC3 is also true in the final 5.2.4. The release will not compile, failing with the error: /usr/bin/ld: Undefined symbols: _res_nclose _res_ninit _res_nmkquery _res_nsend collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 but does find the necessary symbols when the Configure app is checking things over: checking if your OS can spawn processes with inherited handles... yes checking for res_nmkquery... no checking for __res_nmkquery... no checking for res_nmkquery in -lresolv... no checking for __res_nmkquery in -lresolv... no checking for res_nmkquery in -lbind... no checking for __res_nmkquery in -lbind... yes checking for res_nsend... no checking for __res_nsend... yes checking for dn_expand... yes Note: the library libbind.a does have the symbols. Previous Comments: [2007-08-31 15:28:13] jerry at scene-naturally dot dyndns dot org OS X does come with BIND (and it is almost ready to go out of the box) but it has a different set up. The libraries are /usr/lib/libresolv.9.dylib /usr/lib/libresolv.dylib The header file is /usr/include/resolv.h Note: The Developer Tools which you install to have compilers, etc also has the resolv.h file. The only libbind*.* libraries I have are from the BIND 9 installation. Linking the older header file to the new file does not fix things. [2007-08-31 07:05:29] [EMAIL PROTECTED] You must have old libbind.* somewhere in your system which gets picked instead of the new one. Didn't you uninstall the old one before you installed the new one, apparently with different install prefix..? [2007-08-30 21:22:20] jerry at scene-naturally dot dyndns dot org The libraries installed by BIND 9 are libbind9.a libbind.a These are in /usr/local/lib libbind.a does seem to have the symbols, however, libbind9.a does not have these missing symbols. The path /usr/local/lib IS in LD_LIBRARY_PATH The configure app is finding either the library or the header file, but apparently not completely following though on that; the screen echo: checking if your OS can spawn processes with inherited handles... yes checking for res_nmkquery... no checking for __res_nmkquery... no checking for res_nmkquery in -lresolv... no checking for __res_nmkquery in -lresolv... no checking for res_nmkquery in -lbind... no checking for __res_nmkquery in -lbind... yes checking for res_nsend... no checking for __res_nsend... yes checking for dn_expand... yes This is in the configure.log as well. A small part of libbind.a: [2007-08-30 20:21:16] [EMAIL PROTECTED] Where is the library located containing those symbols (can't remember what it was called :) and is the path to that library in LD_LIBRARY_PATH? [2007-08-30 18:15:25] jerry at scene-naturally dot dyndns dot org Description: 1) Compiling fails for various version of PHP 5. It has been suggested to install BIND 8 over the BIND 9 installation, compile PHP and then re-install BIND 9. Not very elegant, but it might work if the older BIND were available. This has become a bigger problem because BIND 8 was declared EOL as of August 27, (no more support either) and the links to the older software were removed from the ISC site. http://www.isc.org/index.pl 2) In comparison, this next one is far more minor, but still a problem: If there are multiple versions of Berkeley DB installed (say 4.1 -- 4.6) Config picks up the older (lowered numbered) version instead o the newest version. The various Makefiles, etc. have to be hand-edited to replace the occurrences of say db-4.5 with db-4.6 Reproduce code: --- Compile fails regardless of using a simple ./configure make or a full ./configure options options ... options make 2) Expected result: The usual line saying to the effect that the compile was successful and reminding the user to run 'make test'. Actual result: -- /usr/bin/ld: Undefined symbols: _res_nclose _res_ninit _res_nmkquery _res_nsend collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 -- Edit this bug report at http://bugs.php.net/?id=42490&edit=1
#42497 [Opn]: fgets causes PHP hang on socket file pointer
ID: 42497
User updated by: donald at designknights dot com
-Summary: php hangs when using fgets with a socket
Reported By: donald at designknights dot com
Status: Open
Bug Type: Network related
Operating System: SUSE linux 10.1
PHP Version: 5.2.4
New Comment:
i have stream_set_blocking = 1 and used stream_get_line instead of
fgets
this seems to have solved the race condition.
Previous Comments:
[2007-08-31 15:51:30] donald at designknights dot com
Description:
this is a script to connect to a pop3 server and parse emails.
$connection = fsockopen($popServer, $port, $error ,$string ,$timeout);
$response = fgets($connection, $buffer);
$newLine = "\r\n";
$localhost = "www.designknights.com";
if(empty($connection)) {
echo "Failed to connect: $response";
exit;
}
else {
$logArray['connection'] = "Connected to: $response";
}
echo "sending username";
ob_flush();
flush();
fputs($connection, "USER $username". $newLine);
$response = fgets($connection, $buffer);
$logArray['userresponse'] = "$response";
fputs($connection, "PASS $password". $newLine);
$response = fgets($connection, $buffer);
$logArray['passresponse'] = "$response";
if (substr($response,0,3)!="+OK"){
echo "Mail server said: ".$response;
exit;
}
fputs($connection,"LIST".$newLine);
$msg_array = array();
$response = fgets($connection,$buffer);
$logArray['listresponse'] = "$response";
$messages = explode(" ",$response);
$nummessages = $messages['1'];
echo "number of messages =".$nummessages;
stream_set_blocking($connection,1);
for ($i=1;$i<=$nummessages;$i++){
fputs($connection,"retr ".$i.$newLine,$buffer);
$message = '';
$line = '';
//This loop is where it hangs
while (!feof($connection){
$line = fgets($connection,$buffer);
echo " line = $line";
ob_flush();
flush();
}
$message_blown = explode(":",$message);
echo " message $i = ";
print_r($message_blown);
}
echo "return = ".print_r($messages)."";
print_r($logArray);
fclose($connection);
Reproduce code:
---
See above
Expected result:
It should to my understanding put the lines into the var names $message
then explode that message into $message_blown using : as a separator.
Actual result:
--
it hangs and the max execution time kills php5 while running the
script.
--
Edit this bug report at http://bugs.php.net/?id=42497&edit=1
#41350 [Com]: Error in my_thread_global_end()
ID: 41350 Comment by: phpuser at gmail dot com Reported By: graham at directhostinguk dot com Status: No Feedback Bug Type: MySQL related Operating System: Windows 2003 PHP Version: 5.2.3 Assigned To: scottmac New Comment: Error remains in PHP 5.2.4 Previous Comments: [2007-08-29 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-08-24 17:18:49] acosta at mauricio dot net dot ar Hi, I got this issue with iis 6 in xp os. I install the cvs snapshot you referer, with cgi i got the error, but in isapi appears that it dissapears. [2007-08-22 15:38:56] dj02 dot net at nbl dot fi I updated to: 5.2.4RC3-dev (08-22-2007, SNAP). And libraries are updated. mysql -- MySQL Support enabled Active Persistent Links 0 Active Links0 Client API version 5.0.45 Directive Local Value Master Value mysql.allow_persistent On On mysql.connect_timeout 60 60 mysql.default_host no valueno value mysql.default_password no valueno value mysql.default_port 33063306 mysql.default_socketno valueno value mysql.default_user no valueno value mysql.max_links Unlimited Unlimited mysql.max_persistentUnlimited Unlimited mysql.trace_modeOff Off mysqli -- MysqlI Support enabled Client API library version 5.0.45 Client API header version 5.0.45 MYSQLI_SOCKET /tmp/mysql.sock Directive Local Value Master Value mysqli.default_host no valueno value mysqli.default_port 33063306 mysqli.default_pw no valueno value mysqli.default_socket no valueno value mysqli.default_user no valueno value mysqli.max_linksUnlimited Unlimited mysqli.reconnectOff Off [2007-08-22 01:38:45] ng dot sick dot no at gmail dot com Looks like for some reason, the Client API library version of the snap is 5.0.24. PHP Version 5.2.4RC3-dev Build Date Aug 21 2007 20:03:47 Loaded Configuration File C:\php\php.ini mysql MySQL Support enabled Active Persistent Links 0 Active Links 0 Client API version 5.0.24 Directive Local Value Master Value mysql.allow_persistent On On mysql.connect_timeout 60 60 mysql.default_host no value no value mysql.default_password no value no value mysql.default_port no value no value mysql.default_socket no value no value mysql.default_user no value no value mysql.max_links Unlimited Unlimited mysql.max_persistent Unlimited Unlimited mysql.trace_mode Off Off mysqli MysqlI Support enabled Client API library version 5.0.24 Client API header version 5.0.45 MYSQLI_SOCKET /tmp/mysql.sock Directive Local Value Master Value mysqli.default_host no value no value mysqli.default_port 3306 3306 mysqli.default_pw no value no value mysqli.default_socket no value no value mysqli.default_user no value no value mysqli.max_links Unlimited Unlimited mysqli.reconnect Off Off [2007-08-21 16:37:41] [EMAIL PROTECTED] Does your phpinfo show 5.2.3 or 5.2.4-RC2? The MySQL library version looks correct but the code to correctly use the library wasn't added until after 5.2.3 was released. 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/41350 -- Edit this bug report at http://bugs.php.net/?id=41350&edit=1
#42503 [Bgs]: switch case matching
ID: 42503
Updated by: [EMAIL PROTECTED]
Reported By: aya at eh dot org
Status: Bogus
Bug Type: Feature/Change Request
Operating System: Irrelevant
PHP Version: 5.2.4
New Comment:
(strict checking would break billions of scripts out there, so this
wont change)
Previous Comments:
[2007-08-31 18:15:14] [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
switch/case doesn't do strict checks
[2007-08-31 18:08:01] aya at eh dot org
Description:
What are the chances of changing the way in which switch case-matching
works, from a '=='-equivalent to a '==='-equivalent?
Alternatively, how about a huge warning on the manual page for the
switch statement for people who might reasonably expect that the
attached code would act in a sane fashion?
Reproduce code:
---
switch (null)
{
case 0:
echo "PHP case-matching is brain-damaged.\n";
break;
case null:
echo "PHP case-matching is sane.\n";
break;
}
Expected result:
PHP case-matching is sane.
Actual result:
--
PHP case-matching is brain-damaged.
--
Edit this bug report at http://bugs.php.net/?id=42503&edit=1
#42503 [Opn->Bgs]: switch case matching
ID: 42503
Updated by: [EMAIL PROTECTED]
Reported By: aya at eh dot org
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: Irrelevant
PHP Version: 5.2.4
New Comment:
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
switch/case doesn't do strict checks
Previous Comments:
[2007-08-31 18:08:01] aya at eh dot org
Description:
What are the chances of changing the way in which switch case-matching
works, from a '=='-equivalent to a '==='-equivalent?
Alternatively, how about a huge warning on the manual page for the
switch statement for people who might reasonably expect that the
attached code would act in a sane fashion?
Reproduce code:
---
switch (null)
{
case 0:
echo "PHP case-matching is brain-damaged.\n";
break;
case null:
echo "PHP case-matching is sane.\n";
break;
}
Expected result:
PHP case-matching is sane.
Actual result:
--
PHP case-matching is brain-damaged.
--
Edit this bug report at http://bugs.php.net/?id=42503&edit=1
#42162 [Opn->Ver]: The x coordinate disappears from form request
ID: 42162
Updated by: [EMAIL PROTECTED]
Reported By: xoneca+php at gmail dot com
-Status: Open
+Status: Verified
Bug Type: Scripting Engine problem
Operating System: Windows XP SP2
PHP Version: 5.2.3
Previous Comments:
[2007-08-31 16:50:50] xoneca+php at gmail dot com
It happens in both FF2 and IE7.
[2007-08-12 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-08-04 14:28:51] [EMAIL PROTECTED]
Does it happen with any browser? f.e. Firefox?
[2007-08-01 11:29:10] xoneca+php at gmail dot com
I said that submiting a form with an image like this (note the 2nd
index set in the name attribute):
PHP will create:
array(1) {
["image"]=>
array(1) {
[2]=>
string(2) "45"
}
}
Where 45 is the Y coordinate, but PHP forgets to store also the X
coordinate as expected:
array(1) {
["image"]=>
array(2) {
[0]=>
string(2) "45"
[1]=>
string(2) "32"
}
}
But this one (note the index not set in the name attribute):
Will create:
array(1) {
["image"]=>
array(2) {
[0]=>
string(2) "59"
[1]=>
string(2) "22"
}
}
Where 59 is the X coordinate and 22 the Y one.
[2007-08-01 10:50:15] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/42162
--
Edit this bug report at http://bugs.php.net/?id=42162&edit=1
#42501 [Opn]: glob() with GLOB_BRACE using Windows paths
ID: 42501 User updated by: eric at ericmmartin dot com -Summary: glob() with GLOB_BRACE has different results in Windows Reported By: eric at ericmmartin dot com Status: Open Bug Type: Filesystem function related Operating System: Windows XP PHP Version: 5.2.4 New Comment: Updated title Previous Comments: [2007-08-31 18:05:57] eric at ericmmartin dot com Description: glob() with the GLOB_BRACE flag seems to have a bug. I believe that the colon (:) in a pattern in braces, is causing the problem. I tried escaping the colon, but that did not seem to work. Reproduce code: --- Expected result: Array ( [0] => c:/globtest/firstfolder/arrow_down.png [1] => c:/globtest/firstfolder/arrow_off.png [2] => c:/globtest/firstfolder/arrow_up.png [3] => c:/globtest/secondfolder/arrow_down.png [4] => c:/globtest/secondfolder/arrow_off.png [5] => c:/globtest/secondfolder/arrow_up.png ) Array ( [0] => c:/globtest/firstfolder/arrow_down.png [1] => c:/globtest/firstfolder/arrow_off.png [2] => c:/globtest/firstfolder/arrow_up.png [3] => c:/globtest/secondfolder/arrow_down.png [4] => c:/globtest/secondfolder/arrow_off.png [5] => c:/globtest/secondfolder/arrow_up.png ) Actual result: -- Array ( ) Array ( [0] => c:/globtest/firstfolder/arrow_down.png [1] => c:/globtest/firstfolder/arrow_off.png [2] => c:/globtest/firstfolder/arrow_up.png [3] => c:/globtest/secondfolder/arrow_down.png [4] => c:/globtest/secondfolder/arrow_off.png [5] => c:/globtest/secondfolder/arrow_up.png ) -- Edit this bug report at http://bugs.php.net/?id=42501&edit=1
#42503 [NEW]: switch case matching
From: aya at eh dot org
Operating system: Irrelevant
PHP version: 5.2.4
PHP Bug Type: Feature/Change Request
Bug description: switch case matching
Description:
What are the chances of changing the way in which switch case-matching
works, from a '=='-equivalent to a '==='-equivalent?
Alternatively, how about a huge warning on the manual page for the switch
statement for people who might reasonably expect that the attached code
would act in a sane fashion?
Reproduce code:
---
switch (null)
{
case 0:
echo "PHP case-matching is brain-damaged.\n";
break;
case null:
echo "PHP case-matching is sane.\n";
break;
}
Expected result:
PHP case-matching is sane.
Actual result:
--
PHP case-matching is brain-damaged.
--
Edit bug report at http://bugs.php.net/?id=42503&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42503&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42503&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42503&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42503&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42503&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42503&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42503&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42503&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42503&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42503&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42503&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42503&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42503&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42503&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42503&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42503&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42503&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42503&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42503&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42503&r=mysqlcfg
#42502 [NEW]: GCC no longer implements
From: supportnew at byethost dot com
Operating system: debian linux 4
PHP version: 5.2.4
PHP Bug Type: *Compile Issues
Bug description: GCC no longer implements
Description:
When compiling the stable 5.2.4 branch of php the compile process dies at
the same point.
I have tried this on 3 seperate servers (using the different versions of
GCC )
Reproduce code:
---
download stable, configure with
./configure --prefix=/usr/phpapache2
--with-apxs2=/usr/local/apache2/bin/apxs --disable-cgi
--with-config-file-path=/etc/php4/apache --enable-inline-optimization
--enable-memory-limit --disable-debug --disable-rpath --disable-static
--with-layout=GNU --with-pear=/usr/share/php --enable-calendar
--enable-track-vars --enable-trans-sid --enable-bcmath --without-bz2
--disable-ctype --with-iconv --enable-exif --disable-ftp --with-gettext
--enable-mbstring --disable-sockets --disable-wddx --with-xsl
--with-expat-dir=/usr --disable-yp --with-zlib --without-pgsql
--without-openssl --with-zip=/usr --disable-dbx
--with-exec-dir=/usr/lib/php4/libexec --with-mcrypt --without-sybase-ct
--with-mysql=/usr --with-zlib-dir=/usr --with-gd=/usr/local/gd
--with-jpeg-dir=/usr --with-png-dir=/usr --with-xpm-dir=/usr
--with-ttf=shared,/usr --with-t1lib --with-freetype-dir=/usr
--enable-gd-native-ttf --with-sqlite --with-mysqli --with-xsl
--enable-ctype --with-pdo-mysql --without-pdo-sqlite --with-pspell
using
gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
config.log can be found here
http://byet.org/config.log
Expected result:
no errors.
Actual result:
--
In file included from
/root/php-5.2.4/ext/mbstring/oniguruma/regerror.c:37:
/usr/lib/gcc/i486-linux-gnu/4.1.2/include/varargs.h:4:2: error: #error
"GCC no longer implements ."
/usr/lib/gcc/i486-linux-gnu/4.1.2/include/varargs.h:5:2: error: #error
"Revise your code to use ."
/root/php-5.2.4/ext/mbstring/oniguruma/regerror.c: In function
'onig_error_code_to_str':
/root/php-5.2.4/ext/mbstring/oniguruma/regerror.c:196: error: expected
declaration specifiers before 'va_dcl'
/root/php-5.2.4/ext/mbstring/oniguruma/regerror.c:265: error: expected
'=', ',', ';', 'asm' or '__attribute__' before 'OnigUChar'
/root/php-5.2.4/ext/mbstring/oniguruma/regerror.c:271: error: expected
declaration specifiers before 'va_dcl'
/root/php-5.2.4/ext/mbstring/oniguruma/regerror.c:270: error: declaration
for parameter 'fmt' but no such parameter
/root/php-5.2.4/ext/mbstring/oniguruma/regerror.c:269: error: declaration
for parameter 'pat_end' but no such parameter
/root/php-5.2.4/ext/mbstring/oniguruma/regerror.c:268: error: declaration
for parameter 'pat' but no such parameter
/root/php-5.2.4/ext/mbstring/oniguruma/regerror.c:267: error: declaration
for parameter 'enc' but no such parameter
/root/php-5.2.4/ext/mbstring/oniguruma/regerror.c:266: error: declaration
for parameter 'bufsize' but no such parameter
/root/php-5.2.4/ext/mbstring/oniguruma/regerror.c:334: error: expected '{'
at end of input
make: *** [ext/mbstring/oniguruma/regerror.lo] Error 1
--
Edit bug report at http://bugs.php.net/?id=42502&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42502&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42502&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42502&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42502&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42502&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42502&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42502&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42502&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42502&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42502&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42502&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42502&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42502&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42502&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42502&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42502&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42502&r=gnused
Floating point limitations
#42501 [NEW]: glob() with GLOB_BRACE has different results in Windows
From: eric at ericmmartin dot com Operating system: Windows XP PHP version: 5.2.4 PHP Bug Type: Filesystem function related Bug description: glob() with GLOB_BRACE has different results in Windows Description: glob() with the GLOB_BRACE flag seems to have a bug. I believe that the colon (:) in a pattern in braces, is causing the problem. I tried escaping the colon, but that did not seem to work. Reproduce code: --- Expected result: Array ( [0] => c:/globtest/firstfolder/arrow_down.png [1] => c:/globtest/firstfolder/arrow_off.png [2] => c:/globtest/firstfolder/arrow_up.png [3] => c:/globtest/secondfolder/arrow_down.png [4] => c:/globtest/secondfolder/arrow_off.png [5] => c:/globtest/secondfolder/arrow_up.png ) Array ( [0] => c:/globtest/firstfolder/arrow_down.png [1] => c:/globtest/firstfolder/arrow_off.png [2] => c:/globtest/firstfolder/arrow_up.png [3] => c:/globtest/secondfolder/arrow_down.png [4] => c:/globtest/secondfolder/arrow_off.png [5] => c:/globtest/secondfolder/arrow_up.png ) Actual result: -- Array ( ) Array ( [0] => c:/globtest/firstfolder/arrow_down.png [1] => c:/globtest/firstfolder/arrow_off.png [2] => c:/globtest/firstfolder/arrow_up.png [3] => c:/globtest/secondfolder/arrow_down.png [4] => c:/globtest/secondfolder/arrow_off.png [5] => c:/globtest/secondfolder/arrow_up.png ) -- Edit bug report at http://bugs.php.net/?id=42501&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42501&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42501&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42501&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42501&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42501&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42501&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42501&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42501&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42501&r=support Expected behavior:http://bugs.php.net/fix.php?id=42501&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42501&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42501&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42501&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42501&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42501&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42501&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42501&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42501&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42501&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42501&r=mysqlcfg
#42162 [NoF->Opn]: The x coordinate disappears from form request
ID: 42162
User updated by: xoneca+php at gmail dot com
Reported By: xoneca+php at gmail dot com
-Status: No Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: Windows XP SP2
PHP Version: 5.2.3
New Comment:
It happens in both FF2 and IE7.
Previous Comments:
[2007-08-12 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-08-04 14:28:51] [EMAIL PROTECTED]
Does it happen with any browser? f.e. Firefox?
[2007-08-01 11:29:10] xoneca+php at gmail dot com
I said that submiting a form with an image like this (note the 2nd
index set in the name attribute):
PHP will create:
array(1) {
["image"]=>
array(1) {
[2]=>
string(2) "45"
}
}
Where 45 is the Y coordinate, but PHP forgets to store also the X
coordinate as expected:
array(1) {
["image"]=>
array(2) {
[0]=>
string(2) "45"
[1]=>
string(2) "32"
}
}
But this one (note the index not set in the name attribute):
Will create:
array(1) {
["image"]=>
array(2) {
[0]=>
string(2) "59"
[1]=>
string(2) "22"
}
}
Where 59 is the X coordinate and 22 the Y one.
[2007-08-01 10:50:15] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
[2007-07-31 17:32:30] xoneca+php at gmail dot com
Description:
Indexed returns only "Y" value but not "X".
Reproduce code:
---
Expected result:
array(1) {
["image"]=>
array(2) {
["x"]=>
string(1) "3"
["y"]=>
string(1) "2"
}
}
// OR:
array(2) {
["image_x"]=>
array(1) {
[0]=>
int(3)
}
["image_y"]=>
array(1) {
[0]=>
int(2)
}
}
// Or something similar.
Actual result:
--
array(1) {
["image"]=>
array(1) {
string(1) "2"
}
}
--
Edit this bug report at http://bugs.php.net/?id=42162&edit=1
#42496 [NEW]: cursor is not closed when using 2 clobs in a select query
From: iddekingej at lycos dot com
Operating system: win 2000
PHP version: 5.2.4
PHP Bug Type: OCI8 related
Bug description: cursor is not closed when using 2 clobs in a select query
Description:
When a query contains 2 clob fields then the cursor is not closed after
oci_free_statement.
I run the attached script with the following table
tblDocuments
(id number
,v1 clob
,v2 clob
)
After a while the script gives a ora-01000 (maximum number of open
cursors).
When tblDocuments contains only one clob field, the script keeps running
fine.
I can monitor opencursors with the following script:
select a.value, s.username, s.sid, s.serial#
from v$sesstat a, v$statname b, v$session s
where a.statistic# = b.statistic# and s.sid=a.sid
and b.name = 'opened cursors current
When I monitor the script and tblDocuments has 2 clobs, the opencursor
increases until maximum number of cursors is reached and the script failes
with a ora -0100.
When I momitor the script and tblDocument has 1 clob, the number of script
stays about the same.
The versions are
Windows 2000 server
Oracle 10.2.0.2 on the same machine
PHP 5.2.4 (File downloaded from php site)
Apache 2.2
Maximum number of cursors is 500
Version 5.2.2 and 5.2.3 has the same problem.
When I enable debug I get the following information
OCI8 DEBUG: OCIHandleAlloc at (ext\oci8\oci8_statement.c:61)
OCI8 DEBUG: OCIStmtPrepare2 at (ext\oci8\oci8_statement.c:77)
OCI8 DEBUG: OCIAttrSet at (ext\oci8\oci8_statement.c:135)
OCI8 DEBUG: OCIAttrSet at (ext\oci8\oci8_statement.c:144)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:418)
OCI8 DEBUG: OCIStmtExecute at (ext\oci8\oci8_statement.c:442)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:471)
OCI8 DEBUG: OCIParamGet at (ext\oci8\oci8_statement.c:491)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:500)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:510)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:520)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:530)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:543)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:553)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:563)
OCI8 DEBUG: OCIDescriptorFree at (ext\oci8\oci8_statement.c:571)
OCI8 DEBUG: OCIDefineByPos at (ext\oci8\oci8_statement.c:694)
OCI8 DEBUG: OCIParamGet at (ext\oci8\oci8_statement.c:491)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:500)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:510)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:520)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:530)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:543)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:553)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:563)
OCI8 DEBUG: OCIDescriptorFree at (ext\oci8\oci8_statement.c:571)
OCI8 DEBUG: OCIDefineByPos at (ext\oci8\oci8_statement.c:676)
OCI8 DEBUG: OCIDefineDynamic at (ext\oci8\oci8_statement.c:719)
OCI8 DEBUG: OCIParamGet at (ext\oci8\oci8_statement.c:491)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:500)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:510)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:520)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:530)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:543)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:553)
OCI8 DEBUG: OCIAttrGet at (ext\oci8\oci8_statement.c:563)
OCI8 DEBUG: OCIDescriptorFree at (ext\oci8\oci8_statement.c:571)
OCI8 DEBUG: OCIDefineByPos at (ext\oci8\oci8_statement.c:676)
OCI8 DEBUG: OCIDefineDynamic at (ext\oci8\oci8_statement.c:719)
OCI8 DEBUG: OCIStmtFetch at (ext\oci8\oci8_statement.c:168)
OCI8 DEBUG: OCIStmtRelease at (ext\oci8\oci8_statement.c:746)
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8_statement.c:757)
OCI8 DEBUG: OCISessionEnd at (ext\oci8\oci8.c:1523)
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:1527)
OCI8 DEBUG: OCIServerDetach at (ext\oci8\oci8.c:1531)
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:1535)
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:1539)
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:1543)
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:1547)
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:461)
OCI8 DEBUG: OCIHandleFree at (ext\oci8\oci8.c:466)
Reproduce code:
---
$l_res=oci_new_connect("","","");
oci_execute($l_st);
while(1){
$l_cnt++;
$l_st=oci_parse($l_res,"select * from tblDocuments where
id=$l_cnt ");
oci_execute($l_st);
$l_row=oci_fetch_row($l_st);
oci_free_statement($l_st);
echo $l_cnt,':';print_r($l_row);
}
--
Edit bug report at http://bugs.php.net/?id=42496&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42496&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42496&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.ph
#42500 [NEW]: memcmp does not check full array
From: doppelbauer at gmx dot net
Operating system: any
PHP version: 5.2.4
PHP Bug Type: GetImageSize related
Bug description: memcmp does not check full array
Description:
Don't know, if this is a bug in the "getimagesize()" function.
The "php_getimagetype()" compares just 3 bytes of the 4-byte array.
Source code: /ext/standard/image.c
PHPAPI int php_getimagetype(php_stream * stream, char *filetype
TSRMLS_DC)
{
...
PHPAPI const char php_sig_psd[4] = {'8', 'B', 'P', 'S'};
...
} else if (!memcmp(filetype, php_sig_psd, 3)) {
...
}
--
Edit bug report at http://bugs.php.net/?id=42500&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42500&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42500&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42500&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42500&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42500&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42500&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42500&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42500&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42500&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42500&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42500&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42500&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42500&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42500&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42500&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42500&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42500&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42500&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42500&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42500&r=mysqlcfg
#42499 [NEW]: After multi-statement execution via PDO::exec() connection becomes unusable
From: suhachov at gmail dot com
Operating system: FC
PHP version: 5.2.4
PHP Bug Type: PDO related
Bug description: After multi-statement execution via PDO::exec() connection
becomes unusable
Description:
$dbh = PDO('mysql:...',...);
$dbh->exec("SET some_var='value';SET names 'utf8'");
$dbh->query("SELECT NOW()");
# Error: Cannot execute queries while other unbuffered queries are active.
...
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY doesn't help.
I found that in mysql_handle_doer() multi-results aren't freed.
I'm not a MySQL C API professional, but this patch seems to solve this
problem:
--- php-5.1.6/ext/pdo_mysql/mysql_driver.c 2007-08-31 19:47:15.0
+0400
+++ php-5.1.6/ext/pdo_mysql/mysql_driver.c 2007-08-31 19:50:09.0
+0400
@@ -243,36 +243,20 @@
static long mysql_handle_doer(pdo_dbh_t *dbh, const char *sql, long
sql_len TSRMLS_DC)
{
- int ret_val;
pdo_mysql_db_handle *H = (pdo_mysql_db_handle *)dbh->driver_data;
if (mysql_real_query(H->server, sql, sql_len)) {
pdo_mysql_error(dbh);
- ret_val = -1;
+ return -1;
} else {
- // !!
my_ulonglong c = mysql_affected_rows(H->server);
if (c == (my_ulonglong) -1) {
pdo_mysql_error(dbh);
- ret_val = (H->einfo.errcode ? -1 : 0);
+ return (H->einfo.errcode ? -1 : 0);
} else {
- ret_val = c;
- }
+ return c;
}
-
-#if HAVE_MYSQL_NEXT_RESULT
- while (mysql_more_results(H->server)) {
- MYSQL_RES *res;
- if (mysql_next_result(H->server) != 0) {
- break;
}
- res = mysql_store_result(H->server);
- if (res) {
- mysql_free_result(res);
- }
- }
-#endif
- return ret_val;
}
static char *pdo_mysql_last_insert_id(pdo_dbh_t *dbh, const char *name,
unsigned int *len TSRMLS_DC)
--
Edit bug report at http://bugs.php.net/?id=42499&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42499&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42499&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42499&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42499&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42499&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42499&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42499&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42499&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42499&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42499&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42499&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42499&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42499&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42499&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42499&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42499&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42499&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42499&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42499&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42499&r=mysqlcfg
#42498 [NEW]: Memory leak
From: doppelbauer at gmx dot net Operating system: any PHP version: 5.2.4 PHP Bug Type: IMAP related Bug description: Memory leak Description: It seams, there there is a memory leak in "imap_rfc822_parse_adrlist()". A solution would be, to call "mail_free_address()" from the c-client library, after "rfc822_parse_adrlist()". -- Edit bug report at http://bugs.php.net/?id=42498&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42498&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42498&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42498&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42498&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42498&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42498&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42498&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42498&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42498&r=support Expected behavior:http://bugs.php.net/fix.php?id=42498&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42498&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42498&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42498&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42498&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42498&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42498&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42498&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42498&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42498&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42498&r=mysqlcfg
#42497 [NEW]: php hangs when using fgets with a socket
From: donald at designknights dot com
Operating system: SUSE linux 10.1
PHP version: 5.2.4
PHP Bug Type: Network related
Bug description: php hangs when using fgets with a socket
Description:
this is a script to connect to a pop3 server and parse emails.
$connection = fsockopen($popServer, $port, $error ,$string ,$timeout);
$response = fgets($connection, $buffer);
$newLine = "\r\n";
$localhost = "www.designknights.com";
if(empty($connection)) {
echo "Failed to connect: $response";
exit;
}
else {
$logArray['connection'] = "Connected to: $response";
}
echo "sending username";
ob_flush();
flush();
fputs($connection, "USER $username". $newLine);
$response = fgets($connection, $buffer);
$logArray['userresponse'] = "$response";
fputs($connection, "PASS $password". $newLine);
$response = fgets($connection, $buffer);
$logArray['passresponse'] = "$response";
if (substr($response,0,3)!="+OK"){
echo "Mail server said: ".$response;
exit;
}
fputs($connection,"LIST".$newLine);
$msg_array = array();
$response = fgets($connection,$buffer);
$logArray['listresponse'] = "$response";
$messages = explode(" ",$response);
$nummessages = $messages['1'];
echo "number of messages =".$nummessages;
stream_set_blocking($connection,1);
for ($i=1;$i<=$nummessages;$i++){
fputs($connection,"retr ".$i.$newLine,$buffer);
$message = '';
$line = '';
//This loop is where it hangs
while (!feof($connection){
$line = fgets($connection,$buffer);
echo " line = $line";
ob_flush();
flush();
}
$message_blown = explode(":",$message);
echo " message $i = ";
print_r($message_blown);
}
echo "return = ".print_r($messages)."";
print_r($logArray);
fclose($connection);
Reproduce code:
---
See above
Expected result:
It should to my understanding put the lines into the var names $message
then explode that message into $message_blown using : as a separator.
Actual result:
--
it hangs and the max execution time kills php5 while running the script.
--
Edit bug report at http://bugs.php.net/?id=42497&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42497&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42497&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42497&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42497&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42497&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42497&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42497&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42497&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42497&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42497&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42497&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42497&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42497&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42497&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42497&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42497&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42497&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42497&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42497&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42497&r=mysqlcfg
#42490 [Fbk->Opn]: PHP will not compile with BIND 9 installed
ID: 42490 User updated by: jerry at scene-naturally dot dyndns dot org Reported By: jerry at scene-naturally dot dyndns dot org -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: OS X 10.4.10 PHP Version: 5.2.4RC3 New Comment: OS X does come with BIND (and it is almost ready to go out of the box) but it has a different set up. The libraries are /usr/lib/libresolv.9.dylib /usr/lib/libresolv.dylib The header file is /usr/include/resolv.h Note: The Developer Tools which you install to have compilers, etc also has the resolv.h file. The only libbind*.* libraries I have are from the BIND 9 installation. Linking the older header file to the new file does not fix things. Previous Comments: [2007-08-31 07:05:29] [EMAIL PROTECTED] You must have old libbind.* somewhere in your system which gets picked instead of the new one. Didn't you uninstall the old one before you installed the new one, apparently with different install prefix..? [2007-08-30 21:22:20] jerry at scene-naturally dot dyndns dot org The libraries installed by BIND 9 are libbind9.a libbind.a These are in /usr/local/lib libbind.a does seem to have the symbols, however, libbind9.a does not have these missing symbols. The path /usr/local/lib IS in LD_LIBRARY_PATH The configure app is finding either the library or the header file, but apparently not completely following though on that; the screen echo: checking if your OS can spawn processes with inherited handles... yes checking for res_nmkquery... no checking for __res_nmkquery... no checking for res_nmkquery in -lresolv... no checking for __res_nmkquery in -lresolv... no checking for res_nmkquery in -lbind... no checking for __res_nmkquery in -lbind... yes checking for res_nsend... no checking for __res_nsend... yes checking for dn_expand... yes This is in the configure.log as well. A small part of libbind.a: [2007-08-30 20:21:16] [EMAIL PROTECTED] Where is the library located containing those symbols (can't remember what it was called :) and is the path to that library in LD_LIBRARY_PATH? [2007-08-30 18:15:25] jerry at scene-naturally dot dyndns dot org Description: 1) Compiling fails for various version of PHP 5. It has been suggested to install BIND 8 over the BIND 9 installation, compile PHP and then re-install BIND 9. Not very elegant, but it might work if the older BIND were available. This has become a bigger problem because BIND 8 was declared EOL as of August 27, (no more support either) and the links to the older software were removed from the ISC site. http://www.isc.org/index.pl 2) In comparison, this next one is far more minor, but still a problem: If there are multiple versions of Berkeley DB installed (say 4.1 -- 4.6) Config picks up the older (lowered numbered) version instead o the newest version. The various Makefiles, etc. have to be hand-edited to replace the occurrences of say db-4.5 with db-4.6 Reproduce code: --- Compile fails regardless of using a simple ./configure make or a full ./configure options options ... options make 2) Expected result: The usual line saying to the effect that the compile was successful and reminding the user to run 'make test'. Actual result: -- /usr/bin/ld: Undefined symbols: _res_nclose _res_ninit _res_nmkquery _res_nsend collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 -- Edit this bug report at http://bugs.php.net/?id=42490&edit=1
#42488 [Fbk->Opn]: SoapServer reports an encoding error and the error itself breaks
ID: 42488
User updated by: edman007 at edman007 dot com
Reported By: edman007 at edman007 dot com
-Status: Feedback
+Status: Open
Bug Type: SOAP related
Operating System: Linux
PHP Version: 5.2.4
New Comment:
Actually i'm using the snapshot from yesterday (about 12 hours before
the php 5.2.4 release), last night after i submitted the bug something
changed the version to 5.2.4, and i even got my email to prove that i
put the snap down as what i was using in the original report
Operating system: Linux
PHP version: 5CVS-2007-08-30 (snap)
PHP Bug Type: SOAP related
Bug description: SoapServer reports an encoding error and the error
itself breaks
the phpinfo() says its PHP Version 5.2.5-dev
Previous Comments:
[2007-08-31 15:03:56] [EMAIL PROTECTED]
And are you really using PHP 5.2.4 (released yesterday) ?
[2007-08-30 14:15:12] edman007 at edman007 dot com
Description:
when a function passes a string that is not UTF-8 compliant back to
SoapServer as part of a response SoapServer throws and error saying (or
i guess its suppose to) that it could not encode it.
However the error message reports the error message itself, not the
problematic string as the cause of the error, and then finishes off with
a small portion of the problematic string, resulting in a very hard to
understand error message that also does not really say where it failed.
Reproduce code:
---
---client.php--
getBadUTF();
} catch (SoapFault $e){
echo $e->faultstring;
}
?>
---server.php---
addFunction('getBadUTF');
$soap->handle();
?>
---something.wsdl---
http://www.example.com/";
xmlns:soapenc12="http://www.w3.org/2003/05/soap-encoding";
xmlns:tns="http://www.example.com/";
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/";
xmlns:soapenc11="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:soap12="http://www.w3.org/2003/05/soap-envelope";
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";>
http://schemas.xmlsoap.org/soap/http"/>
http://localhost/server.php"/>
Expected result:
SOAP-ERROR: Encoding: string 'stuff"thing'
Actual result:
--
SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR:
Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding:
string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string
'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR:
Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding:
string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string
'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR:
Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding:
string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string
'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR:
Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding:
string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string
'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR:
Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding:
string 'SOAP-ERROR: Encoding: string 'st
--
Edit this bug report at http://bugs.php.net/?id=42488&edit=1
#42214 [Fbk->Opn]: SoapServer sends clients internal PHP errors
ID: 42214
User updated by: stuart dot caie at gmail dot com
Reported By: stuart dot caie at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: SOAP related
Operating System: Ubuntu
PHP Version: 5.2.4RC1
Assigned To: dmitry
New Comment:
Yes, I would like the soap extension to let me hide fatal error
messages. Please add that option, either in code or in the php.ini
I still think PHP itself needs to be fixed so it can continue running
user code after a fatal error. However, that is a bigger change and less
likely to be done. I'll look to see if such a bug is already raised,
otherwise I'll raise that as another bug.
Thanks
Stuart
Previous Comments:
[2007-08-31 12:44:10] [EMAIL PROTECTED]
PHP is not able to execute user-code after a fatal error.
The only thing I can do with this - provide a special SoapServer option
to hide error messages. In this case it always will send
"[SOAP-ENV:Server] Internal error".
Do you like such solution?
[2007-08-05 21:58:46] stuart dot caie at gmail dot com
Description:
When presenting a SOAP API to the general public, I do not want the
text of PHP errors to be send down the wire as "SOAP-ENV;Server" faults.
It's just as embarrassing and as much of a security risk as having the
display_errors INI option turned on - it could reveal exploitable
private implementation details to hostile users.
I would like to catch all PHP errors, log them and instead send the
user a custom SOAP fault which gives them a unique error ID to report
(which matches with my log), but does not reveal the actual PHP error
message.
However,
1. use_soap_error_handler() does nothing. Set it to true, it sends out
SOAP-ENV:Server faults with the PHP error message. Set it to false, it
still sends out SOAP-ENV:Server faults with the PHP error message.
2. User-defined error handlers can't catch E_ERROR, E_PARSE,
E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING, and
most of E_STRICT. Other scripting languages such as Perl (via
$SIG{__DIE__}) or Ruby (via begin/rescue) let user code catch fatal
errors, PHP comes up short.
I'd like you to allow PHP to catch fatal errors in the user defined
error handler. If you won't fix that, please add some kind of kludge to
SoapServer so that it doesn't reveal the text of PHP errors to clients.
Reproduce code:
---
fault('error', "report \"$ticket\" to
support");
}
set_error_handler('error_handler');
use_soap_error_handler(false);
$server = new SoapServer(NULL, array('uri' =>
'http://localhost/server.php'));
$server->setClass('test');
$server->handle();
?>
'http://localhost/server.php', 'location' =>
'http://localhost/server.php'));
$client ->test();
?>
Expected result:
client.php: Uncaught SoapFault exception: [error] report ""
to support
server.php: entry in /tmp/soap_error_log reading:
[] 1: Call to undefined function obvious_error() in
server.php line 4
Actual result:
--
client.php: Uncaught SoapFault exception: [SOAP-ENV:Server] Call to
undefined function obvious_error()
server.php: no entry in /tmp/soap_error_log.
--
Edit this bug report at http://bugs.php.net/?id=42214&edit=1
#42495 [Opn->Bgs]: Failure when compiling with apache2
ID: 42495 Updated by: [EMAIL PROTECTED] Reported By: v_anusuya at hotmail dot com -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Solaris PHP Version: 5.2.4 New Comment: Not PHP bug. You should use all GNU tools, not just GCC but also GNU ld. See also bug #34516 Previous Comments: [2007-08-31 14:05:46] v_anusuya at hotmail dot com Description: I am trying to compile PHP 5.2.4 on a Solaris machine. Apache 2.2.4 is installed (configured with --enable-so tag) on this server. I use the following setting:- bash-2.05# gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2.2/specs Configured with: ../configure --disable-nls --with-ld=/usr/ccs/bin/ld --with-as=/usr/ccs/bin/as Thread model: posix gcc version 3.2.2 bash-2.05# ld -v GNU ld version 2.17 bash-2.05#CC=gcc ./configure --with-apxs2=/usr/local/apache2/bin/apxs When I try to "make" , it errors out with the following message:- ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status make: *** [libphp5.la] Error 1 Expected result: The make process should have completed without any errors. Actual result: -- Last few lines of the output from make process. Text relocation remains referenced against symbol offset in file 0x179c /usr/local/lib/libz.a(inflate.o) 0x17a0 /usr/local/lib/libz.a(inflate.o) 0x17a4 /usr/local/lib/libz.a(inflate.o) 0x17a8 /usr/local/lib/libz.a(inflate.o) 0x17ac /usr/local/lib/libz.a(inflate.o) 0x17b0 /usr/local/lib/libz.a(inflate.o) 0x17b4 /usr/local/lib/libz.a(inflate.o) 0x17b8 /usr/local/lib/libz.a(inflate.o) 0x17bc /usr/local/lib/libz.a(inflate.o) 0x17c0 /usr/local/lib/libz.a(inflate.o) 0x17c4 /usr/local/lib/libz.a(inflate.o) 0x17c8 /usr/local/lib/libz.a(inflate.o) 0x17cc /usr/local/lib/libz.a(inflate.o) 0x17d0 /usr/local/lib/libz.a(inflate.o) 0x17d4 /usr/local/lib/libz.a(inflate.o) 0x17d8 /usr/local/lib/libz.a(inflate.o) 0x17dc /usr/local/lib/libz.a(inflate.o) 0x17e0 /usr/local/lib/libz.a(inflate.o) 0x17e4 /usr/local/lib/libz.a(inflate.o) 0x17e8 /usr/local/lib/libz.a(inflate.o) 0x17ec /usr/local/lib/libz.a(inflate.o) 0x17f0 /usr/local/lib/libz.a(inflate.o) 0x17f4 /usr/local/lib/libz.a(inflate.o) 0x17f8 /usr/local/lib/libz.a(inflate.o) 0x17fc /usr/local/lib/libz.a(inflate.o) 0x1800 /usr/local/lib/libz.a(inflate.o) 0x1804 /usr/local/lib/libz.a(inflate.o) 0x1808 /usr/local/lib/libz.a(inflate.o) 0x180c /usr/local/lib/libz.a(inflate.o) 0x1810 /usr/local/lib/libz.a(inflate.o) 0x40 /usr/local/lib/libz.a(deflate.o) 0x4c /usr/local/lib/libz.a(deflate.o) 0x58 /usr/local/lib/libz.a(deflate.o) 0x64 /usr/local/lib/libz.a(deflate.o) 0x70 /usr/local/lib/libz.a(deflate.o) 0x7c /usr/local/lib/libz.a(deflate.o) 0x88 /usr/local/lib/libz.a(deflate.o) 0x94 /usr/local/lib/libz.a(deflate.o) 0xa0 /usr/local/lib/libz.a(deflate.o) 0xac /usr/local/lib/libz.a(deflate.o) 0x98 /usr/local/lib/libz.a(zutil.o) 0x9c /usr/local/lib/libz.a(zutil.o) 0xa0 /usr/local/lib/libz.a(zutil.o) 0xa4 /usr/local/lib/libz.a(zutil.o) 0xa8 /usr/local/lib/libz.a(zutil.o) 0xac /usr/local/lib/libz.a(zutil.o) 0xb0 /usr/local/lib/libz.a(zutil.o) 0xb4 /usr/local/lib/libz.a(zutil.o) 0x
#42488 [Opn->Fbk]: SoapServer reports an encoding error and the error itself breaks
ID: 42488
Updated by: [EMAIL PROTECTED]
Reported By: edman007 at edman007 dot com
-Status: Open
+Status: Feedback
Bug Type: SOAP related
Operating System: Linux
PHP Version: 5.2.4
New Comment:
And are you really using PHP 5.2.4 (released yesterday) ?
Previous Comments:
[2007-08-30 14:15:12] edman007 at edman007 dot com
Description:
when a function passes a string that is not UTF-8 compliant back to
SoapServer as part of a response SoapServer throws and error saying (or
i guess its suppose to) that it could not encode it.
However the error message reports the error message itself, not the
problematic string as the cause of the error, and then finishes off with
a small portion of the problematic string, resulting in a very hard to
understand error message that also does not really say where it failed.
Reproduce code:
---
---client.php--
getBadUTF();
} catch (SoapFault $e){
echo $e->faultstring;
}
?>
---server.php---
addFunction('getBadUTF');
$soap->handle();
?>
---something.wsdl---
http://www.example.com/";
xmlns:soapenc12="http://www.w3.org/2003/05/soap-encoding";
xmlns:tns="http://www.example.com/";
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/";
xmlns:soapenc11="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:soap12="http://www.w3.org/2003/05/soap-envelope";
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";>
http://schemas.xmlsoap.org/soap/http"/>
http://localhost/server.php"/>
Expected result:
SOAP-ERROR: Encoding: string 'stuff"thing'
Actual result:
--
SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR:
Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding:
string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string
'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR:
Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding:
string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string
'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR:
Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding:
string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string
'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR:
Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding:
string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string
'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR:
Encoding: string 'SOAP-ERROR: Encoding: string 'SOAP-ERROR: Encoding:
string 'SOAP-ERROR: Encoding: string 'st
--
Edit this bug report at http://bugs.php.net/?id=42488&edit=1
#42495 [NEW]: Failure when compiling with apache2
From: v_anusuya at hotmail dot com Operating system: Solaris PHP version: 5.2.4 PHP Bug Type: Compile Failure Bug description: Failure when compiling with apache2 Description: I am trying to compile PHP 5.2.4 on a Solaris machine. Apache 2.2.4 is installed (configured with --enable-so tag) on this server. I use the following setting:- bash-2.05# gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2.2/specs Configured with: ../configure --disable-nls --with-ld=/usr/ccs/bin/ld --with-as=/usr/ccs/bin/as Thread model: posix gcc version 3.2.2 bash-2.05# ld -v GNU ld version 2.17 bash-2.05#CC=gcc ./configure --with-apxs2=/usr/local/apache2/bin/apxs When I try to "make" , it errors out with the following message:- ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status make: *** [libphp5.la] Error 1 Expected result: The make process should have completed without any errors. Actual result: -- Last few lines of the output from make process. Text relocation remains referenced against symbol offset in file 0x179c /usr/local/lib/libz.a(inflate.o) 0x17a0 /usr/local/lib/libz.a(inflate.o) 0x17a4 /usr/local/lib/libz.a(inflate.o) 0x17a8 /usr/local/lib/libz.a(inflate.o) 0x17ac /usr/local/lib/libz.a(inflate.o) 0x17b0 /usr/local/lib/libz.a(inflate.o) 0x17b4 /usr/local/lib/libz.a(inflate.o) 0x17b8 /usr/local/lib/libz.a(inflate.o) 0x17bc /usr/local/lib/libz.a(inflate.o) 0x17c0 /usr/local/lib/libz.a(inflate.o) 0x17c4 /usr/local/lib/libz.a(inflate.o) 0x17c8 /usr/local/lib/libz.a(inflate.o) 0x17cc /usr/local/lib/libz.a(inflate.o) 0x17d0 /usr/local/lib/libz.a(inflate.o) 0x17d4 /usr/local/lib/libz.a(inflate.o) 0x17d8 /usr/local/lib/libz.a(inflate.o) 0x17dc /usr/local/lib/libz.a(inflate.o) 0x17e0 /usr/local/lib/libz.a(inflate.o) 0x17e4 /usr/local/lib/libz.a(inflate.o) 0x17e8 /usr/local/lib/libz.a(inflate.o) 0x17ec /usr/local/lib/libz.a(inflate.o) 0x17f0 /usr/local/lib/libz.a(inflate.o) 0x17f4 /usr/local/lib/libz.a(inflate.o) 0x17f8 /usr/local/lib/libz.a(inflate.o) 0x17fc /usr/local/lib/libz.a(inflate.o) 0x1800 /usr/local/lib/libz.a(inflate.o) 0x1804 /usr/local/lib/libz.a(inflate.o) 0x1808 /usr/local/lib/libz.a(inflate.o) 0x180c /usr/local/lib/libz.a(inflate.o) 0x1810 /usr/local/lib/libz.a(inflate.o) 0x40 /usr/local/lib/libz.a(deflate.o) 0x4c /usr/local/lib/libz.a(deflate.o) 0x58 /usr/local/lib/libz.a(deflate.o) 0x64 /usr/local/lib/libz.a(deflate.o) 0x70 /usr/local/lib/libz.a(deflate.o) 0x7c /usr/local/lib/libz.a(deflate.o) 0x88 /usr/local/lib/libz.a(deflate.o) 0x94 /usr/local/lib/libz.a(deflate.o) 0xa0 /usr/local/lib/libz.a(deflate.o) 0xac /usr/local/lib/libz.a(deflate.o) 0x98 /usr/local/lib/libz.a(zutil.o) 0x9c /usr/local/lib/libz.a(zutil.o) 0xa0 /usr/local/lib/libz.a(zutil.o) 0xa4 /usr/local/lib/libz.a(zutil.o) 0xa8 /usr/local/lib/libz.a(zutil.o) 0xac /usr/local/lib/libz.a(zutil.o) 0xb0 /usr/local/lib/libz.a(zutil.o) 0xb4 /usr/local/lib/libz.a(zutil.o) 0xb8 /usr/local/lib/libz.a(zutil.o) 0xbc /usr/local/lib/libz.a(zutil.o) gzwrite 0xd3c /usr/local/lib/libz.a(gzio.o) gzwrite 0xf50 /usr/local/lib/libz.a(gzio.o) gzwrite 0x1520
#42474 [Opn->Asn]: mssql_fetch_* returns 0 instead of NULL when a bit field is NULL
ID: 42474 Updated by: [EMAIL PROTECTED] Reported By: jpittman2 at gmail dot com -Status: Open +Status: Assigned Bug Type: MSSQL related Operating System: Windows 2003 (5.2) PHP Version: 5.2.3 -Assigned To: +Assigned To: fmk Previous Comments: [2007-08-29 17:47:58] jpittman2 at gmail dot com Description: mssql_fetch_* returns 0 instead of NULL when the datatype is "bit". Reproduce code: --- Expected result: Should return (NULL, 0, 1) Actual result: -- returns (0, 0, 1) -- Edit this bug report at http://bugs.php.net/?id=42474&edit=1
#42492 [Fbk->Opn]: FTP functions apparently use wrong IP address for PORT in PASV mode
ID: 42492
User updated by: php at stock-consulting dot com
Reported By: php at stock-consulting dot com
-Status: Feedback
+Status: Open
Bug Type: FTP related
Operating System: Windows 2000
PHP Version: 5.2.4
New Comment:
Yes, defnitely, I just downloaded it...yesterday? F***! ***! *** ** *
! Just checked it (php.exe -v). It's PHP 5.2.3. Okay. Sorry.
Upgraded to 5.2.4 now, checked (php.exe -v), yup, now I'm at 5.2.4!
Yup. I can confirm the bug in 5.2.4 as well. The warning is now:
Warning: ftp_get(): PORT command only accepts client IP address
(80.x.x.x!=
10.0.0.1). in my_script.php on line 71
Best regards, Klaus
Previous Comments:
[2007-08-31 11:27:49] [EMAIL PROTECTED]
And you're really using PHP 5.2.4?
[2007-08-31 11:15:27] php at stock-consulting dot com
Description:
Situation: the local machine, which executes the PHP script via the
command line, sits behind a NAT firefall and needs to retrieve directory
listings and files from an FTP server sitting somewhere on the Internet.
Passive FTP is required to traverse the firewall. The local machine has
the IP address 10.0.0.1 (subnet configured as Class C). The external
(WAN) IP of the router/firewall is 80.x.x.x (address partially concealed
to protect the, erm, innocent).
Now the problem: the script correctly connects to the FTP server and
begins to retrieve directory listings (recursively) and files. At some
RANDOM point, the following warning appears:
Warning: ftp_chdir(): PORT command only accepts client IP address
(80.x.x.x
!=10.0.0.1). in my_script.php on line 40
This warning then appears both at all further attempts to retrieve
directory listings and files. The transfers are not successful.
Note that directory and file retrieval works perfectly UNTIL the
warning occurs for the first time, at some random time. When the script
is restarted, it will again work for some listings and files, until, at
some different point, the warning will appear again.
Reproduce code:
---
// Short version, stripped from anything which appeared not so useful
for this bug report
function remote_scan($path) {
global $ftp;
ftp_chdir($ftp, $path);
$raw_entries = ftp_rawlist($ftp, $path);
foreach ($raw_entries AS $line) {
$entry = preg_split('@\s+@', $line, 9);
if ($entry[4] == 0) {
remote_scan($path . $entry[8] . '/');
} else {
ftp_get($ftp, 'x:/local_path' . $path . $entry[8],
$path .
$entry[8], FTP_BINARY);
}
}
}
$ftp = ftp_connect('ftp.url', 47624); // server uses non-standard port
$login_result = ftp_login($ftp, 'user', 'password');
ftp_pasv($ftp, true);
remote_scan('/');
ftp_close($ftp);
--
Edit this bug report at http://bugs.php.net/?id=42492&edit=1
#42214 [Asn->Fbk]: SoapServer sends clients internal PHP errors
ID: 42214
Updated by: [EMAIL PROTECTED]
Reported By: stuart dot caie at gmail dot com
-Status: Assigned
+Status: Feedback
Bug Type: SOAP related
Operating System: Ubuntu
PHP Version: 5.2.4RC1
Assigned To: dmitry
New Comment:
PHP is not able to execute user-code after a fatal error.
The only thing I can do with this - provide a special SoapServer option
to hide error messages. In this case it always will send
"[SOAP-ENV:Server] Internal error".
Do you like such solution?
Previous Comments:
[2007-08-05 21:58:46] stuart dot caie at gmail dot com
Description:
When presenting a SOAP API to the general public, I do not want the
text of PHP errors to be send down the wire as "SOAP-ENV;Server" faults.
It's just as embarrassing and as much of a security risk as having the
display_errors INI option turned on - it could reveal exploitable
private implementation details to hostile users.
I would like to catch all PHP errors, log them and instead send the
user a custom SOAP fault which gives them a unique error ID to report
(which matches with my log), but does not reveal the actual PHP error
message.
However,
1. use_soap_error_handler() does nothing. Set it to true, it sends out
SOAP-ENV:Server faults with the PHP error message. Set it to false, it
still sends out SOAP-ENV:Server faults with the PHP error message.
2. User-defined error handlers can't catch E_ERROR, E_PARSE,
E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING, and
most of E_STRICT. Other scripting languages such as Perl (via
$SIG{__DIE__}) or Ruby (via begin/rescue) let user code catch fatal
errors, PHP comes up short.
I'd like you to allow PHP to catch fatal errors in the user defined
error handler. If you won't fix that, please add some kind of kludge to
SoapServer so that it doesn't reveal the text of PHP errors to clients.
Reproduce code:
---
fault('error', "report \"$ticket\" to
support");
}
set_error_handler('error_handler');
use_soap_error_handler(false);
$server = new SoapServer(NULL, array('uri' =>
'http://localhost/server.php'));
$server->setClass('test');
$server->handle();
?>
'http://localhost/server.php', 'location' =>
'http://localhost/server.php'));
$client ->test();
?>
Expected result:
client.php: Uncaught SoapFault exception: [error] report ""
to support
server.php: entry in /tmp/soap_error_log reading:
[] 1: Call to undefined function obvious_error() in
server.php line 4
Actual result:
--
client.php: Uncaught SoapFault exception: [SOAP-ENV:Server] Call to
undefined function obvious_error()
server.php: no entry in /tmp/soap_error_log.
--
Edit this bug report at http://bugs.php.net/?id=42214&edit=1
#42493 [NEW]: odbc_pconnect: persisent connections with different locales
From: dave dot lane at gmx dot net Operating system: Linux PHP version: 5.2.4 PHP Bug Type: ODBC related Bug description: odbc_pconnect: persisent connections with different locales Description: We have an environment where we both use odbc_pconnect and different locales. DB2 recognises the locale and returns data formatted based on this locale. That means when we do a setlocale(LC_ALL, de_DE); before we connect we get float formatted so: 1,235412E+004 and when we do a setlocale(LC_ALL, en_GB); we get float formatted so 1.235412E+004. This works fine when we use odbc_connect. The problem is when we use odbc_pconnect connections are recycled without taking the locale into account. Sometimes we get english when we have set german and vice versa. -- Edit bug report at http://bugs.php.net/?id=42493&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42493&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42493&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42493&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42493&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42493&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42493&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42493&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42493&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42493&r=support Expected behavior:http://bugs.php.net/fix.php?id=42493&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42493&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42493&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42493&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42493&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42493&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42493&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42493&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42493&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42493&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42493&r=mysqlcfg
#42453 [Asn->Csd]: CGI SAPI does not shut down cleanly with -i/-m/-v cmdline options
ID: 42453 Updated by: [EMAIL PROTECTED] Reported By: hans at parse dot nl -Status: Assigned +Status: Closed Bug Type: CGI related Operating System: Linux PHP Version: 5.2.4RC3 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-08-30 06:22:07] schneecrash+php at gmail dot com after applying 'cgi_main.c.patch' from above to latest php52x-branch, i see, % php -v PHP 5.2.4 (cli) (built: Aug 29 2007 18:13:08) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with eAccelerator v0.9.6-dev, Copyright (c) 2004-2007 eAccelerator, by eAccelerator with Xdebug v2.1.0-dev, Copyright (c) 2002, 2003, 2004, 2005, 2006, 2007, by Derick Rethans as before for php(cli). but for php(cgi), i now see, % php-cgi -v PHP 5.2.4 (cgi-fcgi) (built: Aug 29 2007 18:13:31) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies where i do *not* get the, [23661] EACCELERATOR: PHP unclean shutdown but i also am 'missing' the with eAccelerator ... with Xdebug ... where, % php -m | egrep -i "eaccelerator|xdebug" eAccelerator xdebug Xdebug eAccelerator % php-cgi -m | egrep -i "eaccelerator|xdebug" (empty) given, % egrep -i "eaccelerator|xdebug" php-cli.ini zend_extension_ts="/usr/local/lib/php/extensions/no-debug-zts-20060613/eaccelerator.so" zend_extension_ts="/usr/local/lib/php/extensions/no-debug-zts-20060613/xdebug.so" and, % diff -ur php-cgi.ini php-cli.ini % [2007-08-28 11:46:05] [EMAIL PROTECTED] Dmitry, you can commit that patch..or if you don't have time, I can do it. :) [2007-08-28 11:31:55] [EMAIL PROTECTED] I had a discussion with Dmitry a few weeks ago and got directed towards an onexit handler for dealing with module cleanup since my issue was aimed at MySQL on Win32. If other people are having problems then it may be worth while patching it, I've created a patch at http://server.macvicar.net/patches/cgi_main.c.patch [2007-08-28 09:14:20] hans at parse dot nl Description: The CGI SAPI initializes extensions through the regular MINIT/RINIT functions, but lacks a call to php_request_shutdown() for proper extension shutdown on some command line options. This is the case for command line options -v, -i and -m, which call exit(0) without requesting module/extension shutdown first. The CLI SAPI *does* clean up nicely after -v/-i/-m and does not exhibit this behavior. Reproduce code: --- With CGI SAPI: # php-cgi -v PHP 5.2.4RC3 (cgi-fcgi) (built: Aug 27 2007 16:51:33) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with eAccelerator v0.9.6-dev, Copyright (c) 2004-2007 eAccelerator, by eAccelerator [23661] EACCELERATOR: PHP unclean shutdown With CLI SAPI: # php -v PHP 5.2.4RC3 (cli) (built: Aug 27 2007 16:51:49) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with eAccelerator v0.9.6-dev, Copyright (c) 2004-2007 eAccelerator, by eAccelerator Expected result: nice clean shutdown through RSHUTDOWN/MSHUTDOWN. Actual result: -- exit(0) without shutting down modules/extensions -- Edit this bug report at http://bugs.php.net/?id=42453&edit=1
#40694 [Ver->Fbk]: __call() does not allow passing args by reference
ID: 40694
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Verified
+Status: Feedback
Bug Type:Scripting Engine problem
PHP Version: 5CVS-2007-03-02 (CVS)
New Comment:
test(&$v); //NB 2
var_dump($v);
?>
This code results in:
str
5
int(5)
So I believe this report can be closed.
Previous Comments:
[2007-03-02 17:51:47] [EMAIL PROTECTED]
Summary from IRC:
This should be fixable by selectively populating arg_info in
zend_std_get_method() with a structure that turns on the pass rest by
ref flag. That'll tell the macros in zend_vm_def.h to send the
arguments by reference. From there, you might need to modify
zend_std_call_user_call() a little bit where it's building the args
array... (Havn't looked close enough to be sure)
While addressing this, you should look at the return value as well,
again this should be a minor matter of checking the __call
implementation and flipping the return type in zend_std_get_method()...
[2007-03-02 17:27:59] [EMAIL PROTECTED]
Description:
__call() method does not allow specifying the arguments array by
reference. Essentially this means that there is no way to return
modified arguments when using overloading.
Reproduce code:
---
class Foo {
function __call($method, &$args)
{
print $args[0]."\n";
$args[0] = 5;
print $args[0]."\n";
return true;
}
}
$v = 'str';
$o = new Foo();
$o->test($v);
var_dump($v);
Expected result:
str
5
int(5)
Actual result:
--
str
5
string(3) "str"
--
Edit this bug report at http://bugs.php.net/?id=40694&edit=1
#42492 [Opn->Fbk]: FTP functions apparently use wrong IP address for PORT in PASV mode
ID: 42492
Updated by: [EMAIL PROTECTED]
Reported By: php at stock-consulting dot com
-Status: Open
+Status: Feedback
Bug Type: FTP related
Operating System: Windows 2000
PHP Version: 5.2.4
New Comment:
And you're really using PHP 5.2.4?
Previous Comments:
[2007-08-31 11:15:27] php at stock-consulting dot com
Description:
Situation: the local machine, which executes the PHP script via the
command line, sits behind a NAT firefall and needs to retrieve directory
listings and files from an FTP server sitting somewhere on the Internet.
Passive FTP is required to traverse the firewall. The local machine has
the IP address 10.0.0.1 (subnet configured as Class C). The external
(WAN) IP of the router/firewall is 80.x.x.x (address partially concealed
to protect the, erm, innocent).
Now the problem: the script correctly connects to the FTP server and
begins to retrieve directory listings (recursively) and files. At some
RANDOM point, the following warning appears:
Warning: ftp_chdir(): PORT command only accepts client IP address
(80.x.x.x
!=10.0.0.1). in my_script.php on line 40
This warning then appears both at all further attempts to retrieve
directory listings and files. The transfers are not successful.
Note that directory and file retrieval works perfectly UNTIL the
warning occurs for the first time, at some random time. When the script
is restarted, it will again work for some listings and files, until, at
some different point, the warning will appear again.
Reproduce code:
---
// Short version, stripped from anything which appeared not so useful
for this bug report
function remote_scan($path) {
global $ftp;
ftp_chdir($ftp, $path);
$raw_entries = ftp_rawlist($ftp, $path);
foreach ($raw_entries AS $line) {
$entry = preg_split('@\s+@', $line, 9);
if ($entry[4] == 0) {
remote_scan($path . $entry[8] . '/');
} else {
ftp_get($ftp, 'x:/local_path' . $path . $entry[8],
$path .
$entry[8], FTP_BINARY);
}
}
}
$ftp = ftp_connect('ftp.url', 47624); // server uses non-standard port
$login_result = ftp_login($ftp, 'user', 'password');
ftp_pasv($ftp, true);
remote_scan('/');
ftp_close($ftp);
--
Edit this bug report at http://bugs.php.net/?id=42492&edit=1
#42491 [Opn->Fbk]: Segmentation fault during install-pear-installer
ID: 42491 Updated by: [EMAIL PROTECTED] Reported By: bernard dot prevosto at ifremer dot fr -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: solaris 5.8 PHP Version: 5.2.4 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-08-31 10:56:22] bernard dot prevosto at ifremer dot fr Description: Make install of php-5.2.4 seems not to work our servers. Configure goes well, make seems to work also, but we've got a segmentation fault during make install. Everything was OK with PHP 5.1.6 . (it's the sams problem that Bug #40474) Reproduce code: --- ./configure --prefix=/home/services/logiciels/compilateurs/php-5.2.4 --with-ldap=/home/services/bibli/openldap --with-mysql=/home/services/bibli/mysql --with-pgsql=/home/services/logiciels/compilateurs/php-5.2.4/bases/pgsql --with-oci8=/home/services/logiciels/compilateurs/php-5.2.4/bases/ora920 --with-gd --with-zlib-dir=/home/services/bibli/zlib --enable-zip --with-jpeg-dir=/home/services/bibli/jpeglib --with-png-dir=/home/services/bibli/pnglib --with-gettext=/home/services/logiciels/gettext --with-libxml-dir=/home/services/bibli/xml2lib --with-iconv --enable-calendar --enable-mbstring=all --enable-exif --disable-pdo --with-config-file-path=/home/services/logiciels/compilateurs/php-5.2.4 #(it's OK) make (it's OK) make install (segmentation fault) Expected result: no segmentation fault Actual result: -- louet>47% make install Installing PHP SAPI module: cgi Installing PHP CGI binary: /home/services/logiciels/compilateurs/php-5.2.4/bin/ Installing PHP CLI binary: /home/services/logiciels/compilateurs/php-5.2.4/bin/ Installing PHP CLI man page: /home/services/logiciels/compilateurs/php-5.2.4/man/man1/ Installing build environment: /home/services/logiciels/compilateurs/php-5.2.4/lib/php/build/ Installing header files: /home/services/logiciels/compilateurs/php-5.2.4/include/php/ Installing helper programs: /home/services/logiciels/compilateurs/php-5.2.4/bin/ program: phpize program: php-config Installing man pages: /home/services/logiciels/compilateurs/php-5.2.4/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /home/services/logiciels/compilateurs/php-5.2.4/lib/php/ Segmentation Fault gmake[1]: *** [install-pear-installer] Error 139 gmake: *** [install-pear] Error 2 - I have the same problem whith: louet>138% sapi/cli/php pear/install-pear-nozlib.phar Segmentation Fault -- Edit this bug report at http://bugs.php.net/?id=42491&edit=1
#42492 [NEW]: FTP functions apparently use wrong IP address for PORT in PASV mode
From: php at stock-consulting dot com
Operating system: Windows 2000
PHP version: 5.2.4
PHP Bug Type: FTP related
Bug description: FTP functions apparently use wrong IP address for PORT in
PASV mode
Description:
Situation: the local machine, which executes the PHP script via the
command line, sits behind a NAT firefall and needs to retrieve directory
listings and files from an FTP server sitting somewhere on the Internet.
Passive FTP is required to traverse the firewall. The local machine has the
IP address 10.0.0.1 (subnet configured as Class C). The external (WAN) IP
of the router/firewall is 80.x.x.x (address partially concealed to protect
the, erm, innocent).
Now the problem: the script correctly connects to the FTP server and
begins to retrieve directory listings (recursively) and files. At some
RANDOM point, the following warning appears:
Warning: ftp_chdir(): PORT command only accepts client IP address
(80.x.x.x
!=10.0.0.1). in my_script.php on line 40
This warning then appears both at all further attempts to retrieve
directory listings and files. The transfers are not successful.
Note that directory and file retrieval works perfectly UNTIL the warning
occurs for the first time, at some random time. When the script is
restarted, it will again work for some listings and files, until, at some
different point, the warning will appear again.
Reproduce code:
---
// Short version, stripped from anything which appeared not so useful for
this bug report
function remote_scan($path) {
global $ftp;
ftp_chdir($ftp, $path);
$raw_entries = ftp_rawlist($ftp, $path);
foreach ($raw_entries AS $line) {
$entry = preg_split('@\s+@', $line, 9);
if ($entry[4] == 0) {
remote_scan($path . $entry[8] . '/');
} else {
ftp_get($ftp, 'x:/local_path' . $path . $entry[8],
$path . $entry[8],
FTP_BINARY);
}
}
}
$ftp = ftp_connect('ftp.url', 47624); // server uses non-standard port
$login_result = ftp_login($ftp, 'user', 'password');
ftp_pasv($ftp, true);
remote_scan('/');
ftp_close($ftp);
--
Edit bug report at http://bugs.php.net/?id=42492&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42492&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42492&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42492&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42492&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42492&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42492&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42492&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42492&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42492&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42492&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42492&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42492&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42492&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42492&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42492&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42492&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42492&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42492&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42492&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42492&r=mysqlcfg
#42491 [NEW]: Segmentation fault during install-pear-installer
From: bernard dot prevosto at ifremer dot fr Operating system: solaris 5.8 PHP version: 5.2.4 PHP Bug Type: Compile Failure Bug description: Segmentation fault during install-pear-installer Description: Make install of php-5.2.4 seems not to work our servers. Configure goes well, make seems to work also, but we've got a segmentation fault during make install. Everything was OK with PHP 5.1.6 . (it's the sams problem that Bug #40474) Reproduce code: --- ./configure --prefix=/home/services/logiciels/compilateurs/php-5.2.4 --with-ldap=/home/services/bibli/openldap --with-mysql=/home/services/bibli/mysql --with-pgsql=/home/services/logiciels/compilateurs/php-5.2.4/bases/pgsql --with-oci8=/home/services/logiciels/compilateurs/php-5.2.4/bases/ora920 --with-gd --with-zlib-dir=/home/services/bibli/zlib --enable-zip --with-jpeg-dir=/home/services/bibli/jpeglib --with-png-dir=/home/services/bibli/pnglib --with-gettext=/home/services/logiciels/gettext --with-libxml-dir=/home/services/bibli/xml2lib --with-iconv --enable-calendar --enable-mbstring=all --enable-exif --disable-pdo --with-config-file-path=/home/services/logiciels/compilateurs/php-5.2.4 #(it's OK) make (it's OK) make install (segmentation fault) Expected result: no segmentation fault Actual result: -- louet>47% make install Installing PHP SAPI module: cgi Installing PHP CGI binary: /home/services/logiciels/compilateurs/php-5.2.4/bin/ Installing PHP CLI binary: /home/services/logiciels/compilateurs/php-5.2.4/bin/ Installing PHP CLI man page: /home/services/logiciels/compilateurs/php-5.2.4/man/man1/ Installing build environment: /home/services/logiciels/compilateurs/php-5.2.4/lib/php/build/ Installing header files: /home/services/logiciels/compilateurs/php-5.2.4/include/php/ Installing helper programs: /home/services/logiciels/compilateurs/php-5.2.4/bin/ program: phpize program: php-config Installing man pages: /home/services/logiciels/compilateurs/php-5.2.4/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /home/services/logiciels/compilateurs/php-5.2.4/lib/php/ Segmentation Fault gmake[1]: *** [install-pear-installer] Error 139 gmake: *** [install-pear] Error 2 - I have the same problem whith: louet>138% sapi/cli/php pear/install-pear-nozlib.phar Segmentation Fault -- Edit bug report at http://bugs.php.net/?id=42491&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42491&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42491&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42491&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42491&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42491&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42491&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42491&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42491&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42491&r=support Expected behavior:http://bugs.php.net/fix.php?id=42491&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42491&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42491&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42491&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42491&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42491&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42491&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42491&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42491&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42491&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42491&r=mysqlcfg
#42223 [Asn->Bgs]: SoapServer truncates XML document if Server Class includes UTF8 file
ID: 42223 Updated by: [EMAIL PROTECTED] Reported By: j8859 at clix dot pt -Status: Assigned +Status: Bogus Bug Type: SOAP related Operating System: Linux PHP Version: 5.2.4RC1 Assigned To: dmitry New Comment: Just look into util-UTF8.php and remove first three bytes. It seems like a UTF-8 prefix for some Windows editor. Previous Comments: [2007-08-06 19:33:52] j8859 at clix dot pt Description: SoapServer truncates XML document if the Server Class includes a UTF8 file. The error only occurs if the XML document returned is larger than 8000 bytes. In this case, tha XML document is truncated in the last 3 bytes. The BOM [Byte-Order Mark] also is 3 bytes long, could it be related with the bug? Reproduce code: --- There are a lot of files involved. Download them from: http://web.ioio.info/wstest/wstest.zip You can see the bug here: http://web.ioio.info/wstest/client.php You can download the ZIP file, extract it to an Apache directory, correct all addresses: change "web.ioio.info/wstest" for your own address in all files, and try the following in the TestWS.php file: 1) uncomment [require_once "util-ANSI.php";] comment [require_once "util-UTF8.php";] -> The error doesn't occur 2) On line 14, replace "800" by "700" (the XML document will be smaller than 8000 bytes) -> The error doesn't occur Expected result: http://schemas.xmlsoap.org/soap/envelope/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"; SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";>0123456789 ...(800 times: 0123456789)... 0123456789 Actual result: -- http://schemas.xmlsoap.org/soap/envelope/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"; SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";>0123456789 ...(800 times: 0123456789)... 0123456789 Misses the last 3 chars: "e>\n" -- Edit this bug report at http://bugs.php.net/?id=42223&edit=1
#42359 [Asn->Csd]: xsd:list type not parsed
ID: 42359 Updated by: [EMAIL PROTECTED] Reported By: dennis at d23 dot nl -Status: Assigned +Status: Closed Bug Type: SOAP related Operating System: Linux FC7 PHP Version: 5.2.4RC2 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-08-21 11:35:42] [EMAIL PROTECTED] Assigned to the SOAP extension maintainer. [2007-08-21 09:54:12] dennis at d23 dot nl Description: The xsd:list type is not parsed (correctly) from a WSDL. These types are frequently present in wsdl's generated from .NET, but might also be present in WSDL's from other sources. The list type represents an element which contains multiple space seperated values. (http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#dt-list) Reproduce code: --- /** WSDL : http://www.d23.nl/soaplist/listTest.wsdl */ http://www.d23.nl/soaplist/listTest.wsdl";); print_r($soap->__getTypes()); ?> Expected result: Array ( [0] => string listItem [1] => string enumItem [2] => enumItem listItem2 ) Actual result: -- Array ( [0] => anyType listItem [1] => string anonymous [2] => string enumItem [3] => anyType listItem2 ) -- Edit this bug report at http://bugs.php.net/?id=42359&edit=1
#42096 [Opn->Fbk]: is_dir() truncates dirs when using UNC paths
ID: 42096 Updated by: [EMAIL PROTECTED] Reported By: michael202 at gmx dot de -Status: Open +Status: Feedback Bug Type: Streams related Operating System: Windows only PHP Version: 5.2CVS-2007-07-24 New Comment: As is_dir() uses stat to check whether passed path is directory or not I doubt this can really be any PHP bug, just another limitiation of Windows. Try doing the same using something else than PHP and I bet the result is the same. And this is totally bogus: echo(is_dir($p) . "\n"); Proto for the function http://php.net/is_dir is: bool is_dir ( string $filename ) "Returns TRUE if the filename exists and is a directory, FALSE otherwise." Previous Comments: [2007-08-08 09:09:04] michael202 at gmx dot de running a script that makes a few thousand accesses to a samba server (that is used by approx. 30 other hosts) causes this server to "crash" and dismount the samba share. [2007-07-25 14:43:22] michael202 at gmx dot de tested with php5.2-win32-latest.zip from today morning 2007-07-25 08h08 error is still in there [2007-07-25 08:48:13] michael202 at gmx dot de Description: calling is_dir() with an UNC path truncates each part of the path. The last character is missing. This results in unnecessary errors (on the host side) and slowdowns (on client side). Reproduce code: --- windows only (php 5.2.3, Windows XP with cmd.exe) and linux host. STATUS_BAD_NETWORK_NAME FindFirst2, Pattern: \dir these are in /var/log/messages in 'hostA' ... smbd/service.c:make_connection(252) ... couldn't find service volume I think this is another problem with tsrm_virtual_cwd.c where around line 500 state_cwd_length is set to 2 if a slash is found at the beginning. Perhaps the existence of UNC paths is not checked for. -- Edit this bug report at http://bugs.php.net/?id=42096&edit=1
#42086 [Asn->Csd]: SoapServer return Procedure '' not present for WSIBasic compliant wsdl
ID: 42086
Updated by: [EMAIL PROTECTED]
Reported By: sanderovich at avaya dot com
-Status: Assigned
+Status: Closed
Bug Type: SOAP related
Operating System: linux
PHP Version: 5.2.3
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-08-15 08:22:21] [EMAIL PROTECTED]
Dmitry, feedback was given..
[2007-08-15 06:12:05] sanderovich at avaya dot com
I believe that there are here two different problems.
The first is that the Soap client does not create the SoapBody
correctly for a function without parameters(the SoapBody is empty),
that's why my SoapClient includes the following lines:
if ( $parameters == null)
{
$return = $itc_client->__soapCall($methodName, array(new
SoapParam(null, $methodName)), null, $security_header);
// $return = $itc_client->__soapCall($methodName,
array(), null,
$security_header);
}
The second problem is in the SoapServer that does recognize functions
without parameters.
[2007-08-15 02:29:37] michael dot tutty at gmail dot com
This bug seems to be the root of the problem. Has it been fixed??
http://bugs.php.net/bug.php?id=30302
[2007-08-15 01:47:52] michael dot tutty at gmail dot com
Also, the zip file referenced by the O.P. is available as of two
minutes ago. Must have been a temporary outage.
[2007-08-15 01:26:53] michael dot tutty at gmail dot com
Here's a minimal WSDL that shows the problem:
http://pastebin.com/m18b5d1fc
Here's the class file I used to reproduce with the WSDL above:
http://pastebin.com/m28bdf0f0
Here's a test client script: http://pastebin.com/m303880eb
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/42086
--
Edit this bug report at http://bugs.php.net/?id=42086&edit=1
#42326 [Asn->Csd]: SoapServer crash
ID: 42326 Updated by: [EMAIL PROTECTED] Reported By: edman007 at edman007 dot com -Status: Assigned +Status: Closed Bug Type: SOAP related Operating System: Linux PHP Version: 5.2-CVS-2007-08-16 Assigned To: dmitry New Comment: You have a bug in your WSDL file. You refer to _type_ productDetailsType. However productDetailsType is not a type but element. Also classmap works only with types and not with elements. Anyway PHP must not crash. The crush is fixed in CVS HEAD and PHP_5_2. Previous Comments: [2007-08-17 20:29:23] [EMAIL PROTECTED] Assigned to the maintainer of SOAP extension. [2007-08-17 16:01:06] edman007 at edman007 dot com Nope, did not help, here is the backtrace (gdb) bt 15 full #0 0xb752ab3b in get_encoder (sdl=0x8302600, ns=0x83021d0 "http://www.example.com/";, type=0x83013b8 "productDetailsType") at /root/php-5.2-cvs/php5.2-200708171430/ext/soap/php_sdl.c:118 enc = (encodePtr) 0x0 nscat = 0x8300fbc "\b" ns_len = 23 type_len = 18 len = 42 #1 0xb74ffd39 in master_to_xml (encode=0xb7a530fc, data=0x8301bcc, style=2, parent=0x8341c88) at /root/php-5.2-cvs/php5.2-200708171430/ext/soap/php_encoding.c:450 enc = (encodePtr) 0x0 ce = (zend_class_entry *) 0x83022dc tmp = (zval **) 0x83013a4 type_len = 19 idx = 0 pos = (HashPosition) 0x8301398 type_name = 0x83013b8 "productDetailsType" node = (xmlNodePtr) 0x0 #2 0xb750b810 in guess_xml_convert (type=0x8303450, data=0x8301bcc, style=2, parent=0x8341c88) at /root/php-5.2-cvs/php5.2-200708171430/ext/soap/php_encoding.c:2685 enc = (encodePtr) 0xb7a530fc ret = (xmlNodePtr) 0xb79e2a80 #3 0xb750cfe2 in sdl_guess_convert_xml (enc=0x8303450, data=0x8301bcc, style=2, parent=0x8341c88) at /root/php-5.2-cvs/php5.2-200708171430/ext/soap/php_encoding.c:3108 type = (sdlTypePtr) 0x0 ret = (xmlNodePtr) 0x0 #4 0xb7500367 in master_to_xml (encode=0x8303450, data=0x8301bcc, style=2, parent=0x8341c88) at /root/php-5.2-cvs/php5.2-200708171430/ext/soap/php_encoding.c:483 node = (xmlNodePtr) 0x0 #5 0xb750b810 in guess_xml_convert (type=0x8303450, data=0x8301bcc, style=2, parent=0x8341c88) at /root/php-5.2-cvs/php5.2-200708171430/ext/soap/php_encoding.c:2685 enc = (encodePtr) 0xb7a530fc ret = (xmlNodePtr) 0xb79e2a80 #6 0xb750cfe2 in sdl_guess_convert_xml (enc=0x8303450, data=0x8301bcc, style=2, parent=0x8341c88) at /root/php-5.2-cvs/php5.2-200708171430/ext/soap/php_encoding.c:3108 type = (sdlTypePtr) 0x0 ret = (xmlNodePtr) 0x0 #7 0xb7500367 in master_to_xml (encode=0x8303450, data=0x8301bcc, style=2, parent=0x8341c88) at /root/php-5.2-cvs/php5.2-200708171430/ext/soap/php_encoding.c:483 node = (xmlNodePtr) 0x0 #8 0xb750b810 in guess_xml_convert (type=0x8303450, data=0x8301bcc, style=2, parent=0x8341c88) at /root/php-5.2-cvs/php5.2-200708171430/ext/soap/php_encoding.c:2685 enc = (encodePtr) 0xb7a530fc ret = (xmlNodePtr) 0xb79e2a80 #9 0xb750cfe2 in sdl_guess_convert_xml (enc=0x8303450, data=0x8301bcc, style=2, parent=0x8341c88) at /root/php-5.2-cvs/php5.2-200708171430/ext/soap/php_encoding.c:3108 type = (sdlTypePtr) 0x0 ret = (xmlNodePtr) 0x0 #10 0xb7500367 in master_to_xml (encode=0x8303450, data=0x8301bcc, style=2, parent=0x8341c88) at /root/php-5.2-cvs/php5.2-200708171430/ext/soap/php_encoding.c:483 node = (xmlNodePtr) 0x0 #11 0xb750b810 in guess_xml_convert (type=0x8303450, data=0x8301bcc, style=2, parent=0x8341c88) at /root/php-5.2-cvs/php5.2-200708171430/ext/soap/php_encoding.c:2685 enc = (encodePtr) 0xb7a530fc ret = (xmlNodePtr) 0xb79e2a80 #12 0xb750cfe2 in sdl_guess_convert_xml (enc=0x8303450, data=0x8301bcc, style=2, parent=0x8341c88) at /root/php-5.2-cvs/php5.2-200708171430/ext/soap/php_encoding.c:3108 type = (sdlTypePtr) 0x0 ret = (xmlNodePtr) 0x0 #13 0xb7500367 in master_to_xml (encode=0x8303450, data=0x8301bcc, style=2, parent=0x8341c88) at /root/php-5.2-cvs/php5.2-200708171430/ext/soap/php_encoding.c:483 node = (xmlNodePtr) 0x0 #14 0xb750b810 in guess_xml_convert (type=0x8303450, data=0x8301bcc, style=2, parent=0x8341c88) at /root/php-5.2-cvs/php5.2-200708171430/ext/soap/php_encoding.c:2685 enc = (encodePtr) 0xb7a530fc ret = (xmlNodePtr) 0xb79e2a80 (More stack frames follow...) (gdb) bt -25 full #71353 0xb7500367 in master_to_xml (encode=0x8303450, data=0x8301bcc, style=2, parent=0x8341c88) at /root/php-5.2-cvs/php5.2-200708171430/ext/soap/php_encoding.c:483 node = (xmlNodePtr) 0x0 #71354 0xb75054f0 in model_to_xml_object (node=0x8341c88, model=0x8306de0, object=0xbfada7a0, style=2, strict=1) at /root/php-5.2-cvs/php5.2-200708171430/ext/soap/ph
#41561 [Asn->Csd]: Values set with php_admin_* in httpd.conf can be overwritten with ini_set()
ID: 41561
Updated by: [EMAIL PROTECTED]
Reported By: samy-delux at gmx dot de
-Status: Assigned
+Status: Closed
Bug Type: PHP options/info functions
Operating System: Ubuntu Linux
PHP Version: 5.2.3
Assigned To: tony2001
New Comment:
Patch re-applied, it's not the one causing above problems.
thetaphi: Open separate report about this.
Previous Comments:
[2007-08-03 13:28:57] [EMAIL PROTECTED]
I suppose there is something special with error reporting that corrupts
it. It seems that it does not like it to be changed to ZEND_INI_SYSTEM
because the @operator tries to change the value (e.g. in
zend_vm_execute.h), which fails silently:
static int ZEND_BEGIN_SILENCE_SPEC_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
{
zend_op *opline = EX(opline);
Z_LVAL(EX_T(opline->result.u.var).tmp_var) = EG(error_reporting);
Z_TYPE(EX_T(opline->result.u.var).tmp_var) = IS_LONG; /* shouldn't be
necessary */
if (EX(old_error_reporting) == NULL) {
EX(old_error_reporting) = &EX_T(opline->result.u.var).tmp_var;
}
if (EG(error_reporting)) {
zend_alter_ini_entry("error_reporting",
sizeof("error_reporting"),
"0", 1, ZEND_INI_USER, ZEND_INI_STAGE_RUNTIME);
}
ZEND_VM_NEXT_OPCODE();
}
=> When error_reporting was overwritten with ADMIN privileges it cannot
be changed anymore by the @ operator :)
For my first idea where this bug comes from: You should move
if (stage == ZEND_INI_STAGE_ACTIVATE && modify_type == ZEND_INI_SYSTEM)
{
ini_entry->modifiable = ZEND_INI_SYSTEM;
}
Behind the if-clause: "if (!modified) {..." to only modify the thread
local ini-entry!
[2007-08-03 12:53:16] [EMAIL PROTECTED]
The patch corrupts overwriting of ini entries in multithreaded
webserver SJSWS (formerly iplanet/SunONE).
It seems that the INI entry is modified in a way that corrupts its
further usage. I would suggest to change this patch that the modify_type
in ini_entry->modifiable = ZEND_INI_SYSTEM should only be set in the
replicated "modified" ini entry that is only available to the current
request. Changing it in the global ini table corrupts it and stops
further threads from modifying it (where no php_admin value is used and
it should be overwriteable!)...
see discussion on [EMAIL PROTECTED]
[2007-06-08 14:48:41] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2007-06-05 15:02:22] genetiq at gmail dot com
can reproduce this bug on my machine (Mac OS X 10.4.9, Apache2, PHP
5.2.3)
[2007-06-03 14:18:09] samy-delux at gmx dot de
I tried it with include_path and it does work as well:
'inc.php' lies in '/var/www/test/prohibited_include' and should not be
includeable!
Reproduce code:
---
/etc/apache2/httpd.conf :
php_admin_value include_path "/var/www/test/allowed_include"
path.php :
Expected result:
The result is the following:
Warning: include(inc.php) [function.include]: failed to open stream: No
such file or directory in /var/www/test/path.php on line 5
Warning: include() [function.include]: Failed opening 'inc.php' for
inclusion (include_path='/var/www/test/allowed_include') in
/var/www/test/path.php on line 5
Actual result:
--
The result is the following:
No Error because the file gets included nicely!
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/41561
--
Edit this bug report at http://bugs.php.net/?id=41561&edit=1
#36561 [Opn->Asn]: PDO_ODBC/MSSQL does not work with bound params in subquery
ID: 36561
Updated by: [EMAIL PROTECTED]
Reported By: travis at raybold dot com
-Status: Open
+Status: Assigned
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5.2.4
-Assigned To:
+Assigned To: fmk
New Comment:
Assigned to the maintainer.
Previous Comments:
[2007-08-31 07:33:12] [EMAIL PROTECTED]
Very nice that you didn't bother trying with the RCs..
[2007-08-30 16:20:54] travis at raybold dot com
the problem still occurs on:
PHP 5.2.4 (cli) (built: Aug 30 2007 07:06:31)
[2007-06-22 17:50:11] blohr at triad dot rr dot com
This bug affects my app, too. I'm using PHP 5.2.3 on Windows XP Pro
SP2, under both IIS 5.1 and Apache 2.2, with SQL Server 2005 Express.
I don't know if it'll help or not, but here's some more reproduce code.
Just fix the PDO DSN string to something valid.
exec($createTable);
$db->exec($createTable2);
$ins = $db->prepare('INSERT INTO ##test (intCol, textCol) VALUES (:i,
:t)');
$ins->execute(array('i'=>1, 't'=>'A String'));
$ins2 = $db->prepare('INSERT INTO ##test2 (intCol2, textCol2) VALUES
(:i, :t)');
$ins2->execute(array('i'=>1, 't'=>'Another String'));
$sel = $db->prepare('SELECT * FROM ##test WHERE intCol = (SELECT
intCol2 FROM ##test2 WHERE textCol2 = :t)');
$sel->execute(array('t'=>'Another String')) or
var_dump($sel->errorInfo());
$sel = $db->prepare('SELECT * FROM ##test WHERE intCol = (SELECT
intCol2 FROM ##test2 WHERE intCol2 = :i)');
$sel->execute(array('i'=>1)) or var_dump($sel->errorInfo());
$sel = $db->prepare('SELECT * FROM ##test WHERE intCol = (SELECT
intCol2 FROM ##test2 WHERE textCol2 = :t)');
$sel->bindValue('t', 'Another String');
$sel->execute() or var_dump($sel->errorInfo());
$sel = $db->prepare('SELECT * FROM ##test WHERE intCol = (SELECT
intCol2 FROM ##test2 WHERE intCol2 = :i)');
$sel->bindValue('i', 1);
$sel->execute() or var_dump($sel->errorInfo());
$sel = $db->prepare('SELECT * FROM ##test WHERE intCol = (SELECT
intCol2 FROM ##test2 WHERE textCol2 = :t)');
$sel->bindValue('t', 'Another String', PDO::PARAM_STR);
$sel->execute() or var_dump($sel->errorInfo());
$sel = $db->prepare('SELECT * FROM ##test WHERE intCol = (SELECT
intCol2 FROM ##test2 WHERE intCol2 = :i)');
$sel->bindValue('i', 1, PDO::PARAM_INT);
$sel->execute() or var_dump($sel->errorInfo());
$sel = $db->prepare('SELECT * FROM ##test WHERE intCol = (SELECT
intCol2 FROM ##test2 WHERE textCol2 = :t)');
$t = 'Another String';
$sel->bindParam('t', $t, PDO::PARAM_STR);
$sel->execute() or var_dump($sel->errorInfo());
$sel = $db->prepare('SELECT * FROM ##test WHERE intCol = (SELECT
intCol2 FROM ##test2 WHERE intCol2 = :i)');
$i = 1;
$sel->bindParam('i', $i, PDO::PARAM_INT);
$sel->execute() or var_dump($sel->errorInfo());
?>
[2007-05-24 20:50:41] travis at raybold dot com
Hey Wez, I never saw the feedback til I stumbled on it today, and
clearly have been able to work around this, but it does keep stopping
me.
It happens exactly the same if I omit the PDO::PARAM_INT as the final
parameter.
I am still using the branched version you gave me... I'd be happy to
test with the latest if you think it might be fixed there.
--Travis
[2006-04-09 07:57:01] [EMAIL PROTECTED]
Try using:
$oStatement->bindParam(':TestID', $iTestID);
instead of:
$oStatement->bindParam(':TestID', $iTestID,PDO::PARAM_INT );
The latter is implicitly binding for output, which might be part of
your problem.
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/36561
--
Edit this bug report at http://bugs.php.net/?id=36561&edit=1
#36561 [Opn]: PDO_ODBC/MSSQL does not work with bound params in subquery
ID: 36561
Updated by: [EMAIL PROTECTED]
Reported By: travis at raybold dot com
Status: Open
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5.2.4
New Comment:
Very nice that you didn't bother trying with the RCs..
Previous Comments:
[2007-08-30 16:20:54] travis at raybold dot com
the problem still occurs on:
PHP 5.2.4 (cli) (built: Aug 30 2007 07:06:31)
[2007-08-30 14:14:53] travis at raybold dot com
fixing bug summary...
[2007-08-30 14:13:49] travis at raybold dot com
this bug is still happening, as "blohr at triad dot rr dot com" logged.
[2007-07-10 17:20:05] blohr at triad dot rr dot com
I tried the code I posted previously with the snapshot you referenced.
Unfortunately, it didn't fix the problem. Here are the results:
> php -v
PHP 5.2.4-dev (cli) (built: Jul 10 2007 12:04:20)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
> php mssql-odbc.php
array(4) {
[0]=>
string(5) "42000"
[1]=>
int(402)
[2]=>
string(166) "[Microsoft][SQL Native Client][SQL Server]The data types
varchar and text are incompatible in the equal to operator.
(SQLExecute[402] at ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "42000"
}
array(4) {
[0]=>
string(5) "22018"
[1]=>
int(206)
[2]=>
string(141) "[Microsoft][SQL Native Client][SQL Server]Operand type
clash: text is incompatible with int (SQLExecute[206] at
ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "22018"
}
array(4) {
[0]=>
string(5) "42000"
[1]=>
int(402)
[2]=>
string(166) "[Microsoft][SQL Native Client][SQL Server]The data types
varchar and text are incompatible in the equal to operator.
(SQLExecute[402] at ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "42000"
}
array(4) {
[0]=>
string(5) "22018"
[1]=>
int(206)
[2]=>
string(141) "[Microsoft][SQL Native Client][SQL Server]Operand type
clash: text is incompatible with int (SQLExecute[206] at
ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "22018"
}
array(4) {
[0]=>
string(5) "42000"
[1]=>
int(402)
[2]=>
string(166) "[Microsoft][SQL Native Client][SQL Server]The data types
varchar and text are incompatible in the equal to operator.
(SQLExecute[402] at ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "42000"
}
array(4) {
[0]=>
string(5) "22018"
[1]=>
int(206)
[2]=>
string(141) "[Microsoft][SQL Native Client][SQL Server]Operand type
clash: text is incompatible with int (SQLExecute[206] at
ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "22018"
}
array(4) {
[0]=>
string(5) "42000"
[1]=>
int(402)
[2]=>
string(166) "[Microsoft][SQL Native Client][SQL Server]The data types
varchar and text are incompatible in the equal to operator.
(SQLExecute[402] at ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "42000"
}
array(4) {
[0]=>
string(5) "22018"
[1]=>
int(206)
[2]=>
string(141) "[Microsoft][SQL Native Client][SQL Server]Operand type
clash: text is incompatible with int (SQLExecute[206] at
ext\pdo_odbc\odbc_stmt.c:133)"
[3]=>
string(5) "22018"
}
[2007-07-10 11:33:49] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
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/36561
--
Edit this bug report at http://bugs.php.net/?id=36561&edit=1
#42067 [Opn->Bgs]: fetchAll for firebird missing first row
ID: 42067 Updated by: [EMAIL PROTECTED] Reported By: us at menatwork dot de -Status: Open +Status: Bogus Bug Type: PDO related Operating System: Windows W2k3 PHP Version: 5.2.3 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. Previous Comments: [2007-07-22 13:36:48] us at menatwork dot de Description: the description of the bug is still the same at bug #41509 and bug #35386. Is there a solution meanwhile ? -- Edit this bug report at http://bugs.php.net/?id=42067&edit=1
#42464 [Fbk->Bgs]: MySQL library location issues
ID: 42464 Updated by: [EMAIL PROTECTED] Reported By: juan at pons dot org -Status: Feedback +Status: Bogus Bug Type: MySQL related Operating System: OSX 10.4.10 PHP Version: 5.2.4 New Comment: And FYI: configure wouldn't even pass (you can't even compile PHP) if the library and path to it aren't found. So either your hackish build breaks something or you have something else wrong with your system. Previous Comments: [2007-08-31 07:12:01] [EMAIL PROTECTED] Never heard about phpize? [2007-08-30 20:35:18] juan at pons dot org The reason I need to run buildconf is because I am installing some php extensions that are not part of the standard package and after copying the extensions to the ext directory I run buildconf to recreate the configure script with the right extensions. I am going thru the buildconf step without installing the extension to take one more variable out of the equation and make sure the problem was/is not the extension. If there is a different way to accomplish the same I would love to know. [2007-08-30 20:19:05] [EMAIL PROTECTED] Why are you running buildconf? That's complete waste of time. [2007-08-30 14:23:04] juan at pons dot org Tried compiling with the new snapshot as requested and the problem still persists. Here is the error from config.log configure:98591: ./conftest dyld: Library not loaded: /usr/local/mysql/lib/mysql/libmysqlclient.15.dylib Here is the sequence of to reproduce the problem Install MySQL from the mysql.org packages # tar -zxvf php5.2-latest.tar.gz # cd php5.2-200708301230/ # rm configure # ./buildconf --force ./configure --with-apxs2=/app/apache2/bin/apxs --without-pear --with- config-file-path=/app/ini --with-mcrypt --with-curl --with- curlwrappers --enable-cli --with-mysql=/usr/local/mysql configure gives lots of statuses and then: checking for PDO includes... checking for PDO includes... /Users/jpons/app/src/php5.2-200708301230/ext checking for char *... yes checking size of char *... configure: error: cannot compute sizeof (char *), 77 See `config.log' for more details. [2007-08-28 19:21:35] juan at pons dot org Description: Under OSX, the MySQL binaries from mysql.org get installed under /usr/local/mysql When you try to compile php with --with-mysql=/usr/local/mysql you are unable to compile because the php mysql libs are trying to link against libraries at /usr/local/mysql/lib/mysql which does not exist in this MySQL installation, The correct path should be /usr/local/mysql/lib I found a way around this problem, by creating appropiate symlinks, but this is obviously not ideal Reproduce code: --- # tar -zxvf php-5.2.3.tar.gz # cd php-5.2.3 # rm configure # ./buildconf --force # ./configure --with-apxs2=/app/apache2/bin/apxs --without-pear --with-config-file-path=/app/ini --with-mysql=/usr/local/mysql # make # make install # /app/apache2/bin/apachectl start Expected result: compile php and have it work with apache Actual result: -- httpd: Syntax error on line 53 of /app/apache2/conf/httpd.conf: Cannot load /app/apache2/modules/libphp5.so into server: Library not loaded: /usr/local/mysql/lib/mysql/libmysqlclient.15.dylib\n Referenced from: /app/apache2/modules/libphp5.so\n Reason: image not found -- Edit this bug report at http://bugs.php.net/?id=42464&edit=1
#42464 [Opn->Fbk]: MySQL library location issues
ID: 42464 Updated by: [EMAIL PROTECTED] Reported By: juan at pons dot org -Status: Open +Status: Feedback Bug Type: MySQL related Operating System: OSX 10.4.10 PHP Version: 5.2.4 New Comment: Never heard about phpize? Previous Comments: [2007-08-30 20:35:18] juan at pons dot org The reason I need to run buildconf is because I am installing some php extensions that are not part of the standard package and after copying the extensions to the ext directory I run buildconf to recreate the configure script with the right extensions. I am going thru the buildconf step without installing the extension to take one more variable out of the equation and make sure the problem was/is not the extension. If there is a different way to accomplish the same I would love to know. [2007-08-30 20:19:05] [EMAIL PROTECTED] Why are you running buildconf? That's complete waste of time. [2007-08-30 14:23:04] juan at pons dot org Tried compiling with the new snapshot as requested and the problem still persists. Here is the error from config.log configure:98591: ./conftest dyld: Library not loaded: /usr/local/mysql/lib/mysql/libmysqlclient.15.dylib Here is the sequence of to reproduce the problem Install MySQL from the mysql.org packages # tar -zxvf php5.2-latest.tar.gz # cd php5.2-200708301230/ # rm configure # ./buildconf --force ./configure --with-apxs2=/app/apache2/bin/apxs --without-pear --with- config-file-path=/app/ini --with-mcrypt --with-curl --with- curlwrappers --enable-cli --with-mysql=/usr/local/mysql configure gives lots of statuses and then: checking for PDO includes... checking for PDO includes... /Users/jpons/app/src/php5.2-200708301230/ext checking for char *... yes checking size of char *... configure: error: cannot compute sizeof (char *), 77 See `config.log' for more details. [2007-08-28 19:21:35] juan at pons dot org Description: Under OSX, the MySQL binaries from mysql.org get installed under /usr/local/mysql When you try to compile php with --with-mysql=/usr/local/mysql you are unable to compile because the php mysql libs are trying to link against libraries at /usr/local/mysql/lib/mysql which does not exist in this MySQL installation, The correct path should be /usr/local/mysql/lib I found a way around this problem, by creating appropiate symlinks, but this is obviously not ideal Reproduce code: --- # tar -zxvf php-5.2.3.tar.gz # cd php-5.2.3 # rm configure # ./buildconf --force # ./configure --with-apxs2=/app/apache2/bin/apxs --without-pear --with-config-file-path=/app/ini --with-mysql=/usr/local/mysql # make # make install # /app/apache2/bin/apachectl start Expected result: compile php and have it work with apache Actual result: -- httpd: Syntax error on line 53 of /app/apache2/conf/httpd.conf: Cannot load /app/apache2/modules/libphp5.so into server: Library not loaded: /usr/local/mysql/lib/mysql/libmysqlclient.15.dylib\n Referenced from: /app/apache2/modules/libphp5.so\n Reason: image not found -- Edit this bug report at http://bugs.php.net/?id=42464&edit=1
#42476 [Opn->Fbk]: mbstring overload
ID: 42476 Updated by: [EMAIL PROTECTED] Reported By: pepazbrna at seznam dot cz -Status: Open +Status: Feedback Bug Type: mbstring related Operating System: Win2003 Server PHP Version: 5.2.3 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2007-08-29 18:55:14] pepazbrna at seznam dot cz Description: Setting mbstring.func_overload = 7 for ie. in one virtual host (httpd.conf or .htaccess) overwrite settings for all next vhosts (and adding .htaccess with new setting to this vhosts like mbstring.func_overload = 0 has no effect). Bug is in PHP 5.2.3 in despite of changelog for 5.2.3 (bugs #39361, #39400) -- Edit this bug report at http://bugs.php.net/?id=42476&edit=1
#42490 [Opn->Fbk]: PHP will not compile with BIND 9 installed
ID: 42490 Updated by: [EMAIL PROTECTED] Reported By: jerry at scene-naturally dot dyndns dot org -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: OS X 10.4.10 PHP Version: 5.2.4RC3 New Comment: You must have old libbind.* somewhere in your system which gets picked instead of the new one. Didn't you uninstall the old one before you installed the new one, apparently with different install prefix..? Previous Comments: [2007-08-30 21:22:20] jerry at scene-naturally dot dyndns dot org The libraries installed by BIND 9 are libbind9.a libbind.a These are in /usr/local/lib libbind.a does seem to have the symbols, however, libbind9.a does not have these missing symbols. The path /usr/local/lib IS in LD_LIBRARY_PATH The configure app is finding either the library or the header file, but apparently not completely following though on that; the screen echo: checking if your OS can spawn processes with inherited handles... yes checking for res_nmkquery... no checking for __res_nmkquery... no checking for res_nmkquery in -lresolv... no checking for __res_nmkquery in -lresolv... no checking for res_nmkquery in -lbind... no checking for __res_nmkquery in -lbind... yes checking for res_nsend... no checking for __res_nsend... yes checking for dn_expand... yes This is in the configure.log as well. A small part of libbind.a: [2007-08-30 20:21:16] [EMAIL PROTECTED] Where is the library located containing those symbols (can't remember what it was called :) and is the path to that library in LD_LIBRARY_PATH? [2007-08-30 18:15:25] jerry at scene-naturally dot dyndns dot org Description: 1) Compiling fails for various version of PHP 5. It has been suggested to install BIND 8 over the BIND 9 installation, compile PHP and then re-install BIND 9. Not very elegant, but it might work if the older BIND were available. This has become a bigger problem because BIND 8 was declared EOL as of August 27, (no more support either) and the links to the older software were removed from the ISC site. http://www.isc.org/index.pl 2) In comparison, this next one is far more minor, but still a problem: If there are multiple versions of Berkeley DB installed (say 4.1 -- 4.6) Config picks up the older (lowered numbered) version instead o the newest version. The various Makefiles, etc. have to be hand-edited to replace the occurrences of say db-4.5 with db-4.6 Reproduce code: --- Compile fails regardless of using a simple ./configure make or a full ./configure options options ... options make 2) Expected result: The usual line saying to the effect that the compile was successful and reminding the user to run 'make test'. Actual result: -- /usr/bin/ld: Undefined symbols: _res_nclose _res_ninit _res_nmkquery _res_nsend collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 -- Edit this bug report at http://bugs.php.net/?id=42490&edit=1
