date:20101202

Bug #53426 [Fbk->Opn]: Segmentation fault

2010-12-02 Thread dr4k0n at list dot ru

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

 ID: 53426
 User updated by:dr4k0n at list dot ru
 Reported by:dr4k0n at list dot ru
 Summary:Segmentation fault
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:PCRE related
 Operating System:   Gentoo Linux 2.6.34-xenU-fly
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

PCRE related settings in php.ini not helps...



Full report:

PHP 5.3.3-pl1-gentoo (cli)



script:

$news = file_get_contents ('news.dat');

$pregNews = '#]*>([^<]+)([^<]|<[^h]|[^<]*(([^<]|<[^/]|#sui';

preg_match_all ($pregNews, $news, $newsResult, PREG_SET_ORDER);



news.dat: http://www.infoskidka.ru/common/news.dat

valgrind report: http://www.infoskidka.ru/common/news_segfault.txt


Previous Comments:

[2010-12-02 11:34:24] paj...@php.net

It is most likely one of the pcre stack segfault, increase it (via
php.ini's pcre.backtrack_limit setting) may fix this problem.



If it still crashes, we will need a short script to reproduce the
problem, self containted too.


[2010-12-02 08:47:27] dr4k0n at list dot ru

So, what about problem? It's really error in PCRE module? If it's
problem in module, when it will be fixed? Do you need PHP scripts with
code which makes segfault?


[2010-12-01 00:46:47] dr4k0n at list dot ru

I tried PHP 5.3.3 with enables mysqlnd and I disable all mysql
connections... Not works: again segfault.

I tried PHP 5.3.4RC1: and again segfault. Report:
http://www.infoskidka.ru/common/php_debug_segfault_5.3.4RC1.txt


[2010-11-30 12:32:22] johan...@php.net

And please don't use distribution packages but build our sources. Gentoo
and others apply patches we don't know and have no control over.


[2010-11-30 12:31:23] paj...@php.net

And we still need a way to actually reproduce this crash, like a small
script.




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/bug.php?id=53426


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

[PHP-BUG] Bug #53460 [NEW]: glob() returns false for a pattern that matches zero files

2010-12-02 Thread cameel2+php at gmail dot com

From: 
Operating system: Arch Linux
PHP version:  5.3.3
Package:  Filesystem function related
Bug Type: Bug
Bug description:glob() returns false for a pattern that matches zero files

Description:

On my system the glob() returns false if there are no files matching the
pattern even though the documentation
(http://php.net/manual/en/function.glob.php) states that it should return
an empty array. 



PHP version: 5.3.3



The only things I have changed in php.ini are open_basedir
(/srv/http/:/home/:/usr/share/webapps:/etc/webapps:/tmp/:/usr/share/pear/:/usr/share/symfony)
and enabling of several extensions (mcrypt, mysql, pdo, pdo_sqlite). 



I've seen similar bugs reported and closed a few years ago: #29928

Test script:
---
   

Expected result:

glob() should return an empty array if no files match the pattern.

Actual result:
--
The script prints 'false' when run on my box (both under Apache 2.2.17 and
with php from command line).

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

[PHP-BUG] Bug #53459 [NEW]: session_start() not compatible with memcache session handler failover

2010-12-02 Thread mhaidar at squiz dot com dot au

From: 
Operating system: lenny9
PHP version:  5.2SVN-2010-12-03 (SVN)
Package:  Session related
Bug Type: Bug
Bug description:session_start() not compatible with memcache session handler 
failover

Description:

memcache extension allows for failover (memcache.allow_failover = 1)

and can be used as a session handler (session.save_handler = memcache)



Unfortunately when failover happens a notice is thrown at session_start().



session_start() [function.session-start]: php_network_getaddresses:
getaddrinfo failed: Name or service not known



Failover still works but the page is completed corrupted.

The manual is misleading: Quote 

"memcache.allow_failover boolean



Whether to transparently failover to other servers on errors."



session_start does not deal with this so we can stay "transparent".


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

Bug #53458 [Opn]: Non-linear performance degradation on certain prepared SELECT queries

2010-12-02 Thread wez

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

 ID: 53458
 Updated by: w...@php.net
 Reported by:don at smugmug dot com
 Summary:Non-linear performance degradation on certain
 prepared SELECT queries
 Status: Open
 Type:   Bug
 Package:PDO related
 Operating System:   CentOS 5.5
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

from a twitter conversation with Don, the heart of this issue is that
the there 

appears to be a difference in the performance of fetch() or fetchAll()
depending 

on whether query() or prepare() + execute() were used.



Given that query() is really just prepare() + execute() under the
covers, it is 

difficult to explain this difference.


Previous Comments:

[2010-12-03 03:36:14] don at smugmug dot com

FYI, setting PDO::MYSQL_ATTR_USE_BUFFERED_QUERY to true/false didn't
have a large impact.  Still ~10X slower than any of the other methods
either way.  (Buffered was slightly faster)


[2010-12-02 23:39:10] don at smugmug dot com

Here's my PHP build configuration:



'./configure' '--enable-exif' '--with-gd' '--enable-gd-native-ttf'
'--with-jpeg-

dir=/usr' '--with-png-dir=/usr' '--with-freetype-dir=/usr' '--with-zlib'
'--

enable-inline-optimization' '--with-bz2' '--with-apxs2' '--with-xmlrpc'
'--with-

curl' '--with-libdir=lib64' '--with-pdo-mysql=mysqlnd' '--with-mcrypt'
'--enable-

bcmath' '--with-gmp' '--enable-mbstring' '--with-mysql=mysqlnd'
'--with-openssl' 

'--with-mysqli=mysqlnd'


[2010-12-02 23:29:50] don at smugmug dot com

Description:

When retrieving results from prepared PDO statements against MySQL, we
get 

performance that diverges from expected by 10X or more on results as low
as 1 

rows.  This only occurs for 'SELECT ... WHERE Id IN ( .. )' queries.  



The attached script provides two PDO prepared approaches
('row-prepared', default, 

and 'all-prepared') as well as a variety of control methods that use
non-prepared 

PDO queries, straight MySQL, and prepared queries using MySQLi.  Only
PDO with 

prepared queries exhibits the problem.



If the query is broken up into chunks that return 1000 rows or less
prior to 

execution, then combined afterwards in PHP, performance is as expected.

Test script:
---
You can get the sample script from:
http://www.smugmug.com/test/pdo-problem.php.gz

Expected result:

pdo-problem.php?type=row-prepared and pdo-problem.php?type=all-prepared
should 

return in ~0.5s, like the other types (row, all, chunk, mysql, mysqli).

Actual result:
--
pdo-problem.php?type=row-prepared and pdo-problem.php?type=all-prepared
return in 

~6s instead of ~0.5s






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

Bug #46679 [Com]: WSDL Error SOAP-ERROR unresolved element 'ref'

2010-12-02 Thread dpholden at gmail dot com

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

 ID: 46679
 Comment by: dpholden at gmail dot com
 Reported by:internet at cardiff dot fr
 Summary:WSDL Error  SOAP-ERROR  unresolved element 'ref'
 Status: Verified
 Type:   Bug
 Package:SOAP related
 Operating System:   *
 PHP Version:5.*, 6CVS (2009-05-05)
 Block user comment: N
 Private report: N

 New Comment:

I can confirm that this error is still present, only in later version of
PHP (Im using PHP 5.3)  the error message differs slightly.



SOAP-ERROR: Parsing Schema: can't import schema from
'http://example.com/myfile.xsd'



Where the WSDL trying to be validated contains an import to the XSD



http://example.com/myfile.xsd"/>



And the XSD file: http://example.com/myfile.xsd contains ref elements:






Previous Comments:

[2008-11-27 08:57:54] internet at cardiff dot fr

Description:



When parsing a validated WSDL Structure (WSDL is government issued)

php throws  : 

Error: WSDL Error Details: SOAP-ERROR: Parsing Schema: unresolved

element 'ref'



Error is declared solved in 5.2.5 but is not...



Reproduce code:

---

 try

 {

$client = new

SoapClient('http://www.nycotix.net/test/wsdl/ImmatTestService/ImmatTestSe

rvice.wsdl', 

array("trace" => true, "exceptions" => true, 'soap_version' =>

SOAP_1_2));

}



Expected result:



No errors thrown


[2008-11-26 09:23:59] internet at cardiff dot fr

Description:

When parsing a validated WSDL Structure (WSDL is government issued)

php throws  : 

Error: WSDL Error Details: SOAP-ERROR: Parsing Schema: unresolved
element 'ref'



Error is declared solved in 5.2.5 but is not...

Reproduce code:
---
 try

 {

$client = new
SoapClient('http://www.cardiff.fr/test/wsdl/TestImmatService/TestImmatService.wsdl',


array("trace" => true, "exceptions" => true, 'soap_version' =>
SOAP_1_2));

}

Expected result:

No errors thrown







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

Bug #53458 [Com]: Non-linear performance degradation on certain prepared SELECT queries

2010-12-02 Thread don at smugmug dot com

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

 ID: 53458
 Comment by: don at smugmug dot com
 Reported by:don at smugmug dot com
 Summary:Non-linear performance degradation on certain
 prepared SELECT queries
 Status: Open
 Type:   Bug
 Package:PDO related
 Operating System:   CentOS 5.5
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

FYI, setting PDO::MYSQL_ATTR_USE_BUFFERED_QUERY to true/false didn't
have a large impact.  Still ~10X slower than any of the other methods
either way.  (Buffered was slightly faster)


Previous Comments:

[2010-12-02 23:39:10] don at smugmug dot com

Here's my PHP build configuration:



'./configure' '--enable-exif' '--with-gd' '--enable-gd-native-ttf'
'--with-jpeg-

dir=/usr' '--with-png-dir=/usr' '--with-freetype-dir=/usr' '--with-zlib'
'--

enable-inline-optimization' '--with-bz2' '--with-apxs2' '--with-xmlrpc'
'--with-

curl' '--with-libdir=lib64' '--with-pdo-mysql=mysqlnd' '--with-mcrypt'
'--enable-

bcmath' '--with-gmp' '--enable-mbstring' '--with-mysql=mysqlnd'
'--with-openssl' 

'--with-mysqli=mysqlnd'


[2010-12-02 23:29:50] don at smugmug dot com

Description:

When retrieving results from prepared PDO statements against MySQL, we
get 

performance that diverges from expected by 10X or more on results as low
as 1 

rows.  This only occurs for 'SELECT ... WHERE Id IN ( .. )' queries.  



The attached script provides two PDO prepared approaches
('row-prepared', default, 

and 'all-prepared') as well as a variety of control methods that use
non-prepared 

PDO queries, straight MySQL, and prepared queries using MySQLi.  Only
PDO with 

prepared queries exhibits the problem.



If the query is broken up into chunks that return 1000 rows or less
prior to 

execution, then combined afterwards in PHP, performance is as expected.

Test script:
---
You can get the sample script from:
http://www.smugmug.com/test/pdo-problem.php.gz

Expected result:

pdo-problem.php?type=row-prepared and pdo-problem.php?type=all-prepared
should 

return in ~0.5s, like the other types (row, all, chunk, mysql, mysqli).

Actual result:
--
pdo-problem.php?type=row-prepared and pdo-problem.php?type=all-prepared
return in 

~6s instead of ~0.5s






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

Bug #53439 [Opn->Asn]: DatePeriod does not expose any properties

2010-12-02 Thread cataphract

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

 ID: 53439
 Updated by: cataphr...@php.net
 Reported by:from dot php dot net at brainbox dot cz
 Summary:DatePeriod does not expose any properties
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:Date/time related
 Operating System:   Windows XP SP3
 PHP Version:5.3.3
-Assigned To:
+Assigned To:cataphract
 Block user comment: N
 Private report: N



Previous Comments:

[2010-12-01 17:58:19] from dot php dot net at brainbox dot cz

Description:

The DatePeriod instance does not expose its internal properties, thus
makes impossible to extend the class.



The properties are not visible in the reflection as well. Also, when I
cast the instance to array (which usually exposes all properties), no
props are shown.



The draft of the test follows.

Test script:
---
$dp = new DatePeriod(new DateTime('2010-01-01'), new
DateInterval('P1D'), 2);

$r = new ReflectionObject($dp);

$arr = (array)$dp; // cast to array to see the values of propeties



echo "Properties:\r\n";

foreach($r->getProperties() as $v) {

echo $v->getName()."\r\n";

}

echo "\r\n";



echo "Methods:\r\n";

foreach($r->getMethods() as $v) {

echo $v->getName()."\r\n";

}

echo "\r\n";



echo "Array cast:\r\n";

echo strtr(print_r($arr, true), "\0", '_');

Expected result:

Properties:

any_valid_properties...

...listed_here_after_implementing



Array cast:

Array

(

   any_valid_properties...

   ...listed_here_after_implementing

)



Actual result:
--
Properties:



Array cast:

Array

(

)








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

Req #29085 [Asn->Csd]: bad default include_path on Windows

2010-12-02 Thread pajoye

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

 ID: 29085
 Updated by: paj...@php.net
 Reported by:christian at wenz dot org
 Summary:bad default include_path on Windows
-Status: Assigned
+Status: Closed
 Type:   Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
 Operating System:   Windows
 PHP Version:5.0.0RC3
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:

[2009-09-16 18:33:23] paj...@php.net

First of all what you are asking has nothing to do with this bug. There
is another report about this issue, marked as "to be documented".



About you mysql problem, load the mysql extension(s) and everything will
be fine. Please further support question on the php-windows or php-setup
mailing list.



Thanks for your understanding,


[2009-09-16 18:30:37] php dot netsm at majorsite dot com

So, what does this mean to those of us NOT yet on W2K3?



php.net says support for W2K Server, but 5.3 requires newer software.



I'm STILL unable to get the .ini working and I have a lot of pages
simply not loading (now I'm very glad I didn't do a full xfer to .php
pages this last few months as I wanted - I would be totally out of
business!)



I have some php pages working - the 'simple' ones that are
self-contained, but all those that use mysql are DEAD as php says  Fatal
error: Call to undefined function mysql_connect() in [FILENAMEREMOVED]
on line XXX



I was able to get my MDaemon WorldClient working by doing a re-route and
using its built-in server, but mysql is out.



Just not sure where to go/what to try anymore.  if .ini would simply
read, I'm sure all would be fine, but WHAT TO DO



thanks for any help!


[2009-09-09 06:18:28] christian at wenz dot org

great to see that this bug/change request gets some lovin' after over
five years ;-) This should do the trick in win32/build/config.w32:



---SNIP---

107c107

<   PHP_PREFIX = "C:\\php" + PHP_VERSION;

---

>   PHP_PREFIX = "C:\\php";

---SNIP---



Not sure if this should go into 5.x -- of course I'd love to see it, but
we would probably change the current behavior, and some people might
actually have installed PHP into C:\php5 and expect the include_path to
contain that automatically.


[2009-09-08 23:50:05] paj...@php.net

Agreed. Let change it in trunk at least, or maybe in 5.3.2 as well.


[2009-09-07 23:43:37] php dot netsm at majorsite dot com

I, too, find this VERY confusing, and I can't seem to get around it.



Running Win2K Server (was to upgrade this year - market stopped that...)
and have had PHP running on 5.0.3 for awhile (in C:\Program Files\PHP -
the 'default' from the install).



Went to upgrade and found latest versions need Win2003 Server or better,
so I had to take 5.2.10, but I cannot get the .ini to read.



Install.txt file says to avoid \program files\ so I deleted that and
went for a 'clean' install to \php\



phpinfo() says I'm looking at loaded .ini from C:\PHP\php.ini I've tried
setting the php.ini include_path = ".;c:\php;c:\php\ext", yet phpinfo()
says include_path is .;C:\php5\pear



The comments on this page were from 2004 - and the 'fix' was that
"people want to run php4 and php5, though, how long has php4 been gone,
and this issue is still relevant 5 years on.  this IS (IMHO) a BAD
thing and very confusing.



I look forward to some reply as I now have php running again, but none
of my databases run, none of my 'include' files work, etc.



And, please do not tell me to save my .ini file in some other location -
I've tried \winnt\system32, \winnt, c:\ and certainly c:\php - nothing
has worked.  I am almost frustrated enough to try c:\php5 and even
c:\php5\pear, but I am trying to use the install instructions!



I think this php5 error is a bug and should be fixed - even in other
versions of php (for those of us that can't afford the upgrade).




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/bug.php?id=29085


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

Bug #50410 [Asn->Csd]: curl extension slows down PHP

2010-12-02 Thread pajoye

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

 ID: 50410
 Updated by: paj...@php.net
 Reported by:procyonar at gmail dot com
 Summary:curl extension slows down PHP
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:cURL related
 Operating System:   win32 only - Windows 7
 PHP Version:*
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

Fixed in 5.3.4RC2, it will be present in 5.3 final.


Previous Comments:

[2010-09-17 21:37:43] paj...@php.net

The problem has been diagnosed, however it is not sure yet how and when
it can be fixed. See the other comments for the details.


[2010-09-17 18:58:02] misc at themeads dot net

Some additional data...



I happened to still have 5.2.5 and 5.2.6 around on the harddrive, I
dropped the 

php_curl.dll from each into my php5.2.14 installation, and they both
were snappy 

and no delay.  



I put the 5.2.13 php_curl.dll back in there, and back to the 5-7 second
delay.  



Note that the delay occurs whether you're actually exercising curl
functions or 

not... i.e., a simple page with only phpinfo() call will also result in
the same 

slowness. So it's just the act of loading the extension (which again,
lends 

credence to the "initialization" cause... but again, this simply didn't
exist in 

earlier versions of the extension, so the initialization changed, and
introduced 

this delay. 



The submitter of this article indicated it was observed in 5.2.11, my
testing 

confirmed it's in 5.2.13 as well.  I'd be curious to see results of
testing from 

5.2.6 thru 5.2.11 to see where this delay was introduced, but
unfortunately 

don't have copies of php in all those versions.


[2010-09-17 18:28:59] misc at themeads dot net

I've found this exists in 5.2.13. 

I tried to test 5.2.14, but find the same issue noted in 

http://bugs.php.net/bug.php?id=52346 in which php_curl.dll won't load at
all.  



I'm running Win2008 R2/IIS 7.5.  What I noticed is that this exists only
when 

running php in cgi mode, which of course spins up a separate php.exe for
each 

request.  If you run in it isapi mode, which loads php and these
extensions into 

the IIS worker process for the site, then this doesn't occur.  



These observations lend credence to the theory that it's related to a
delay in 

initialization when the php_curl.dll is loaded, as noted in 

http://bugs.php.net/bug.php?id=50406 ... although the answer given there
of 

"it's slow because it initializes" and then summarily closing the bug
report, is 

pretty worthless... why is the initialization so slow?  surely this is
due to 

something introduced to that initialization process with some revision,
because 

php_curl.dll hasn't always had this type of delay as a result of it's
cumbersome 

initialization process.


[2010-08-23 00:23:05] michaelhood at gmail dot com

Still exists with the php_curl.dll bundled with 5.3.3.


[2010-05-25 02:26:08] andrew at mammoth dot com dot au

Hi,



Windows Explorer says the version of libeay32.dll for me which was
included with 

PHP is 0.9.8k



I downloaded the sources from www.openssl.org/sources for that version
and the 

latest 1.0.0.



I've pastebin'd the rand_win.c code which has the RAND_screen() method
mentioned 

earlier.



OpenSSL 0.9.8k: http://pastebin.com/CjCt7bL3

OpenSSL 1.0.0: http://pastebin.com/yeQS1khQ

Diff: http://pastebin.com/fWuyTKDC



It's interesting to see the usage of MAXDELAY (1 second) and several
methods 

within that loop referencing that delay (when added together, maybe add
up to 

the 3-5 seconds delay people are experiencing).



Even the latest OpenSSL code appears to have this problem?



I've only skimmed over the diff ^ changes, perhaps they have
improved/reduced 

the delay for Windows I'm not sure.



Probably worth testing a newer libeay32.dll/php_curl module though.



If you need me to test I'd be happy to, just link me to the updated
files.




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/bug.php?id=50410


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

Bug #53458 [Com]: Non-linear performance degradation on certain prepared SELECT queries

2010-12-02 Thread don at smugmug dot com

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

 ID: 53458
 Comment by: don at smugmug dot com
 Reported by:don at smugmug dot com
 Summary:Non-linear performance degradation on certain
 prepared SELECT queries
 Status: Open
 Type:   Bug
 Package:PDO related
 Operating System:   CentOS 5.5
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

Here's my PHP build configuration:



'./configure' '--enable-exif' '--with-gd' '--enable-gd-native-ttf'
'--with-jpeg-

dir=/usr' '--with-png-dir=/usr' '--with-freetype-dir=/usr' '--with-zlib'
'--

enable-inline-optimization' '--with-bz2' '--with-apxs2' '--with-xmlrpc'
'--with-

curl' '--with-libdir=lib64' '--with-pdo-mysql=mysqlnd' '--with-mcrypt'
'--enable-

bcmath' '--with-gmp' '--enable-mbstring' '--with-mysql=mysqlnd'
'--with-openssl' 

'--with-mysqli=mysqlnd'


Previous Comments:

[2010-12-02 23:29:50] don at smugmug dot com

Description:

When retrieving results from prepared PDO statements against MySQL, we
get 

performance that diverges from expected by 10X or more on results as low
as 1 

rows.  This only occurs for 'SELECT ... WHERE Id IN ( .. )' queries.  



The attached script provides two PDO prepared approaches
('row-prepared', default, 

and 'all-prepared') as well as a variety of control methods that use
non-prepared 

PDO queries, straight MySQL, and prepared queries using MySQLi.  Only
PDO with 

prepared queries exhibits the problem.



If the query is broken up into chunks that return 1000 rows or less
prior to 

execution, then combined afterwards in PHP, performance is as expected.

Test script:
---
You can get the sample script from:
http://www.smugmug.com/test/pdo-problem.php.gz

Expected result:

pdo-problem.php?type=row-prepared and pdo-problem.php?type=all-prepared
should 

return in ~0.5s, like the other types (row, all, chunk, mysql, mysqli).

Actual result:
--
pdo-problem.php?type=row-prepared and pdo-problem.php?type=all-prepared
return in 

~6s instead of ~0.5s






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

[PHP-BUG] Bug #53458 [NEW]: Non-linear performance degradation on certain prepared SELECT queries

2010-12-02 Thread don at smugmug dot com

From: 
Operating system: CentOS 5.5
PHP version:  5.3.3
Package:  PDO related
Bug Type: Bug
Bug description:Non-linear performance degradation on certain prepared SELECT 
queries

Description:

When retrieving results from prepared PDO statements against MySQL, we get


performance that diverges from expected by 10X or more on results as low as
1 

rows.  This only occurs for 'SELECT ... WHERE Id IN ( .. )' queries.  



The attached script provides two PDO prepared approaches ('row-prepared',
default, 

and 'all-prepared') as well as a variety of control methods that use
non-prepared 

PDO queries, straight MySQL, and prepared queries using MySQLi.  Only PDO
with 

prepared queries exhibits the problem.



If the query is broken up into chunks that return 1000 rows or less prior
to 

execution, then combined afterwards in PHP, performance is as expected.

Test script:
---
You can get the sample script from:
http://www.smugmug.com/test/pdo-problem.php.gz

Expected result:

pdo-problem.php?type=row-prepared and pdo-problem.php?type=all-prepared
should 

return in ~0.5s, like the other types (row, all, chunk, mysql, mysqli).

Actual result:
--
pdo-problem.php?type=row-prepared and pdo-problem.php?type=all-prepared
return in 

~6s instead of ~0.5s

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

[PHP-BUG] Req #53457 [NEW]: number_format must support more than one character for thousands separator

2010-12-02 Thread mbabuskov at yahoo dot com

From: 
Operating system: Any
PHP version:  Irrelevant
Package:  Strings related
Bug Type: Feature/Change Request
Bug description:number_format must support more than one character for 
thousands separator

Description:

>From the documentation for number_format function:



thousands_sep

Sets the thousands separator.

Only the first byte of thousands_sep is used. 



This makes it useless for any real world usage. The recommended HTML
character for thousands separator is half-space, or   which is 8
characters. Function is only usable for obsolete or archaic systems



http://en.wikipedia.org/wiki/Thin_space

http://en.wikipedia.org/wiki/Thousands_separator#Digit_grouping

Test script:
---
echo number_format(123456, 2, '.', ' ');

Expected result:

123 456.00

Actual result:
--
123&456.00

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

Bug #53455 [Opn->Bgs]: ssdee-_fuzzy_compare only returns 0

2010-12-02 Thread johannes

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

 ID: 53455
 Updated by: johan...@php.net
 Reported by:islam dot sharabash at gmail dot com
 Summary:ssdee-_fuzzy_compare only returns 0
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:*General Issues
 Operating System:   Centos 5
 PHP Version:5.2.14
 Block user comment: N
 Private report: N

 New Comment:

please report bugs for PECL extensions on http://pecl.php.net, sorry if
this is confusing.


Previous Comments:

[2010-12-02 21:49:55] islam dot sharabash at gmail dot com

Description:

---

>From manual page:
http://www.php.net/function.ssdeep-fuzzy-compare#Return Values

---



Test script:
---




Expected result:

blah

string(7) "3:2n:2n"

int(100)



Match of 100 is expected

Actual result:
--
blah

string(7) "3:2n:2n"

int(0) 



Match of 0 returned, no matter the input






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

[PHP-BUG] Bug #53455 [NEW]: ssdee-_fuzzy_compare only returns 0

2010-12-02 Thread islam dot sharabash at gmail dot com

From: 
Operating system: Centos 5
PHP version:  5.2.14
Package:  *General Issues
Bug Type: Bug
Bug description:ssdee-_fuzzy_compare only returns 0

Description:

---

>From manual page: http://www.php.net/function.ssdeep-fuzzy-compare#Return
Values

---



Test script:
---




Expected result:

blah

string(7) "3:2n:2n"

int(100)



Match of 100 is expected

Actual result:
--
blah

string(7) "3:2n:2n"

int(0) 



Match of 0 returned, no matter the input

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

Bug #28586 [Com]: hmmm

2010-12-02 Thread crazy dot sage at gmail dot com

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

 ID: 28586
 Comment by: crazy dot sage at gmail dot com
 Reported by:dave at faf dot co dot nz
 Summary:hmmm
 Status: Bogus
 Type:   Bug
 Package:Session related
 Operating System:   Linux
 PHP Version:4.3.6
 Block user comment: N
 Private report: N

 New Comment:

PHP 5.2.14, Windows NT 6.1 build 7600 bug is still there

PHP 5.2.14 FreeBSD 7.2-RELEASE-p2 bug isn't observed


Previous Comments:

[2004-05-31 08:54:35] dave at faf dot co dot nz

appears it doesn't show up in a simple start session, set session, set
variable check session test.


[2004-05-31 06:05:12] dave at faf dot co dot nz

Description:

If session variable keys are used in the page as regular variables, ie;
$_SESSION['IsGod'] and $IsGod, the session variable is replaced with the
value of the local variable. I couldn't believe it myself, but its been
causing errors ALL OVER THE PLACE !!!. anyway, feel free to check it,
the checkbox the value was reading from was named chkIsGod so thats not
it, and on changing local to "$God" the problem died.



Horrible bug.







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

Bug #53454 [Opn->Csd]: Memory leak when using non-static class member as static one or inversely

2010-12-02 Thread hritter at e-onsoftware dot com

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

 ID: 53454
 User updated by:hritter at e-onsoftware dot com
 Reported by:hritter at e-onsoftware dot com
 Summary:Memory leak when using non-static class member as
 static one or inversely
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Performance problem
 Operating System:   Linux gentoo
 PHP Version:5.2.14
 Block user comment: N
 Private report: N

 New Comment:

I am really confused, the leak was due to the PHP debugger I
implemented. (No leak when test the bug without this debugger)


Previous Comments:

[2010-12-02 19:36:50] hritter at e-onsoftware dot com

Description:

I had some memory overflow errors. I logged the memory usage step by
step and then I see a difference of 50Mo between two logs.



In the method called between this two logs, I used a static class
attribute as a non-static one (with $this). The modification on the
attribute took effect but triggered an "Interoperability or
Compatibility Notice".

I fixed this error and I had a gain of 50 Mo!!



I have the same bug with a non-static method used as a static method
(with self::). I had a gain of 90Mo because this method was really far
away in the code.





It is a pretty harsh punishment for a compatibility error ;-)

Test script:
---
class LeakTester

{

private static $nTest = 0;



public function Test()

{

$this->nTest++;

echo $this->nTest."\n";

}

}



// ---> Test

$oTest = new LeakTester();

$oTest->Test();

echo memory_get_usage()."\n"; // (1)

$oTest->Test();

echo memory_get_usage()."\n"; // (2) > (1)

Expected result:

(2) should be equal to (1)

Actual result:
--
(2) is really greater than (1)






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

[PHP-BUG] Bug #53454 [NEW]: Memory leak when using non-static class member as static one or inversely

2010-12-02 Thread hritter at e-onsoftware dot com

From: 
Operating system: Linux gentoo
PHP version:  5.2.14
Package:  Performance problem
Bug Type: Bug
Bug description:Memory leak when using non-static class member as static one or 
inversely

Description:

I had some memory overflow errors. I logged the memory usage step by step
and then I see a difference of 50Mo between two logs.



In the method called between this two logs, I used a static class attribute
as a non-static one (with $this). The modification on the attribute took
effect but triggered an "Interoperability or Compatibility Notice".

I fixed this error and I had a gain of 50 Mo!!



I have the same bug with a non-static method used as a static method (with
self::). I had a gain of 90Mo because this method was really far away in
the code.





It is a pretty harsh punishment for a compatibility error ;-)

Test script:
---
class LeakTester

{

private static $nTest = 0;



public function Test()

{

$this->nTest++;

echo $this->nTest."\n";

}

}



// ---> Test

$oTest = new LeakTester();

$oTest->Test();

echo memory_get_usage()."\n"; // (1)

$oTest->Test();

echo memory_get_usage()."\n"; // (2) > (1)

Expected result:

(2) should be equal to (1)

Actual result:
--
(2) is really greater than (1)

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

Bug #45209 [Com]: segmentation fault, when exit script (when i open PGSQL conection)

2010-12-02 Thread liam at morland dot ca

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

 ID: 45209
 Comment by: liam at morland dot ca
 Reported by:p dot elagin at gmail dot com
 Summary:segmentation fault, when exit script (when i open
 PGSQL conection)
 Status: No Feedback
 Type:   Bug
 Package:PDO related
 Operating System:   Linux
 PHP Version:5.2.6
 Block user comment: N
 Private report: N

 New Comment:

I had this problem with PHP 5.3.3. I solved it by loading pgsql.so
before curl.so on advice of this page:



http://linux.m2osw.com/php_cli_segmentation_fault_with_pgsql


Previous Comments:

[2009-05-03 01:00:13] 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".


[2009-04-25 15:05:44] j...@php.net

Please try using this CVS snapshot:

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

  http://windows.php.net/snapshots/

And do NOT apply any 3rd party patches (like Suhosin..)


[2008-08-31 15:13:03] p dot elagin at gmail dot com

http - turn off 





GNU gdb 6.8-debian

Copyright (C) 2008 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later


This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"

and "show warranty" for details.

This GDB was configured as "x86_64-linux-gnu"...

(gdb)  set arg /var/www/script/test-pdo.php

(gdb) run

Starting program: /usr/bin/php /var/www/script/test-pdo.php

[Thread debugging using libthread_db enabled]

[New Thread 0x2ba9c0b35080 (LWP 3698)]



Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread 0x2ba9c0b35080 (LWP 3698)]

0x2ba9c562bae0 in ?? ()

(gdb) bt

#0  0x2ba9c562bae0 in ?? ()

#1  0x2ba9c024afdf in ?? () from /usr/lib/libcrypto.so.0.9.8

#2  0x2ba9c184b659 in ?? () from /usr/lib/libcurl.so.4

#3  0x2ba9c185d4e2 in ?? () from /usr/lib/libcurl.so.4

#4  0x2ba9c1853a13 in curl_global_cleanup () from
/usr/lib/libcurl.so.4

#5  0x2ba9c1615e89 in zm_shutdown_curl (type=9, module_number=1) at
/tmp/buildd/php5-5.2.6/ext/curl/interface.c:687

#6  0x00670d31 in module_destructor (module=0xc02300) at
/tmp/buildd/php5-5.2.6/Zend/zend_API.c:1921

#7  0x006772c0 in zend_hash_apply_deleter (ht=0xb74c20,
p=0xc022a0) at /tmp/buildd/php5-5.2.6/Zend/zend_hash.c:805

#8  0x00677578 in zend_hash_graceful_reverse_destroy
(ht=0xb74c20) at /tmp/buildd/php5-5.2.6/Zend/zend_hash.c:840

#9  0x0066ccb7 in zend_shutdown () at
/tmp/buildd/php5-5.2.6/Zend/zend.c:814

#10 0x00626b75 in php_module_shutdown () at
/tmp/buildd/php5-5.2.6/main/main.c:1906

#11 0x006ea306 in main (argc=-312573176, argv=0x2ba9c050c358) at
/tmp/buildd/php5-5.2.6/sapi/cli/php_cli.c:1341


[2008-08-31 15:09:28] p dot elagin at gmail dot com

>php test-pdo.php

>gdb php

GNU gdb 6.8-debian

Copyright (C) 2008 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later


This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"

and "show warranty" for details.

This GDB was configured as "x86_64-linux-gnu"...

(gdb) set arg /var/www/script/test-pdo.php

(gdb) run

Starting program: /usr/bin/php /var/www/script/test-pdo.php

[Thread debugging using libthread_db enabled]

[New Thread 0x2b427e11d080 (LWP 3526)]



Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread 0x2b427e11d080 (LWP 3526)]

0x2b4282e72ae0 in ?? ()

(gdb) bt

#0  0x2b4282e72ae0 in ?? ()

#1  0x2b427d832fdf in ?? () from /usr/lib/libcrypto.so.0.9.8

#2  0x2b427e83b659 in ?? () from /usr/lib/libcurl.so.4

#3  0x2b427e84d4e2 in ?? () from /usr/lib/libcurl.so.4

#4  0x2b427e843a13 in curl_global_cleanup () from
/usr/lib/libcurl.so.4

#5  0x2b427e5e0d79 in zm_shutdown_http_request (type=9,
module_number=1) at /tmp/pear/temp/pecl_http/http_request_api.c:194

#6  0x2b427e5c812a in zm_shutdown_http (type=1, module_number=41) at
/tmp/pear/temp/pecl_http/http.c:339

#7  0x00670d31 in module_destructor (module=0xc02310) at
/tmp/buildd/php5-5.2.6/Zend/zend_API.c:1921

#8  0x006772c0 in zend_hash_apply_deleter (ht=0xb74c20,
p=0xc022b0) at /tmp/buildd/php5-5.2.6/Zend/zend_hash.c:805

#9  0x00677578 in zend_hash_graceful_revers

[PHP-BUG] Bug #53452 [NEW]: fileinfo magic file path bug

2010-12-02 Thread gep at osiacat dot ru

From: 
Operating system: Cent OS
PHP version:  5.3.3
Package:  *General Issues
Bug Type: Bug
Bug description:fileinfo magic file path bug

Description:

This bug was reproduced only in PHP 5.3.3 On PHP 5.2.6 works fine.

If you pass a path to magic file situated in Cent OS in
"/usr/share/file/magic" 

to finfo_open, then PHP cannot parse magic file.



Though finfo_open(FILEINFO_MIME_TYPE) without second parameter as magic
file path 

works fine. (magic file path is taken from system environment)

Test script:
---
$finfo = finfo_open(FILEINFO_MIME_TYPE, '/usr/share/file/magic'); 

echo finfo_file($finfo, 'www/images/message-container/info_icon.png');

Expected result:

image/png

Actual result:
--
PHP Notice:  finfo_open(): Warning: description `8-bit ISDN mu-law
compressed 

(CCITT G.721 ADPCM voice data enco' truncated in
/home/blackjack/www/test.php on 

line 1

PHP Notice:  finfo_open(): Warning: description `8-bit ISDN mu-law
compressed 

(CCITT G.721 ADPCM voice data enco' truncated in
/home/blackjack/www/test.php on 

line 1

PHP Notice:  finfo_open(): Warning: <= not supported in 

/home/blackjack/www/test.php on line 1

PHP Notice:  finfo_open(): Warning: <= not supported in 

/home/blackjack/www/test.php on line 1

PHP Notice:  finfo_open(): Warning: <= not supported in 

/home/blackjack/www/test.php on line 1

PHP Notice:  finfo_open(): Warning: >= not supported in 

/home/blackjack/www/test.php on line 1

PHP Warning:  finfo_open(): Failed to load magic database at 

'/usr/share/file/magic'. in /home/blackjack/www/test.php on line 1

PHP Warning:  finfo_file() expects parameter 1 to be resource, boolean
given in 

/home/blackjack/www/test.php on line 1

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

Bug #53438 [Bgs]: array_fill/array_fill_keys don't run constructors multiple times

2010-12-02 Thread alxndr+bugs dot php dot net at gmail dot com

Bug #52510 [Com]: pg_query_params

2010-12-02 Thread stclaus at tiscalinet dot it

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

 ID: 52510
 Comment by: stclaus at tiscalinet dot it
 Reported by:phpdev dot ru at gmail dot com
 Summary:pg_query_params
 Status: Feedback
 Type:   Bug
 Package:PostgreSQL related
 Operating System:   Mac OS X 10.6.4
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

It seems resolved with the trunk version (just compiled 5.3.4RC3-dev) on
Mac OSX 10.6.5


Previous Comments:

[2010-10-29 05:07:54] bob at garettgroup dot com

My environment is:

Mac OS X 10.6.4

PHP 5.3.2

Apache 2.2.15

PostgreSQL 8.4.4



This is all confirm by phpinfo()



pg_connect() works as expected, however pg_query_params() is reported as
not found.


[2010-08-02 00:41:48] fel...@php.net

Probably the extension was compiled against an old libpq... because
pg_execute() and pg_query_params() requires PgSQL 7.4 or later.


[2010-08-02 00:33:09] phpdev dot ru at gmail dot com

Description:

Got a fatal error while trying to execute pg_query_params() or
pg_execute()

php 5.3.3 with libpq 8.4.4

Test script:
---
http://bugs.php.net/bug.php?id=52510&edit=1

Bug #53450 [Opn->Bgs]: Autoloading random failures , Fatal error: Class * not found

2010-12-02 Thread johannes

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

 ID: 53450
 Updated by: johan...@php.net
 Reported by:martin dot jonas at lifeweb dot cz
 Summary:Autoloading random failures , Fatal error: Class *
 not found
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:*General Issues
 Operating System:   Debian Etch
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

Please report issues in commercial distributions to the vendor.


Previous Comments:

[2010-12-02 13:06:54] martin dot jonas at lifeweb dot cz

Description:

Since upgrade to version 5.0.3 of Zend Server CE and PHP 5.3.3 we have
problems with autoloading classes.



Sometimes (randomly) autoloading classes failed with Fatal error. Most
times everytihnig works correctly but sometimes series of failures
happend.

Problem occurs in all our applications on server (including Zend Server
administratio cosole). 



Example of log entries:

[01-Dec-2010 16:15:19] PHP Fatal error: Class 'Debug' not found in
/var/www/zakazky/papouch/cz/ariadne/debug.php on line 16

[01-Dec-2010 16:15:30] PHP Fatal error: Class 'Debug' not found in
/var/www/zakazky/papouch/cz/ariadne/debug.php on line 16

[01-Dec-2010 16:15:37] PHP Fatal error: Class 'Zwas_Path' not found in
/usr/local/zend/gui/UserServer/index.php on line 43





We using Zend server CE 5.0.3, PHP 5.3.3, Server Apache/2.2.3 (Debian)
PHP/5.3.3 mod_ssl/2.2.3 OpenSSL/0.9.8c







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

[PHP-BUG] Bug #53450 [NEW]: Autoloading random failures , Fatal error: Class * not found

2010-12-02 Thread martin dot jonas at lifeweb dot cz

From: 
Operating system: Debian Etch
PHP version:  5.3.3
Package:  *General Issues
Bug Type: Bug
Bug description:Autoloading random failures , Fatal error: Class * not found

Description:

Since upgrade to version 5.0.3 of Zend Server CE and PHP 5.3.3 we have
problems with autoloading classes.



Sometimes (randomly) autoloading classes failed with Fatal error. Most
times everytihnig works correctly but sometimes series of failures
happend.

Problem occurs in all our applications on server (including Zend Server
administratio cosole). 



Example of log entries:

[01-Dec-2010 16:15:19] PHP Fatal error: Class 'Debug' not found in
/var/www/zakazky/papouch/cz/ariadne/debug.php on line 16

[01-Dec-2010 16:15:30] PHP Fatal error: Class 'Debug' not found in
/var/www/zakazky/papouch/cz/ariadne/debug.php on line 16

[01-Dec-2010 16:15:37] PHP Fatal error: Class 'Zwas_Path' not found in
/usr/local/zend/gui/UserServer/index.php on line 43





We using Zend server CE 5.0.3, PHP 5.3.3, Server Apache/2.2.3 (Debian)
PHP/5.3.3 mod_ssl/2.2.3 OpenSSL/0.9.8c


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

Req #53448 [Com]: Syslog never returns false while a FALSE is documented in php manual

2010-12-02 Thread sskaje at gmail dot com

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

 ID: 53448
 Comment by: sskaje at gmail dot com
 Reported by:sskaje at gmail dot com
 Summary:Syslog never returns false while a FALSE is
 documented in php manual
 Status: Bogus
 Type:   Feature/Change Request
 Package:Network related
 Operating System:   Irrelevant
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

@johannes

I reported as a feature requesting but not a bug.



In php manual it documented a return value of FALSE, but in that file it
RETURN_TRUE without checking if syslog()/std_syslog() works.



I just want a RETURN_FALSE after checking the return value of 

272 php_syslog(priority, "%s", message);


Previous Comments:

[2010-12-02 11:49:24] johan...@php.net

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

Parsing parameters is a special case:



"Note:  If the parameters given to a function are not what it expects,
such as passing an array where a string is expected, the return value of
the function is undefined. In this case it will likely return NULL but
this is just a convention, and cannot be relied upon."



http://php.net/manual/en/functions.internal.php


[2010-12-02 08:14:01] sskaje at gmail dot com

Description:

Sorry for the 'Package affected' select, network related is selected due
to the syslog() in php manual



in line 273 of ext/standard/syslog.c, i found following code:

[code]

272 php_syslog(priority, "%s", message);

273 RETURN_TRUE;

[/code]

while in http://cn.php.net/syslog, it writes:

[code]

Return Values

Returns TRUE on success or FALSE on failure. 

[/code]

Another return value is null from :

[code]

267 if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ls",
&priority,

268   &message, &message_len) == FAILURE) {

269 return;

270 }

[/code]

null is returned only if there is a parameter error.



Can your bring a FALSE returned by php's syslog();



Test script:
---
null

Expected result:

null

Actual result:
--
null






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

Req #53448 [Opn->Bgs]: Syslog never returns false while a FALSE is documented in php manual

2010-12-02 Thread johannes

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

 ID: 53448
 Updated by: johan...@php.net
 Reported by:sskaje at gmail dot com
 Summary:Syslog never returns false while a FALSE is
 documented in php manual
-Status: Open
+Status: Bogus
 Type:   Feature/Change Request
 Package:Network related
 Operating System:   Irrelevant
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 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

Parsing parameters is a special case:



"Note:  If the parameters given to a function are not what it expects,
such as passing an array where a string is expected, the return value of
the function is undefined. In this case it will likely return NULL but
this is just a convention, and cannot be relied upon."



http://php.net/manual/en/functions.internal.php


Previous Comments:

[2010-12-02 08:14:01] sskaje at gmail dot com

Description:

Sorry for the 'Package affected' select, network related is selected due
to the syslog() in php manual



in line 273 of ext/standard/syslog.c, i found following code:

[code]

272 php_syslog(priority, "%s", message);

273 RETURN_TRUE;

[/code]

while in http://cn.php.net/syslog, it writes:

[code]

Return Values

Returns TRUE on success or FALSE on failure. 

[/code]

Another return value is null from :

[code]

267 if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ls",
&priority,

268   &message, &message_len) == FAILURE) {

269 return;

270 }

[/code]

null is returned only if there is a parameter error.



Can your bring a FALSE returned by php's syslog();



Test script:
---
null

Expected result:

null

Actual result:
--
null






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

Req #53446 [Opn->Bgs]: Missing } error message

2010-12-02 Thread johannes

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

 ID: 53446
 Updated by: johan...@php.net
 Reported by:ly...@php.net
 Summary:Missing } error message
-Status: Open
+Status: Bogus
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 Operating System:   N/A
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

Thee are quite a few options. Given



class Foo {

public function bar() {}



the next thing might be a "}" or "public" or "var" or "const" or a
comment or ... the parser can't know. The parser can only tell you what
is not allowed. There's a project for a new parser which tries to
improve error messages.


Previous Comments:

[2010-12-02 06:04:11] ahar...@php.net

I suspect this would need Lemon, but I'll let the people who know about

such things weigh in.


[2010-12-02 05:52:51] ly...@php.net

Description:

Parse error: syntax error, unexpected $end



99 times out of a hundred this means they are missing a closing }



How tricky would it be to make this message say what TOKEN is expected
next, or something along the lines of "look for a missing '}', ')' or
quote" or whatever gets the parser into this state?...



Every newbie gets bit by this.  Some of us got bit a lot. :-)









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

Bug #53426 [Opn->Fbk]: Segmentation fault

2010-12-02 Thread pajoye

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

 ID: 53426
 Updated by: paj...@php.net
 Reported by:dr4k0n at list dot ru
 Summary:Segmentation fault
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:PCRE related
 Operating System:   Gentoo Linux 2.6.34-xenU-fly
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

It is most likely one of the pcre stack segfault, increase it (via
php.ini's pcre.backtrack_limit setting) may fix this problem.



If it still crashes, we will need a short script to reproduce the
problem, self containted too.


Previous Comments:

[2010-12-02 08:47:27] dr4k0n at list dot ru

So, what about problem? It's really error in PCRE module? If it's
problem in module, when it will be fixed? Do you need PHP scripts with
code which makes segfault?


[2010-12-01 00:46:47] dr4k0n at list dot ru

I tried PHP 5.3.3 with enables mysqlnd and I disable all mysql
connections... Not works: again segfault.

I tried PHP 5.3.4RC1: and again segfault. Report:
http://www.infoskidka.ru/common/php_debug_segfault_5.3.4RC1.txt


[2010-11-30 12:32:22] johan...@php.net

And please don't use distribution packages but build our sources. Gentoo
and others apply patches we don't know and have no control over.


[2010-11-30 12:31:23] paj...@php.net

And we still need a way to actually reproduce this crash, like a small
script.


[2010-11-30 12:30:44] paj...@php.net

Try with mysqlnd then. You can compile PHP in your home to try your
script. That won't affect your system install.




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/bug.php?id=53426


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

Bug #53438 [Opn->Bgs]: array_fill/array_fill_keys don't run constructors multiple times

2010-12-02 Thread johannes

Bug #29725 [Com]: variable $HTTP_SERVER_VARS['PHP_SELF'] does not exist or it's clear

2010-12-02 Thread vsraju dot vegesna at gmail dot com

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

 ID: 29725
 Comment by: vsraju dot vegesna at gmail dot com
 Reported by:mex at localnet dot sk
 Summary:variable $HTTP_SERVER_VARS['PHP_SELF'] does not
 exist or it's clear
 Status: Bogus
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Windows XP SP1a
 PHP Version:5.0.1
 Block user comment: N
 Private report: N

 New Comment:

why use $HTTP_SERVER_VARS['PHP_SELF'] variable in onchange event in
JavaScript's php.


Previous Comments:

[2004-08-18 08:21:24] der...@php.net

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

It depends on the webserver whether it is set or not, not really much
something that PHP can do about.



To: scottmacvicar at ntlworld dot com, don't update the bugreports with
quickfixes if you don't know what you're talking about.


[2004-08-18 01:28:00] mex at localnet dot sk

ok, but reference is the same for php 4 and php 5, without any notice
about "register_long_arrays = On".


[2004-08-18 00:57:32] scottmacvicar at ntlworld dot com

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. 



Check your php.ini and make sure you register the old-style 

vars, this was a change made for PHP 5.

 

register_long_arrays = On


[2004-08-18 00:53:39] mex at localnet dot sk

Description:

variable $HTTP_SERVER_VARS['PHP_SELF'] does not exist or it's clear

Reproduce code:
---
on windows xp sp1a I get clear page:







on freebsd 5.2-cvs i get right reply





Expected result:

variable may be filled with relative path to actual script

Actual result:
--
variable is clear (or null?)






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

Bug #52449 [Bgs]: PDB 'vc90.pdb' was not found...

2010-12-02 Thread rquadling

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

 ID: 52449
 Updated by: rquadl...@php.net
 Reported by:markskilb...@php.net
 Summary:PDB 'vc90.pdb' was not found...
 Status: Bogus
 Type:   Bug
 Package:Compile Failure
 Operating System:   Windows
 PHP Version:5.3.3
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

Sorry. Revision:
http://svn.php.net/viewvc/?view=revision&revision=305901 was 

for different bug report. Posted to 52449, rather than 53449


Previous Comments:

[2010-12-02 11:23:21] rquadl...@php.net

Automatic comment from SVN on behalf of rquadling
Revision: http://svn.php.net/viewvc/?view=revision&revision=305901
Log: Correctly case getBasename.
Fixes bug #52449


[2010-07-26 20:47:17] markskilb...@php.net

User error. Not PHP.


[2010-07-26 20:46:36] markskilb...@php.net

Hi, Pierre.



Was an error on my part. I'll mark this as bogus.


[2010-07-26 20:33:36] paj...@php.net

How does it make the exec useless? That's the iconv symbol DB.



But works here, which version did you use and from where (iconv)?


[2010-07-26 20:25:22] markskilb...@php.net

Description:

Hey, guys.



When I compile PHP with debug, I get these warnings which ultimately
leave the 

executable useless.



The vc90.pdb files appear in the ext/extname directories, but it seems
they are 

not looked for in those directories.



Any clues?

Test script:
---
C:\build\php\5.3\5.3.2\src>configure --enable-debug
--with-extra-includes=..\..\

..\include --with-extra-libs=..\..\..\lib --without-xml --without-libxml
--witho

ut-simplexml --disable-xmlreader --disable-xmlwriter --without-mysqlnd

Expected result:

Compilation success

Actual result:
--
libiconv_a_debug.lib(iconv1.obj) : warning LNK4099: PDB 'vc90.pdb' was
not found

 with 'C:\build\php\lib\libiconv_a_debug.lib' or at
'C:\build\php\5.3\5.3.2\src\

Debug_TS\vc90.pdb'; linking object as if no debug info

libiconv_a_debug.lib(localcharset1.obj) : warning LNK4099: PDB
'vc90.pdb' was no

t found with 'C:\build\php\lib\libiconv_a_debug.lib' or at
'C:\build\php\5.3\5.3

.2\src\Debug_TS\vc90.pdb'; linking object as if no debug info

libiconv_a_debug.lib(relocatable1.obj) : warning LNK4099: PDB 'vc90.pdb'
was not

 found with 'C:\build\php\lib\libiconv_a_debug.lib' or at
'C:\build\php\5.3\5.3.

2\src\Debug_TS\vc90.pdb'; linking object as if no debug info

zlib_a_debug.lib(adler32.obj) : warning LNK4099: PDB 'vc90.pdb' was not
found wi

th 'C:\build\php\lib\zlib_a_debug.lib' or at
'C:\build\php\5.3\5.3.2\src\Debug_T

S\vc90.pdb'; linking object as if no debug info

zlib_a_debug.lib(compress.obj) : warning LNK4099: PDB 'vc90.pdb' was not
found w

ith 'C:\build\php\lib\zlib_a_debug.lib' or at
'C:\build\php\5.3\5.3.2\src\Debug_

TS\vc90.pdb'; linking object as if no debug info

zlib_a_debug.lib(crc32.obj) : warning LNK4099: PDB 'vc90.pdb' was not
found with

 'C:\build\php\lib\zlib_a_debug.lib' or at
'C:\build\php\5.3\5.3.2\src\Debug_TS\

vc90.pdb'; linking object as if no debug info

zlib_a_debug.lib(deflate.obj) : warning LNK4099: PDB 'vc90.pdb' was not
found wi

th 'C:\build\php\lib\zlib_a_debug.lib' or at
'C:\build\php\5.3\5.3.2\src\Debug_T

S\vc90.pdb'; linking object as if no debug info

zlib_a_debug.lib(gzio.obj) : warning LNK4099: PDB 'vc90.pdb' was not
found with

'C:\build\php\lib\zlib_a_debug.lib' or at
'C:\build\php\5.3\5.3.2\src\Debug_TS\v

c90.pdb'; linking object as if no debug info

zlib_a_debug.lib(inffast.obj) : warning LNK4099: PDB 'vc90.pdb' was not
found wi

th 'C:\build\php\lib\zlib_a_debug.lib' or at
'C:\build\php\5.3\5.3.2\src\Debug_T

S\vc90.pdb'; linking object as if no debug info

zlib_a_debug.lib(inflate.obj) : warning LNK4099: PDB 'vc90.pdb' was not
found wi

th 'C:\build\php\lib\zlib_a_debug.lib' or at
'C:\build\php\5.3\5.3.2\src\Debug_T

S\vc90.pdb'; linking object as if no debug info

zlib_a_debug.lib(inftrees.obj) : warning LNK4099: PDB 'vc90.pdb' was not
found w

ith 'C:\build\php\lib\zlib_a_debug.lib' or at
'C:\build\php\5.3\5.3.2\src\Debug_

TS\vc90.pdb'; linking object as if no debug info

zlib_a_debug.lib(trees.obj) : warning LNK4099: PDB 'vc90.pdb' was not
found with

 'C:\build\php\lib\zlib_a_debug.lib' or at
'C:\build\php\5.3\5.3.2\src\Debug_TS\

vc90.pdb'; linking object as if no debug info

zlib_a_debug.lib(uncompr.obj) : warning LNK4099: PDB 'vc90.pdb' was not
found wi

th 'C:\build\php\lib\zlib_a_debug.lib' or at
'C:\build\php\5.3\5.3.2\src\Debug_T

S\vc90.pdb'; linking object as if no deb

Bug #53333 [Fbk]: Random crash

2010-12-02 Thread pajoye

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

 ID: 5
 Updated by: paj...@php.net
 Reported by:paj...@php.net
 Summary:Random crash
 Status: Feedback
 Type:   Bug
 Package:MySQLi related
 Operating System:   *
 PHP Version:5.3.3
 Assigned To:mysql
 Block user comment: N
 Private report: N

 New Comment:

You need a debug build to get it working.


Previous Comments:

[2010-12-02 08:45:42] kriscr...@php.net

Unfortunately, still no go with the forward slashes.  Has this new debug
feature actually been tested yet, or perhaps it needs to be enabled in
the source then rebuilt?  I'm fresh out of ideas.  :/


[2010-12-01 23:25:47] kriscr...@php.net

Alrighty, I'll try using forward slashes and will post the outcome when
it's done.  The bug typically takes anywhere from 1 hour up to around 4
hours to repro under stress, so stand by for now.  =)


[2010-12-01 14:13:55] paj...@php.net

Right, but only for the ini setting tests, as it should not be enabled
by default :)


[2010-12-01 14:10:34] and...@php.net

Pierre, I'm a fan of this, but it can, and will probably, hit the
run-time performance. But I can't tell without a benchmark.
Unfortunately Ulf has some other things to do at the moment. It is easy
to change that, just edit mysqlnd.h and find MYSQLND_DBG_ENABLED and set
it to 1 in all cases.


[2010-12-01 14:06:17] paj...@php.net

Wondering if it could be useful to have the logs in non debug builds as
well, what do you think?




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/bug.php?id=5


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

Bug #44686 [Com]: SOAP-ERROR: Parsing WSDL

2010-12-02 Thread norberto dot ostallo at qualitygroup dot it

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

 ID: 44686
 Comment by: norberto dot ostallo at qualitygroup dot it
 Reported by:dmittner at llnw dot com
 Summary:SOAP-ERROR: Parsing WSDL
 Status: No Feedback
 Type:   Bug
 Package:SOAP related
 Operating System:   Gentoo
 PHP Version:5.2.5
 Block user comment: N
 Private report: N

 New Comment:

I'm having the same problem consuming OTA (Open Travel Alliance) XML
files, using php5.3.3 on Ubuntu.

Does anyone know a fix or a workaround?


Previous Comments:

[2010-11-10 11:29:07] php at leentje dot org

Also not working in php5.3 it seems. Why is this bug not being picked
up? It kind of defeats the purpose if I have to store WSDL files
locally... and even worse, also have to change/add name= to the file.


[2010-07-05 12:35:00] belgattitude at gmail dot com

Same error connecting to .net service with PHP 5.2.13 and PHP 5.2.14RC2



Try it with, for example :



$url = "http://d2c.9squared.com/f/ContentRetrieval.asmx?WSDL";;

$soapClient = new SoapClient($url array('soap_version' => SOAP_1_2));





will result in



[WSDL] SOAP-ERROR: Parsing Schema: unresolved element 'ref' attribute.


[2009-04-09 10:26:16] tommy at profi dot it

Same here. Test files available at



http://dev.profi.it/ota.zip



Please review this issue! Thanks a lot!


[2009-03-13 15:05:55] tjxlacrosse at hotmail dot com

Is anyone looking into this?  I'm having the same issue on

Ubuntu 8.10 with PHP 5.2.6-2 when trying to parse a .net web service



WSDL:http://d2c.9squared.com/f/ContentRetrieval.asmx?WSDL


[2009-01-12 22:02:23] simon at connexon dot com

Hi,



I'm having the same problem... And it's a bit tough for me to
troubleshoot because I'm using a file package provided by a website.



http://www.nena.org/xml_schemas/NENAFiles/CurrentNENA/CurrentNENA.zip



I'm trying to get the validateAddress to work (from the v7 interface)
but so far no luck! I'm stuck on this undefined ref variable.




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/bug.php?id=44686


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

Bug #53063 [Com]: and are broken

2010-12-02 Thread r3wald at gmail dot com

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

 ID: 53063
 Comment by: r3wald at gmail dot com
 Reported by:robin2008 at altruists dot org
 Summary: and  are broken
 Status: Open
 Type:   Bug
 Package:XSLT related
 Operating System:   Ubuntu 10.04
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

Please have a look at: http://bugs.php.net/bug.php?id=52257 .



I had exactly the same issue as you have. Disabling redland.so finally
resolved 

it.



Robert


Previous Comments:

[2010-10-14 08:37:01] robin2008 at altruists dot org

Description:

Somewhere between 5.3.0 and 5.3.2, the security model for XSL has been
over tightened. XSL stylesheets which refer to other stylesheet by
 or  now fail to work.

Test script:
---
 (and ) are broken



$aDOM=   new DOMDocument();

$aDOM->loadXML('');

$stylesheet= new DOMDocument();

$proc=   new XSLTProcessor();

$stylesheet->loadXML('http://www.w3.org/1999/XSL/Transform";>');



$proc->importStyleSheet($stylesheet); 

$oops= $proc->transformToDoc($aDOM);



?>

Expected result:

Assuming there is a valid stylesheet at "somesheet.xslt", the transform
should work as per the W3C spec.



Am I missing something? Is there, for example, a way to set this
security default somewhere? Or a class method for XSLTProcessor to
disable this?

Actual result:
--
Warning: XSLTProcessor::importStylesheet()
[xsltprocessor.importstylesheet]: error in
/home/robin/f2f/hardcode/xsl-import.php on line 10



Warning: XSLTProcessor::importStylesheet()
[xsltprocessor.importstylesheet]: Local file read for
/home/robin/f2f/hardcode/somesheet.xslt refused in
/home/robin/f2f/hardcode/xsl-import.php on line 10



Warning: XSLTProcessor::importStylesheet()
[xsltprocessor.importstylesheet]: error in
/home/robin/f2f/hardcode/xsl-import.php on line 10



Warning: XSLTProcessor::importStylesheet()
[xsltprocessor.importstylesheet]: xsl:import: read rights for
/home/robin/f2f/hardcode/somesheet.xslt denied in
/home/robin/f2f/hardcode/xsl-import.php on line 10



Warning: XSLTProcessor::transformToDoc() [xsltprocessor.transformtodoc]:
No stylesheet associated to this object in
/home/robin/f2f/hardcode/xsl-import.php on line 11








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

Req #53434 [Opn->Fbk]: More details for slow requests

2010-12-02 Thread fat

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

 ID: 53434
 Updated by: f...@php.net
 Reported by:webmaster_apc at colnect dot com
 Summary:More details for slow requests
-Status: Open
+Status: Feedback
 Type:   Feature/Change Request
 Package:FPM related
 Operating System:   gentoo linux
 PHP Version:5.3.1RC1
 Block user comment: N
 Private report: N

 New Comment:

I need the output of the ./configure, not its arguments.


Previous Comments:

[2010-12-01 16:02:43] webmaster_apc at colnect dot com

I'm using Gentoo with PHP5.3.3R1 installed. It include php-fpm 0.6.5



These are the flags for the Gentoo install script



 Installed versions:  5.3.3-r3(5.3)(13:28:35 11/28/10)(berkdb bzip2
cli crypt ctype curl fileinfo filter fpm gd gdbm hash iconv json mysql
mysqli mysqlnd nls pcntl pdo phar posix readline session sharedmem
simplexml ssl tidy tokenizer truetype unicode xml zlib -adabas -apache2
-bcmath -birdstep -calendar -cdb -cgi -cjk -curlwrappers -db2 -dbmaker
-debug -doc -embed -empress -empress-bcs -enchant -esoob -exif -firebird
-flatfile -frontbase -ftp -gd-external -gmp -imap -inifile -interbase
-intl -iodbc -ipv6 -kerberos -kolab -ldap -ldap-sasl -libedit -mssql
-oci8 -oci8-instant-client -odbc -pic -postgres -qdbm -recode -sapdb
-sharedext -snmp -soap -sockets -solid -spell -sqlite -sqlite3 -suhosin
-sybase-ct -sysvipc -threads -wddx -xmlreader -xmlrpc -xmlwriter -xpm
-xsl -zip)







phpinfo() produces the following:





'./configure' '--prefix=/usr' '--build=x86_64-pc-linux-gnu'
'--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc'
'--localstatedir=/var/lib' '--prefix=/usr/lib64/php5.3'
'--mandir=/usr/lib64/php5.3/man' '--infodir=/usr/lib64/php5.3/info'
'--libdir=/usr/lib64/php5.3/lib' '--with-libdir=lib64' '--without-pear'
'--disable-maintainer-zts' '--disable-bcmath' '--with-bz2'
'--disable-calendar' '--with-curl' '--without-curlwrappers'
'--without-enchant' '--disable-exif' '--disable-ftp' '--with-gettext'
'--without-gmp' '--disable-intl' '--disable-ipv6' '--without-kerberos'
'--enable-mbstring' '--with-mcrypt' '--without-mssql' '--with-onig=/usr'
'--with-openssl' '--with-openssl-dir=/usr' '--enable-pcntl'
'--without-pgsql' '--without-pspell' '--without-recode' '--enable-shmop'
'--without-snmp' '--disable-soap' '--disable-sockets'
'--without-sqlite3' '--without-sybase-ct' '--disable-sysvmsg'
'--disable-sysvsem' '--disable-sysvshm' '--with-tidy' '--disable-wddx'
'--disable-xmlreader' '--disable-xmlwriter' '--without-xmlrpc'
'--without-xsl' '--disable-zip' '--with-zlib' '--disable-debug'
'--enable-dba' '--without-cdb' '--with-db4' '--disable-flatfile'
'--with-gdbm' '--disable-inifile' '--without-qdbm'
'--with-freetype-dir=/usr' '--with-t1lib=/usr' '--disable-gd-jis-conv'
'--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--without-xpm-dir'
'--with-gd' '--without-interbase' '--with-mysql=mysqlnd'
'--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--with-mysqli=mysqlnd'
'--without-oci8' '--without-pdo-dblib' '--with-pdo-mysql=mysqlnd'
'--without-pdo-pgsql' '--without-pdo-sqlite' '--without-pdo-odbc'
'--with-readline' '--without-libedit' '--with-mm' '--without-sqlite'
'--with-libevent-dir=/usr/lib64' '--with-pcre-regex=/usr'
'--with-pcre-dir=/usr' '--with-config-file-path=/etc/php/fpm-php5.3'
'--with-config-file-scan-dir=/etc/php/fpm-php5.3/ext-active'
'--disable-cli' '--disable-cgi' '--enable-fpm' '--disable-embed'
'--without-apxs2' 



Thanks


[2010-12-01 15:53:06] f...@php.net

FPM uses ptrace or equivalent to do this.



If it does not work, maybe there a problem at configure. That's why I
asked you 

the ./configure output to see if ptrace is detected.


[2010-12-01 15:51:45] webmaster_apc at colnect dot com

Sorry, I didn't read through. You wrote it already exists. Could you
please refer me to the relevant documentation? Thanks.


[2010-12-01 15:49:10] webmaster_apc at colnect dot com

This isn't a bug but a feature request hence I believe the details are
irrelevant. Thanks


[2010-12-01 15:47:42] f...@php.net

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


which system are you using ?



can you give us the ./configure ... --enable-fpm output ?



It already exists in FPM, maybe your system doesn't have what

Bug #53426 [Fbk->Opn]: Segmentation fault

[PHP-BUG] Bug #53460 [NEW]: glob() returns false for a pattern that matches zero files

[PHP-BUG] Bug #53459 [NEW]: session_start() not compatible with memcache session handler failover

Bug #53458 [Opn]: Non-linear performance degradation on certain prepared SELECT queries

Bug #46679 [Com]: WSDL Error SOAP-ERROR unresolved element 'ref'

Bug #53458 [Com]: Non-linear performance degradation on certain prepared SELECT queries

Bug #53439 [Opn->Asn]: DatePeriod does not expose any properties

Req #29085 [Asn->Csd]: bad default include_path on Windows

Bug #50410 [Asn->Csd]: curl extension slows down PHP

Bug #53458 [Com]: Non-linear performance degradation on certain prepared SELECT queries

[PHP-BUG] Bug #53458 [NEW]: Non-linear performance degradation on certain prepared SELECT queries

[PHP-BUG] Req #53457 [NEW]: number_format must support more than one character for thousands separator

Bug #53455 [Opn->Bgs]: ssdee-_fuzzy_compare only returns 0

[PHP-BUG] Bug #53455 [NEW]: ssdee-_fuzzy_compare only returns 0

Bug #28586 [Com]: hmmm

Bug #53454 [Opn->Csd]: Memory leak when using non-static class member as static one or inversely

[PHP-BUG] Bug #53454 [NEW]: Memory leak when using non-static class member as static one or inversely

Bug #45209 [Com]: segmentation fault, when exit script (when i open PGSQL conection)

[PHP-BUG] Bug #53452 [NEW]: fileinfo magic file path bug

Bug #53438 [Bgs]: array_fill/array_fill_keys don't run constructors multiple times

Bug #52510 [Com]: pg_query_params

Bug #53450 [Opn->Bgs]: Autoloading random failures , Fatal error: Class * not found

[PHP-BUG] Bug #53450 [NEW]: Autoloading random failures , Fatal error: Class * not found

Req #53448 [Com]: Syslog never returns false while a FALSE is documented in php manual

Req #53448 [Opn->Bgs]: Syslog never returns false while a FALSE is documented in php manual

Req #53446 [Opn->Bgs]: Missing } error message

Bug #53426 [Opn->Fbk]: Segmentation fault

Bug #53438 [Opn->Bgs]: array_fill/array_fill_keys don't run constructors multiple times

Bug #29725 [Com]: variable $HTTP_SERVER_VARS['PHP_SELF'] does not exist or it's clear

Bug #52449 [Bgs]: PDB 'vc90.pdb' was not found...

Bug #53333 [Fbk]: Random crash

Bug #44686 [Com]: SOAP-ERROR: Parsing WSDL

Bug #53063 [Com]: and are broken

Req #53434 [Opn->Fbk]: More details for slow requests

34 matches

Site Navigation

Mail list logo

Footer information