Bug #63769 [Opn->Nab]: file:// protocol does not support percent-encoded characters
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
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
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
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
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