#38111 [Com]: PHP crashes IIS worker process and application pool
ID: 38111 Comment by: O dot Tuengeler at interactivedialog dot de Reported By: svendavidh at hotmail dot com Status: No Feedback Bug Type: IIS related Operating System: Windows Server 2003 Std. Ed. R2 PHP Version: 5.1.4 New Comment: Have the same Problem using PHP 5.2.3, Windows Server 2003 (SP2), and IIS 6. Clean install. PHP installed as ISAPI extension. Previous Comments: [2008-01-29 23:02:52] kitcargile at hotmail dot com Found a MS KB doc related to this issue. http://support.microsoft.com/kb/892988 [2008-01-10 16:54:55] chrisr at rho-technology dot com Same issues: OS: Windows Server 2003 Web Edition sp1 PHP: 5.1.4 All apps are in the default pool [2007-11-13 10:35:33] ready725 at gmail dot com This bug occurred for me as well. PHP 5.2.5, Installed as ISAPI, IIS 7.0, Windows Vista Ultimate. It happens about 10 minutes after loading a PHP script, then crash every half to 1 hour after that. Can be reproduced by restarting the server, or running a PHP script and waiting for a few minutes. *There might be side-effects to this as well (possibly a memory leak, because after receiving that error, I cannot run other applications without closing some; not comfirmed). [2007-10-30 16:03:26] huet_bartels at hotmail dot com I have the same issue. I am using PHP/5.2.3 on IIS6 with plesk installed. The application pool just crashes every 1/2 to 1 hour. [2007-07-15 13:35:15] zeon77 at gmail dot com The moodle_cron service causes the problem to me... The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/38111 -- Edit this bug report at http://bugs.php.net/?id=38111&edit=1
#44117 [NEW]: SOAP fault, appears that function doesn't exist
From: matt at warnockinc dot com
Operating system: Redhat EL5 64-bit
PHP version: 5.2.5
PHP Bug Type: Reproducible crash
Bug description: SOAP fault, appears that function doesn't exist
Description:
I am writing a script and keep getting an error. It appears that the
function "logout" doesn't exist, however it is in the server, and in the
WSDL. I removed everything but the function, and can reproduce the error
Reproduce code:
---
server:
$server = new SoapServer( 'ws.wsdl', array('uri' =>
"urn://www.herong.home/res")
);
$server->SetClass('ws');
$server->handle();
class ws
{
/**
* logout method
*
* @param string $sessionkey sessionKey
* @return string status status
*/
function logout ( $sessionkey )
{
return "true";
}
}
Client:
$client = new SoapClient(null, array(
'location' => "http://localhost/testserver.php";,
'uri' => "urn://www.herong.home/req",
'trace'=> 1 ));
$return =
$client->__soapCall("logout",array("04cbf12ab33ccf7710c24ef7f59699393371f319"));
print_r( $return );
Expected result:
i should see "true"
Actual result:
--
Fatal error: Uncaught SoapFault exception: [SOAP-ENV:Server] Procedure
'logout' not present in /home/user/public_html/Dunbar/testclient.php:9
Stack trace: #0 /home/user/public_html/Dunbar/testclient.php(9):
SoapClient->__soapCall('logout', Array) #1 {main} thrown in
/home/user/public_html/Dunbar/testclient.php on line 9
--
Edit bug report at http://bugs.php.net/?id=44117&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=44117&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44117&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44117&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44117&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44117&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44117&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44117&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44117&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44117&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44117&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44117&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44117&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44117&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44117&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44117&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=44117&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44117&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44117&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44117&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44117&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44117&r=mysqlcfg
#44116 [NEW]: DOMDocument->loadHTMLFile() & ->saveHtml(), losing misc characters after save
From: chris dot shepherd at gmail dot com
Operating system: Fedora Core 6
PHP version: 5.2CVS-2008-02-14 (snap)
PHP Bug Type: DOM XML related
Bug description: DOMDocument->loadHTMLFile() & ->saveHtml(), losing misc
characters after save
Description:
I built a script which I pull the html down from a url and then do some
editing and output the source with ->saveHTML();
I noticed every now and again the code outputted was missing characters in
misc spots. For example one of my became a . I noticed this
through a diff.
I wanted to eliminate it being on my end of the code so I simply pulled
out all the code and left just $doc->loadHTMLFile($url); and then simply
output with $doc->saveHTML();
If do this and hit refresh, it would during random refreshes lose the
character (every 10/15 refreshes). It was always characters in the same
place in my code, but random when they would disappear.
Reproduce code:
---
$conn = $doc->loadHTMLFile('http://www.chrishan.org');
if($conn){
echo "";
echo $doc->saveHTML();
echo "";
}
Expected result:
I expect it to output my sourcecode from my website. But every 10 to 15
refreshes it loses a couple misc characters from my source.
--
Edit bug report at http://bugs.php.net/?id=44116&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=44116&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44116&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44116&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44116&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44116&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44116&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44116&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44116&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44116&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44116&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44116&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44116&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44116&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44116&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44116&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=44116&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44116&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44116&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44116&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44116&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44116&r=mysqlcfg
#44087 [Fbk->Opn]: Not using correct libxml
ID: 44087 User updated by: hz at nyphp dot com Reported By: hz at nyphp dot com -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: CentOS 4.5 x86_64 PHP Version: 5.2.5 New Comment: I think this is already done: [EMAIL PROTECTED] etc]# ldconfig -p | grep -i xml libxml2.so.2 (libc6,x86-64) => /usr/local/lib/libxml2.so.2 libxml2.so.2 (libc6,x86-64) => /usr/lib64/libxml2.so.2 libxml2.so (libc6,x86-64) => /usr/local/lib/libxml2.so libxml2.so (libc6,x86-64) => /usr/lib64/libxml2.so libxmlsec1.so.1 (libc6,x86-64) => /usr/lib64/libxmlsec1.so.1 libxmlsec1.so (libc6,x86-64) => /usr/lib64/libxmlsec1.so libxmlsec1-openssl.so.1 (libc6,x86-64) => /usr/lib64/libxmlsec1-openssl.so.1 libxmlsec1-openssl.so (libc6,x86-64) => /usr/lib64/libxmlsec1-openssl.so And regardless, shouldn't specifying the directory prefix with --with-libxml-dir=/usr/local and then thus it locating the correct /usr/local/bin/xml2-config during ./configure override the ordering in ldconfig irrelevant? Previous Comments: [2008-02-13 17:05:26] [EMAIL PROTECTED] You need to set the library paths correctly in /etc/ld.so.conf and make sure the path to the new libxml2 libraries is above any other like /usr/lib64 [2008-02-09 18:19:35] hz at nyphp dot com Description: CentOS 4.5 comes with an older version of libxml2, so I've compiled my own version and installed to /usr/local Then I configure PHP using: ./configure \ --with-libdir=lib64 \ --prefix=/usr/local/php \ --with-apxs=/usr/local/apache/bin/apxs \ --with-openssl \ --with-zlib \ --with-curl \ --with-mysql=/usr \ --with-mysqli=/usr/bin/mysql_config \ --disable-pdo \ --without-sqlite \ --enable-pcntl \ --with-xsl=/usr/local \ --with-libxml-dir=/usr/local make fails with errors as in bug #39940. When I move /usr/lib64/libxml2* to a temporary directory (and rerun ldconfig), I get the following error during make: ... -lxml2 -lz -lm -lcrypt -o libphp5.la grep: /usr/lib64/libxml2.la: No such file or directory /bin/sed: can't read /usr/lib64/libxml2.la: No such file or directory libtool: link: `/usr/lib64/libxml2.la' is not a valid libtool archive make: *** [libphp5.la] Error 1 So obviously PHP is not completely listening to where I told it to find libxml2. However, during ./configure, it indicates /usr/local/bin/xml2-config is being used. -- Edit this bug report at http://bugs.php.net/?id=44087&edit=1
#30989 [WFx->Csd]: Multiple include/require case problem with drive letters
ID: 30989 Updated by: [EMAIL PROTECTED] Reported By: info at e-novative dot de -Status: Wont fix +Status: Closed Bug Type: Filesystem function related Operating System: Windows XP PHP Version: 5.0.2 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. I think this was fixed somewhere in 5.2, but definitely works for me in 5.3. Previous Comments: [2004-12-06 11:17:30] info at e-novative dot de BTW, I _did_ search the database, but I didn't find this one. It didn't even show up on the final confirmation page, so I was pretty sure that was a new one. Sorry for that. But why is this a "won't fix"? It is a behaviour that is not desired, and I was banging my head for two days because my Unit Tests just would show up error when run fom phing. It shouldn't be too difficult to make PHP's internal list of files case _insensitive_ on Windows? Would this introduce any problem in another spot - I doubt it? It seems to be case insensitive anyway right now (see the second include in the example) - but not for the drive letter. [2004-12-06 11:05:01] [EMAIL PROTECTED] This has already been suggested before, please search the bug system before posting bugs. [2004-12-06 01:21:47] info at e-novative dot de Description: Include and require treat drive letters in path names case-sensitive (whereas Windows does not). This leads to (unjustified) "Cannot redeclare ..." errors for classes or functions in certain situations. Reproduce code: --- include_once 'c:/some/path/file.php'; include_once 'c:/some/PATH/file.php'; include_once 'C:/some/path/file.php'; (assume file.php contains a function or class definition) Expected result: Running all three include statements should be safe, as the path definitely points to the same directory on Windows. I remember PHP4 used to choke on the second include because paths were treated case-insensitive, however PHP5 chokes on the third one. Actual result: -- The third include_once statement yields an error "Cannot redeclare ... (previously declared in ...) ..." -- Edit this bug report at http://bugs.php.net/?id=30989&edit=1
#44114 [Opn]: [PATH=] in php.ini on windows does not account for case-insensitive FS
ID: 44114 Updated by: [EMAIL PROTECTED] Reported By: stas at zend dot com Status: Open Bug Type: PHP options/info functions Operating System: Windows PHP Version: 5.3CVS-2008-02-14 (CVS) -Assigned To: +Assigned To: jani New Comment: IIRC this code belongs to Jani Previous Comments: [2008-02-14 01:00:53] stas at zend dot com Description: When parsing [PATH=] section in php.ini, the value is taken as hash key as-is. Also, when calling a script its path is taken as-is from DOCROOT and file path. However, on Windows pathes are case-insensitive, meaning the path in script may differ in case from the path in config, but for Windows it would be the same path. It may be true also on other case-insensitive filesystems. The config parser should lowercase the names on Windows both when storing and when searching. -- Edit this bug report at http://bugs.php.net/?id=44114&edit=1
#44114 [NEW]: [PATH=] in php.ini on windows does not account for case-insensitive FS
From: stas at zend dot com Operating system: Windows PHP version: 5.3CVS-2008-02-14 (CVS) PHP Bug Type: PHP options/info functions Bug description: [PATH=] in php.ini on windows does not account for case-insensitive FS Description: When parsing [PATH=] section in php.ini, the value is taken as hash key as-is. Also, when calling a script its path is taken as-is from DOCROOT and file path. However, on Windows pathes are case-insensitive, meaning the path in script may differ in case from the path in config, but for Windows it would be the same path. It may be true also on other case-insensitive filesystems. The config parser should lowercase the names on Windows both when storing and when searching. -- Edit bug report at http://bugs.php.net/?id=44114&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=44114&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44114&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44114&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44114&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44114&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44114&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44114&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44114&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44114&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44114&r=support Expected behavior:http://bugs.php.net/fix.php?id=44114&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44114&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44114&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44114&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44114&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=44114&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44114&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44114&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44114&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44114&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44114&r=mysqlcfg
#43468 [Com]: Curl doesn't handle php://memory stream
ID: 43468
Comment by: quickshiftin at gmail dot com
Reported By: peter at petersmit dot eu
Status: Open
Bug Type: cURL related
Operating System: Ubuntu Linux Gutsy Gibbon
PHP Version: 5.2.5
New Comment:
i have discovered that this does work, partially, for some urls.
im not sure what is preventing this from working on all urls, but even
for ones where it does work, the entire result is not placed in the
buffer.
here is a modification of peters code, which illustrates 2 urls that
work partially, one is the google translate 'api', the other is
php.net.
http://example.com";);
#$c =
curl_init("http://google.com/translate_t?langpair=en%7Cfr&text=newspaper";);
$c = curl_init("http://php.net";);
$st = fopen('php://memory', 'r');
curl_setopt($c, CURLOPT_FILE, $st);
curl_setopt($c, CURLOPT_USERAGENT, 'Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.8.1.11) Gecko/20080115 Firefox/2.0.0.11');
if(!curl_exec($c)) die ("error: ".curl_error($c));
curl_close($c);
rewind($st);
/*
$str = fgets($st);
var_dump($str);
*/
echo stream_get_contents($st);
#echo
"Content|".htmlspecialchars(stream_get_contents($st))."|/Content";
fclose($st);
?>
Previous Comments:
[2007-12-01 10:00:25] peter at petersmit dot eu
Description:
If you use a php://memory stream in combination with curl, nothing is
written to the stream.
A filestream works fine.
Reproduce code:
---
http://example.com";);
$st = fopen("php://memory", "r+");
curl_setopt($c, CURLOPT_FILE, $st);
if(!curl_exec($c)) die ("error: ".curl_error($c));
rewind($st);
echo
"Content|".htmlspecialchars(stream_get_contents($st))."|/Content";
fclose($st);
?>
Expected result:
Content|The content of example.org|/Content
Actual result:
--
Content||/Content
--
Edit this bug report at http://bugs.php.net/?id=43468&edit=1
#44113 [NEW]: New collection creation can fail with OCI-22303
From: christopher dot jones at oracle dot com
Operating system: n/a
PHP version: 5.2.5
PHP Bug Type: OCI8 related
Bug description: New collection creation can fail with OCI-22303
Description:
In some circumstances oci_new_collection() can fail. The problem
was reported to me as occurring from at least PHP 5.1.2 onwards.
The cause appears to be lack of a describe-handle free in the
OCI8 extension; this is under investigation.
Reproduce code:
---
create or replace type ut_num_list_t as table of number;
create or replace procedure test_load(
p_list_1ut_num_list_t)
as
begin
for i in 1..p_list_1.count()
loop
null;
end loop;
end;
/
show errors
:list_1);
end;";
$sth = oci_parse($dbh, $sql);
$type = 'UT_NUM_LIST_T';
$placeholder = ':list_1';
if (!($var = oci_new_collection($dbh, $type)))
{
print "Failed new collection creation on $x\n";
}
foreach ($list as $list_item)
{
$var->append($list_item);
}
oci_bind_by_name($sth, $placeholder, $var, -1, OCI_B_NTY);
try
{
oci_execute($sth);
$var->free();
oci_free_statement($sth);
}
catch (Exception $e)
{
print "Failed on $x\n";
throw $e;
}
}
print "Completed $x\n";
oci_close($dbh);
?>
Expected result:
Completed 10
Actual result:
--
Warning: oci_new_collection(): OCI-22303: type ""."UT_NUM_LIST_T" not
found in /home/cjones/public_html/t1.php on line 26
Failed new collection creation on 65464
--
Edit bug report at http://bugs.php.net/?id=44113&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=44113&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44113&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44113&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44113&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44113&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44113&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44113&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44113&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44113&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44113&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44113&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44113&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44113&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44113&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44113&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=44113&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44113&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44113&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44113&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44113&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44113&r=mysqlcfg
#44101 [Fbk->Opn]: Better explanation of expected behavior
ID: 44101
User updated by: johnston dot joshua at gmail dot com
-Summary: Exceptions thrown with html_errors = on are partially
formatted
Reported By: johnston dot joshua at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: any
PHP Version: 5.2.5
New Comment:
The Exception and Fatal Error work just fine. I am reporting this as a
bug because error output has newlines in it but the HTML display does
not reflect this format. I would expect the stack trace would be wrapped
in or even some sort of list so that it is readable in HTML
output instead of all run together.
If you view it in a browser you see:
Stack trace:#0 [internal function]:
Zend_Controller_Action->__call('helloAction',
Array) #1
/code/dev/php/Zend/Controller/Action.php(497):Portal_TrialController->helloAction()
#2
/code/dev/php/Zend/Controller/Dispatcher/Standard.php(238):Zend_Controller_Action->dispatch('helloAction')
#3
/code/dev/php/Zend/Controller/Front.php(920):Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http),
Object(Zend_Controller_Response_Http)) #4
/home/jjohnston/svn/dev/www/bootstrap.php(96):
Zend_Controller_Front->dispatch() #5
/home/jjohnston/svn/dev/www/bootstrap.php(6): MW_Bootstrap::main() #6
{main} thrown in /code/dev/php/Zend/Controller/Action.php on
line
Notice the text is displayed in a long line without any visual
separation. This is true of any thrown but not caught Exception, not
Zend Framework specific.
The error message does add a before and after the error text.
Previous Comments:
[2008-02-13 16:53:48] [EMAIL PROTECTED]
Exactly what is not right there?
[2008-02-11 22:08:14] johnston dot joshua at gmail dot com
Description:
When an exception is thrown and not caught and html_errors = on the
Fatal Error text is only partially formatted. When you 'view source' in
your web browser you can see the stact trace is nicely formatted but has
no format for content-type: text/html
Actual result:
--
Fatal error: Uncaught exception
'Zend_Controller_Action_Exception' with message
'Portal_TrialController::helloAction() does not exist and was not
trapped in __call()' in /code/dev/php/Zend/Controller/Action.php:480
Stack trace:
#0 [internal function]:
Zend_Controller_Action->__call('helloAction', Array)
#1 /code/dev/php/Zend/Controller/Action.php(497):
Portal_TrialController->helloAction()
#2 /code/dev/php/Zend/Controller/Dispatcher/Standard.php(238):
Zend_Controller_Action->dispatch('helloAction')
#3 /code/dev/php/Zend/Controller/Front.php(920):
Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http),
Object(Zend_Controller_Response_Http))
#4 /home/jjohnston/svn/dev/www/bootstrap.php(96):
Zend_Controller_Front->dispatch()
#5 /home/jjohnston/svn/dev/www/bootstrap.php(6):
MailWise_Bootstrap::main()
#6 {main}
thrown in /code/dev/php/Zend/Controller/Action.php on line
480
--
Edit this bug report at http://bugs.php.net/?id=44101&edit=1
#44096 [Fbk->Opn]: iconv: wrong charset
ID: 44096
User updated by: cpuidle at gmx dot de
Reported By: cpuidle at gmx dot de
-Status: Feedback
+Status: Open
Bug Type: ICONV related
Operating System: WinXP
PHP Version: 5.2.5
New Comment:
See test case- file is ansi, not even any complex characters?
Previous Comments:
[2008-02-13 17:52:17] [EMAIL PROTECTED]
In what charset is the input here..?
[2008-02-11 08:40:15] cpuidle at gmx dot de
Description:
Trying simple charset conversion with iconv:
iconv('iso-8859-1', 'utf-8', 'test');
receive this error:
Notice: iconv() [function.iconv]: Wrong charset, conversion from
`ISO8859-1' to `UTF-8' is not allowed in /var/htdocs/test.php on line 5
Problem: no troubleshooting information available, e.g. list or
supported charsets or similiar.
How can this be diagnosed?
Reproduce code:
---
error_reporting(E_ALL);
$res = iconv('iso-8859-1', 'utf-8', 'test');
Expected result:
No error and/or supporting functions to aid diagnostics.
Actual result:
--
Error message:
Notice: iconv() [function.iconv]: Wrong charset, conversion from
`ISO8859-1' to `UTF-8' is not allowed in /var/htdocs/test.php on line 5
--
Edit this bug report at http://bugs.php.net/?id=44096&edit=1
#43397 [Fbk->Opn]: crashes in _zend_mm_free_int
ID: 43397 User updated by: phajdan dot jr at gmail dot com Reported By: phajdan dot jr at gmail dot com -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: Linux (Gentoo 2007.0) PHP Version: 5.3CVS-2007-11-25 New Comment: Please take a look at my original report - I was unable to extract a simple fragment which is causing the problem. Yet I'm still able to debug the issue in some other way. One thing is worth noting: I'm almost sure it's something withe the new Zend MM introduced in some recent version of PHP. This crash didn't happen earlier (I tested it again with older version just to make sure), and with debug build it also does not happen. Previous Comments: [2008-02-13 18:45:01] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2007-11-26 17:55:30] phajdan dot jr at gmail dot com I can confirm the bug with latest CVS snapshot. GDB backtrace: #0 0xb77f4b79 in _zend_mm_free_int () from /usr/lib/apache2/modules/libphp5.so #1 0xb7810087 in _zval_dtor_func () from /usr/lib/apache2/modules/libphp5.so #2 0xb7803cc9 in _zval_ptr_dtor () from /usr/lib/apache2/modules/libphp5.so #3 0xb781a866 in zend_hash_destroy () from /usr/lib/apache2/modules/libphp5.so #4 0xb78297e3 in zend_object_std_dtor () from /usr/lib/apache2/modules/libphp5.so #5 0xb7829812 in zend_objects_free_object_storage () from /usr/lib/apache2/modules/libphp5.so #6 0xb782cc17 in zend_objects_store_del_ref_by_handle () from /usr/lib/apache2/modules/libphp5.so #7 0xb782cc57 in zend_objects_store_del_ref () from /usr/lib/apache2/modules/libphp5.so #8 0xb7803cc9 in _zval_ptr_dtor () from /usr/lib/apache2/modules/libphp5.so #9 0xb781a866 in zend_hash_destroy () from /usr/lib/apache2/modules/libphp5.so #10 0xb7810087 in _zval_dtor_func () from /usr/lib/apache2/modules/libphp5.so #11 0xb7803cc9 in _zval_ptr_dtor () from /usr/lib/apache2/modules/libphp5.so #12 0xb781a866 in zend_hash_destroy () from /usr/lib/apache2/modules/libphp5.so #13 0xb7810087 in _zval_dtor_func () from /usr/lib/apache2/modules/libphp5.so #14 0xb7803cc9 in _zval_ptr_dtor () from /usr/lib/apache2/modules/libphp5.so #15 0xb781aa56 in zend_hash_clean () from /usr/lib/apache2/modules/libphp5.so #16 0xb7807b75 in zend_cleanup_op_array_data () from /usr/lib/apache2/modules/libphp5.so #17 0xb7807b97 in zend_cleanup_function_data_full () from /usr/lib/apache2/modules/libphp5.so #18 0xb781a73c in zend_hash_apply () from /usr/lib/apache2/modules/libphp5.so #19 0xb7807a09 in zend_cleanup_class_data () from /usr/lib/apache2/modules/libphp5.so #20 0xb781a73c in zend_hash_apply () from /usr/lib/apache2/modules/libphp5.so #21 0xb78040f9 in shutdown_executor () from /usr/lib/apache2/modules/libphp5.so #22 0xb78105fd in zend_deactivate () from /usr/lib/apache2/modules/libphp5.so #23 0xb77cce79 in php_request_shutdown () from /usr/lib/apache2/modules/libphp5.so #24 0xb7893f9d in php_handler () from /usr/lib/apache2/modules/libphp5.so #25 0x08079037 in ap_run_handler () #26 0x0807c1b7 in ap_invoke_handler () #27 0x08087068 in ap_process_request () #28 0x080842cf in ap_process_http_connection () #29 0x0807ff67 in ap_run_process_connection () #30 0x0808b1a4 in child_main () #31 0x0808b409 in make_child () #32 0x0808c177 in ap_mpm_run () #33 0x08066908 in main () [2007-11-25 17:28:12] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.3-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.3-win32-installer-latest.msi [2007-11-24 15:58:06] phajdan dot jr at gmail dot com Description: I have a not-so-small script (20k LOC) and there is a problem during some extensive operations in it: a crash. I tried to find out which part of my program could cause it (tried to comment out some fragments of code etc - but the code isn't very simple, so I couldn't find a fragment possibly related to the crash). I have 3 backtraces, with PHP compiled with -debug (Gentoo USE flag). When compiled with debug, the issue doesn't persist. I don't know how should I debug the problem - if I can do something to help you fix it - I will. A
#44071 [Opn->Fbk]: realpath does not handle drive letters correctly
ID: 44071
Updated by: [EMAIL PROTECTED]
Reported By: csaba at alum dot mit dot edu
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: Windows
PHP Version: 5.2.5
New Comment:
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
Previous Comments:
[2008-02-08 02:08:29] csaba at alum dot mit dot edu
is_file and is_dir seem to be similarly affected.
For example realpath("c:frump") will return false if
c:\frump does not exist (note the extra backslash),
whereas it should be checking for frump hanging off
the current directory on the c: drive
[2008-02-07 16:26:22] csaba at alum dot mit dot edu
Description:
realpath does not handle a drive letters correctly, when the
drive letter is not followed by a backslash:
1) When books is a subdirectory of the current working directory on
the c: drive (getcwd) realpath("c:books") returns false
2) realpath("c:.") and realpath("c:..") both return the three
character string: C:\
Expected result:
1. books\ should be suffixed onto the current working directory of the
c: drive
2. The current working directory of the c: drive (and one level higher
for the case of ..) should be returned, instead of the root.
Csaba Gabor from Vienna
--
Edit this bug report at http://bugs.php.net/?id=44071&edit=1
#43387 [Opn->NoF]: Segmentation fault during shutdown in _zend_mm_free_int()
ID: 43387 Updated by: [EMAIL PROTECTED] Reported By: matteo at beccati dot com -Status: Open +Status: No Feedback Bug Type: Reproducible crash Operating System: GNU/Linux 2.6.18 x86_64 PHP Version: 5.2.5 Previous Comments: [2008-02-09 02:10:55] [EMAIL PROTECTED] not fixed - reopen [2007-12-13 06:18:50] phajdan dot jr at gmail dot com As this bug is now closed due to lack of feedback, can you reopen my original bug http://bugs.php.net/bug.php?id=43397 ? [2007-12-07 15:27:38] phajdan dot jr at gmail dot com I don't know if it is helpful, but I tested with recent snapshot and the bug wasn't fixed (I submitted another bug report, marked as a duplicate of this one). [2007-12-05 15:40:55] [EMAIL PROTECTED] Keep this in feedback status until you have actually tested the snapshot. A fix was committed recently which should fix this one too. [2007-12-04 16:06:52] matteo at beccati dot com We'll try to reproduce it again with either 5.2.4 or 5.2.5 and see if the snapshot fixes it. Thanks for the feedback, we really appreciate it! The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/43387 -- Edit this bug report at http://bugs.php.net/?id=43387&edit=1
#43397 [Bgs->Fbk]: crashes in _zend_mm_free_int
ID: 43397 Updated by: [EMAIL PROTECTED] Reported By: phajdan dot jr at gmail dot com -Status: Bogus +Status: Feedback Bug Type: Scripting Engine problem Operating System: Linux (Gentoo 2007.0) PHP Version: 5.2.5 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2007-11-26 20:17:22] [EMAIL PROTECTED] 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. Dupe of bug #43387 [2007-11-26 17:55:30] phajdan dot jr at gmail dot com I can confirm the bug with latest CVS snapshot. GDB backtrace: #0 0xb77f4b79 in _zend_mm_free_int () from /usr/lib/apache2/modules/libphp5.so #1 0xb7810087 in _zval_dtor_func () from /usr/lib/apache2/modules/libphp5.so #2 0xb7803cc9 in _zval_ptr_dtor () from /usr/lib/apache2/modules/libphp5.so #3 0xb781a866 in zend_hash_destroy () from /usr/lib/apache2/modules/libphp5.so #4 0xb78297e3 in zend_object_std_dtor () from /usr/lib/apache2/modules/libphp5.so #5 0xb7829812 in zend_objects_free_object_storage () from /usr/lib/apache2/modules/libphp5.so #6 0xb782cc17 in zend_objects_store_del_ref_by_handle () from /usr/lib/apache2/modules/libphp5.so #7 0xb782cc57 in zend_objects_store_del_ref () from /usr/lib/apache2/modules/libphp5.so #8 0xb7803cc9 in _zval_ptr_dtor () from /usr/lib/apache2/modules/libphp5.so #9 0xb781a866 in zend_hash_destroy () from /usr/lib/apache2/modules/libphp5.so #10 0xb7810087 in _zval_dtor_func () from /usr/lib/apache2/modules/libphp5.so #11 0xb7803cc9 in _zval_ptr_dtor () from /usr/lib/apache2/modules/libphp5.so #12 0xb781a866 in zend_hash_destroy () from /usr/lib/apache2/modules/libphp5.so #13 0xb7810087 in _zval_dtor_func () from /usr/lib/apache2/modules/libphp5.so #14 0xb7803cc9 in _zval_ptr_dtor () from /usr/lib/apache2/modules/libphp5.so #15 0xb781aa56 in zend_hash_clean () from /usr/lib/apache2/modules/libphp5.so #16 0xb7807b75 in zend_cleanup_op_array_data () from /usr/lib/apache2/modules/libphp5.so #17 0xb7807b97 in zend_cleanup_function_data_full () from /usr/lib/apache2/modules/libphp5.so #18 0xb781a73c in zend_hash_apply () from /usr/lib/apache2/modules/libphp5.so #19 0xb7807a09 in zend_cleanup_class_data () from /usr/lib/apache2/modules/libphp5.so #20 0xb781a73c in zend_hash_apply () from /usr/lib/apache2/modules/libphp5.so #21 0xb78040f9 in shutdown_executor () from /usr/lib/apache2/modules/libphp5.so #22 0xb78105fd in zend_deactivate () from /usr/lib/apache2/modules/libphp5.so #23 0xb77cce79 in php_request_shutdown () from /usr/lib/apache2/modules/libphp5.so #24 0xb7893f9d in php_handler () from /usr/lib/apache2/modules/libphp5.so #25 0x08079037 in ap_run_handler () #26 0x0807c1b7 in ap_invoke_handler () #27 0x08087068 in ap_process_request () #28 0x080842cf in ap_process_http_connection () #29 0x0807ff67 in ap_run_process_connection () #30 0x0808b1a4 in child_main () #31 0x0808b409 in make_child () #32 0x0808c177 in ap_mpm_run () #33 0x08066908 in main () [2007-11-25 17:28:12] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.3-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.3-win32-installer-latest.msi [2007-11-24 15:58:06] phajdan dot jr at gmail dot com Description: I have a not-so-small script (20k LOC) and there is a problem during some extensive operations in it: a crash. I tried to find out which part of my program could cause it (tried to comment out some fragments of code etc - but the code isn't very simple, so I couldn't find a fragment possibly related to the crash). I have 3 backtraces, with PHP compiled with -debug (Gentoo USE flag). When compiled with debug, the issue doesn't persist. I don't know how should I debug the problem - if I can do something to help you fix it - I will. Actual result: -- Backtrace 1: #0 0xb7782fe8 in _zend_mm_free_int () from /usr/lib/apache2/modules/libphp5.so #1 0xb77a6d46 in zend_hash_destroy () from /usr/lib/apache2/modules/
#43564 [Opn->Fbk]: Using session_save_path('2;0777;/some/path') does not persist through script
ID: 43564 Updated by: [EMAIL PROTECTED] Reported By: fxbois at gmail dot com -Status: Open +Status: Feedback Bug Type: Session related Operating System: rhas 3 PHP Version: 5.2.5 New Comment: Do you by any chance try changing PHP ini values using php_value/php_admin_value in httpd.conf or .htacces files? Previous Comments: [2007-12-14 09:47:19] fxbois at gmail dot com Sorry, it has taken more time but PHP still ignore session_save_path() after "some" time. What can I test ? I give you more information about my system - Red Hat Enterprise Linux ES release 3 (Taroon Update 8) - apache 2.0.46 [2007-12-13 00:18:22] [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-12-12 09:34:25] fxbois at gmail dot com PHP 5.2.6-dev seems to correct the bug. It can be a pretty serious security problem (session files end in a bad directory). I hope you will release a new version soon. Could you explain in a few words what bugs have you resolved which linked to the sessions ? [2007-12-12 09:18:30] fxbois at gmail dot com When I restart apache ... session_save_path() returns /tmp/session which is normal [2007-12-11 16:08:20] [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 Works fine here. What is the return value of session_save_path() on the first call? 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/43564 -- Edit this bug report at http://bugs.php.net/?id=43564&edit=1
#43682 [Opn->Fbk]: domain/subdomain problems with session cookies
ID: 43682
Updated by: [EMAIL PROTECTED]
-Summary: headers are OK
Reported By: k dot andris at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Session related
Operating System: Debian Sarge
PHP Version: 5.2.4
New Comment:
I don't see how this is PHP bug at all. More like lighttpd bug if a bug
at all. Check these: What host PHP script gets from ligttpd
($_SERVER['SERVER_NAME'] and what is tried to be set for the cookie.
Previous Comments:
[2008-02-10 18:29:19] k dot andris at gmail dot com
I found it! The problem only occours if you serve the base domain and
the subdomains from different sections of lighttpd config file, like
this:
$HTTP["host"] =~ "^mysite\.com" {
server.document-root = "/var/www/mysite/"
}
$HTTP["host"] =~ "(.+)\.mysite\.com$" {
server.document-root = "/var/www/mysubdomains/"
}
[2008-02-10 18:17:20] k dot andris at gmail dot com
It seems to work on another server. I'll try to find out what was wrong
with the first one. Sorry..
[2008-02-10 17:21:06] k dot andris at gmail dot com
Did you try getting the session variable set on a subdomain at the
root? Like apple.mydomain.com/echo.php sets $_SESSION['apple'] =
'fruit', but mydomain.com/echo.php will not see it. Or does it in your
tests? BTW, session_set_cookie_params lack parameter docs, but I guess
lifetime is in seconds.
[2008-02-05 00:28:53] [EMAIL PROTECTED]
Try using this instead of ini_set():
http://php.net/session_set_cookie_params
Calling this with proper values prior to calling session_start(); works
just fine for me.
[2008-02-02 13:15:14] k dot andris at gmail dot com
Host names pass along fine to the script handling the subdomains.
Actually I used the subdfomain name to set test session variables, like
"a_test2 and "b_test".
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/43682
--
Edit this bug report at http://bugs.php.net/?id=43682&edit=1
#43666 [Ana->Opn]: Adding odbc v3.52 support
ID: 43666 Updated by: [EMAIL PROTECTED] Reported By: iodbc at openlinksw dot com -Status: Analyzed +Status: Open Bug Type:ODBC related PHP Version: 5.2CVS-2007-12-24 (CVS) Previous Comments: [2007-12-27 06:15:54] [EMAIL PROTECTED] Looking through the patch this looks like a clean update for 64bit compatibility. Applying this to HEAD would be wise. [2007-12-24 15:00:07] iodbc at openlinksw dot com Here is the URL to the diff: ftp://download.openlinksw.com/support/php-dev/odbc-types.txt [2007-12-24 10:21:14] iodbc at openlinksw dot com Description: The ext/odbc code does not use ODBC 3.52 API datatypes which makes it impossible to use with WIN64 and Unix 64bit systems. I have created a patch to add this functionality which has also been posted to the php-dev mailing list. -- Edit this bug report at http://bugs.php.net/?id=43666&edit=1
#43668 [Opn]: Added control of ODBC cursor type
ID: 43668 Updated by: [EMAIL PROTECTED] Reported By: iodbc at openlinksw dot com Status: Open Bug Type:ODBC related PHP Version: 5.2CVS-2007-12-24 (CVS) New Comment: See also bug #41404 Previous Comments: [2008-01-02 18:03:28] [EMAIL PROTECTED] this patch should also fix #41404 [2007-12-27 06:17:35] [EMAIL PROTECTED] A much needed patch that will also solve issues on older IBM DB2 installations with leaked memory. Applying this patch is highly recommended. [2007-12-24 15:04:22] iodbc at openlinksw dot com Description: This patch allows the developer to specify what level of cursor support is needed for the application, rather than using the slowest available. ftp://download.openlinksw.com/support/php-dev/odbc-cursor.txt -- Edit this bug report at http://bugs.php.net/?id=43668&edit=1
#43668 [Ana->Opn]: Added control of ODBC cursor type
ID: 43668 Updated by: [EMAIL PROTECTED] Reported By: iodbc at openlinksw dot com -Status: Analyzed +Status: Open Bug Type:ODBC related PHP Version: 5.2CVS-2007-12-24 (CVS) Previous Comments: [2008-01-02 18:03:28] [EMAIL PROTECTED] this patch should also fix #41404 [2007-12-27 06:17:35] [EMAIL PROTECTED] A much needed patch that will also solve issues on older IBM DB2 installations with leaked memory. Applying this patch is highly recommended. [2007-12-24 15:04:22] iodbc at openlinksw dot com Description: This patch allows the developer to specify what level of cursor support is needed for the application, rather than using the slowest available. ftp://download.openlinksw.com/support/php-dev/odbc-cursor.txt -- Edit this bug report at http://bugs.php.net/?id=43668&edit=1
#43669 [Ana->Opn]: Fixed iODBC support for recent SDKs
ID: 43669 Updated by: [EMAIL PROTECTED] Reported By: iodbc at openlinksw dot com -Status: Analyzed +Status: Open Bug Type:ODBC related PHP Version: 5.2CVS-2007-12-24 (CVS) Previous Comments: [2007-12-27 06:19:19] [EMAIL PROTECTED] Untested patch, but since it's provided by the iODBC maintainer, it's probably a safe patch to apply. Extends functionality for iODBC only. [2007-12-24 15:07:39] iodbc at openlinksw dot com Description: PHP ODBC support does not work properly against later versions of the iODBC Driver Manager, so users are missing out on features that are long since supported. ftp://download.openlinksw.com/support/php-dev/odbc-iodbc.txt -- Edit this bug report at http://bugs.php.net/?id=43669&edit=1
#44009 [Opn->Fbk]: fopen hangs with recent upgrade
ID: 44009 Updated by: [EMAIL PROTECTED] Reported By: brandonkahre at charter dot net -Status: Open +Status: Feedback Bug Type: HTTP related Operating System: Windows PHP Version: 5.2.5 New Comment: 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 Previous Comments: [2008-02-01 00:34:53] brandonkahre at charter dot net Description: When opening a file using fopen and a network wrapper (HTTP), the page will lag before finishing. The response from fopen is fast (determined by echo'ing the return, and any code that is to be processed after the fopen function is processed without delay. It is only when the page is ready to finish loading that the lag becomes noticeable. The lag takes 3-6 seconds and does not seem to be affected by any timeout settings in the php.ini file. This problem does not exist in PHP 5.1.2, and started immediately after upgrading to PHP 5.2.4 and 5.2.5. This problem also seems to only exist on my Windows server. Reproduce code: --- http://www.google.com";)); ?> -- Edit this bug report at http://bugs.php.net/?id=44009&edit=1
#44035 [Opn->Fbk]: After a while apache hangs. Specially if i refresh instead of clicking a link
ID: 44035 Updated by: [EMAIL PROTECTED] Reported By: assid at assid dot com -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Windows XP PHP Version: 5.3CVS-2008-02-04 (snap) Previous Comments: [2008-02-05 07:41:40] assid at assid dot com I tried disabling the mysql extensions on windows however that didnt help. I still come across the same issues. I will try and do further tests to see what I can come across. [2008-02-05 07:36:00] assid at assid dot com Yes I actually came across that last night and found out its something to do with mysql. On windows, I am using the same ones that came with the snapshots. On linux I had it compiled against the source [2008-02-05 00:33:12] [EMAIL PROTECTED] You should propably check this out: http://bugs.mysql.com/bug.php?id=25621 I don't know what mysql libraries you have PHP linked with but most likely to the buggy ones, hence the error. [2008-02-04 11:38:35] assid at assid dot com Sorry my bad.. quick update have not tried snapshot on linux yet.. but 5.2.5 and snapshot on windows. And 5.2.5 on linux [2008-02-04 11:37:10] assid at assid dot com I disabled php from apache's modules. Now it doesnt cause apache to hang. Also, earlier if i stopped apache waited a few mins and then tried to start it, it didnt used to do that. Checking the process list, i would always find httpd.exe still running. Disabling the php module now has clean stop/starts of apache. This problem was very prominent in linux as well, as mentioned in my original post. Also something related to this on linux, my sessions used to time out. But I dont know how to check for that. One thing for certain now is that this behavior is common between both platforms on 5.2.5 and current snapshot. 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/44035 -- Edit this bug report at http://bugs.php.net/?id=44035&edit=1
#44069 [Opn->Asn]: Huge memory usage with concatenation using . instead of .=
ID: 44069
Updated by: [EMAIL PROTECTED]
Reported By: frode dot guldberg at exense dot com
-Status: Open
+Status: Assigned
Bug Type: Performance problem
-Operating System: Windows XP
+Operating System: *
PHP Version: 5.2.5
-Assigned To:
+Assigned To: dmitry
New Comment:
Dmitry, can you check this out please? The example script kills my
machine totally if I don't use the .= :)
Previous Comments:
[2008-02-07 13:39:05] frode dot guldberg at exense dot com
Description:
In a for-loop I concatenate two strings. If I at the same time fill a
relatively small array, I get a huge memory consumption. This only
happens if I concatenate the two strings using '.'. If I use '.=' the
memory usage is as expected.
Reproduce code:
---
';
echo 'Memory Before:'.memory_get_usage(true).'';
for($i = 1; $i <= 2000; $i++)
{
// $newstring .= $string; //This uses an expected amount of mem.
$newstring = $newstring . $string; //This uses very much mem.
for($j = 1; $j <= 10; $j++)
{
$array[] = 'test';
}
}
echo 'Memory After:'.memory_get_usage(true).'';
echo 'Total Length of String: '.strlen($newstring).'';
?>
Expected result:
Length: 1050
Before:262144
After:4456448
Length: 210
Actual result:
--
Length: 1050
Before:262144
After:161742848
Length: 210
--
Edit this bug report at http://bugs.php.net/?id=44069&edit=1
#44072 [Opn->Fbk]: substr don't work correctly with binary string
ID: 44072 Updated by: [EMAIL PROTECTED] Reported By: sergey89 at gmail dot com -Status: Open +Status: Feedback Bug Type: Strings related Operating System: FreeBSD 6.3 PHP Version: 5.2.5 New Comment: What exactly IS in that file? It's impossible to test this without the data.. Previous Comments: [2008-02-07 18:31:06] sergey89 at gmail dot com Description: substr don't work correctly with binary strings on FreeBSD 6.3, PHP 5.2.5. I have some binary file. When i tried to cut part of data i get incorrect result. - mbstring.function_overload 0 Reproduce code: --- Expected result: 45e26dc33aad8e93f3f45c8d5100feb0 | 03d900cc2ba7276fb3bb3f1939303e3b Actual result: -- 45e26dc33aad8e93f3f45c8d5100feb0 | d1cea9d93cb48b2d897595f5e96ba352 -- Edit this bug report at http://bugs.php.net/?id=44072&edit=1
#44080 [Opn->Fbk]: Session misbehaviour with Mozilla browsers
ID: 44080 Updated by: [EMAIL PROTECTED] Reported By: k dot mcmanus at gre dot ac dot uk -Status: Open +Status: Feedback Bug Type: Session related Operating System: Solaris and Windows PHP Version: 5.2.5 New Comment: You're not using PHP 5.2.5 in any place? I'd suggest upgrading first. And then check what your session.* settings are in your php.ini file. (or rather from the phpinfo(); output) Previous Comments: [2008-02-13 17:51:47] svenne at krap dot dk for me the bug creeps up in old, stable code that suddently doesn't work any more. as original poster said, IE works fine, FF does not. The bug is also not present in konqueror (kde browser) nor epiphany (gnome browser) As OP said, strings entered to the session object (in my case indirectly via some custom classes) are kept, values from database seems kept, values from queries (GET/POST) are dropped. My server runs Linux (Gentoo, mostly stable) [2008-02-09 02:43:02] k dot mcmanus at gre dot ac dot uk Description: I have EXACTLY the same files on 2 different Apache (Solaris) servers and an IIS server. The example works correctly with IE5.5, 6 and 7 and Opera 9 clients but with Firefox (2.0.0.12 or 2.0.0.11) or Mozilla (1.7.10) clients. Yes, cookies are on in the clients and I have tried restarting the clients and tried several client machines. Please feel free to try the examples... PHP 4.3.10 on Apache http://staffweb.cms.gre.ac.uk/~mk05/session/index.php PHP5.0.5 on Apache http://stuweb.cms.gre.ac.uk/~mk05/session/index.php PHP5.2.3 on IIS http://cms-stu-iis.gre.ac.uk/mk05/session/index.php When you reach activate.php $_SESSION has remembered literals but has forgotten variable values. I am at a loss to explain why it refuses to work in Moz clients. I am am even more confused at to why commenting out the line in register.php fixes the problem. I am not at all clear as to whether the problem lies with Mozilla or PHP. The fact that it affects such a range of versions of both PHP and Mozilla is also mystifying. I cannot imaging what possible mechanism could cause this effect. Reproduce code: --- http://staffweb.cms.gre.ac.uk/~mk05/session/index.php.txt http://staffweb.cms.gre.ac.uk/~mk05/session/register.php.txt http://staffweb.cms.gre.ac.uk/~mk05/session/activate.php.txt These are links not copies so you see exactly the same source. Expected result: 3 stage process index.php -> register.php -> activate.php (you don't need to fill in the forms, just press the buttons) form input from index.php is posted to register.php in register.php the POST data is copied into $_SESSION together with a string literal in activate.php the session values are printed Actual result: -- in activate.php the session has lost the values of the variables but not the value of the literal - only with Mozilla/Firefox browsers -- Edit this bug report at http://bugs.php.net/?id=44080&edit=1
#44096 [Opn->Fbk]: iconv: wrong charset
ID: 44096
Updated by: [EMAIL PROTECTED]
Reported By: cpuidle at gmx dot de
-Status: Open
+Status: Feedback
Bug Type: ICONV related
Operating System: WinXP
PHP Version: 5.2.5
New Comment:
In what charset is the input here..?
Previous Comments:
[2008-02-11 08:40:15] cpuidle at gmx dot de
Description:
Trying simple charset conversion with iconv:
iconv('iso-8859-1', 'utf-8', 'test');
receive this error:
Notice: iconv() [function.iconv]: Wrong charset, conversion from
`ISO8859-1' to `UTF-8' is not allowed in /var/htdocs/test.php on line 5
Problem: no troubleshooting information available, e.g. list or
supported charsets or similiar.
How can this be diagnosed?
Reproduce code:
---
error_reporting(E_ALL);
$res = iconv('iso-8859-1', 'utf-8', 'test');
Expected result:
No error and/or supporting functions to aid diagnostics.
Actual result:
--
Error message:
Notice: iconv() [function.iconv]: Wrong charset, conversion from
`ISO8859-1' to `UTF-8' is not allowed in /var/htdocs/test.php on line 5
--
Edit this bug report at http://bugs.php.net/?id=44096&edit=1
#44080 [Com]: Session misbehaviour with Mozilla browsers
ID: 44080 Comment by: svenne at krap dot dk Reported By: k dot mcmanus at gre dot ac dot uk Status: Open Bug Type: Session related Operating System: Solaris and Windows PHP Version: 5.2.5 New Comment: for me the bug creeps up in old, stable code that suddently doesn't work any more. as original poster said, IE works fine, FF does not. The bug is also not present in konqueror (kde browser) nor epiphany (gnome browser) As OP said, strings entered to the session object (in my case indirectly via some custom classes) are kept, values from database seems kept, values from queries (GET/POST) are dropped. My server runs Linux (Gentoo, mostly stable) Previous Comments: [2008-02-09 02:43:02] k dot mcmanus at gre dot ac dot uk Description: I have EXACTLY the same files on 2 different Apache (Solaris) servers and an IIS server. The example works correctly with IE5.5, 6 and 7 and Opera 9 clients but with Firefox (2.0.0.12 or 2.0.0.11) or Mozilla (1.7.10) clients. Yes, cookies are on in the clients and I have tried restarting the clients and tried several client machines. Please feel free to try the examples... PHP 4.3.10 on Apache http://staffweb.cms.gre.ac.uk/~mk05/session/index.php PHP5.0.5 on Apache http://stuweb.cms.gre.ac.uk/~mk05/session/index.php PHP5.2.3 on IIS http://cms-stu-iis.gre.ac.uk/mk05/session/index.php When you reach activate.php $_SESSION has remembered literals but has forgotten variable values. I am at a loss to explain why it refuses to work in Moz clients. I am am even more confused at to why commenting out the line in register.php fixes the problem. I am not at all clear as to whether the problem lies with Mozilla or PHP. The fact that it affects such a range of versions of both PHP and Mozilla is also mystifying. I cannot imaging what possible mechanism could cause this effect. Reproduce code: --- http://staffweb.cms.gre.ac.uk/~mk05/session/index.php.txt http://staffweb.cms.gre.ac.uk/~mk05/session/register.php.txt http://staffweb.cms.gre.ac.uk/~mk05/session/activate.php.txt These are links not copies so you see exactly the same source. Expected result: 3 stage process index.php -> register.php -> activate.php (you don't need to fill in the forms, just press the buttons) form input from index.php is posted to register.php in register.php the POST data is copied into $_SESSION together with a string literal in activate.php the session values are printed Actual result: -- in activate.php the session has lost the values of the variables but not the value of the literal - only with Mozilla/Firefox browsers -- Edit this bug report at http://bugs.php.net/?id=44080&edit=1
#44108 [Opn->Bgs]: SimpleXMLelement has no children() on element with only attributes?
ID: 44108
Updated by: [EMAIL PROTECTED]
Reported By: php dot net at trueprices dot net
-Status: Open
+Status: Bogus
Bug Type: SimpleXML related
Operating System: Debian
PHP Version: 5.2.5
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
xpath does not set the namespace scope of the returned
SimpleXMLelement.
You are required to set the namespace as demonstrated in previous
comment
Previous Comments:
[2008-02-13 16:22:56] hubert dot roksor at gmail dot com
If $child2 is then $child3 will be or
and there will be no $child4.
Unless this behaviour is considered as a bug by the developer and until
it is fixed, you'll have to specify the children's namespace when
calling children():
- $child2->children('http://schemas.xmlsoap.org/wsdl/') on PHP 5.1 and
later or
- $child2->children('wsdl', true) on PHP 5.2 and later
[2008-02-13 12:47:53] php dot net at trueprices dot net
Description:
SimpleXMLelement has no children() on element with only attributes?
I try to retreive an element by xpath which goes without problems, The
child elements it contains (same namespace) are all empty element with
only attributes. However the returned SimpleXML element does not contain
any children? so i'm unable to retreive there attributes.
Reproduce code:
---
http://schemas.xmlsoap.org/wsdl/";
targetNamespace="http://www.w3.org/2001/XMLSchema";
>
';
echo '';
$xml = simplexml_load_string($data);
if ($xml)
{
$res2 = $xml->xpath('//wsdl:portType/wsdl:operation');
//print_r($res);
foreach ($res2 as $child2)
{
//print_r($child2->children());
echo 'child2'.PHP_EOL;
print_r($child2->getName().PHP_EOL);
print_r(count($child2->children()).PHP_EOL);
print_r($child2);
foreach ($child2->children() as $child3)
{
echo 'child3'.PHP_EOL;
print_r($child3->getName().PHP_EOL);
print_r(count($child3->children()).PHP_EOL);
print_r($child3);
foreach ($child3->children() as $child4)
{
echo 'child4'.PHP_EOL;
print_r($child4->getName().PHP_EOL);
print_r(count($child4->children()).PHP_EOL);
print_r($child4);
}
}
}
}
echo '';
?>
Expected result:
child2 & child3 & child4 should be printed..
child2
operation
2
SimpleXMLElement Object
(
[EMAIL PROTECTED] => Array
(
[name] => SOAP_set
)
)
child2
operation
2
SimpleXMLElement Object
(
[EMAIL PROTECTED] => Array
(
[name] => SOAP_set
)
/* 2 another simplexml element input & output with children &
attributes*/
)
Actual result:
--
Only child2 prints with 0 children
child2
operation
0
SimpleXMLElement Object
(
[EMAIL PROTECTED] => Array
(
[name] => SOAP_set
)
)
child2
operation
0
SimpleXMLElement Object
(
[EMAIL PROTECTED] => Array
(
[name] => SOAP_get
)
)
--
Edit this bug report at http://bugs.php.net/?id=44108&edit=1
#41350 [Com]: Error in my_thread_global_end()
ID: 41350 Comment by: byerly0503 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 New Comment: This bug caused me to spend an hour on the issue. I kept ignoring all of the help related to MySQL since the script I was trying to run, didn't use MySQL. Please fix this by including the right DLL or adjust the installer to give a warning message: "Despite downloading this package, you will need to download an older package, replace the mysql dll, in order to use PHP." Previous Comments: [2008-02-08 06:56:04] OPunWide at hotmail dot com I'm a newbie at this, and am installing php for the first time. Very basic setup, running WinXP, using IIS 5.1 and PHP 5.2.5, installed using the Windows installer. When I first installed I included support for MySQL in the options, but had not installed MySQL. The error happened with a psp script consisting only of pspinfo(). I went back to the installer and removed support for MySQL and the problem went away. I don't think the folks at MySQL can be blamed for this one. [2008-02-07 22:27:08] WS6TA at txlanes dot com I have to agree about the impression this makes on potential LAMP adopters. I am a long-time Windows/MSSQL person looking at the LAMP stack as an alternative to MS. However, I download PHP 5.2.5 and start reading the manual only to get the error "Error in my_thread_global_end()" the first time I used the CLI. So, I go searching and find all kinds of references to dll swaps for PHP side AND the MySQL side. I don't even have MySQL installed yet... I was looking at PHP's ability to be a standalone scripting tool as well as a web-database tool. Anyway, I then find this thread where it appears the bug has been around since approximately May 2007 and PHP version 5.2.3. I commented out "extension=php_mysql.dll" in the php.ini to stop the error, but I think I will want this extension once I install MySQL. My hat's off to the people that started and have contributed to the PHP codebase. Please understand that I am not trying to bash anyone. I simply want to reiterate the PHP is crucial component to the LAMP stack and having to search for a bug fix on the very first run discourages potential new adopters. I'm very impressed with what I know about PHP thus far and would hate to think a potential adopter could be discouraged at square one in their evaluation. [2008-01-22 20:30:48] codeslinger at compsalot dot com Ping, Can we get php updated please? This problem is now one year old. Everyone who updates to the latest Windows php = 5.2.5 encounters this bug, it results in total breakage of loading the mysql dll. This bug has cost thousands upon thousands of man-hours to be expended/wasted by site admins in trying to locate the cause of the problem and the fix for it. In some cases it has also caused people to abandon the use of php-mysql programs altogether. According to MySQL Bug: http://bugs.mysql.com/bug.php?id=25621 The final resolution is that the problem was with mysql not php and that the problem was fixed awhile ago, and that all that is needed is for php to update to the latest mysql library. Given the fundamental importance of the php mysql interface, as in LAMP, it is inexplicable that it has taken an entire year to resolve what appears to have been a fairly simple fix. [2008-01-11 21:39:37] jmair at parkcountyre2 dot org IIS 6 on Windows 2003 server fully patched. php 5.2.5 mysql This issue was killing me for a week. I tried every successful attempt from previous posts and no resolve. I was also getting this problem with no mysql. I downloaded and installed fastcgi and followed the manual install for fastcgi and php, not only is the Php not displaying the error, but it's running faster than I've ever seen, maybe almost as fast as a linux box =0 hope this helps somebody. here is the link. http://www.iis.net/articles/view.aspx/IIS7/Hosting-Web-Applications/PHP/Using-FastCGI-to-Host-PHP-Applications-on-IIS-6-0-?Page=2 [2008-01-10 17:49:50] amoo_miki at yahoo dot com This is caused by windows security: to be sure: 1) Check if the drive where PHP is installed is an NTFS partition. 2) If yes, "Read & Execute" for "Everyone" for the "ext" folder. php -v at the command-line should not show you the error anymore. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report
#44111 [Opn->Bgs]: get_object_vars() produces different output with 5.2.3 and 5.2.5
ID: 44111
Updated by: [EMAIL PROTECTED]
Reported By: leandro dot rhcp99 at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Ubuntu 7.10
PHP Version: 5.2.5
New Comment:
change the "private" to "public" and it works like you expect. No bug
here.
Previous Comments:
[2008-02-13 17:05:56] leandro dot rhcp99 at gmail dot com
Description:
I'm php user and move my php projects from 5.2.3 to 5.2.5. In this
changing I've got some problems on function get_object_vars. And seeing
the changelog (http://bugs.php.net/bug.php?id=40757) I've noted that
have some changes on this function.
Reproduce code:
---
class Modelo {
public function __construct() {
echo "Construtor Teste:";
echo "";
print_r(array_keys(get_object_vars($this)));
echo "";
}
}
class Teste extends Modelo {
//Atributte
private $atributo1;
private $atributo2;
public function setAtributo1($atributo1) {
$this->atributo1 = $atributo1;
}
public function getAtributo1(){
return $this->atributo1;
}
public function setAtributo2($atributo2) {
$this->atributo2 = $atributo2;
}
public function getAtributo2(){
return $this->atributo2;
}
}
$objeto = new Teste();
Expected result:
Array
(
[0] => atributo1
[1] => atributo2
)
Actual result:
--
Array
(
)
--
Edit this bug report at http://bugs.php.net/?id=44111&edit=1
#44111 [NEW]: Function get_object_vars produce diferent output when use on 5.2.3 and 5.2.5
From: leandro dot rhcp99 at gmail dot com
Operating system: Ubuntu 7.10
PHP version: 5.2.5
PHP Bug Type: Unknown/Other Function
Bug description: Function get_object_vars produce diferent output when use on
5.2.3 and 5.2.5
Description:
I'm php user and move my php projects from 5.2.3 to 5.2.5. In this
changing I've got some problems on function get_object_vars. And seeing the
changelog (http://bugs.php.net/bug.php?id=40757) I've noted that have some
changes on this function.
Reproduce code:
---
class Modelo {
public function __construct() {
echo "Construtor Teste:";
echo "";
print_r(array_keys(get_object_vars($this)));
echo "";
}
}
class Teste extends Modelo {
//Atributte
private $atributo1;
private $atributo2;
public function setAtributo1($atributo1) {
$this->atributo1 = $atributo1;
}
public function getAtributo1(){
return $this->atributo1;
}
public function setAtributo2($atributo2) {
$this->atributo2 = $atributo2;
}
public function getAtributo2(){
return $this->atributo2;
}
}
$objeto = new Teste();
Expected result:
Array
(
[0] => atributo1
[1] => atributo2
)
Actual result:
--
Array
(
)
--
Edit bug report at http://bugs.php.net/?id=44111&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=44111&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44111&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44111&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44111&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44111&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44111&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44111&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44111&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44111&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44111&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44111&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44111&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44111&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44111&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44111&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=44111&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44111&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44111&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44111&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44111&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44111&r=mysqlcfg
#44090 [Fbk->Csd]: php won't load on vista...
ID: 44090 User updated by: ombladon_1991_arad at yahoo dot com Reported By: ombladon_1991_arad at yahoo dot com -Status: Feedback +Status: Closed Bug Type: Apache2 related Operating System: VISTA ULTIMATE PHP Version: 5.2.5 New Comment: if i install apache+php doesnt work... but if i install wamp it works perfect... so i guess bug closed lol...probably vista needs some tweaks to run php corectly and wamp has those^^ Previous Comments: [2008-02-13 17:00:52] [EMAIL PROTECTED] And you're sure that short_open_tag is enabled for you? Try this instead: [2008-02-10 10:26:24] ombladon_1991_arad at yahoo dot com Description: php doesn't load on vista.. i did install it, runs perfect...but after rebot when i try to load a php page i get a blank page Reproduce code: --- Expected result: the info Actual result: -- blank page -- Edit this bug report at http://bugs.php.net/?id=44090&edit=1
#44087 [Opn->Fbk]: Not using correct libxml
ID: 44087 Updated by: [EMAIL PROTECTED] Reported By: hz at nyphp dot com -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: CentOS 4.5 x86_64 PHP Version: 5.2.5 New Comment: You need to set the library paths correctly in /etc/ld.so.conf and make sure the path to the new libxml2 libraries is above any other like /usr/lib64 Previous Comments: [2008-02-09 18:19:35] hz at nyphp dot com Description: CentOS 4.5 comes with an older version of libxml2, so I've compiled my own version and installed to /usr/local Then I configure PHP using: ./configure \ --with-libdir=lib64 \ --prefix=/usr/local/php \ --with-apxs=/usr/local/apache/bin/apxs \ --with-openssl \ --with-zlib \ --with-curl \ --with-mysql=/usr \ --with-mysqli=/usr/bin/mysql_config \ --disable-pdo \ --without-sqlite \ --enable-pcntl \ --with-xsl=/usr/local \ --with-libxml-dir=/usr/local make fails with errors as in bug #39940. When I move /usr/lib64/libxml2* to a temporary directory (and rerun ldconfig), I get the following error during make: ... -lxml2 -lz -lm -lcrypt -o libphp5.la grep: /usr/lib64/libxml2.la: No such file or directory /bin/sed: can't read /usr/lib64/libxml2.la: No such file or directory libtool: link: `/usr/lib64/libxml2.la' is not a valid libtool archive make: *** [libphp5.la] Error 1 So obviously PHP is not completely listening to where I told it to find libxml2. However, during ./configure, it indicates /usr/local/bin/xml2-config is being used. -- Edit this bug report at http://bugs.php.net/?id=44087&edit=1
#44090 [Opn->Fbk]: php won't load on vista...
ID: 44090 Updated by: [EMAIL PROTECTED] Reported By: ombladon_1991_arad at yahoo dot com -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: VISTA ULTIMATE PHP Version: 5.2.5 New Comment: And you're sure that short_open_tag is enabled for you? Try this instead: Previous Comments: [2008-02-10 10:26:24] ombladon_1991_arad at yahoo dot com Description: php doesn't load on vista.. i did install it, runs perfect...but after rebot when i try to load a php page i get a blank page Reproduce code: --- Expected result: the info Actual result: -- blank page -- Edit this bug report at http://bugs.php.net/?id=44090&edit=1
#44091 [Opn->Fbk]: CGI / FastCGI has encountered a problem and needs to close
ID: 44091 Updated by: [EMAIL PROTECTED] Reported By: jeremic1974 at yahoo dot com -Status: Open +Status: Feedback Bug Type: CGI related Operating System: Windows XP Professional PHP Version: 5.2.5 New Comment: 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 Previous Comments: [2008-02-10 19:03:22] jeremic1974 at yahoo dot com I think that the problem is connected with PHP on Tomcat. If I deploy PHP application on Apache it works fine. However, any PHP application deployed to the Tomcat fires this errors. When I have install PHP I have choose Apache 2.2 module. Do I have to configure something in Tomcat to work with PHP? [2008-02-10 15:51:05] jeremic1974 at yahoo dot com Description: I'm trying to install PHP/Java v5.1.2 (as well as 4.3.1) to the Tomcat 6 (and to the Tomcat 5.5.4 too). However, each time I try to access it through Web browser I got a plenty of error message: "CGI / FastCGI has encountered a problem and needs to close. We are sorry for the inconvenience." -- Edit this bug report at http://bugs.php.net/?id=44091&edit=1
#42805 [Com]: gzuncompress data error
ID: 42805
Comment by: ugtour at gmail dot com
Reported By: dwlnetnl at users dot sourceforge dot net
Status: No Feedback
Bug Type: Zlib Related
Operating System: Mac OS X 10.4.10 Intel
PHP Version: 5.2.4
New Comment:
never mind its working fine.
Previous Comments:
[2008-02-13 16:46:10] ugtour at gmail dot com
bug, please fix it
[2008-01-30 18:06:11] legolas558 at users dot sourceforge dot net
Same problem here, with PHP5.
Zlib compiled version: 1.2.1.1
Zilb linked version: 1.2.3
On my local host I have both versions 1.2.3 and it works fine
[2007-10-09 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-10-01 10:47:06] [EMAIL PROTECTED]
Your example script works just fine for me.
Exactly what PHP version are you using? And with what zlib version do
you link PHP with?
[2007-10-01 00:54:25] dwlnetnl at users dot sourceforge dot net
Description:
When I uncompress some gzcompress()'d data I get an data error. It's
Qcodo form data.
Reproduce code:
---
$gz_base64 =
'eNrtW1tvG7kVzk8RBuhLgbXusj3uFpBlp3Fry3KkJEBfDGqGlhhTpJakfNnA/e09vAw5M5a0MrraBNt5CRyeQ/Lj4bl8pDjX8XEcnSE5n3Ik0ihuNeNvMm724ujdX99RqQYUSTlECyyjk+v4KI5uLolUp/wpinsto9oxqlKJgZRGOzqR8WEcUdCbgh78DwaN3mUdT5HE7whTH/kjqJK4qRVa2SCXaIrpey4+4l9WROBUd9dT/EXWiKyJXGvreFOfT4wBYKMEgAsjdU0fPv16ofBirJ4p1svSExh4oVWrfvMdYJJTlNwPOOUiOhnqkQ69gIsUiy0iN42MwahDrsZYRWu0vpBUzd0Aa0yaa59S9p4zMCWFNU3jxonfLye5UIiSxMv8ErTMbaUZ7ijf6foBC0oY9t06+W5j8it2vY7zvcZKkHvMV8p3K4g/sbQ0ag6MwHmjeQ/4gMlsrlxrM2v15nnxc0DrGFOcKMLZFU8zE48Jm1l7BxP/Ez2gcSLIUhnv1Oa6TQBA3TnpwVffHtxD9oVAz9EJipvt+BsB/Nc6WLyjRLF1kUY2i7Zt5q8/1Sy22jXDtZ+iwlo+I7rC5S216tpNhwU76Zn+IfhqWRAUPRisouNoR3hglX6aCmwj9RUsawanoQcbIYZp9PuCbe0KFqAM4E+BNmHtZgr7gtreFapGAm6YbELacfJ9Ae3sChSmfE9ciKzB2bbifcHs7goT0tMlT5AO701QD4PKvuD2do56yGDXYoYYkdsw61qYV9sX7sM3RNgIC7nZyN1MYV9Qj96QuUaCf4XZtmQup7EvsMe7gj3W1AOKTAr1aBPco5zOvgA3G2/ICxO03JYXtHhvOJtviTSDZHt20JGWV9sb8NYbDPxJYrHFwFq8H5wv34vMtrMFnBG5pJpQTQ3nd/QT+jjBhqG/N+k129ZsLM1JZl/s1xoJTkXXS5QQ9Vze5H6SABv7F3YCd15akKcBWkkswYdI6mLB!
TeX59GAFuVu8tqvfl3OGphSnfl+8wcPJqWAdQDlB0wtY3JM+vzXCYDDbhHM6Ic4XW3kndwDPhSitGmb6TCSZUuwh7HYYMJSr2ci2puc7qQU9xXdg4rIZtaR/p7AoOIMOIgb/rMxRQhbA6dmQYCaHF89m2nfuKH/c5LGgMuKSZAmqoHIczJWFrU8Wl/hOlQ8HV/wBI2egoiMNwM8Epxf2SBxHSScKo0ESAEdbFA5u0DZCAjPlerqdamfCwZzQ1Mn8AagRf3t5ndCGJW/R7p7zo25RYkxYcE4QXbMRmuHXrgfnOXJHwmDOk0DyRaDlEou8QqOwlXa2K6zmPHWGt03GQr0QFlLxRV9BCE9XCrulDguXEVbH5KWc3CU7sFXfOEw4JuqsDzg4S+aI6WWZNnty1N570/+KnmynKG7nLlpgLgs4qxQtMHXh9uV24Ib0toD5vyCiLhLO/FYaipTiO7SieYoEqucPsOXmrgNWd2MHs20WSAjVcFZ2fUprKnlf6jw8F6GQIM6wyfR66S8vuvaE8e36wQdhWSESfQEx1h7PMVYuEFuNXNIMG5ZJfRGw48or2LMJFgvCkPLx4sYArQt5Snlyf07xwixOy1888iWD5KXspRAMfGPLcHxo63lIcmiWbRS0peTBbIu3ypndgHJZA/lUzx39BqBmoUzplHXOFFhZL9k5uzfJBD+pcmKa4AXMq1yAtnxM9VeK20gwMQ45wI/nVzZCaRpynbftmeDLCRIz7Ctd2M8PXJBfwQER7VMye53rwm3NZywUSTbpOaDgqzrbSefTspSDgpbGtFGrW9Ay9AiWVVYLKfFCasV/c4bf6+qUKbR9Hv2kk85HLIESbJgz6F7yx9/QbR2GbKXVPiCWUnwGxTYJ0eQWoa9Kc0pXhJHFarFVBT0FlR/mBtO6WZpdNd8qXfr+BPxwWNHCH4sWDisymJHBZkUGvxcZdIl+V9pT+IVi74wo7B8wHutj/zeEp1kR!
norw/EGEp5MnPNTEWcV4KsZTMZ69MZ5WxXgqxrOB8fg7no82lirKU1GeivL8zpSnm6c8wg
ZaxXkqzlNxnr1xnnbFeSrOs57ztD2yixmD6AgA9BO/cnUrKQdIa5RDmGp41hkLT8lDfELO0DpjhdTKPPluZQu40e3mQbh2w5IHGkLmbjEFjNULFF8AR2gF7xcA/Sj8/i3iTNaN3NOc7JfSKO41i29zLLvSCQa24m9kMatJkfwc1f+TPlKGFaN1uSQp4bfygdUhYbD7+uPjYx3KHexUnSzAl6VWYQyL22bnYEbuotqjzlE/R81OVJubJGb/RhT+GFEMC65pRAcHB1H979EWdraOjkLEyCViG8vqfqjbj/USvmINFWuoWMP/xBq6fzrW0KhYwx/xWiY72xaKd3b8Xr/G3K6f8vQZilk2V7tbVhjMcXKvfbjoW6VygCidPC+zejjkrPQ0yt3P+LoPpKDTaIcriLKBylSoHQI+oasUpxuYUy/7Bs5+T/RLwlNuviYKvu2+NOKzGRZ5ke+E9TurvKSdSZZcFgT+u6XE2matLP9Nk5atXc5WbheuuUYCPxC+kjqvY6nsZ1Z6K8yIwQNcynSj6yFHyD7R7EE2qetnzbLuGdWYKEuaXvOqpb6Nu00FutPsSheMA7WkB8v5MtrGB46zMjMEOpdLdfr7jZf/AluLSsY='
$gz = base64_decode($gz_base64);
echo gzuncompress($gz);
Expected result:
O:9:"Dashboard":21:{s:16:"
Actual result:
--
PHP Warning: gzuncompress(): data error
--
Edit this bug report at http://bugs.php.net/?id=42805&edit=1
#44101 [Opn->Fbk]: Exceptions thrown with html_errors = on are partially formatted
ID: 44101
Updated by: [EMAIL PROTECTED]
Reported By: johnston dot joshua at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: any
PHP Version: 5.2.5
New Comment:
Exactly what is not right there?
Previous Comments:
[2008-02-11 22:08:14] johnston dot joshua at gmail dot com
Description:
When an exception is thrown and not caught and html_errors = on the
Fatal Error text is only partially formatted. When you 'view source' in
your web browser you can see the stact trace is nicely formatted but has
no format for content-type: text/html
Actual result:
--
Fatal error: Uncaught exception
'Zend_Controller_Action_Exception' with message
'Portal_TrialController::helloAction() does not exist and was not
trapped in __call()' in /code/dev/php/Zend/Controller/Action.php:480
Stack trace:
#0 [internal function]:
Zend_Controller_Action->__call('helloAction', Array)
#1 /code/dev/php/Zend/Controller/Action.php(497):
Portal_TrialController->helloAction()
#2 /code/dev/php/Zend/Controller/Dispatcher/Standard.php(238):
Zend_Controller_Action->dispatch('helloAction')
#3 /code/dev/php/Zend/Controller/Front.php(920):
Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http),
Object(Zend_Controller_Response_Http))
#4 /home/jjohnston/svn/dev/www/bootstrap.php(96):
Zend_Controller_Front->dispatch()
#5 /home/jjohnston/svn/dev/www/bootstrap.php(6):
MailWise_Bootstrap::main()
#6 {main}
thrown in /code/dev/php/Zend/Controller/Action.php on line
480
--
Edit this bug report at http://bugs.php.net/?id=44101&edit=1
#44110 [Opn->Bgs]: intval problem with conversion from float to int (without decimal places)
ID: 44110 Updated by: [EMAIL PROTECTED] Reported By: dstuff at brainsware dot org -Status: Open +Status: Bogus Bug Type: *Math Functions Operating System: Any PHP Version: 5.2.5 New Comment: Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about "floats" and what IEEE 754 is, read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. Previous Comments: [2008-02-13 16:14:03] dstuff at brainsware dot org Description: Some float values after multiplication by 100 (for elemination of decimal places) get rounded down by one after running intval() on the result. Reproduce code: --- '; } } ?> Expected result: Expected value after evaluation: 7047 Actual result: -- Actual value after evaluation: 7073 -- Edit this bug report at http://bugs.php.net/?id=44110&edit=1
#44102 [Opn->Fbk]: Problem with compiling SQL Relay & PHP
ID: 44102 Updated by: [EMAIL PROTECTED] Reported By: admin at relax-info dot com -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: MAC OS X Leopard 10.5.1 PHP Version: 5.2.5 New Comment: Exactly what does this has to do with PHP? Your log is for something else than building PHP, AFAICT. You should propably be asking support from the sql relay folks.. Previous Comments: [2008-02-11 22:18:56] admin at relax-info dot com Description: After PHP compilation the libphp.a are not present on MAC OS X Reproduce code: --- The PHP configure options: /configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --mandir=/usr/share/man --infodir=/usr/share/info --with-apxs2=/usr/sbin/apxs --with-curl --with-gd --enable-exif --enable-cli --enable-zip --with-jpeg-dir=/usr/src/libjpeg --with-zlib=/usr --with-config-file-path=/etc --with-openssl --with-xmlrpc --with-xsl=/usr --without-pear --with-mysql=/usr/local/mysql --with-mysql-sock=/var/mysql --with-mysqli=/usr/local/mysql/bin/mysql_config --disable-ipv6 Expected result: Compile SQL Relay as "Additional Modules" Actual result: -- first try errors : ld: library not found for -lphp collect2: ld returned 1 exit status make[4]: *** [libsql_relay.la] Error 1 Full log: http://relax-info.com/data/file/Installing_sql_relay.txt -- Edit this bug report at http://bugs.php.net/?id=44102&edit=1
#42805 [Com]: gzuncompress data error
ID: 42805
Comment by: ugtour at gmail dot com
Reported By: dwlnetnl at users dot sourceforge dot net
Status: No Feedback
Bug Type: Zlib Related
Operating System: Mac OS X 10.4.10 Intel
PHP Version: 5.2.4
New Comment:
bug, please fix it
Previous Comments:
[2008-01-30 18:06:11] legolas558 at users dot sourceforge dot net
Same problem here, with PHP5.
Zlib compiled version: 1.2.1.1
Zilb linked version: 1.2.3
On my local host I have both versions 1.2.3 and it works fine
[2007-10-09 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-10-01 10:47:06] [EMAIL PROTECTED]
Your example script works just fine for me.
Exactly what PHP version are you using? And with what zlib version do
you link PHP with?
[2007-10-01 00:54:25] dwlnetnl at users dot sourceforge dot net
Description:
When I uncompress some gzcompress()'d data I get an data error. It's
Qcodo form data.
Reproduce code:
---
$gz_base64 =
'eNrtW1tvG7kVzk8RBuhLgbXusj3uFpBlp3Fry3KkJEBfDGqGlhhTpJakfNnA/e09vAw5M5a0MrraBNt5CRyeQ/Lj4bl8pDjX8XEcnSE5n3Ik0ihuNeNvMm724ujdX99RqQYUSTlECyyjk+v4KI5uLolUp/wpinsto9oxqlKJgZRGOzqR8WEcUdCbgh78DwaN3mUdT5HE7whTH/kjqJK4qRVa2SCXaIrpey4+4l9WROBUd9dT/EXWiKyJXGvreFOfT4wBYKMEgAsjdU0fPv16ofBirJ4p1svSExh4oVWrfvMdYJJTlNwPOOUiOhnqkQ69gIsUiy0iN42MwahDrsZYRWu0vpBUzd0Aa0yaa59S9p4zMCWFNU3jxonfLye5UIiSxMv8ErTMbaUZ7ijf6foBC0oY9t06+W5j8it2vY7zvcZKkHvMV8p3K4g/sbQ0ag6MwHmjeQ/4gMlsrlxrM2v15nnxc0DrGFOcKMLZFU8zE48Jm1l7BxP/Ez2gcSLIUhnv1Oa6TQBA3TnpwVffHtxD9oVAz9EJipvt+BsB/Nc6WLyjRLF1kUY2i7Zt5q8/1Sy22jXDtZ+iwlo+I7rC5S216tpNhwU76Zn+IfhqWRAUPRisouNoR3hglX6aCmwj9RUsawanoQcbIYZp9PuCbe0KFqAM4E+BNmHtZgr7gtreFapGAm6YbELacfJ9Ae3sChSmfE9ciKzB2bbifcHs7goT0tMlT5AO701QD4PKvuD2do56yGDXYoYYkdsw61qYV9sX7sM3RNgIC7nZyN1MYV9Qj96QuUaCf4XZtmQup7EvsMe7gj3W1AOKTAr1aBPco5zOvgA3G2/ICxO03JYXtHhvOJtviTSDZHt20JGWV9sb8NYbDPxJYrHFwFq8H5wv34vMtrMFnBG5pJpQTQ3nd/QT+jjBhqG/N+k129ZsLM1JZl/s1xoJTkXXS5QQ9Vze5H6SABv7F3YCd15akKcBWkkswYdI6mLB!
TeX59GAFuVu8tqvfl3OGphSnfl+8wcPJqWAdQDlB0wtY3JM+vzXCYDDbhHM6Ic4XW3kndwDPhSitGmb6TCSZUuwh7HYYMJSr2ci2puc7qQU9xXdg4rIZtaR/p7AoOIMOIgb/rMxRQhbA6dmQYCaHF89m2nfuKH/c5LGgMuKSZAmqoHIczJWFrU8Wl/hOlQ8HV/wBI2egoiMNwM8Epxf2SBxHSScKo0ESAEdbFA5u0DZCAjPlerqdamfCwZzQ1Mn8AagRf3t5ndCGJW/R7p7zo25RYkxYcE4QXbMRmuHXrgfnOXJHwmDOk0DyRaDlEou8QqOwlXa2K6zmPHWGt03GQr0QFlLxRV9BCE9XCrulDguXEVbH5KWc3CU7sFXfOEw4JuqsDzg4S+aI6WWZNnty1N570/+KnmynKG7nLlpgLgs4qxQtMHXh9uV24Ib0toD5vyCiLhLO/FYaipTiO7SieYoEqucPsOXmrgNWd2MHs20WSAjVcFZ2fUprKnlf6jw8F6GQIM6wyfR66S8vuvaE8e36wQdhWSESfQEx1h7PMVYuEFuNXNIMG5ZJfRGw48or2LMJFgvCkPLx4sYArQt5Snlyf07xwixOy1888iWD5KXspRAMfGPLcHxo63lIcmiWbRS0peTBbIu3ypndgHJZA/lUzx39BqBmoUzplHXOFFhZL9k5uzfJBD+pcmKa4AXMq1yAtnxM9VeK20gwMQ45wI/nVzZCaRpynbftmeDLCRIz7Ctd2M8PXJBfwQER7VMye53rwm3NZywUSTbpOaDgqzrbSefTspSDgpbGtFGrW9Ay9AiWVVYLKfFCasV/c4bf6+qUKbR9Hv2kk85HLIESbJgz6F7yx9/QbR2GbKXVPiCWUnwGxTYJ0eQWoa9Kc0pXhJHFarFVBT0FlR/mBtO6WZpdNd8qXfr+BPxwWNHCH4sWDisymJHBZkUGvxcZdIl+V9pT+IVi74wo7B8wHutj/zeEp1kR!
norw/EGEp5MnPNTEWcV4KsZTMZ69MZ5WxXgqxrOB8fg7no82lirKU1GeivL8zpSnm6c8wg
ZaxXkqzlNxnr1xnnbFeSrOs57ztD2yixmD6AgA9BO/cnUrKQdIa5RDmGp41hkLT8lDfELO0DpjhdTKPPluZQu40e3mQbh2w5IHGkLmbjEFjNULFF8AR2gF7xcA/Sj8/i3iTNaN3NOc7JfSKO41i29zLLvSCQa24m9kMatJkfwc1f+TPlKGFaN1uSQp4bfygdUhYbD7+uPjYx3KHexUnSzAl6VWYQyL22bnYEbuotqjzlE/R81OVJubJGb/RhT+GFEMC65pRAcHB1H979EWdraOjkLEyCViG8vqfqjbj/USvmINFWuoWMP/xBq6fzrW0KhYwx/xWiY72xaKd3b8Xr/G3K6f8vQZilk2V7tbVhjMcXKvfbjoW6VygCidPC+zejjkrPQ0yt3P+LoPpKDTaIcriLKBylSoHQI+oasUpxuYUy/7Bs5+T/RLwlNuviYKvu2+NOKzGRZ5ke+E9TurvKSdSZZcFgT+u6XE2matLP9Nk5atXc5WbheuuUYCPxC+kjqvY6nsZ1Z6K8yIwQNcynSj6yFHyD7R7EE2qetnzbLuGdWYKEuaXvOqpb6Nu00FutPsSheMA7WkB8v5MtrGB46zMjMEOpdLdfr7jZf/AluLSsY='
$gz = base64_decode($gz_base64);
echo gzuncompress($gz);
Expected result:
O:9:"Dashboard":21:{s:16:"
Actual result:
--
PHP Warning: gzuncompress(): data error
--
Edit this bug report at http://bugs.php.net/?id=42805&edit=1
#44108 [Com]: SimpleXMLelement has no children() on element with only attributes?
ID: 44108
Comment by: hubert dot roksor at gmail dot com
Reported By: php dot net at trueprices dot net
Status: Open
Bug Type: SimpleXML related
Operating System: Debian
PHP Version: 5.2.5
New Comment:
If $child2 is then $child3 will be or
and there will be no $child4.
Unless this behaviour is considered as a bug by the developer and until
it is fixed, you'll have to specify the children's namespace when
calling children():
- $child2->children('http://schemas.xmlsoap.org/wsdl/') on PHP 5.1 and
later or
- $child2->children('wsdl', true) on PHP 5.2 and later
Previous Comments:
[2008-02-13 12:47:53] php dot net at trueprices dot net
Description:
SimpleXMLelement has no children() on element with only attributes?
I try to retreive an element by xpath which goes without problems, The
child elements it contains (same namespace) are all empty element with
only attributes. However the returned SimpleXML element does not contain
any children? so i'm unable to retreive there attributes.
Reproduce code:
---
http://schemas.xmlsoap.org/wsdl/";
targetNamespace="http://www.w3.org/2001/XMLSchema";
>
';
echo '';
$xml = simplexml_load_string($data);
if ($xml)
{
$res2 = $xml->xpath('//wsdl:portType/wsdl:operation');
//print_r($res);
foreach ($res2 as $child2)
{
//print_r($child2->children());
echo 'child2'.PHP_EOL;
print_r($child2->getName().PHP_EOL);
print_r(count($child2->children()).PHP_EOL);
print_r($child2);
foreach ($child2->children() as $child3)
{
echo 'child3'.PHP_EOL;
print_r($child3->getName().PHP_EOL);
print_r(count($child3->children()).PHP_EOL);
print_r($child3);
foreach ($child3->children() as $child4)
{
echo 'child4'.PHP_EOL;
print_r($child4->getName().PHP_EOL);
print_r(count($child4->children()).PHP_EOL);
print_r($child4);
}
}
}
}
echo '';
?>
Expected result:
child2 & child3 & child4 should be printed..
child2
operation
2
SimpleXMLElement Object
(
[EMAIL PROTECTED] => Array
(
[name] => SOAP_set
)
)
child2
operation
2
SimpleXMLElement Object
(
[EMAIL PROTECTED] => Array
(
[name] => SOAP_set
)
/* 2 another simplexml element input & output with children &
attributes*/
)
Actual result:
--
Only child2 prints with 0 children
child2
operation
0
SimpleXMLElement Object
(
[EMAIL PROTECTED] => Array
(
[name] => SOAP_set
)
)
child2
operation
0
SimpleXMLElement Object
(
[EMAIL PROTECTED] => Array
(
[name] => SOAP_get
)
)
--
Edit this bug report at http://bugs.php.net/?id=44108&edit=1
#44110 [NEW]: intval problem with conversion from float to int (without decimal places)
From: dstuff at brainsware dot org Operating system: Any PHP version: 5.2.5 PHP Bug Type: *Math Functions Bug description: intval problem with conversion from float to int (without decimal places) Description: Some float values after multiplication by 100 (for elemination of decimal places) get rounded down by one after running intval() on the result. Reproduce code: --- '; } } ?> Expected result: Expected value after evaluation: 7047 Actual result: -- Actual value after evaluation: 7073 -- Edit bug report at http://bugs.php.net/?id=44110&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=44110&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44110&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44110&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44110&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44110&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44110&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44110&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44110&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44110&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44110&r=support Expected behavior:http://bugs.php.net/fix.php?id=44110&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44110&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44110&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44110&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44110&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=44110&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44110&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44110&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44110&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44110&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44110&r=mysqlcfg
#44092 [Fbk]: exp() function returns incorrect result if passed hex
ID: 44092 Updated by: [EMAIL PROTECTED] -Summary: zoe Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: *Math Functions Operating System: Linux 32 PHP Version: 5.3CVS-2008-02-10 (CVS) New Comment: (fix summary) Previous Comments: [2008-02-12 07:36:16] [EMAIL PROTECTED] commited fix to /ext/standard/math.c and /ext/standard/tests/math/exp_error.phpt in PHP5.3 and PHP 5.2 [2008-02-11 16:22:30] [EMAIL PROTECTED] Felipe - I think they should probably all change. I'm happy to work through one at a time (or maybe you'd like to fix some?), I don't really want to do them all in one update. I used exp() to make sure that I was doing the right thing. Quite a few of the tests would also need changing (because I worked around this for a while). I think sin() and cos() at least are wrong. I've also got bugs pending in number_format() and hypot() - which *might* be the same issue. Zoe [2008-02-11 16:07:30] [EMAIL PROTECTED] Hello Ilia, in this case, should all math functions in ext/standard/ use the new parsing parameter, no? Only fix the exp() sounds wrong to me... [2008-02-11 14:23:35] [EMAIL PROTECTED] Go ahead and apply the patch to the code & the test. [2008-02-10 17:27:40] [EMAIL PROTECTED] If this patch goes in, the test exp_error.phpt will need a small change too. I'm happy to do that. 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/44092 -- Edit this bug report at http://bugs.php.net/?id=44092&edit=1
#44109 [NEW]: sem_remove does not seem to take SYSVSEM_USAGE into account
From: thornza at yahoo dot com Operating system: Linux PHP version: 5.2.5 PHP Bug Type: Feature/Change Request Bug description: sem_remove does not seem to take SYSVSEM_USAGE into account Description: Two processes - processA and processB - are using a semaphore. processA sem_get()s the semaphore. (the semaphore is created) processB sem_get()s the semaphore. (the semaphore is already created, so the semaphore id is just returned) processA sem_acquire()s the semaphore and begins to work in the critical section. processB sem_acquire()s the semaphore and BLOCKS. processA finishes in it's critical section and sem_release()s. processA sem_remove()s the semaphore ***THE SEMAPHORE HAS NOW BEEN REMOVED - I think that this part is incorrect processB now is NOT able to continue as the semaphore has been removed. sem_remove() should take the SYSVSEM_USAGE (see sysvsem.c) count into consideration when it is called. Only if this count is == 1 should the semaphore be removed. This will allow the last process that is using the semaphore to remove it from the system. Reproduce code: --- Expected result: processA and processB both able to work in their critical sections without error. Actual result: -- Log messages such as the following are generated: [13-Feb-2008 14:36:30] PHP Warning: sem_acquire() [function.sem-acquire]: failed to acquire key 0x2b72: Invalid argument in /opt/MarkDW/Exec/Form.php on line 1282 -- Edit bug report at http://bugs.php.net/?id=44109&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=44109&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44109&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44109&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44109&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44109&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44109&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44109&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44109&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44109&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44109&r=support Expected behavior:http://bugs.php.net/fix.php?id=44109&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44109&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44109&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44109&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44109&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=44109&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44109&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44109&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44109&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44109&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44109&r=mysqlcfg
#43748 [Asn]: MSI installer fails with error 2738
ID: 43748 User updated by: alvaro at demogracia dot com Reported By: alvaro at demogracia dot com Status: Assigned Bug Type: *General Issues Operating System: Windows Vista PHP Version: 5.2.5 Assigned To: jmertic New Comment: Thank you, I'll test it ASAP. In case someone wants to test the new installer but has fiddled with vbscript.dll and jscript.dll, here's a link that explains how to reset it to Windows Vista default status: http://blogs.msdn.com/heaths/archive/2007/05/31/windows-installer-errors-2738-and-2739-with-script-custom-actions.aspx It seems that Microsoft discourages re-registering these DLLs from an elevated console. Previous Comments: [2008-02-08 04:30:18] [EMAIL PROTECTED] Can you retest the next snapshot release; I made some adjustments to hopefully help this out. [2008-01-28 15:33:03] [EMAIL PROTECTED] It's actually something different, more specific to Vista not liking custom actions written in VBScript unless you are running from an elevated console as you did. Other than re-writing the custom actions as managed c++, you can do one of two things - Re-register vbscript.dll or jscript.dll under an elevated console -or- - Run the installer from an elevated console. I'm going to look into re-writing the custom actions as managed C++ in the future. [2008-01-04 07:20:06] alvaro at demogracia dot com Description: I can't install any *.msi package newer that 2.5.3 under Windows Vista by double-clicking the file. Even though my user has admin rights, I need to run it from an elevated console. Installer doesn't warn about it. It starts as usual, prompts for options, asks for elevation and finally stops with this error message: "The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2738." The chosen options do not seem to make any difference. It also happens with today's snapshot (2.5.6-dev 2008-01-04): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi I believe it's not a dupe of #43230 because that fixed the problem for my Windows XP box but not for my Vista box. As I said, opening an elevated console and running it for command line does work. Reproduce code: --- Please find an excerpt from verbose logging mode output below (non-elevated console). msiexec /i php-5.2.5-win32-installer.msi /l*v error.log Full logs can be found here: http://alvaro.es/archivos/error_2.5.2_2007-12-11.log.zip [30KB] http://alvaro.es/archivos/error_2.5.6-dev_2008-01-04.log.zip [30KB] Actual result: -- [...] MSI (s) (CC:6C) [07:51:45:428]: Running as a service. MSI (s) (CC:6C) [07:51:45:432]: Hello, I'm your 32bit Impersonated custom action server. MSI (s) (CC:E4) [07:51:45:434]: Note: 1: 2205 2: 3: Error MSI (s) (CC:E4) [07:51:45:434]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 2738 DEBUG: Error 2738: Could not access VBScript runtime for custom action The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2738. The arguments are: , , MSI (s) (CC:E4) [07:51:46:615]: Note: 1: 2205 2: 3: Error MSI (s) (CC:E4) [07:51:46:615]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1709 MSI (s) (CC:E4) [07:51:46:615]: Product: PHP 5.2.3 -- The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2738. The arguments are: , , [...] MSI (c) (A8:DC) [07:51:47:896]: Windows Installer installed the product. Product Name: PHP 5.2.5. Product Version: 5.2.5. Product Language: 1033. Installation success or error status: 1603. MSI (c) (A8:DC) [07:51:47:900]: Grabbed execution mutex. MSI (c) (A8:DC) [07:51:47:900]: Cleaning up uninstalled install packages, if any exist MSI (c) (A8:DC) [07:51:47:901]: MainEngineThread is returning 1603 === Verbose logging stopped: 04/01/2008 7:51:47 === -- Edit this bug report at http://bugs.php.net/?id=43748&edit=1
#44108 [NEW]: SimpleXMLelement has no children() on element with only attributes?
From: php dot net at trueprices dot net
Operating system: Debian
PHP version: 5.2.5
PHP Bug Type: SimpleXML related
Bug description: SimpleXMLelement has no children() on element with only
attributes?
Description:
SimpleXMLelement has no children() on element with only attributes?
I try to retreive an element by xpath which goes without problems, The
child elements it contains (same namespace) are all empty element with only
attributes. However the returned SimpleXML element does not contain any
children? so i'm unable to retreive there attributes.
Reproduce code:
---
http://schemas.xmlsoap.org/wsdl/";
targetNamespace="http://www.w3.org/2001/XMLSchema";
>
';
echo '';
$xml = simplexml_load_string($data);
if ($xml)
{
$res2 = $xml->xpath('//wsdl:portType/wsdl:operation');
//print_r($res);
foreach ($res2 as $child2)
{
//print_r($child2->children());
echo 'child2'.PHP_EOL;
print_r($child2->getName().PHP_EOL);
print_r(count($child2->children()).PHP_EOL);
print_r($child2);
foreach ($child2->children() as $child3)
{
echo 'child3'.PHP_EOL;
print_r($child3->getName().PHP_EOL);
print_r(count($child3->children()).PHP_EOL);
print_r($child3);
foreach ($child3->children() as $child4)
{
echo 'child4'.PHP_EOL;
print_r($child4->getName().PHP_EOL);
print_r(count($child4->children()).PHP_EOL);
print_r($child4);
}
}
}
}
echo '';
?>
Expected result:
child2 & child3 & child4 should be printed..
child2
operation
2
SimpleXMLElement Object
(
[EMAIL PROTECTED] => Array
(
[name] => SOAP_set
)
)
child2
operation
2
SimpleXMLElement Object
(
[EMAIL PROTECTED] => Array
(
[name] => SOAP_set
)
/* 2 another simplexml element input & output with children &
attributes*/
)
Actual result:
--
Only child2 prints with 0 children
child2
operation
0
SimpleXMLElement Object
(
[EMAIL PROTECTED] => Array
(
[name] => SOAP_set
)
)
child2
operation
0
SimpleXMLElement Object
(
[EMAIL PROTECTED] => Array
(
[name] => SOAP_get
)
)
--
Edit bug report at http://bugs.php.net/?id=44108&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=44108&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44108&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44108&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44108&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44108&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44108&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44108&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44108&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44108&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44108&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44108&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44108&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44108&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44108&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44108&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=44108&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44108&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44108&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44108&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44108&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44108&r=mysqlcfg
#44098 [Fbk->Opn]: imap_utf8 returns Capitols only
ID: 44098
User updated by: steffen at dislabs dot de
Reported By: steffen at dislabs dot de
-Status: Feedback
+Status: Open
Bug Type: Network related
Operating System: Debian
PHP Version: 5.2.5
New Comment:
ok i was wrong with debian.
This is the info from phpinfo:
FreeBSD xx 6.2-RELEASE-p9 FreeBSD 6.2-RELEASE-p9 #0: Fri Dec 28
22:40:13 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP i386
Previous Comments:
[2008-02-13 01:17:20] [EMAIL PROTECTED]
Works fine to me... What libc-client-dev version you have used?
I used 7:2002edebian1-13.1ubuntu1
[2008-02-11 11:30:12] steffen at dislabs dot de
Description:
using imap_utf8 returns only capitols.
This behavior changed with 5.2.5 as it worked in 5.2.4 correct.
Reproduce code:
---
echo imap_utf8('=?iso-8859-1?b?THV6b26uMTQ=?= dot CoM');
Expected result:
Luzon®14 dot CoM
Actual result:
--
LUZON®14 DOT COM
--
Edit this bug report at http://bugs.php.net/?id=44098&edit=1
