Bug #63769 [Opn->Nab]: file:// protocol does not support percent-encoded characters

2012-12-15 Thread ab
Edit report at https://bugs.php.net/bug.php?id=63769&edit=1

 ID: 63769
 Updated by: a...@php.net
 Reported by:hanskrentel at yahoo dot de
 Summary:file:// protocol does not support percent-encoded
 characters
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Streams related
 Operating System:   Windows
 PHP Version:5.4.9
 Block user comment: N
 Private report: N

 New Comment:

Since both "catalog%202.xml" and "catalog 2.xml" are perfectly valid filenames, 
the fs function behaviour is correct. The user can decide where it's needed url 
encoded and where it's not.


Previous Comments:

[2012-12-14 15:51:57] hanskrentel at yahoo dot de

Description:

Using a file-URI containing characters that are percent-encoded (one byte/octet 
is encoded as a character triplet, e.g. Space -> %20) do not work. The URI is 
not properly decoded.

Consider the following file on disk:

c:\temp\catalog 2.xml

PHP is able to find it existing via:

is_file('file:///C:/temp/catalog 2.xml');

However, commonly that file is written as:

file:///C:/temp/catalog%202.xml

And using that filename in PHP via:

is_file('file:///C:/temp/catalog%202.xml');

gives FALSE.

(Example is a libxml catalog file, properly specified for libxml)

When you're looking into this, it might be worth to also look for + as encoding 
for space - just not that this case gets overlooked.




Test script:
---
 '/', ' ' => '%20']), 
rawurlencode($name));
printf('%s - %s (%d)', is_file($uri) ? 'OK' : 'FAIL', $uri, unlink($name));

Expected result:

OK - file:///C:/temp/catalog%202.xml (1)

Actual result:
--
FAIL - file:///C:/temp/catalog%202.xml (1)






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


[PHP-BUG] Bug #63780 [NEW]: Segmentation fault when try to get $request

2012-12-15 Thread php dot maks3w at virtualplanets dot net
From: php dot maks3w at virtualplanets dot net
Operating system: 
PHP version:  5.4.9
Package:  SOAP related
Bug Type: Bug
Bug description:Segmentation fault when try to get $request

Description:

Situation: Custom class which extend from SoapClient and override "public 
function __doRequest($request, $location, $action, $version, $one_way =
null)"

$request can't be used to compare strings, instead throw a Segmentation
Fault 
error.

$request looks like a C Pointer or any other type instead of a PHP String
type

As workaround you can filter the variable passing the value through a
function 
which return basically the same value of the argument passed as input (like

ltrim) after that it's possible save the returned value and now is a normal
PHP 
String and can be compared.

Test script:
---
FAILING CODE:
public $lastRequest;

function __doRequest($request, $location, $action, $version, $one_way = 0)
{
$this->lastRequest = $request;
}

$this->assertEquals('SomeContent', $this->lastRequest); // Segmentation
Faul.


WORKAROUND:
public $lastRequest;

function __doRequest($request, $location, $action, $version, $one_way = 0)
{
$this->lastRequest = ltrim($request); // Pass $request through a
function
}

$this->assertEquals('SomeContent', $this->lastRequest); // Works



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



Bug #62111 [Com]: MySQL PDO memory leaks, when used own result row class

2012-12-15 Thread enumag at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=62111&edit=1

 ID: 62111
 Comment by: enumag at gmail dot com
 Reported by:hosiplan at gmail dot com
 Summary:MySQL PDO memory leaks, when used own result row
 class
 Status: Open
 Type:   Bug
 Package:PDO related
 Operating System:   Linux
 PHP Version:5.4.4RC1
 Block user comment: N
 Private report: N

 New Comment:

Try this one instead. It does not matter whether you use MySQL or SQLlite. The 
problem is that if you add some arguments for the constructor, it consumes more 
and more memory without any reason.

-
class pdo_row {
public function __construct() { }
}

$pdo = new PDO('mysql:host=127.0.0.1;dbname=information_schema', 'root', '');

$pdo->exec("DROP TABLE test");
$pdo->exec("CREATE TABLE test(id INT, col VARCHAR(200))");
for ($i = 0; $i < 100; $i++) {
  $pdo->exec(sprintf("INSERT INTO test(id, col) VALUES (1, 
'012345678901234567890123456789012345678901234567890123456789-%d')", $i));
}

printf("With ctor argument (memory usage increase):");
for ($i = 0; $i < 10; $i++) {
$stmt = $pdo->prepare("SELECT col FROM test");
$stmt->setFetchMode(PDO::FETCH_CLASS, 'pdo_row', array($stmt));
$stmt->execute();
$rows = $stmt->fetchAll();
printf("emalloc %d kB, malloc %d kB\n",
memory_get_usage() / 1024,
memory_get_usage(true) / 1024);
}

printf("Without ctor argument (no memory usage increase):");
for ($i = 0; $i < 10; $i++) {
$stmt = $pdo->prepare("SELECT col FROM test");
$stmt->setFetchMode(PDO::FETCH_CLASS, 'pdo_row');
$stmt->execute();
$rows = $stmt->fetchAll();
printf("emalloc %d kB, malloc %d kB\n",
memory_get_usage() / 1024,
memory_get_usage(true) / 1024);
}


Previous Comments:

[2012-06-13 15:10:15] u...@php.net

It matters a whole lot what the cause is. It is not a leak. First, it helps to 
have some clean test code, such as this:

class pdo_row {
public function __construct($stmt) {
$stmt = NULL;
}
}

/* $pdo = new PDO("mysql:dbname=test;unix_socket=/var/run/mysql/mysql.sock", 
"root", ""); */
$pdo = new PDO("sqlite::memory:");

$pdo->exec("DROP TABLE test");
$pdo->exec("CREATE TABLE test(id INT, col VARCHAR(200))");
for ($i = 0; $i < 100; $i++) {
  $pdo->exec(sprintf("INSERT INTO test(id, col) VALUES (1, 
'012345678901234567890123456789012345678901234567890123456789-%d')", $i));
}

for ($i = 0; $i < 10; $i++) {
$stmt = $pdo->prepare("SELECT col FROM test");
$stmt->execute();
$stmt->setFetchMode(PDO::FETCH_CLASS, 'pdo_row', array($stmt));
$rows = $stmt->fetchAll();
printf("emalloc %d kB, malloc %d kB\n",
memory_get_usage() / 1024,
memory_get_usage(true) / 1024);
}


Running the above for SQLlite gives me:

emalloc 205 kB, malloc 256 kB
emalloc 206 kB, malloc 512 kB
emalloc 207 kB, malloc 512 kB
emalloc 208 kB, malloc 512 kB
emalloc 209 kB, malloc 512 kB
emalloc 210 kB, malloc 512 kB
emalloc 211 kB, malloc 512 kB
emalloc 212 kB, malloc 512 kB
emalloc 213 kB, malloc 512 kB
emalloc 214 kB, malloc 512 kB


Running the above for MySQL gives me:



emalloc 221 kB, malloc 256 kB
emalloc 231 kB, malloc 512 kB
emalloc 240 kB, malloc 512 kB
emalloc 250 kB, malloc 512 kB
emalloc 259 kB, malloc 512 kB
emalloc 269 kB, malloc 512 kB
emalloc 278 kB, malloc 512 kB
emalloc 288 kB, malloc 512 kB
emalloc 297 kB, malloc 512 kB
emalloc 307 kB, malloc 512 kB


Second, it helps to understand the matter. In both cases emalloc() figures 
increase, which is to be expected. PHP objects are created, the extensions 
allocate memory using the PHP internal e*alloc() function family and the 
figures increase. And, in both cases malloc() figures are the same. 

No difference between MySQL and SQLite.


[2012-06-12 16:18:47] hosiplan at gmail dot com

I don't really care what you name it. It's a real problem and its eating my 
memory and it shouldn't!


[2012-06-12 13:33:16] u...@php.net

There is no leak with MySQL. Memory usage increases, that's it.

==6216== LEAK SUMMARY:
==6216==definitely lost: 0 bytes in 0 blocks
==6216==indirectly lost: 0 bytes in 0 blocks
==6216==  possibly lost: 0 bytes in 0 blocks
==6216==still reachable: 54 bytes in 2 blocks
==6216== suppressed: 0 bytes in 0 blocks
==6216== Rerun with --leak-check=full to see details of leaked memory


[2012-06-11 13:48:11] juzna dot cz at gmail dot com

The same causes PHP to crash completely on Windows 32bit with MSSQL server 
(using 
sqlsrv driver). I gue

Bug #63706 [Ver]: Cannot build PHP-5.5 with --enable-dtrace on Fedora 17

2012-12-15 Thread dsp
Edit report at https://bugs.php.net/bug.php?id=63706&edit=1

 ID: 63706
 Updated by: d...@php.net
 Reported by:sebast...@php.net
 Summary:Cannot build PHP-5.5 with --enable-dtrace on Fedora
 17
 Status: Verified
 Type:   Bug
 Package:*General Issues
 Operating System:   Fedora 17
 PHP Version:5.5Git-2012-12-06 (Git)
 Assigned To:dsp
 Block user comment: N
 Private report: N

 New Comment:

go ahead and merge it then


Previous Comments:

[2012-12-15 08:12:33] sebast...@php.net

The patch solves the issue for me: I can build PHP-5.5 with --enable-dtrace.


[2012-12-11 07:12:10] r...@php.net

The following patch has been added/updated:

Patch Name: dtrace-cflags.patch
Revision:   1355209930
URL:
https://bugs.php.net/patch-display.php?bug=63706&patch=dtrace-cflags.patch&revision=1355209930


[2012-12-10 11:53:00] d...@php.net

This might be one of the issues, but my investigations said that usually the 
problem is that a main/main.o build is triggered by a prequisite of 
zend_dtrace.d.o that shouldnt be there.


[2012-12-10 11:49:33] r...@php.net

The issue seems to come from CFLAGS beeing exported, so used in the dtrace/gcc 
sub-process.

>From Makefile
CFLAGS = $(CFLAGS_CLEAN) -prefer-non-pic -static
CFLAGS_CLEAN = -I/usr/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic 
-fno-strict-aliasing -Wno-pointer-sign -fvisibility=hidden

Obviously -prefer-non-pic is not a gcc option, but a libtool one.

The attached patch use CFLAGS_CLEAN instead of CFLAGS for dtrace build.

It solves the dtrace build issue on fedora (and rpm) build.

If you think it's ok, I will apply it.


[2012-12-10 11:46:00] r...@php.net

The following patch has been added/updated:

Patch Name: dtrace-cflags.patch
Revision:   1355139960
URL:
https://bugs.php.net/patch-display.php?bug=63706&patch=dtrace-cflags.patch&revision=1355139960




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

https://bugs.php.net/bug.php?id=63706


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


Bug #63706 [Ver->Csd]: Cannot build PHP-5.5 with --enable-dtrace on Fedora 17

2012-12-15 Thread sebastian
Edit report at https://bugs.php.net/bug.php?id=63706&edit=1

 ID: 63706
 Updated by: sebast...@php.net
 Reported by:sebast...@php.net
 Summary:Cannot build PHP-5.5 with --enable-dtrace on Fedora
 17
-Status: Verified
+Status: Closed
 Type:   Bug
 Package:*General Issues
 Operating System:   Fedora 17
 PHP Version:5.5Git-2012-12-06 (Git)
 Assigned To:dsp
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of remi
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=717b367085d55528cad82716bc5ad9736831540f
Log: Fixed bug #63706: Cannot build PHP-5.5 with --enable-dtrace on Fedora 17


Previous Comments:

[2012-12-15 22:00:50] d...@php.net

go ahead and merge it then


[2012-12-15 08:12:33] sebast...@php.net

The patch solves the issue for me: I can build PHP-5.5 with --enable-dtrace.


[2012-12-11 07:12:10] r...@php.net

The following patch has been added/updated:

Patch Name: dtrace-cflags.patch
Revision:   1355209930
URL:
https://bugs.php.net/patch-display.php?bug=63706&patch=dtrace-cflags.patch&revision=1355209930


[2012-12-10 11:53:00] d...@php.net

This might be one of the issues, but my investigations said that usually the 
problem is that a main/main.o build is triggered by a prequisite of 
zend_dtrace.d.o that shouldnt be there.


[2012-12-10 11:49:33] r...@php.net

The issue seems to come from CFLAGS beeing exported, so used in the dtrace/gcc 
sub-process.

>From Makefile
CFLAGS = $(CFLAGS_CLEAN) -prefer-non-pic -static
CFLAGS_CLEAN = -I/usr/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic 
-fno-strict-aliasing -Wno-pointer-sign -fvisibility=hidden

Obviously -prefer-non-pic is not a gcc option, but a libtool one.

The attached patch use CFLAGS_CLEAN instead of CFLAGS for dtrace build.

It solves the dtrace build issue on fedora (and rpm) build.

If you think it's ok, I will apply 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

https://bugs.php.net/bug.php?id=63706


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