date:20080729

#45599 [Com]: strip_tags() truncates rest of string with invalid attribute

2008-07-29 Thread jet at synth-tec dot com

 ID:   45599
 Comment by:   jet at synth-tec dot com
 Reported By:  david at grudl dot com
 Status:   Verified
 Bug Type: Strings related
 Operating System: *
 PHP Version:  5.2CVS, 5.3CVS, 6CVS (2008-07-22)
 New Comment:

I am having the same problem.  If an attribute has an extra quote in
it, will cut off all the text afterwards.  

Example Input:

strip_tags('
text before link
http://google.com"";>google.com
text after link
test 1
test 2
')


Expected Output:
-
text before link
text after link
test 1
test 2


Actual Output:
--
text before link



Note, I do not have this problem in PHP 5.0.4 or previous versions


Previous Comments:


[2008-07-22 23:37:57] david at grudl dot com

Description:

Problematic backslash in HTML attribute (bug exists since PHP 5.2.2)

Reproduce code:
---
1) 
echo strip_tags('Hello  World');

2) this case is not HTML valid, but who cares...
echo strip_tags('Hello  World');

Expected result:

Hello  World

(in both cases)

Actual result:
--
Hello

(in both cases)





-- 
Edit this bug report at http://bugs.php.net/?id=45599&edit=1

#45649 [Bgs]: IE header not send #url

2008-07-29 Thread xiefei dot admin at gmail dot com

 ID:   45649
 User updated by:  xiefei dot admin at gmail dot com
 Reported By:  xiefei dot admin at gmail dot com
 Status:   Bogus
 Bug Type: PHP options/info functions
 Operating System: header
 PHP Version:  5.2.6
 New Comment:

thinks , This is IE bug


Previous Comments:


[2008-07-29 17:21:25] [EMAIL PROTECTED]

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

This is browser dependent. The browser do not have to send the #hash
while sending HTTP request (e.g. if you add #123 to the address of a
page you are viewing, the browser will not refresh the page, it will
just scroll to the element named "123").



[2008-07-29 01:27:52] xiefei dot admin at gmail dot com

form enctype is multipart/form-data



[2008-07-29 01:24:09] xiefei dot admin at gmail dot com

Description:

when I upload file but header in ie not have #url, in firefox  header
#url are have , if you remove  the name
,then header have #123 ,if not remove name then header the url not have
#123,why?




Reproduce code:
---
in ie not have #123


http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
http://www.w3.org/1999/xhtml";>


Untitled Document











ie have #123




http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
http://www.w3.org/1999/xhtml";>


Untitled Document










Expected result:

/a/w#123

Actual result:
--
/a/w





-- 
Edit this bug report at http://bugs.php.net/?id=45649&edit=1

#43158 [Opn->Bgs]: [ssl_verify_result] => 0

2008-07-29 Thread felipe

 ID:   43158
 Updated by:   [EMAIL PROTECTED]
 Reported By:  p dot vanbrouwershaven at networking4all dot com
-Status:   Open
+Status:   Bogus
 Bug Type: cURL related
 Operating System: Linux *** 2.6.8-2-686 #1 Tue Au
 PHP Version:  5.2CVS-2008-07-21
 New Comment:

That is a bug in libcurl.


Thanks.


Previous Comments:


[2008-07-21 12:34:09] p dot vanbrouwershaven at networking4all dot com

I tried with php5.2-200807211030 but the problem still exists.

curl_error returns:

SSL: certificate subject name 'www.verisign.com' does not match target
host name 'verisign.com'

curl_getinfo returns:

Array
(
[url] => https://verisign.com/
[content_type] => text/html
[http_code] => 301
[header_size] => 182
[request_size] => 135
[filetime] => -1
[ssl_verify_result] => 0
[redirect_count] => 0
[total_time] => 1.072121
[namelookup_time] => 0.184282
[connect_time] => 0.342402
[pretransfer_time] => 0.905169
[size_upload] => 0
[size_download] => 0
[speed_download] => 0
[speed_upload] => 0
[download_content_length] => 0
[upload_content_length] => 0
[starttransfer_time] => 1.07203
[redirect_time] => 0
[certinfo] => 
)



[2007-10-31 11:35:19] p dot vanbrouwershaven at networking4all dot com

There was a space in my post just before http:// this is not the
problem but just an error in my post.

$url = ' https://verisign.com';

Array
(
[url] => https://verisign.com
[http_code] => 0
[header_size] => 0
[request_size] => 0
[filetime] => -1
[ssl_verify_result] => 0
[redirect_count] => 0
[total_time] => 0
[namelookup_time] => 3.5E-05
[connect_time] => 0.155727
[pretransfer_time] => 0
[size_upload] => 0
[size_download] => 0
[speed_download] => 0
[speed_upload] => 0
[download_content_length] => 0
[upload_content_length] => 0
[starttransfer_time] => 0
[redirect_time] => 0
)



[2007-10-31 10:51:45] p dot vanbrouwershaven at networking4all dot com

Description:

I have some problems with the curl. On the console I get the right
response message but in PHP I see no difference between a valid and an
invalid SSL Certificate.

Curl command in PHP:

$url = ' https://verisign.com';

$ch = curl_init();
curl_setopt($ch, CURLOPT_TIMEOUT, 10);
curl_setopt($ch, CURLE_OPERATION_TIMEOUTED, 10);
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 0);
$result = curl_exec ($ch);
$info = curl_getinfo($ch);
curl_close ($ch);

print_r($info);

Curl command on console:

curl -I https://verisign.com

Console result:

curl -I https://verisign.com
curl: (51) SSL: certificate subject name 'www.verisign.com' does not
match target host name 'verisign.com' 

PHP Result:
[ssl_verify_result] => 0



Reproduce code:
---
$url = ' https://verisign.com';

$ch = curl_init();
curl_setopt($ch, CURLOPT_TIMEOUT, 10);
curl_setopt($ch, CURLE_OPERATION_TIMEOUTED, 10);
curl_setopt($ch, CURLOPT_URL, $url); 
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 0);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 1);

$result = curl_exec ($ch);
$info = curl_getinfo($ch);
curl_close ($ch);

print_r($info);

Expected result:

Array
(
[url] =>  https://verisign.com
[http_code] => 0
[header_size] => 0
[request_size] => 0
[filetime] => -1
[ssl_verify_result] => 51
[redirect_count] => 0
[total_time] => 0
[namelookup_time] => 0
[connect_time] => 0
[pretransfer_time] => 0
[size_upload] => 0
[size_download] => 0
[speed_download] => 0
[speed_upload] => 0
[download_content_length] => 0
[upload_content_length] => 0
[starttransfer_time] => 0
[redirect_time] => 0
)

Actual result:
--
Array
(
[url] =>  https://verisign.com
[http_code] => 0
[header_size] => 0
[request_size] => 0
[filetime] => -1
[ssl_verify_result] => 0
[redirect_count] => 0
[total_time] => 0
[namelookup_time] => 0
[connect_time] => 0
[pretransfer_time] => 0
[size_upload] => 0
[size_download] => 0
[speed_download] => 0
[speed_upload] => 0
[download_content_length] => 0
[upload_content_length] => 0
[starttransfer_time] => 0
[redirect_time] => 0
)





-- 
Edit this bug report at http://bugs.php.net/?id=43158&edit=1

#44581 [Opn->Fbk]: SoapClient-error with Document-Style WSDL

2008-07-29 Thread didou

 ID:   44581
 Updated by:   [EMAIL PROTECTED]
 Reported By:  storozhilov at mail dot ru
-Status:   Open
+Status:   Feedback
 Bug Type: SOAP related
 Operating System: FreeBSD 7.0-RELEASE #2
 PHP Version:  5.2.5
 New Comment:

Can't seem to access resources from http://soap.tver.pregrad.net/.
Please make them available somewhere.

Also, include a meaningful debuging information, like the XML request
sent:

$client = new SoapClient("isale.wsdl", array('trace' => true));
try {
$uuid = $client->initUserSession(1, 'user', 'password');
} catch (Exception $e) {
echo $client->__getLastRequest();
}




Previous Comments:


[2008-03-31 14:28:40] storozhilov at mail dot ru

Description:

It's recommended to use Document-style WSDL, so we've made our
SOAP-server, that publish WSDL-document of this style. Unfortunately,
PHP SOAP-module works fine with RPC-style, but makes a error with the
same, but Document-style WSDL. Our SOAP-server, written using gSOAP
works fine with gSOAP-based clients, but can't serve PHP ones.

Reproduce code:
---
1. WSDL is here: http://pregrad.net/temp/isale.wsdl

2. PHP code is:

initUserSession(1, 'user', 'password');

?>




Expected result:

without errors

Actual result:
--
PHP Fatal error:  Uncaught SoapFault exception: [SOAP-ENV:Client]
Method 'parameters' not implemented: method name or namespace not
recognized in
/usr/home/illy/Programming/SOAP/PHP/document_style_wsdl/run_me.php:5
Stack trace:
#0 [internal function]: SoapClient->__call('initUserSession', Array)
#1
/usr/home/illy/Programming/SOAP/PHP/document_style_wsdl/run_me.php(5):
SoapClient->initUserSession(1, 'user', 'password')
#2 {main}
  thrown in
/usr/home/illy/Programming/SOAP/PHP/document_style_wsdl/run_me.php on
line 5






-- 
Edit this bug report at http://bugs.php.net/?id=44581&edit=1

#45537 [Com]: localhost web page crashes if php5ts.dll (5.2.6.6) exist

2008-07-29 Thread stlee2112 at netscape dot net

 ID:   45537
 Comment by:   stlee2112 at netscape dot net
 Reported By:  roldan at introsplash dot com
 Status:   No Feedback
 Bug Type: Apache2 related
 Operating System: Windows XP
 PHP Version:  5.2.6
 New Comment:

I have encountered this same issue with php5ts.dll  is there a newer
version of 5.2.6.6 yet?  can i just replace php5ts.dll 5.2.6?


Previous Comments:


[2008-07-27 21:59:38] jays at poczta dot onet dot pl

You must copy everything from php-5.2.6-Win32.zip\ to c:\Program
Files\PHP\



[2008-07-27 21:37:04] jays at poczta dot one dot tpl

szAppName : httpd.exe szAppVer : 2.2.9.0 szModName : php5ts.dll

szModVer : 5.2.6.6 offset : abda 

mysql   mysql-6.0.5-alpha
php PHP Version 5.2.6
apache 2.2 apache_2.2.9-win32-



[2008-07-25 01:00:03] 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".



[2008-07-24 18:19:34] roland-php at thegreentree dot za dot net

I get this bug when loading any .php page.  

I have downloaded again, checked the md5 sig which is correct. 

szAppName : httpd.exe   szAppVer : 2.2.9.0
szModName : php5ts.dll  szModVer : 5.2.6.6
offset : 0009c51d 

I have re-installed php to no avail.

Platform: Windows XP Pro SP2

Also running mySQL.



[2008-07-17 14:14:26] roldan at introsplash dot com

I downloaded PHP 5.2.6 a second time and did a binary compare on the
latest release of PHP 5.2.6. The PHP version 5.2.6 I had did not match
in size. embedded in my installed version php5ts.dll file showed an
"RC5" difference.
I uninstalled my version and installed the one without the the "rc5".
That eliminated the issue.



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/45537

-- 
Edit this bug report at http://bugs.php.net/?id=45537&edit=1

#45636 [Opn->Asn]: fileinfo ext duplicate strndup

2008-07-29 Thread jani

 ID:   45636
 Updated by:   [EMAIL PROTECTED]
 Reported By:  Fedora at FamilleCollet dot com
-Status:   Open
+Status:   Assigned
 Bug Type: Compile Failure
 Operating System: Linux (Fedora 9)
 PHP Version:  5.3CVS-2008-07-27 (snap)
-Assigned To:  
+Assigned To:  derick
 New Comment:

Assigned to the maintainer.


Previous Comments:


[2008-07-27 15:59:37] Fedora at FamilleCollet dot com

ok,  thanks for the information about system lib.

So, error occur with bundled lib.



[2008-07-27 15:30:26] [EMAIL PROTECTED]

FYI: This extension only compiles with the bundled library. There is no
way to use external libmagic anymore.




[2008-07-27 15:26:11] Fedora at FamilleCollet dot com

First try with --enable-fileinfo=shared
Second try with --enable-fileinfo=shared,/usr

In fact, "file-devel" is installed, which provides libmagic.so and was
used by PECL extension Fileinfo 1.0.4.

The bundled extension doesn't seem tu use the system library.

Regards



[2008-07-27 09:13:46] [EMAIL PROTECTED]

Compiles fine for me in Linux. What was the full configure line you
used?



[2008-07-27 07:14:07] Fedora at FamilleCollet dot com

Description:

Fileinfo extention is now enabled by default but doesn't compile
because it use "strndup" with is provided both by the system and the
source (softmagic.c)

Source code of softmagic.c contain a test arround is local defined
fonction :

#ifndef HAVE_STRNDUP
char * strndup(const char *, size_t);

...
#endif

But nothing set this macro.
I don't find anything in the .m4 files

Perhaps it should better use the zend_strndup ?

Reproduce code:
---
make


Expected result:

Build succed

Actual result:
--
/home/rpmbuild/BUILD/php5.3-200807270630/ext/fileinfo/libmagic/softmagic.c:305:
error: expected identifier or '(' before '__extension__'
/home/rpmbuild/BUILD/php5.3-200807270630/ext/fileinfo/libmagic/softmagic.c:308:
error: expected identifier or '(' before '__extension__'
make: *** [ext/fileinfo/libmagic/softmagic.lo] Error 1






-- 
Edit this bug report at http://bugs.php.net/?id=45636&edit=1

#45644 [Opn->Bgs]: eval() consumes a lot more memory in 64bit system than 32 bit

2008-07-29 Thread jani

 ID:   45644
 Updated by:   [EMAIL PROTECTED]
 Reported By:  trepseb at hotmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Performance problem
 Operating System: Linux fedora
 PHP Version:  5.2.6
 Assigned To:  fb-req-jani
 New Comment:

For more info, check bug #41053, bug #40720 which have quite good
explanation why this happens.


Previous Comments:


[2008-07-29 14:13:09] trepseb at hotmail dot com

Thank you jani. This really was an issue with a debugger extension. I
still don't understand why the "same" debugger does not have a problem
in 32 bit systems and why you would see this as expected behaviour, but
it works now. Maybe this is something for the zend people to analyze.
Until now must developer systems are not 64 bit and it's very difficult
to get to the grounds of this on your server alone.



[2008-07-28 20:17:54] [EMAIL PROTECTED]

# uname -a
Linux linux5 2.6.20-1.2944.fc6 #1 SMP Tue Apr 10 17:46:00 EDT 2007
x86_64 x86_64 x86_64 GNU/Linux

# USE_ZEND_ALLOC=0 php t.php
start 8208
end 8208

# USE_ZEND_ALLOC=1 php t.php
start 92496
end 223888

# USE_ZEND_ALLOC=1 php -n t.php
start 90952
end 94032

Note the last result. The second is with Xdebug enabled. 
Do you by any chance have Xdebug (or any other Zend extension) loaded?
If so, this is quite expected behaviour..




[2008-07-28 12:18:41] trepseb at hotmail dot com

Description:

We were using eval extensivly for making a dynamic code parser. It used
to be all ok till we needed to use it for more than 3 iterations.
Suddenly our memory limit was reached. We tracked it down to the
underlying code.

Strangely this is only an issue with 64 Bit systems. A PowerMac Dual
has this Problem the same as a 8 Core XEON. The INTEL and AMD with 32
bits don't have a Problem, here the script requires no additional memory
with each cycle.

Probably this has to do with some underlying library, but maybe you can
figure out which.

Here is a part of my php info

Linux  2.6.23.17-88.fc7 #1 SMP Thu May 15 00:02:29 EDT 2008
x86_64
Build Date  May 8 2008 08:38:49
Configure Command   './configure' '--build=x86_64-redhat-linux-gnu'
'--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu'
'--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64'
'--libexecdir=/usr/libexec' '--localstatedir=/var'
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--cache-file=../config.cache'
'--with-libdir=lib64' '--with-config-file-path=/etc'
'--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic'
'--disable-rpath' '--without-pear' '--with-bz2' '--with-curl'
'--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr'
'--with-png-dir=/usr' '--enable-gd-native-ttf' '--without-gdbm'
'--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr'
'--with-openssl' '--with-png' '--with-pspell' '--with-expat-dir=/usr'
'--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU'
'--enable-exif' '--enable-ftp' '--enable-magic-quotes'
'--enable-sockets' '--enable-sysvsem' '--enable-sysvshm'
'--enable-sysvmsg' '--enable-track-vars' '--enable-trans-sid'
'--enable-yp' '--enable-wddx' '--with-kerberos' '--enable-ucd-snmp-hack'
'--with-unixODBC=shared,/usr' '--enable-memory-limit' '--enable-shmop'
'--enable-calendar' '--enable-dbx' '--enable-dio' '--without-mime-magic'
'--without-sqlite' '--with-libxml-dir=/usr' '--with-xml'
'--with-system-tzdata' '--with-apxs2=/usr/sbin/apxs' '--without-mysql'
'--without-gd' '--without-odbc' '--disable-dom' '--disable-dba'
'--without-unixODBC' '--disable-pdo' '--disable-xmlreader'
'--disable-xmlwriter' '--disable-json'


I checked the other eval errors, but they did not have much to do with
mine, and they are all stone old ;).

Reproduce code:
---
echo "start ".memory_get_usage()."\n";

$aData['an_anfrage_art'] = '150';

$aData['ega_codes'] = '12|13|15|17|18|23';

for ($i=0;$i<10;$i++){

   eval('$bCondition = !in_array( \'150\' ,
array(12,13,15,17,18,23));');

}

echo "end ".memory_get_usage();

Expected result:

start 46592 
end 47980

32 bit system. This is the expected result the memory usage is constant
with more cycles

Actual result:
--
start 78488
end 1710444

64 bit system. Here the memory usage is growing linearly. More cycles
make the memory consumption grow. 





-- 
Edit this bug report at http://bugs.php.net/?id=45644&edit=1

#45657 [Bgs]: header() problem with special chars: ï¿½, ï¿½ and ï¿½

2008-07-29 Thread jakob at skatetown dot dk

 ID:   45657
 User updated by:  jakob at skatetown dot dk
 Reported By:  jakob at skatetown dot dk
 Status:   Bogus
 Bug Type: HTTP related
 Operating System: Linux
 PHP Version:  4.4.8
 New Comment:

This is NOT a support question!
It's a bug...!
No servers can handle it.
It's not "wrong setup".
Its the function it's wrong with.. :S
No i've had to make a HTML redirect, and that's not optimal!


Previous Comments:


[2008-07-29 20:05:56] [EMAIL PROTECTED]

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

You have to use the IDN version of the domain name:
http://mct.verisign-grs.com/conversiontool/convertServlet?input=www.uddannelsesstÃ¤tte.dk&type=UTF8
(pick the punycode one). Firefox properly re-codes that to
http://www.uddannelsesstÃ¤tte.dk.



[2008-07-29 19:28:25] jakob at skatetown dot dk

This is pretty urgent, cause Denmark has just released domain names
with Ã¦, Ã¸ and Ã¥.



[2008-07-29 19:27:16] jakob at skatetown dot dk

Description:

The header function dont work with international characters lik: Ã¦, Ã¸
and Ã¥.
It replace them with %f8 and stuff like that.
ex: header("Location: http://www.uddannelsesstÃ¸tte.dk";);

http://www.uddannelsesstÃ¸tte.dk is a danish site, that helps students
finding money.

Reproduce code:
---
header("Location: http://www.uddannelsesstÃ¸tte.dk";);

Expected result:

Redirected to the site "http://www.uddannelsesstÃ¸tte.dk";

Actual result:
--
Broser output:
Couldn't find http://www.uddannelsesst%f8tte.dk





-- 
Edit this bug report at http://bugs.php.net/?id=45657&edit=1

#45657 [Opn->Bgs]: header() problem with special chars: ï¿½, ï¿½ and ï¿½

2008-07-29 Thread derick

ID: 45657
Updated by: [EMAIL PROTECTED]
Reported By: jakob at skatetown dot dk
-Status: Open
+Status: Bogus
Bug Type: HTTP related
Operating System: Linux
PHP Version: 4.4.8
New Comment:

Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

You have to use the IDN version of the domain name:
http://mct.verisign-grs.com/conversiontool/convertServlet?input=www.uddannelsesstÃ¤tte.dk&type=UTF8
(pick the punycode one). Firefox properly re-codes that to
http://www.uddannelsesstÃ¤tte.dk.

Previous Comments:

[2008-07-29 19:28:25] jakob at skatetown dot dk

This is pretty urgent, cause Denmark has just released domain names
with Ã¦, Ã¸ and Ã¥.

[2008-07-29 19:27:16] jakob at skatetown dot dk

Description:

The header function dont work with international characters lik: Ã¦, Ã¸
and Ã¥.
It replace them with %f8 and stuff like that.
ex: header("Location: http://www.uddannelsesstÃ¸tte.dk";);

http://www.uddannelsesstÃ¸tte.dk is a danish site, that helps students
finding money.

Reproduce code:
---
header("Location: http://www.uddannelsesstÃ¸tte.dk";);

Expected result:

Redirected to the site "http://www.uddannelsesstÃ¸tte.dk";

Actual result:
--
Broser output:
Couldn't find http://www.uddannelsesst%f8tte.dk

--
Edit this bug report at http://bugs.php.net/?id=45657&edit=1

#45657 [Com]: header() problem with special chars: ï¿½, ï¿½ and ï¿½

2008-07-29 Thread jakob at skatetown dot dk

 ID:   45657
 Comment by:   jakob at skatetown dot dk
 Reported By:  jakob at skatetown dot dk
 Status:   Open
 Bug Type: HTTP related
 Operating System: Linux
 PHP Version:  4.4.8
 New Comment:

This is pretty urgent, cause Denmark has just released domain names
with Ã¦, Ã¸ and Ã¥.


Previous Comments:


[2008-07-29 19:27:16] jakob at skatetown dot dk

Description:

The header function dont work with international characters lik: Ã¦, Ã¸
and Ã¥.
It replace them with %f8 and stuff like that.
ex: header("Location: http://www.uddannelsesstÃ¸tte.dk";);

http://www.uddannelsesstÃ¸tte.dk is a danish site, that helps students
finding money.

Reproduce code:
---
header("Location: http://www.uddannelsesstÃ¸tte.dk";);

Expected result:

Redirected to the site "http://www.uddannelsesstÃ¸tte.dk";

Actual result:
--
Broser output:
Couldn't find http://www.uddannelsesst%f8tte.dk





-- 
Edit this bug report at http://bugs.php.net/?id=45657&edit=1

#45657 [NEW]: header() problem with special chars: ï¿½, ï¿½ and ï¿½

2008-07-29 Thread jakob at skatetown dot dk

From: jakob at skatetown dot dk
Operating system: Linux
PHP version:  4.4.8
PHP Bug Type: HTTP related
Bug description:  header() problem with special chars: Ã¦, Ã¸ and Ã¥

Description:

The header function dont work with international characters lik: Ã¦, Ã¸ and
Ã¥.
It replace them with %f8 and stuff like that.
ex: header("Location: http://www.uddannelsesstÃ¸tte.dk";);

http://www.uddannelsesstÃ¸tte.dk is a danish site, that helps students
finding money.

Reproduce code:
---
header("Location: http://www.uddannelsesstÃ¸tte.dk";);

Expected result:

Redirected to the site "http://www.uddannelsesstÃ¸tte.dk";

Actual result:
--
Broser output:
Couldn't find http://www.uddannelsesst%f8tte.dk

-- 
Edit bug report at http://bugs.php.net/?id=45657&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=45657&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=45657&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=45657&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45657&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=45657&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=45657&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45657&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45657&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=45657&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45657&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=45657&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=45657&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45657&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=45657&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45657&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45657&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=45657&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=45657&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=45657&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45657&r=mysqlcfg

#45645 [Bgs]: eval causes "Internal Server Error"

2008-07-29 Thread lbarnaud

 ID:   45645
 Updated by:   [EMAIL PROTECTED]
 Reported By:  sergey89 at gmail dot com
 Status:   Bogus
 Bug Type: PHP options/info functions
 Operating System: Debian GNU/Linux 4.0r3
 PHP Version:  5.2.6
 New Comment:

In the first example the headers has already been sent (due to
ob_flush()), so PHP can't set the HTTP status code.


Previous Comments:


[2008-07-29 11:14:27] sergey89 at gmail dot com

Where is the logic?

---
 errors are shown ->
http status is 200. In case there is nothing to output, you get 500.




[2008-07-28 14:39:17] sergey89 at gmail dot com

After eval() script continues executing normally and I see expected
result on the page.



[2008-07-28 13:58:10] sergey89 at gmail dot com

Description:

I evaluate broken script with eval function. If display_errors is On i
get status 200 in http response, but if is Off i get status 500. It is
normal behaviour? error.log is empty.

Reproduce code:
---
http://bugs.php.net/?id=45645&edit=1

#45649 [Opn->Bgs]: IE header not send #url

2008-07-29 Thread lbarnaud

 ID:   45649
 Updated by:   [EMAIL PROTECTED]
 Reported By:  xiefei dot admin at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: PHP options/info functions
 Operating System: header
 PHP Version:  5.2.6
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

This is browser dependent. The browser do not have to send the #hash
while sending HTTP request (e.g. if you add #123 to the address of a
page you are viewing, the browser will not refresh the page, it will
just scroll to the element named "123").


Previous Comments:


[2008-07-29 01:27:52] xiefei dot admin at gmail dot com

form enctype is multipart/form-data



[2008-07-29 01:24:09] xiefei dot admin at gmail dot com

Description:

when I upload file but header in ie not have #url, in firefox  header
#url are have , if you remove  the name
,then header have #123 ,if not remove name then header the url not have
#123,why?




Reproduce code:
---
in ie not have #123


http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
http://www.w3.org/1999/xhtml";>


Untitled Document











ie have #123




http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
http://www.w3.org/1999/xhtml";>


Untitled Document










Expected result:

/a/w#123

Actual result:
--
/a/w





-- 
Edit this bug report at http://bugs.php.net/?id=45649&edit=1

#45656 [NEW]: spl_autoload cannot handle exceptions

2008-07-29 Thread php at benjaminschulz dot com

From: php at benjaminschulz dot com
Operating system: any
PHP version:  5.3CVS-2008-07-29 (CVS)
PHP Bug Type: SPL related
Bug description:  spl_autoload cannot handle exceptions 

Description:

If spl_autoload() is triggered by class_exists() it is able to handle
occuring exceptions but if it is triggered through "new .." then exceptions
are silently ignored.
Attached is an adapted copy of spl_autoload_012.phpt.

Reproduce code:
---
--TEST--
SPL: spl_autoload() capturing multiple Exceptions in __autoload
--FILE--

===DONE===
--EXPECTF--
autoload_first
autoload_second

Fatal error: Uncaught exception 'Exception' with message 'first' in
%sspl_autoload_013.php:%d
Stack trace:
#0 [internal function]: autoload_first('ThisClassDoesNo...')
#1 [internal function]: spl_autoload_call('ThisClassDoesNo...')
#2 %sspl_autoload_013.php(%d): class_exists('ThisClassDoesNo...')
#3 {main}

Next exception 'Exception' with message 'second' in
%sspl_autoload_013.php:%d
Stack trace:
#0 [internal function]: autoload_second('ThisClassDoesNo...')
#1 [internal function]: spl_autoload_call('ThisClassDoesNo...')
#2 %sspl_autoload_013.php(%d): class_exists('ThisClassDoesNo...')
#3 {main}
  thrown in %sspl_autoload_013.php on line %d


Actual result:
--
autoload_first
autoload_second
PHP Fatal error:  Class 'ThisClassDoesNotExist' not found in ... on line
0

Fatal error: Class 'ThisClassDoesNotExist' not found in ... on line 0

-- 
Edit bug report at http://bugs.php.net/?id=45656&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=45656&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=45656&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=45656&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45656&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=45656&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=45656&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45656&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45656&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=45656&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45656&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=45656&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=45656&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45656&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=45656&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45656&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45656&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=45656&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=45656&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=45656&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45656&r=mysqlcfg

#44994 [Com]: exec() produces zombie processes on Windows, hangs Apache

2008-07-29 Thread nobody at dontsendmespam dot com

 ID:   44994
 Comment by:   nobody at dontsendmespam dot com
 Reported By:  dbarrett at vistaprint dot com
 Status:   Assigned
 Bug Type: Program Execution
 Operating System: Windows 2003 Server, 64-bit
 PHP Version:  5.2.6
 Assigned To:  pajoye
 New Comment:

i can reproduce this problem on a debian server with apache2 and
php5.2.6 running as fcgi


Previous Comments:


[2008-07-23 02:02:29] efesar at gmail dot com

I just upgraded from PHP 5.1.2 to 5.2.6, and this exact problem happens
to me. The exec and shell_exec used to work, and now they don't. They
hang the php process, and every subsequent call to exec produces a lost
cmd.exe ... 

Incidentally passthru() causes the same behavior.

Maybe it has something to do with the rotatelogs.exe ... somebody
earlier mentioned that it was waiting on c:\Apache2\logs\error.log ... 


So, basically, we can't run any system calls whatsoever via PHP. I
don't want to use a COM object, because I like portable code ... but
that might be the best step until this bug is fixed.



[2008-07-07 18:57:12] stephen dot cuppett at sas dot com

I am also experiencing this problem.  I have been able to recreate it
with system() as well as proc_open().  With proc_open() it doesn't seem
to matter if I set bypass_shell or not, just determines whether I have a
dangling cmd.exe process or not...

cmd.exe seems to stop at Wait:UserReq, but that probably doesn't mean
much.

I am able to reproduce it with XAMPP 1.6.6a (PHP 5.2.5) on Windows XP
or Windows Server 2003 (32-bit).

I don't have much to add in terms of documentation as I don't get
anything in the httpd logs, but using the following code snippet:

protected function runSAS($filename) {
$this->log("Requested to run SAS file:
" . $filename, LOG_DEBUG);

$toRun  = "\"" . SAS . "\"";
$toRun .= " -sysin '" . $filename .
"'";
$toRun .= " -CONFIG '" . SASV9CFG .
"'";
$toRun .= " -PRINT '" . TEMP_DIR . "/"
. basename($filename) . ".lst'";
$toRun .= " -LOG '" . TEMP_DIR . "/" .
basename($filename) . ".log'";
$toRun .= " -NOSPLASH";

$this->log("SAS command to run: " .
$toRun, LOG_DEBUG);

$descriptorspec = array(
0 => array("pipe",
"r"),  // stdin is a pipe that the child will read from
1 => array("pipe",
"w"),  // stdout is a pipe that the child will write to
2 => array("pipe", "w")
  // stderr is a file to write to
);

$res = proc_open($toRun,
$descriptorspec, $pipes, null, null, array(/*"bypass_shell" =>
true*/));

if (is_resource($res)) {
//fwrite($pipes[0],
"exit\n");
//fflush($pipes[0]);
fclose($pipes[0]);
fclose($pipes[1]);
fclose($pipes[2]);

$return_value =
proc_close($res);

$this->log("Return
value from SAS: " . $return_value, LOG_DEBUG);
}
}


When it does seem to complete, I'll get this in my log:

2008-06-26 20:23:55 Debug: Return value from SAS: 1

Nothing should come out on the pipes at all and when I set it up to
read those and it completes, there is no data read.  However, in a hang
case, PHP blocks reading STDOUT instead of on proc_close never getting
any data... even if I set the stream to be non-blocking on the pipe
explicitely after proc_open.



[2008-05-29 13:21:51] dbarrett at vistaprint dot com

I replaced all occurrences of exec() and shell_exec() in MediaWiki with
calls to a custom COM object that invokes programs.  The problem went
away. This strongly suggests that PHP's implementation of exec(0 and
shell_exec() is the culprit. I suspect a race condition.



[2008-05-14 15:09:43] dbarrett at vistaprint dot com

Description:

This is an inte

#41350 [Com]: Error in my_thread_global_end()

2008-07-29 Thread marcin dot slowinski at keratronik dot pl

 ID:   41350
 Comment by:   marcin dot slowinski at keratronik dot pl
 Reported By:  graham at directhostinguk dot com
 Status:   No Feedback
 Bug Type: MySQL related
 Operating System: Windows 2003
 PHP Version:  5.2.6
 Assigned To:  scottmac
 New Comment:

I solved problem by copying libMySQL from my MySQL server to PHP dir.

Windows XP SP2
Apache 2.2.9 with mod_ssl
PHP 5.2.6 (crashed with oryginal libmysql.dll)
MySQL 5.0.27-community-nt

Regards
Marcin


Previous Comments:


[2008-07-20 19:58:29] froggywillneverdie at msn dot com

I'm using PHP 5.2.6 on Windows Vista SP1.

My scripts take around 5 seconds to exit if php_mysql.dll is enabled in
php.ini.



[2008-07-14 19:39:08] bkeene at whisolutions dot nospamplease dot com

It looks like the system automatically closed out this ticket, but it
is still an issue.

I have commented out every extension in my PHP5.2.6 installation with
the exception of the php_mysql.dll OR php_mysqli.dll and still
experience the problem.

Running php.exe -v on a windows 2003 box STILL takes 5 seconds.

I happened to locate a previous version of php5.1.6 (Aug 23 2006) and
used that version of the libmysql.dll and the delay ceases.

At a minimum, could a valid, previous version of the libmysql.dll be
bundled with the installation so that the command line versions of PHP
can function correctly?

Also, I never experienced this issue with MySQL when running PHP
scripts served by Apache 2.2 as a module (not CGI).



[2008-06-20 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".



[2008-06-19 11:50:13] Computer dot Pers at gmail dot com

So mysql dll from 5.2.1 cures the problem... 
Where i can take php 5.2.1 (or this dll)??? 
there no any live links in google...



[2008-06-12 08:44:56] [EMAIL PROTECTED]

This was a change by MySQL, not by PHP. We simply bundle the latest
version of MySQL, if you use PHP 5.2.2 with the libmysql.dll you will
see the issue.

They're looking at other changes to try and solve an issue where every
new thread needs to call mysql_thread_init() which isn't ideal. Until
then either use the non-thread-safe version of PHP or downgrade your
libmysql.dll



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/41350

-- 
Edit this bug report at http://bugs.php.net/?id=41350&edit=1

#45644 [Fbk->Opn]: eval() consumes a lot more memory in 64bit system than 32 bit

2008-07-29 Thread trepseb at hotmail dot com

 ID:   45644
 User updated by:  trepseb at hotmail dot com
 Reported By:  trepseb at hotmail dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Performance problem
 Operating System: Linux fedora
 PHP Version:  5.2.6
 Assigned To:  fb-req-jani
 New Comment:

Thank you jani. This really was an issue with a debugger extension. I
still don't understand why the "same" debugger does not have a problem
in 32 bit systems and why you would see this as expected behaviour, but
it works now. Maybe this is something for the zend people to analyze.
Until now must developer systems are not 64 bit and it's very difficult
to get to the grounds of this on your server alone.


Previous Comments:


[2008-07-28 20:17:54] [EMAIL PROTECTED]

# uname -a
Linux linux5 2.6.20-1.2944.fc6 #1 SMP Tue Apr 10 17:46:00 EDT 2007
x86_64 x86_64 x86_64 GNU/Linux

# USE_ZEND_ALLOC=0 php t.php
start 8208
end 8208

# USE_ZEND_ALLOC=1 php t.php
start 92496
end 223888

# USE_ZEND_ALLOC=1 php -n t.php
start 90952
end 94032

Note the last result. The second is with Xdebug enabled. 
Do you by any chance have Xdebug (or any other Zend extension) loaded?
If so, this is quite expected behaviour..




[2008-07-28 12:18:41] trepseb at hotmail dot com

Description:

We were using eval extensivly for making a dynamic code parser. It used
to be all ok till we needed to use it for more than 3 iterations.
Suddenly our memory limit was reached. We tracked it down to the
underlying code.

Strangely this is only an issue with 64 Bit systems. A PowerMac Dual
has this Problem the same as a 8 Core XEON. The INTEL and AMD with 32
bits don't have a Problem, here the script requires no additional memory
with each cycle.

Probably this has to do with some underlying library, but maybe you can
figure out which.

Here is a part of my php info

Linux  2.6.23.17-88.fc7 #1 SMP Thu May 15 00:02:29 EDT 2008
x86_64
Build Date  May 8 2008 08:38:49
Configure Command   './configure' '--build=x86_64-redhat-linux-gnu'
'--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu'
'--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64'
'--libexecdir=/usr/libexec' '--localstatedir=/var'
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--cache-file=../config.cache'
'--with-libdir=lib64' '--with-config-file-path=/etc'
'--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic'
'--disable-rpath' '--without-pear' '--with-bz2' '--with-curl'
'--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr'
'--with-png-dir=/usr' '--enable-gd-native-ttf' '--without-gdbm'
'--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr'
'--with-openssl' '--with-png' '--with-pspell' '--with-expat-dir=/usr'
'--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU'
'--enable-exif' '--enable-ftp' '--enable-magic-quotes'
'--enable-sockets' '--enable-sysvsem' '--enable-sysvshm'
'--enable-sysvmsg' '--enable-track-vars' '--enable-trans-sid'
'--enable-yp' '--enable-wddx' '--with-kerberos' '--enable-ucd-snmp-hack'
'--with-unixODBC=shared,/usr' '--enable-memory-limit' '--enable-shmop'
'--enable-calendar' '--enable-dbx' '--enable-dio' '--without-mime-magic'
'--without-sqlite' '--with-libxml-dir=/usr' '--with-xml'
'--with-system-tzdata' '--with-apxs2=/usr/sbin/apxs' '--without-mysql'
'--without-gd' '--without-odbc' '--disable-dom' '--disable-dba'
'--without-unixODBC' '--disable-pdo' '--disable-xmlreader'
'--disable-xmlwriter' '--disable-json'


I checked the other eval errors, but they did not have much to do with
mine, and they are all stone old ;).

Reproduce code:
---
echo "start ".memory_get_usage()."\n";

$aData['an_anfrage_art'] = '150';

$aData['ega_codes'] = '12|13|15|17|18|23';

for ($i=0;$i<10;$i++){

   eval('$bCondition = !in_array( \'150\' ,
array(12,13,15,17,18,23));');

}

echo "end ".memory_get_usage();

Expected result:

start 46592 
end 47980

32 bit system. This is the expected result the memory usage is constant
with more cycles

Actual result:
--
start 78488
end 1710444

64 bit system. Here the memory usage is growing linearly. More cycles
make the memory consumption grow. 





-- 
Edit this bug report at http://bugs.php.net/?id=45644&edit=1

#45655 [Opn->Fbk]: result of crypt() without salt is always empty

2008-07-29 Thread pajoye

 ID:   45655
 Updated by:   [EMAIL PROTECTED]
 Reported By:  iver at jackewitz dot de
-Status:   Open
+Status:   Feedback
 Bug Type: *Encryption and hash functions
 Operating System: ubuntu 8.04
 PHP Version:  5.2.6
-Assigned To:  
+Assigned To:  pajoye
 New Comment:

It really depends of which libc you use, and if you have the right
algorithm present. If MD5 and DES are not present, them it is expected.

Please try using PHP 5.3 snapshot, all algorithms are now available, no
matter which libc you use (or not).


Previous Comments:


[2008-07-29 13:09:18] iver at jackewitz dot de

Description:

Desc:
result of crypt() without salt is always empty

PHP-Version:
- 5.2.4
- 5.2.6

5.2.3 it's okay

Reproduce code:
---
echo(crypt('Hallo'));

Expected result:

1rwefw34rf2345wer # something like that






-- 
Edit this bug report at http://bugs.php.net/?id=45655&edit=1

#45655 [NEW]: result of crypt() without salt is always empty

2008-07-29 Thread iver at jackewitz dot de

From: iver at jackewitz dot de
Operating system: ubuntu 8.04
PHP version:  5.2.6
PHP Bug Type: *Encryption and hash functions
Bug description:  result of crypt() without salt is always empty

Description:

Desc:
result of crypt() without salt is always empty

PHP-Version:
- 5.2.4
- 5.2.6

5.2.3 it's okay

Reproduce code:
---
echo(crypt('Hallo'));

Expected result:

1rwefw34rf2345wer # something like that


-- 
Edit bug report at http://bugs.php.net/?id=45655&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=45655&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=45655&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=45655&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45655&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=45655&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=45655&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45655&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45655&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=45655&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45655&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=45655&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=45655&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45655&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=45655&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45655&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45655&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=45655&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=45655&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=45655&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45655&r=mysqlcfg

#44055 [Bgs]: wrong default cast for offset used in fseek

2008-07-29 Thread pajoye

 ID:   44055
 Updated by:   [EMAIL PROTECTED]
 Reported By:  vadim at vadiaz dot com
 Status:   Bogus
 Bug Type: Zip Related
 Operating System: Linux x86_64
 PHP Version:  5.2.6
 Assigned To:  pajoye
 New Comment:

"It is not bogus because zip extention is now part of main package
and bug fix was not released in 5.2.6 :( now I am rebuilding php rpms
for all my distributions :("

It is bogus as it is duplicated. Zip is released both in pecl and with
the core distribution. An update for PECL is planed after 5.3.0-alpha1
or alpha2. This update works for 5.2.x as well. Almost all linux distro
uses PECL as mainstream releases.

Btw, the fix is in CVS already.


Previous Comments:


[2008-07-29 10:37:19] vadim at vadiaz dot com

It is not bogus because zip extention is now part of main package
and bug fix was not released in 5.2.6 :(
now I am rebuilding php rpms for all my distributions :(



[2008-02-05 22:49:43] [EMAIL PROTECTED]

Duplicated, it is already reported in pecl:
http://pecl.php.net/bugs/bug.php?id=12965

no need to duplicate it here.



[2008-02-05 21:32:10] vadim at vadiaz dot com

Description:

zip extention failed to open zip files with thousands of files in root
directory on 64 bit Linux systems. From strace I seen than fseek get
value close to max_long.
After reviewing code I figured out that it caused by wrong default type
cast in php-5.2.5/ext/zip/lib/zip_open.c:313

fseek(fp, -(cd->size+cd->comment_len+EOCDLEN), SEEK_END);

which should be:

fseek(fp, -((long)(cd->size+cd->comment_len+EOCDLEN)), SEEK_END);

because on 64 bit systems long is 8 byte. 
I aaplied following path and rebuild rpms for my CentOS 5 from scratch
which solves the problem

--- php-5.2.5/ext/zip/lib/zip_open.c.seek_error 2008-02-05
22:05:03.0 +0200
 
+++ php-5.2.5/ext/zip/lib/zip_open.c2008-02-05 23:17:05.0
+0200   
  
@@ -313,7 +313,7 @@


/* go to start of cdir and read it entry by entry */   


bufp = NULL;   


clearerr(fp);  


-   fseek(fp, -(cd->size+cd->comment_len+EOCDLEN), SEEK_END);  


+   fseek(fp, -((long)(cd->size+cd->comment_len+EOCDLEN)),
SEEK_END);  
 
if (ferror(fp) || ((unsigned int)ftell(fp) != cd->offset)) {   


/* seek error or offset of cdir wrong */   


if (ferror(fp)) 




Reproduce code:
---


Test of ZipArchive







Expected result:



Test of ZipArchive


ZipArchive works Ok



Actual result:
--
can not open stream 'zip0://testSite.zip/f1/tst.php'





-- 
Edit this bug report at http://bugs.php.net/?id=44055&edit=1

#40034 [Com]: mssql_connect(): Unable to connect to server

2008-07-29 Thread c dot pasticcio at gawab dot com

 ID:   40034
 Comment by:   c dot pasticcio at gawab dot com
 Reported By:  chris dot clos at lmcu dot org
 Status:   Assigned
 Bug Type: MSSQL related
 Operating System: Windows Server 2003
 PHP Version:  5.2.0
 Assigned To:  fmk
 New Comment:

We have the same problems with sevral configurations on windows 2003.
- webserver: win2k3 + Apache 2.2.9 + Php 5.2.6
- webserver: win2k3 + Apache 2.0.59 + Php 5.1.6
- db server: win2k3 + sql server 2000

We have other 2 webservers with latest Apache and Php releases running
on windows 2000 that don't suffer this problem.

On all webservers we have ntwdblib.dll version 2000.80.194.0.
On db server with win2k3 we have a ntwdblib.dll version
2000.80.2039.0.
We didn't try to change the libs yet.


Previous Comments:


[2008-07-23 00:01:23] efesar at gmail dot com

Recently I upgraded to PHP 5.2.6 (Apache 2.2.9, Win2003 SP2, MSSQL 2000
SP4 on a separate box) from 5.1.2 (Apache 2.0.58) and this problem
suddenly reared its ugly head. Apache wouldn't connect to the database
for more than a few hours. PHP was running the "2000.2.8.0" DLL ... I
copied the "2000.80.2273.0" DLL over from the MSSQL 2000 box and
restarted the web box. 

I'm hoping this fixes the issue. We tried to use Microsoft's 2005 PHP
driver, but it was hopelessly bad at managing resources (If we ran more
than 15 calls to sqlsrv_query() in a single PHP session, it crashed PHP
and Apache consistently). 

So far, so good. If this solution doesn't work within 72 hours to fix
the problem, I'll come back to add another comment so that people
reading this bug report will know it's still a problem. Otherwise, if
I'm not back in a week or so, assume the DLL swap is the fix. 

Incidentally, we also run a PostgreSQL box. We connect to both MSSQL
and PGSQL from the same web server, and the PGSQL connection has never
failed.



[2007-06-30 18:34:46] jmckinzie at novonics dot com

I may be having some similar behavior related to this bug. I'm having
issues with database connections dropping on a Win 2K3 box, running
Apache 1.3.37, PHP 5.1.6 and MS SQL 2005 Express. I am able to connect
most of the time using mssql_connect. However, on a consistent basis,
probably 15-45 minutes, my mssql_connect calls begin to fail with the
same message as above:

PHP Warning:  mssql_connect(): Unable to connect to server:  x.x.x.x

Restarting Apache fixes the problem and I am able to connect for a
short time. I'm using ntwdblib.dll, version 2000.80.194.0, and have not
upgraded to 2000.80.2039.0.



[2007-01-23 05:36:47] ivanvart at gmail dot com

We have the same problem... we solved (but we dont know if is the best
option) changing the ntwdblib.dll (ver. 2000.80.2039.0) in the php
directory.



[2007-01-22 21:18:17] tschoenbachler at eoncc dot com

I too has seen this problem on one of my customers machines and FYI,
restarting IIS temporarily fixes the problem. As a work around can I do
a regsvr32 on the new ntwdblib.dll and if so where can I get it...?



[2007-01-12 16:30:37] [EMAIL PROTECTED]

But you are packing the dll's :-)

As far as I know different versions of ntwdblib.dll will default to
either tcpip or netbios for the default protocol. There might also be a
registry setting for this (I'll look for that tonight when I get home).

Just copying the dll to the system does not give you access to the
client configuration tools that allow you to change the defaults or
create server aliases that should be used as the host parameter for
mssql_connect().

If the newer version of ntwdblib.dll solves the problem I'd say we
should bundle 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/40034

-- 
Edit this bug report at http://bugs.php.net/?id=40034&edit=1

#45650 [Bgs]: MD5 should use utf8 to be comparable with non-php hashes

2008-07-29 Thread tom at tdwright dot co dot uk

ID: 45650
User updated by: tom at tdwright dot co dot uk
Reported By: tom at tdwright dot co dot uk
Status: Bogus
Bug Type: Feature/Change Request
Operating System: Linux + Windows
PHP Version: 5.2.6
New Comment:

Naturally...
OK, so part of the lock/key string I was hashing was from a static file
read with fopen. Unbeknown to me, the string that was read contained
trailing whitespace which affected the hash.
Bit of a d'oh moment when I reversed the lock+key to key+lock and saw a
space in the middle.
Easily rectified by changing my source to:
$mangle = str_replace(array("\n", "\r", "\t", " ", "\o", "\xOB"), '',
$key . $lock);
$hash1 = md5($mangle);
That array of whitespace is probably a bit OTT, but I wasn't taking
chances and that was a snippet I had laying around.
Anyway, my MD5 hashes now match in .Net, Flash and PHP - w00t!

Previous Comments:

[2008-07-29 11:55:55] [EMAIL PROTECTED]

Maybe you want to add what the problem was, so that others can find
that possibly here and don't waste time in the future :)

[2008-07-29 11:48:23] tom at tdwright dot co dot uk

Scratch all of the above.
And please accept my most sincere apologies for wasting your generously
donated time.

[2008-07-29 11:34:21] tom at tdwright dot co dot uk

OK, so if the encoding doesn't matter, something else is wrong.
Take a look at this script:
http://tdwright.co.uk/phpplayground/scribesense/pollscript.php?hash=ecb38fcfc2a18b712ed3dea22a3a65e7
It takes a hashed key/lock pair generated by a remote non-php client
and compares it to a hash of the same string produced locally by php.
For debugging purposes I've told it to output the string to be hashed,
the local hash and the supplied hash.
Note that the hash generated by two different online md5 generators
(http://www.miraclesalad.com/webtools/md5.php and
http://md5.br-design.co.uk/) both agree with the value produced by the
non-php MD5.
You've marked this as bogus because I attributed the fault incorrectly,
but that doesn't mean MD5 works properly and I maintain that this is a
bug.
Your quick response however, was certainly appreciated as I've been
pulling my hair out! =)

[2008-07-29 04:57:32] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

md5 always takes the argument as a bit vector rather than a string of
letters, i.e. no encoding matters. If your script is written in ISO-
8559-15 and you passed an embedded string literal to md5(), the result

is the hash of a ISO-8859-15 string, even though the script accepts
HTTP
requests that are supposed to be in UTF-8.

[2008-07-29 02:39:47] tom at tdwright dot co dot uk

Description:

It seems that the MD5 function in php uses the UTF7 encoding of a
string for the algorithm. Every other implementation seems to use UTF8.
Finding out about this discrepancy was not easy as
a) The programming community at large presumably takes it for granted
that MD5 uses a UTF8 encoded string
b) PHP programmers don't often need to compare their PHP generated
hashes with those generated outside of PHP.
It's a really annoying quirk and I'd love to see a change (even if it's
an option).

Reproduce code:
---

Expected result:

true

MD5 hashes should match wherever they are generated.

Actual result:
--
false

The PHP implementation of the MD5 algorithm produces hashes which are
incongruent with the results of any other (AFAIK) MD5 implementation.

--
Edit this bug report at http://bugs.php.net/?id=45650&edit=1

#45653 [Opn->Bgs]: ArrayAccess does not call offsetSet when an element is incremented

2008-07-29 Thread colder

 ID:   45653
 Updated by:   [EMAIL PROTECTED]
-Summary:  ArrayObject does not call offsetSet when an element is
   incremented
 Reported By:  agalkin at agalkin dot ru
-Status:   Open
+Status:   Bogus
-Bug Type: SPL related
+Bug Type: Scripting Engine problem
 Operating System: Mac OS X 10.5.4
 PHP Version:  5.2.6
 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

This is expected, indirect modifications through ArrayAccess is not
supported (for now), that means
$b =& $obj['foo']; $b = 2;
$obj['foo']++
++$obj['foo'];
array_pop($obj['foo']);
etc.. won't work

The fact that += works is an exception, as it's virtually $obj['foo'] =
$obj['foo'] + 1;




Previous Comments:


[2008-07-29 11:11:04] agalkin at agalkin dot ru

Description:

When an element of ArrayObject is incremented (++ operation), the
object does not call its offsetSet method. I've tried overloading all
public methods in ArrayObject: offsetGet is called, but not offsetSet or
any other. Same with decrementing (--). This behaviour makes it
impossible to handle all array modifications by overloading ArrayObject
methods in derived class.

Reproduce code:
---
class myArray extends ArrayIterator
{
public function offsetSet($index, $newval)
{
echo "offsetSet called\n";
return parent::offsetSet($index, $newval);
}
}

$a = new myArray(array('x' => 1));

echo "x += 1\n";
$a['x'] += 1; // calls offsetGet, then offsetSet with updated value
echo $a['x']."\n";

echo "x++\n";
$a['x']++; // only calls offsetGet
echo $a['x']."\n"; // but the value gets incremented


Expected result:

x += 1
offsetSet called
2
x++
offsetSet called
3


Actual result:
--
x += 1
offsetSet called
2
x++
3






-- 
Edit this bug report at http://bugs.php.net/?id=45653&edit=1

#45650 [Bgs]: MD5 should use utf8 to be comparable with non-php hashes

2008-07-29 Thread derick

ID: 45650
Updated by: [EMAIL PROTECTED]
Reported By: tom at tdwright dot co dot uk
Status: Bogus
Bug Type: Feature/Change Request
Operating System: Linux + Windows
PHP Version: 5.2.6
New Comment:

Maybe you want to add what the problem was, so that others can find
that possibly here and don't waste time in the future :)

Previous Comments:

[2008-07-29 11:48:23] tom at tdwright dot co dot uk

Scratch all of the above.
And please accept my most sincere apologies for wasting your generously
donated time.

[2008-07-29 11:34:21] tom at tdwright dot co dot uk

[2008-07-29 04:57:32] [EMAIL PROTECTED]

is the hash of a ISO-8859-15 string, even though the script accepts
HTTP
requests that are supposed to be in UTF-8.

[2008-07-29 02:39:47] tom at tdwright dot co dot uk

Description:

Reproduce code:
---

Expected result:

true

MD5 hashes should match wherever they are generated.

Actual result:
--
false

The PHP implementation of the MD5 algorithm produces hashes which are
incongruent with the results of any other (AFAIK) MD5 implementation.

--
Edit this bug report at http://bugs.php.net/?id=45650&edit=1

#45650 [Bgs]: MD5 should use utf8 to be comparable with non-php hashes

2008-07-29 Thread tom at tdwright dot co dot uk

Scratch all of the above.
And please accept my most sincere apologies for wasting your generously
donated time.

Previous Comments:

[2008-07-29 11:34:21] tom at tdwright dot co dot uk

[2008-07-29 04:57:32] [EMAIL PROTECTED]

is the hash of a ISO-8859-15 string, even though the script accepts
HTTP
requests that are supposed to be in UTF-8.

[2008-07-29 02:39:47] tom at tdwright dot co dot uk

Description:

Reproduce code:
---

Expected result:

true

MD5 hashes should match wherever they are generated.

Actual result:
--
false

The PHP implementation of the MD5 algorithm produces hashes which are
incongruent with the results of any other (AFAIK) MD5 implementation.

--
Edit this bug report at http://bugs.php.net/?id=45650&edit=1

#45650 [Bgs]: MD5 should use utf8 to be comparable with non-php hashes

2008-07-29 Thread tom at tdwright dot co dot uk

Previous Comments:

[2008-07-29 04:57:32] [EMAIL PROTECTED]

is the hash of a ISO-8859-15 string, even though the script accepts
HTTP
requests that are supposed to be in UTF-8.

[2008-07-29 02:39:47] tom at tdwright dot co dot uk

Description:

Reproduce code:
---

Expected result:

true

MD5 hashes should match wherever they are generated.

Actual result:
--
false

The PHP implementation of the MD5 algorithm produces hashes which are
incongruent with the results of any other (AFAIK) MD5 implementation.

--
Edit this bug report at http://bugs.php.net/?id=45650&edit=1

#45630 [Fbk->Opn]: IIS7 + PHP5.3 via FastCGI = Crash

2008-07-29 Thread ast dot markus at gmx dot net

 ID:   45630
 User updated by:  ast dot markus at gmx dot net
 Reported By:  ast dot markus at gmx dot net
-Status:   Feedback
+Status:   Open
 Bug Type: CGI related
 Operating System: Windows Vista SP1 x64
 PHP Version:  5.3CVS-2008-07-26 (snap)
 New Comment:

> Does this happen with Apache?
I tried Apache. But Apache does not work for me at all (not because of
PHP) and I have currently no time to try to fix Apache. I am sorry.
Maybe I try it later again ...

But here are my cgi/fastcgi related php.ini options:
cgi.force_redirect = 0
cgi.fix_pathinfo = 1
fastcgi.impersonate = 1


Previous Comments:


[2008-07-27 11:10:58] [EMAIL PROTECTED]

Does this happen with Apache? (Please try) And please provide the
cgi/fastcgi related php.ini options you have used.



[2008-07-26 08:51:13] ast dot markus at gmx dot net

Description:

Try to use a PHP5.3dev via FastCGI on IIS7 causes php-cgi.php to crash.

Reproduce code:
---


Expected result:

the phpinfo table

Actual result:
--
Thread 0 - System ID 3912
Entry point   php_cgi!fcgi_impersonate+26 
Create time   16.07.2008 18:07:25 
Time spent in user mode   0 Days 0:0:0.78 
Time spent in kernel mode   0 Days 0:0:0.265 






Function Arg 1 Arg 2 Arg 3   Source 
php5ts!zend_mm_safe_error+196 018a0968 018a0b58 1009f909   

php5ts!_zend_mm_realloc_int+a86 01ac2d88 01f4 00c0ddcc 
  
php5ts!children_scan_black+39 00c0fe00 0010 0001   

php_cgi!fcgi_write+4df 00c0ff78  56433230
php5ts!php_log_err+f1 003e  02119688
kernel32!HeapFree+14 00407830  00c0ff94
php_cgi!mainCRTStartup+da 00405ea6 7efde000 
ntdll!_RtlUserThreadStart+1b      





PHP5TS!ZEND_MM_SAFE_ERROR+196In
php-cgi__PID__3380__Date__07_16_2008__Time_06_07_26PM__96__Second_Chance_Exception_C005.dmp
the assembly instruction at php5ts!zend_mm_safe_error+196 in
M:\Server\Tools\PHP5.3\php5ts.dll from The PHP Group has caused an
access violation exception (0xC005) when trying to read from memory
location 0x033638d8 on thread 0

Module Information 
Image Name: M:\Server\Tools\PHP5.3\php5ts.dll   Symbol Type:  PDB 
Base address: 0x1000   Time Stamp:  Wed Jul 09 10:20:38 2008  
Checksum: 0x   Comments:   
COM DLL: False   Company Name:  The PHP Group 
ISAPIExtension: False   File Description:  PHP Script Interpreter 
ISAPIFilter: False   File Version:  5.3.0-dev 
Managed DLL: False   Internal Name:  PHP Script Interpreter 
VB DLL: False   Legal Copyright:  Copyright © 1997-2008 The PHP Group 
Loaded Image Name:  php5ts.dll   Legal Trademarks:  PHP 
Mapped Image Name: Original filename:  php5ts.dll 
Module name:  php5ts   Private Build:   
Single Threaded:  False   Product Name:  PHP 
Module Size:  5,18 MBytes   Product Version:  5.3.0-dev 
Symbol File Name:  M:\Server\Tools\PHP5.3\debug\php5ts.pdb   Special
Build:  & 



Thread 0 - System ID 5380
Entry point   php_cgi!fcgi_impersonate+26 
Create time   16.07.2008 22:37:23 
Time spent in user mode   0 Days 0:0:0.46 
Time spent in kernel mode   0 Days 0:0:0.171 






Function Arg 1 Arg 2 Arg 3   Source 
php5ts!zend_mm_shutdown+58 00bfdce7 003f 00c0ddcc
php_cgi!fcgi_get_params+bf 00405102 00c0ddcc 00bfdc78
msvcrt!_read+d1  0002 0001




PHP5TS!ZEND_MM_SHUTDOWN+58In
php-cgi__PID__5472__Date__07_16_2008__Time_10_37_38PM__106__Second_Chance_Exception_C005.dmp
the assembly instruction at php5ts!zend_mm_shutdown+58 in
M:\Server\Tools\PHP5.3\php5ts.dll from The PHP Group has caused an
access violation exception (0xC005) when trying to read from memory
location 0x on thread 0





-- 
Edit this bug report at http://bugs.php.net/?id=45630&edit=1

#45384 [Com]: parse_ini_file will result in parse error with no trailing newline

2008-07-29 Thread mats dot lindh at gmail dot com

 ID:   45384
 Comment by:   mats dot lindh at gmail dot com
 Reported By:  [EMAIL PROTECTED]
 Status:   Critical
 Bug Type: Filesystem function related
 Operating System: Ubuntu
 PHP Version:  5.3CVS-2008-06-28 (CVS)
 New Comment:

The fix to #45372 did not fix this issue, the problem is still in both
the PHP5_3 and HEAD branches.


Previous Comments:


[2008-06-29 00:50:26] [EMAIL PROTECTED]

$ echo -n "foo.bar = baz " > test.ini
20:46 [EMAIL PROTECTED]:~
$ /opt/php53/bin/php -r 'var_dump(parse_ini_file("test.ini"));'
array(1) {
  ["foo.bar"]=>
  string(4) "baz "
}

so the answer is, yes, a trailing space does not cause the error...if
this needs to be marked as a duplicate, whatever it takes to get this
working the same as php<=5.2



[2008-06-28 11:22:11] [EMAIL PROTECTED]

This is probably also related to the re2c/YYFILL() scanner issues I
described in Bug #45372.

I assume it's because a variable length rule is matching ("baz" in your
example) when it hits EOF and YYFILL() causes a return/abort. This
(unexpected $end) is more likely to happen with ini parsing, etc. where
it doesn't usually happen with VALID code in a PHP script because the
last thing matched in a typical file is with a fixed length rule (e.g.
"?>" or ";"), and these things only happen with variable length matches
as I explained in the other bug, though they shouldn't with working
scanner code, IMO.


BTW, does putting a space or something other than a newline after baz
allow it to work? Any character that's not allowed in the rule matching
baz should also make it "magically" work. :-)



[2008-06-28 03:05:49] [EMAIL PROTECTED]

Description:

an ini file with no trailing newline will result in "Parse error",
php5.3 only, 5.2 parses the file fine

Reproduce code:
---
$ echo -n "foo.bar = baz" > test.ini
$ /opt/php53/bin/php -r 'var_dump(parse_ini_file("test.ini"));'

Expected result:

array(1) {
  ["foo.bar"]=>
  string(3) "baz"
}


Actual result:
--
Warning: syntax error, unexpected $end in test.ini on line 1
 in Command line code on line 1

Call Stack:
0.0003 312916   1. {main}() Command line code:0
0.0128 312936   2. parse_ini_file() Command line code:1

array(0) {
}






-- 
Edit this bug report at http://bugs.php.net/?id=45384&edit=1

#45652 [Bgs]: Empty string replaced with blank character

2008-07-29 Thread dsauneuf at guillemot dot fr

 ID:   45652
 User updated by:  dsauneuf at guillemot dot fr
 Reported By:  dsauneuf at guillemot dot fr
 Status:   Bogus
 Bug Type: MSSQL related
 Operating System: Windows
 PHP Version:  5.2.6
 New Comment:

As I told you it is working fine under fedora / apache / freetds, and
this is running with the SAME mssql database.
If you are compting the number of character in an empty string, the
result cannot be something different than 0, as it is the definition of
the empty string ! So the result is wrong. Now, it can have something to
see with either php.ini or the api ntwdblib.dll, or even the way the API
is used by PHP, but it cannot be the expected behavior. It is not how
MSSQL works either.

If this has been submitted *many* times already, can you please provide
me with the resolution brought to those case ?


Previous Comments:


[2008-07-29 10:50:10] [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.

This has been submitted *many* times already, and it is also expected
behavior. It\'s simply how MSSQL works.



[2008-07-29 10:43:39] dsauneuf at guillemot dot fr

Description:

Empty string turned into a blank character.

---
Running a php site under windows 2003 / IIS / ntwdblib.dll
(2000.80.2039.0) to access an SQL server 2000 database. 
Same thing under Windows XP / IIS / ntwdblib.dll.
Works fine under fedora / apache / freetds.

Denis



Reproduce code:
---
$sql=" select '' ";
$res_id=mssql_query($sql)or die ("Database Error");
$row=mssql_fetch_row($res_id);
echo strlen($row[0]);


Expected result:

Should return 0.

Actual result:
--
Returns 1.





-- 
Edit this bug report at http://bugs.php.net/?id=45652&edit=1

#45645 [Bgs]: eval causes "Internal Server Error"

2008-07-29 Thread sergey89 at gmail dot com

 ID:   45645
 User updated by:  sergey89 at gmail dot com
 Reported By:  sergey89 at gmail dot com
 Status:   Bogus
 Bug Type: PHP options/info functions
 Operating System: Debian GNU/Linux 4.0r3
 PHP Version:  5.2.6
 New Comment:

Where is the logic?

---
 errors are shown ->
http status is 200. In case there is nothing to output, you get 500.




[2008-07-28 14:39:17] sergey89 at gmail dot com

After eval() script continues executing normally and I see expected
result on the page.



[2008-07-28 13:58:10] sergey89 at gmail dot com

Description:

I evaluate broken script with eval function. If display_errors is On i
get status 200 in http response, but if is Off i get status 500. It is
normal behaviour? error.log is empty.

Reproduce code:
---
http://bugs.php.net/?id=45645&edit=1

#45653 [NEW]: ArrayObject does not call offsetSet when an element is incremented

2008-07-29 Thread agalkin at agalkin dot ru

From: agalkin at agalkin dot ru
Operating system: Mac OS X 10.5.4
PHP version:  5.2.6
PHP Bug Type: SPL related
Bug description:  ArrayObject does not call offsetSet when an element is 
incremented

Description:

When an element of ArrayObject is incremented (++ operation), the object
does not call its offsetSet method. I've tried overloading all public
methods in ArrayObject: offsetGet is called, but not offsetSet or any
other. Same with decrementing (--). This behaviour makes it impossible to
handle all array modifications by overloading ArrayObject methods in
derived class.

Reproduce code:
---
class myArray extends ArrayIterator
{
public function offsetSet($index, $newval)
{
echo "offsetSet called\n";
return parent::offsetSet($index, $newval);
}
}

$a = new myArray(array('x' => 1));

echo "x += 1\n";
$a['x'] += 1; // calls offsetGet, then offsetSet with updated value
echo $a['x']."\n";

echo "x++\n";
$a['x']++; // only calls offsetGet
echo $a['x']."\n"; // but the value gets incremented


Expected result:

x += 1
offsetSet called
2
x++
offsetSet called
3


Actual result:
--
x += 1
offsetSet called
2
x++
3


-- 
Edit bug report at http://bugs.php.net/?id=45653&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=45653&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=45653&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=45653&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45653&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=45653&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=45653&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45653&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45653&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=45653&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45653&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=45653&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=45653&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45653&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=45653&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45653&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45653&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=45653&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=45653&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=45653&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45653&r=mysqlcfg

#44974 [Com]: ZipArchive can't open large archives

2008-07-29 Thread vadim at vadiaz dot com

 ID:   44974
 Comment by:   vadim at vadiaz dot com
 Reported By:  florian dot ember at gmail dot com
 Status:   Assigned
 Bug Type: Zip Related
 Operating System: Debian
 PHP Version:  5.2.6
 Assigned To:  pajoye
 New Comment:

This looks like exactly the same bug as
http://bugs.php.net/bug.php?id=44055 - zip archive with more than 1000
entries in root or archive produce an error on 64bit Linux systems
I fixed it and rebuild php from source for my servers
the patch is:

--- php-5.2.6.orig/ext/zip/lib/zip_open.c   2008-01-14 05:19:41.0
+0200
+++ php-5.2.6/ext/zip/lib/zip_open.c2008-07-29 14:04:36.0
+0300
@@ -313,7 +313,7 @@
/* go to start of cdir and read it entry by entry */
bufp = NULL;
clearerr(fp);
-   fseek(fp, -(cd->size+cd->comment_len+EOCDLEN), SEEK_END);
+   fseek(fp, -((long)(cd->size+cd->comment_len+EOCDLEN)), SEEK_END);
if (ferror(fp) || ((unsigned int)ftell(fp) != cd->offset)) {
/* seek error or offset of cdir wrong */
if (ferror(fp))


Previous Comments:


[2008-05-12 18:19:40] florian dot ember at gmail dot com

Description:

Opening archives with more than 1300 or so files fails with ER_READ. I
encountered this while using the close/reopen method to avoid using up
all available filehandles. On a Windows box the script below runs
without errors.

Reproduce code:
---
open('./useless.zip', ZipArchive::CREATE);
for ($i = 1; $i <= 2000; ++$i) {
$file = "$i.txt";
touch($file);
if (!$za->addFile("./$file", $file)) {
exit("Couldn't add $file");
}
echo "Added $file\n";
if ($za->numFiles % 100 == 0) {
$za->close();
$res = $za->open('./useless.zip', ZipArchive::CREATE);
if ($res !== true) {
exit("Close/reopen: Error #$res @ $i");
}
echo "Close/reopen @ $i\n";
}
}
unlink('./useless.zip');
echo 'Done.';

Expected result:

Added 1.txt
Added 2.txt
[...]
Added 2000.txt
Done.

Actual result:
--
Added 1.txt
Added 2.txt
[...]
Added 1299.txt
Close/reopen: Error #5 @ 1300





-- 
Edit this bug report at http://bugs.php.net/?id=44974&edit=1

#45652 [Opn->Bgs]: Empty string replaced with blank character

2008-07-29 Thread derick

 ID:   45652
 Updated by:   [EMAIL PROTECTED]
 Reported By:  dsauneuf at guillemot dot fr
-Status:   Open
+Status:   Bogus
 Bug Type: MSSQL related
 Operating System: Windows
 PHP Version:  5.2.6
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.

This has been submitted *many* times already, and it is also expected
behavior. It's simply how MSSQL works.


Previous Comments:


[2008-07-29 10:43:39] dsauneuf at guillemot dot fr

Description:

Empty string turned into a blank character.

---
Running a php site under windows 2003 / IIS / ntwdblib.dll
(2000.80.2039.0) to access an SQL server 2000 database. 
Same thing under Windows XP / IIS / ntwdblib.dll.
Works fine under fedora / apache / freetds.

Denis



Reproduce code:
---
$sql=" select '' ";
$res_id=mssql_query($sql)or die ("Database Error");
$row=mssql_fetch_row($res_id);
echo strlen($row[0]);


Expected result:

Should return 0.

Actual result:
--
Returns 1.





-- 
Edit this bug report at http://bugs.php.net/?id=45652&edit=1

#45652 [NEW]: Empty string replaced with blank character

2008-07-29 Thread dsauneuf at guillemot dot fr

From: dsauneuf at guillemot dot fr
Operating system: Windows
PHP version:  5.2.6
PHP Bug Type: MSSQL related
Bug description:  Empty string replaced with blank character

Description:

Empty string turned into a blank character.

---
Running a php site under windows 2003 / IIS / ntwdblib.dll
(2000.80.2039.0) to access an SQL server 2000 database. 
Same thing under Windows XP / IIS / ntwdblib.dll.
Works fine under fedora / apache / freetds.

Denis



Reproduce code:
---
$sql=" select '' ";
$res_id=mssql_query($sql)or die ("Database Error");
$row=mssql_fetch_row($res_id);
echo strlen($row[0]);


Expected result:

Should return 0.

Actual result:
--
Returns 1.

-- 
Edit bug report at http://bugs.php.net/?id=45652&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=45652&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=45652&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=45652&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45652&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=45652&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=45652&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45652&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45652&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=45652&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45652&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=45652&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=45652&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45652&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=45652&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45652&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45652&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=45652&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=45652&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=45652&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45652&r=mysqlcfg

#41193 [Asn->Fbk]: relative paths affecting script performance (compared to 5.1.x)

2008-07-29 Thread dmitry

 ID:   41193
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mauroi at digbang dot com
-Status:   Assigned
+Status:   Feedback
 Bug Type: Performance problem
 Operating System: Win32
 PHP Version:  5.2.3
 Assigned To:  dmitry
 New Comment:

I don't see any slowdown with current 5.2 and 5.3

5.1.7-dev: 483.88600349426
5.2.7-dev: 479.18510437012
5.3.0-dev: 424.29900169373



Previous Comments:


[2008-04-03 16:17:24] mh at nextra dot ch

It's still there in 5.3.0-dev.



[2007-07-14 09:12:46] [EMAIL PROTECTED]

Dmitry, please check this out. 



[2007-06-15 02:49:54] [EMAIL PROTECTED]

Just to add to this report - it looks very much like it's impacting
PHP-GTK (CLI only) Windows users too.

The base demo script in the PHP-GTK distro is reportedly 'twice as
slow' under 5.2.3 as it is under 5.1.6 in the same environment with the
same GTK+ libraries in tow.

The base demo script includes a long list of class files via relative
includes. The relevant bit of code goes:

protected function load_demos()
{
$files = glob(dirname(__FILE__).'/components/*.php');
foreach ($files as $id => $file) {
$GLOBALS['class'] = null;
if (basename($file) != basename(__FILE__)) {
if ([EMAIL PROTECTED]($file)) {
continue;
}
etc
(see
http://cvs.php.net/viewvc.cgi/php-gtk/demos/phpgtk2-demo.php?content-type=text%2Fplain&view=co
for the murky details)

The performance difference is also reported as 'visibly noticeable'
between relative and hard-coded paths under 5.2.3, although that's a
less direct comparison.

Ping me if you think I can help with any donkeywork, this one's fairly
major for us and may hold up our 'surprise release', given that the demo
scripts number rather less than the number of includes you could expect
in a RL application.

- Steph



[2007-05-09 15:47:49] mauroi at digbang dot com

Thanks Mark... The original example comes from a real life application,
but yours is far much better. Hope someone will take a look at it now
it's simpler.

Regards,
Mauro.



[2007-05-09 15:36:37] mark at markwest dot me dot uk

I can reproduce what I believe to be the same issue too.

A very simple test case to highlight this issue is 



Sample results, measured using xdebug, are as follows

is_readable with non-existent file
5.1.6 5000 calls to is_readable taking 166ms
5.2.2 5000 calls to is_readable taking 1511ms

is_readable with existing file
5.1.6 5000 calls to is_readable taking 135ms
5.2.2 5000 calls to is_readable taking 151ms

When the file isn't present php 5.2.x takes significantly longer that
in previous releases.

-Mark



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/41193

-- 
Edit this bug report at http://bugs.php.net/?id=41193&edit=1

#44055 [Bgs]: wrong default cast for offset used in fseek

2008-07-29 Thread vadim at vadiaz dot com

 ID:   44055
 User updated by:  vadim at vadiaz dot com
 Reported By:  vadim at vadiaz dot com
 Status:   Bogus
 Bug Type: Zip Related
 Operating System: Linux x86_64
-PHP Version:  5.2.5
+PHP Version:  5.2.6
 Assigned To:  pajoye
 New Comment:

It is not bogus because zip extention is now part of main package
and bug fix was not released in 5.2.6 :(
now I am rebuilding php rpms for all my distributions :(


Previous Comments:


[2008-02-05 22:49:43] [EMAIL PROTECTED]

Duplicated, it is already reported in pecl:
http://pecl.php.net/bugs/bug.php?id=12965

no need to duplicate it here.



[2008-02-05 21:32:10] vadim at vadiaz dot com

Description:

zip extention failed to open zip files with thousands of files in root
directory on 64 bit Linux systems. From strace I seen than fseek get
value close to max_long.
After reviewing code I figured out that it caused by wrong default type
cast in php-5.2.5/ext/zip/lib/zip_open.c:313

fseek(fp, -(cd->size+cd->comment_len+EOCDLEN), SEEK_END);

which should be:

fseek(fp, -((long)(cd->size+cd->comment_len+EOCDLEN)), SEEK_END);

because on 64 bit systems long is 8 byte. 
I aaplied following path and rebuild rpms for my CentOS 5 from scratch
which solves the problem

--- php-5.2.5/ext/zip/lib/zip_open.c.seek_error 2008-02-05
22:05:03.0 +0200
 
+++ php-5.2.5/ext/zip/lib/zip_open.c2008-02-05 23:17:05.0
+0200   
  
@@ -313,7 +313,7 @@


/* go to start of cdir and read it entry by entry */   


bufp = NULL;   


clearerr(fp);  


-   fseek(fp, -(cd->size+cd->comment_len+EOCDLEN), SEEK_END);  


+   fseek(fp, -((long)(cd->size+cd->comment_len+EOCDLEN)),
SEEK_END);  
 
if (ferror(fp) || ((unsigned int)ftell(fp) != cd->offset)) {   


/* seek error or offset of cdir wrong */   


if (ferror(fp)) 




Reproduce code:
---


Test of ZipArchive







Expected result:



Test of ZipArchive


ZipArchive works Ok



Actual result:
--
can not open stream 'zip0://testSite.zip/f1/tst.php'





-- 
Edit this bug report at http://bugs.php.net/?id=44055&edit=1

#38613 [Com]: SNMP issues via Apache but ok via PHP CLI

2008-07-29 Thread cinek at xo dot pl

 ID:   38613
 Comment by:   cinek at xo dot pl
 Reported By:  neil at fissure dot net
 Status:   No Feedback
 Bug Type: SNMP related
 Operating System: CentOS release 4.3
 PHP Version:  5.1.5
 New Comment:

This bug is still in PHP 5.2.6 

Works perfectly with commented line, in the 
PHP_MSHUTDOWN_FUNCTION(snmp) function of:
ext/snmp/snmp.c


Previous Comments:


[2007-04-10 01:00:00] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2007-04-02 22:07:29] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip





[2006-08-30 17:52:38] neil at fissure dot net

Commenting out this line, in the 
PHP_MSHUTDOWN_FUNCTION(snmp) function of:
src/web/php-5.1.6/ext/snmp/snmp.c

diff snmp.c snmp.c.orig 
223c223
< /*snmp_shutdown("snmpapp"); */
---
>   snmp_shutdown("snmpapp");

but possibly at the risk of re-introducing the memory 
leak it was added to combat?



[2006-08-30 16:56:20] neil at fissure dot net

I figured it was a PHP issue as it matched a similar bug 
report which was acknowledged to be due to a code change 
in PHP.

In that bug, sniper AT php.net, who make the change, 
said they were using Apache 2 (and would test with 
Apache 1.x if they got a chance). So I'm figuring this 
issue lies with PHP and Apache 1.x

I'm happy to do any requested testing/diagnostics if you 
can give me some pointers.

I'm getting the same errors as in bug 32680 (which was 
acknowledged to be a PHP issue, not say an Apache 
issue).

Thanks for your time, Neil.



[2006-08-28 06:22:20] [EMAIL PROTECTED]

Why do you think it's a PHP issue?




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/38613

-- 
Edit this bug report at http://bugs.php.net/?id=38613&edit=1

#44505 [Asn->Fbk]: include_once behavior when including UNC file

2008-07-29 Thread dmitry

 ID:  44505
 Updated by:  [EMAIL PROTECTED]
 Reported By: lmeyer at ea dot com
-Status:  Assigned
+Status:  Feedback
 Bug Type:Performance problem
 PHP Version: 5.2CVS-2008-03-25
 Assigned To: dmitry
 New Comment:

I don't see any performance difference with PHP_5_2 and PHP_5_3 CVS
versions. I also looked into filesystem calls with sysinternals FileMon
and didn't see any difference. Probably this issue is already fixed.



Previous Comments:


[2008-07-21 12:10:46] [EMAIL PROTECTED]

Switch to not OS specific.

Dmitry, can you take a look?



[2008-04-03 10:36:13] mh at nextra dot ch

It's still there in 5.3.0-dev.



[2008-04-02 19:05:43] mh at nextra dot ch

Same here. 

Including a file with full path spec (i.e.
k:\www\testserver.com\docs\inc.php) is the fastest here:
include_once count in 5 sec: 1356

Simply including the same file witout giving the full path spec is
extremly slow:
include_once count in 5 sec: 170



[2008-03-25 21:38:24] lmeyer at ea dot com

WIN PATH : //NAS/nas/www/adodb5/adodb.inc.php
LNX PATH : NAS\\nas\\www\\adodb5\\adodb.inc.php
REALPATH : using realpath as suggested in bug#44125

  WIN PATH  LNX PATH  WIN PATH   LNX PATH
  REALPATH   REALPATH
PHP 5.2 Dev Snap
200803252030
 
FIRST INCLUDE ONCE (sec)  0.04  0.05  0.05   0.06
5sec. INCLUDE_ONCE (count)295358152   288045 282244

It's way better :), but still the problem remains for linux style path
without realpath.



[2008-03-24 22:26:18] lmeyer at ea dot com

Adding some results using php 5.2.3 and 5.2.5 :

WIN PATH : //NAS/nas/www/adodb5/adodb.inc.php
LNX PATH : NAS\\nas\\www\\adodb5\\adodb.inc.php
REALPATH : using realpath as suggested in bug#44125

  WIN PATH  LNX PATH  WIN PATH   LNX PATH
  REALPATH   REALPATH
PHP 5.2.3
FIRST INCLUDE ONCE (sec)  0.05  0.02  0.07   0.06
5sec. INCLUDE_ONCE (count)250   338488232332800

PHP 5.2.5
FIRST INCLUDE ONCE (sec)  0.08  0.07  0.06   0.14
5sec. INCLUDE_ONCE (count)215   228   310427 298643



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/44505

-- 
Edit this bug report at http://bugs.php.net/?id=44505&edit=1

#43224 [Fbk->Opn]: support real graceful reload of fastcgi

2008-07-29 Thread glen at delfi dot ee

 ID:   43224
 User updated by:  glen at delfi dot ee
 Reported By:  glen at delfi dot ee
-Status:   Feedback
+Status:   Open
 Bug Type: Feature/Change Request
 Operating System: PLD Linux
 PHP Version:  5.2.5RC2
 Assigned To:  dmitry
 New Comment:

Didn't know about SIGQUIT, but ok, you can keep the signal handlers, 
but closing listening sockets on SIGTERM does not break process 
managers, it will do only good.

as for original behaviour, if you have some long running request 
running and you terminate fcgi processes with SIGTERM you can not 
start new fcgi processes on same tcp port (as the socket is still in 
use)

so to summarize signal handlers would be:
SIGTERM, SIGUSR1 - graceful shutdown -- listening sockets are 
closed, processing continues until scripts finish

SIGINT, SIGQUIT (, SIGKILL) - immediate shutdown -- listening 
sockets are closed, processes are terminated unconditionally whether 
they are idle or not.


Previous Comments:


[2008-07-29 09:00:33] [EMAIL PROTECTED]

FastCGI PHP SAPI supports only gracefull restart initiated by SIGTERM
and SIGUSR1, however you still able to terminate worker processes with
sending SIGINT/SIGQUIT to process group.

I'm not going to change it as it may break behavior with some FastCGI
managers.



[2008-06-11 11:18:40] glen at delfi dot ee

hi

any progress with the patch?

i can confirm that it works without problems since i initially 
created the patch.



[2007-11-09 11:42:42] glen at delfi dot ee

Description:

currently (checked 5.3 and 5.2) php-fcgi when receiving terminating 
signal, finishes the request, ie does not terminate immedately.

however it does not close the socket it is listening for incoming 
connections.

and there's no way to make the process really terminate in a nice 
way. ie if you really want to terminate fcgi backend processes while 
not caring whether the request is finished or not you can do this 
only by sending SIGKILL, but it might be too brutal :)

for the first problem i've created patch for unix (linux) platform, 
few testing shows that it really works.

for the second problem i'd suggest to use SIGINT for graceful 
restart (close listening socket, end when php processing finishes)

and SIGTERM would just close listening socket and abort php 
processing by making the child exit itself.

patch for 5.2.4 (also 5.2.5RC2):
http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-fcgi-graceful.patch?only_with_tag=MAIN

patch for 5.3-snap:
http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-fcgi-graceful.patch?only_with_tag=DEVEL







-- 
Edit this bug report at http://bugs.php.net/?id=43224&edit=1

#43224 [Asn->Fbk]: support real graceful reload of fastcgi

2008-07-29 Thread dmitry

 ID:   43224
 Updated by:   [EMAIL PROTECTED]
 Reported By:  glen at delfi dot ee
-Status:   Assigned
+Status:   Feedback
 Bug Type: Feature/Change Request
 Operating System: PLD Linux
 PHP Version:  5.2.5RC2
 Assigned To:  dmitry
 New Comment:

FastCGI PHP SAPI supports only gracefull restart initiated by SIGTERM
and SIGUSR1, however you still able to terminate worker processes with
sending SIGINT/SIGQUIT to process group.

I'm not going to change it as it may break behavior with some FastCGI
managers.


Previous Comments:


[2008-06-11 11:18:40] glen at delfi dot ee

hi

any progress with the patch?

i can confirm that it works without problems since i initially 
created the patch.



[2007-11-09 11:42:42] glen at delfi dot ee

Description:

currently (checked 5.3 and 5.2) php-fcgi when receiving terminating 
signal, finishes the request, ie does not terminate immedately.

however it does not close the socket it is listening for incoming 
connections.

and there's no way to make the process really terminate in a nice 
way. ie if you really want to terminate fcgi backend processes while 
not caring whether the request is finished or not you can do this 
only by sending SIGKILL, but it might be too brutal :)

for the first problem i've created patch for unix (linux) platform, 
few testing shows that it really works.

for the second problem i'd suggest to use SIGINT for graceful 
restart (close listening socket, end when php processing finishes)

and SIGTERM would just close listening socket and abort php 
processing by making the child exit itself.

patch for 5.2.4 (also 5.2.5RC2):
http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-fcgi-graceful.patch?only_with_tag=MAIN

patch for 5.3-snap:
http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-fcgi-graceful.patch?only_with_tag=DEVEL







-- 
Edit this bug report at http://bugs.php.net/?id=43224&edit=1

#45288 [Fbk->Asn]: set_include_path() functionality broken

2008-07-29 Thread dmitry

 ID:   45288
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php at isnoop dot net
-Status:   Feedback
+Status:   Assigned
 Bug Type: Filesystem function related
 Operating System: Ubuntu 7.04 server
 PHP Version:  5.3CVS-2008-06-17 (snap)
 Assigned To:  dmitry
 New Comment:

Works fine with php.ini-dist

[EMAIL PROTECTED] CGI-DEBUG]$ cat bug45288.php
http://bugs.php.net/45288

-- 
Edit this bug report at http://bugs.php.net/?id=45288&edit=1

#45651 [Opn->Bgs]: Apache Unable to load dynamic library php_pgsql.dll

2008-07-29 Thread pajoye

 ID:   45651
 Updated by:   [EMAIL PROTECTED]
 Reported By:  try at dk dot ibm dot com
-Status:   Open
+Status:   Bogus
 Bug Type: PostgreSQL related
 Operating System: Windows xp
 PHP Version:  5.2.6
-Assigned To:  
+Assigned To:  pajoye
 New Comment:

Duplicate #44931


Previous Comments:


[2008-07-29 07:43:51] try at dk dot ibm dot com

Description:

I cannot get a connection to the PostGres database from php version
5.2.6. This is possible with php version 5.2.5

Reproduce code:
---
php.ini contains extension=php_pgsql.dll

Expected result:

Apache being able to load php_pgsql.dll

Actual result:
--
Starting Apache 2.2.8 writes in the error log: "PHP Warning:  PHP
Startup: Unable to load dynamic library 'C:\\php\\ext\\php_pgsql.dll' -
The operating system cannot run %1.\r\n in Unknown on line 0"






-- 
Edit this bug report at http://bugs.php.net/?id=45651&edit=1

#45651 [NEW]: Apache Unable to load dynamic library php_pgsql.dll

2008-07-29 Thread try at dk dot ibm dot com

From: try at dk dot ibm dot com
Operating system: Windows xp
PHP version:  5.2.6
PHP Bug Type: PostgreSQL related
Bug description:  Apache Unable to load dynamic library php_pgsql.dll

Description:

I cannot get a connection to the PostGres database from php version 5.2.6.
This is possible with php version 5.2.5

Reproduce code:
---
php.ini contains extension=php_pgsql.dll

Expected result:

Apache being able to load php_pgsql.dll

Actual result:
--
Starting Apache 2.2.8 writes in the error log: "PHP Warning:  PHP Startup:
Unable to load dynamic library 'C:\\php\\ext\\php_pgsql.dll' - The
operating system cannot run %1.\r\n in Unknown on line 0"


-- 
Edit bug report at http://bugs.php.net/?id=45651&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=45651&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=45651&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=45651&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45651&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=45651&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=45651&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45651&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45651&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=45651&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45651&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=45651&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=45651&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45651&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=45651&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45651&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45651&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=45651&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=45651&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=45651&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45651&r=mysqlcfg

43 matches

Mail list logo