[PHP-BUG] Bug #53093 [NEW]: Broken data in object
From: Operating system: Gentoo Linux 2.6.31-xenU-fly PHP version: 5.2.14 Package: *General Issues Bug Type: Bug Bug description:Broken data in object Description: PHP broke data in memory... Script: http://www.infoskidka.ru/common/splitTest.php It will show: --- Array ( [0] = CDBResult Object ( [advance_anchors] = Array ( [0] = 10 [1] = 20 ) ) ) CDBResult Object ( [advance_anchors] = 10 ) CDBResult Object ( [advance_anchors] = 20 ) Array ( [0] = CDBResult Object ( [advance_anchors] = 20 ) [1] = CDBResult Object ( [advance_anchors] = 20 ) ) --- But I expect: --- Array ( [0] = CDBResult Object ( [advance_anchors] = Array ( [0] = 10 [1] = 20 ) ) ) CDBResult Object ( [advance_anchors] = 10 ) CDBResult Object ( [advance_anchors] = 20 ) Array ( [0] = CDBResult Object ( [advance_anchors] = 10 ) [1] = CDBResult Object ( [advance_anchors] = 20 ) ) --- -- Edit bug report at http://bugs.php.net/bug.php?id=53093edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53093r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53093r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53093r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53093r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53093r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53093r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53093r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53093r=needscript Try newer version: http://bugs.php.net/fix.php?id=53093r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53093r=support Expected behavior: http://bugs.php.net/fix.php?id=53093r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53093r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53093r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53093r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53093r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53093r=dst IIS Stability: http://bugs.php.net/fix.php?id=53093r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53093r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53093r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53093r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53093r=mysqlcfg
Bug #53093 [Opn-Csd]: Broken data in object
Edit report at http://bugs.php.net/bug.php?id=53093edit=1 ID: 53093 User updated by:dr4k0n at list dot ru Reported by:dr4k0n at list dot ru Summary:Broken data in object -Status: Open +Status: Closed Type: Bug Package:*General Issues Operating System: Gentoo Linux 2.6.31-xenU-fly PHP Version:5.2.14 Block user comment: N New Comment: It's because of not I not use clone operator Previous Comments: [2010-10-18 09:07:14] dr4k0n at list dot ru Description: PHP broke data in memory... Script: http://www.infoskidka.ru/common/splitTest.php It will show: --- Array ( [0] = CDBResult Object ( [advance_anchors] = Array ( [0] = 10 [1] = 20 ) ) ) CDBResult Object ( [advance_anchors] = 10 ) CDBResult Object ( [advance_anchors] = 20 ) Array ( [0] = CDBResult Object ( [advance_anchors] = 20 ) [1] = CDBResult Object ( [advance_anchors] = 20 ) ) --- But I expect: --- Array ( [0] = CDBResult Object ( [advance_anchors] = Array ( [0] = 10 [1] = 20 ) ) ) CDBResult Object ( [advance_anchors] = 10 ) CDBResult Object ( [advance_anchors] = 20 ) Array ( [0] = CDBResult Object ( [advance_anchors] = 10 ) [1] = CDBResult Object ( [advance_anchors] = 20 ) ) --- -- Edit this bug report at http://bugs.php.net/bug.php?id=53093edit=1
Bug #49741 [Com]: I have a problem create a phar file on my system
Edit report at http://bugs.php.net/bug.php?id=49741edit=1
ID: 49741
Comment by: kazemipouya at gmail dot com
Reported by:admin at sulehosting dot co dot za
Summary:I have a problem create a phar file on my system
Status: Bogus
Type: Bug
Package:PHAR related
Operating System: open suse 11.1
PHP Version:5.3.0
Block user comment: N
New Comment:
After one year of reporting this bug, I got the same problem. I followed
all comments but for me, the phar is not there!!
$phar = new Phar('./test.phar', 0, 'test.phar');
$phar-startBuffering();
$phar['test.txt'] = 'phar is here';
$phar-setStub($phar-createDefaultStub('index-cli.php',
'index.php'));
Previous Comments:
[2009-10-06 11:21:10] sjo...@php.net
Setting to Bogus because it seemed to work after all.
[2009-10-05 21:17:48] admin at sulehosting dot co dot za
It works, the phar file gets created. Thanks a lot. I am trying to go
through the changes to see what caused it to work.
[2009-10-05 11:24:38] sjo...@php.net
Could you please to run your example script again, with error reporting
enabled and check whether it works? If it does not, please provide an
strace, like this:
strace php -f foo.php 2 strace.txt
Please provide an URL to the strace here (you can use a pastebin). Thank
you.
[2009-10-05 08:45:33] admin at sulehosting dot co dot za
1)file_put_contents (works!)
$strFile = '/tmp/myFile.txt';
$strData = 'hello world';
$res = file_put_contents($strFile, $strData);
if($res):
print 'it works';
else:
print 'it failed';
endif;
2)uname -a
Linux pegasus 2.6.27.29-0.1-pae #1 SMP 2009-08-15 17:53:59 +0200 i686
i686 i386 GNU/Linux
[2009-10-03 18:45:34] f...@php.net
Could you please verify that writing to /tmp works at all (for example
file_put_contents() in the same script) and also say if it's 32bit or
64bit
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=49741
--
Edit this bug report at http://bugs.php.net/bug.php?id=49741edit=1
[PHP-BUG] Req #53094 [NEW]: Use '0' instead of '' as a result of converting boolean FALSE to string
From:
Operating system: Irrelevant
PHP version: Irrelevant
Package: Scripting Engine problem
Bug Type: Feature/Change Request
Bug description:Use '0' instead of '' as a result of converting boolean FALSE
to string
Description:
I'd like to propose a change in converting booleans to string.
It'd be better if (string) FALSE returns '0' instead of empty string ('').
Why to do so?
a) More logical behavior.
b) Using booleans in output would be meaningful.
c) Backward-compatible change - as documentation says: This allows
conversion back and forth between boolean and string values. - this
behavior is not changed by this, because (bool) '0' is FALSE.
Test script:
---
?php
echo (string) FALSE; //nothing now, '0' requested
var_dump((bool) '0'); //FALSE, no change
var_dump((string) FALSE === '0'); //FALSE, TRUE requested
--
Edit bug report at http://bugs.php.net/bug.php?id=53094edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53094r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53094r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53094r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53094r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53094r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53094r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53094r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53094r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53094r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53094r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53094r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53094r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53094r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53094r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53094r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53094r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53094r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53094r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53094r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53094r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53094r=mysqlcfg
[PHP-BUG] Req #53095 [NEW]: Optional type hinting on variables
From:
Operating system: Nix/Win
PHP version: 5.3.3
Package: Java related
Bug Type: Feature/Change Request
Bug description:Optional type hinting on variables
Description:
I know there's been a lot of discussion about type hinting for years now.
It's prevalent in most OOP languages and as PHP makes the move towards
being an OOP scripting language, it would make sense to introduce certain
language features. Unless there is a technical constraint (quite possible),
would it be possible to introduce type hinting on variables?
I make the argument because it would be encourage data validation based on
the variable type rather than having to create functions to check if the
input matches the variable type. It would vastly improve current and future
frameworks, reduce code and improve error handling (assuming the programmer
implements).
Cast exceptions would need to be implemented as well, eg. String could not
be cast to int, int cannot be set a string value etc.
It can also in part replace the is_int, is_numeric, is_bool etc. functions;
functions which wouldn't be needed if there was variable type hinting.
Test script:
---
?php
$a = 0;
int $b = 0;
changeVar($var) {
try {
$var = 'abc123';
} catch (Exception $ex) {
echo 'could not change variable value or something';
}
}
Expected result:
There will be a compile time error because variable type hinting isn't
supported. If it were to be implemented you would expect something along
the lines of:
changeVar($a);
changeVar($b);
// prints exception message
echo $a; // abc123
echo $b; // 0
Actual result:
--
Throws a compile time error, isn't supported by php
--
Edit bug report at http://bugs.php.net/bug.php?id=53095edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53095r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53095r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53095r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53095r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53095r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53095r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53095r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53095r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53095r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53095r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53095r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53095r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53095r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53095r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53095r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53095r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53095r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53095r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53095r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53095r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53095r=mysqlcfg
Bug #40286 [Com]: PHP fastcgi with PHP_FCGI_CHILDREN don't kill children when parent is killed
Edit report at http://bugs.php.net/bug.php?id=40286edit=1 ID: 40286 Comment by: jason at backup-technology dot co dot uk Reported by:gabriel at oxeva dot fr Summary:PHP fastcgi with PHP_FCGI_CHILDREN don't kill children when parent is killed Status: No Feedback Type: Bug Package:CGI related Operating System: Linux 2.6 PHP Version:5.2.0+ Assigned To:dmitry Block user comment: N New Comment: We're experiencing this issue with 5.2.14 and also 5.3.3. On 5.2.14 the strace of the hanging processes with parent ID 1 left behind show this: Process 21330 attached - interrupt to quit accept(0, It hangs on that and if we interrupt it shows: Process 21330 attached - interrupt to quit accept(0, unfinished ... Running a gdb (with debug symbols) and attaching to the process and running bt we get: (gdb) bt #0 0x00320c8d4530 in __accept_nocancel () from /lib64/libc.so.6 #1 0x0062abe8 in fcgi_accept_request (req=0x7fff3cb385b0) at /usr/src/debug/php-5.2.14/sapi/cgi/fastcgi.c:957 #2 0x0062c14f in main (argc=1, argv=0x7fff3cb3a758) at /usr/src/debug/php-5.2.14/sapi/cgi/cgi_main.c:1703 On the 5.3.3 (with no debug symbols) we have the following: (gdb) bt #0 0x0038936d4530 in __accept_nocancel () from /lib64/libc.so.6 #1 0x0063e0c3 in ?? () #2 0x0063ad2a in ?? () #3 0x00389361d994 in __libc_start_main () from /lib64/libc.so.6 #4 0x00421ec9 in _start () Hope this helps. Jason. Previous Comments: [2009-07-26 21:55:21] machochito at gmail dot com I have the same problem on CentOS 5.3 with php 5.2.9. Have someone solution to this problem? Thanks. [2009-07-22 20:45:21] bgross at mcw dot edu ... on second thought, after looking at my php.ini again, I think the major change was due to adding the line session.gc_probability = 1. I believe this is set to session.gc_probability = 0 by default in Debian [2009-07-22 20:14:41] bgross at mcw dot edu I'm not familiar with the inner-workings PHP, so I'm sorry if this is not relevant. I was experiencing a problem with php-cgi processes staying around and filling up my memory. After I added the line cgi.fix_pathinfo=1 to my php.ini, the problem went away. I'm using PHP FastCGI 5.2.6 with Lighttpd 1.4.19 on Debian 5.0.2 Hope that's helpful [2009-07-02 03:41:27] porjo38 at yahoo dot com dot au The php 5.3.0 changelog states the following: Fixed bug #40286 (PHP fastcgi with PHP_FCGI_CHILDREN don't kill children when parent is killed). (Dmitry) I've just compiled php 5.3.0 under Centos5.3 with Apache2.2.3 + mod_fcgid2.2-4. The issue is still occuring for me. When I restart Apache, I usually end up with a bunch of php-cgi process with ppid of 1 (init), although it doesn't happen every time. [2009-05-16 03:43:15] scripts at topducks dot com I'm using php5.2.9 mod_fcgid, not using children method. Whenever I restart apache I get orphaned php processes. Without the cron job to check and kill them off they would waste a lot of memory. 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=40286 -- Edit this bug report at http://bugs.php.net/bug.php?id=40286edit=1
Bug #52389 [Com]: Memory (de)allocation problem for pgsql notices
Edit report at http://bugs.php.net/bug.php?id=52389edit=1 ID: 52389 Comment by: jaromir dot dolecek at skype dot net Reported by:miroslav dot zacek at skype dot net Summary:Memory (de)allocation problem for pgsql notices Status: Feedback Type: Bug Package:PostgreSQL related Operating System: Linux (Kubuntu) PHP Version:5.3.2 Block user comment: N New Comment: I've uploaded revised patch - the previous version has crash problem with pg_last_error(), because _php_pgsql_trim_message() was also used in context, where non-persistent return value was expected I'll post the repeat PHP skript and some analysis shortly. Previous Comments: [2010-08-26 11:35:41] miroslav dot zacek at skype dot net I tried to create a simple test that crashes but it is not so easy. More complex page with several requests and session in DB crashes (not always, several reloads are needed usually). I'll try to create it but I'm quite busy now so it won't be that fast. Sorry. [2010-08-14 01:13:49] fel...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Have you tried it without Suhosin? [2010-08-13 14:43:57] clint at ubuntu dot com I've not seen the segfault that Miroslav is reporting. However, I applied the patch to the latest version of php in Ubuntu (5.3.3- ubuntu4) and there was no problem running phppgadmin as ethan suggests. I would guess Ethan's problem is more likely this one: https://sourceforge.net/tracker/? func=detailaid=2954087group_id=37132atid=418980 Which basically says that phppgadmin won't support php 5.3 in their stable tree. [2010-08-03 00:04:45] ethan at remindercall dot com I've applied this patch to the 5.3.2 sources and it causes new problems - PHPPgAdmin doesn't even function with the patch applied. [2010-08-02 10:10:42] miroslav dot zacek at skype dot net GNU gdb (GDB) 7.1-ubuntu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html 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. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/sbin/apache2...done. (gdb) handle SIG33 pass nostop noprint SignalStop Print Pass to program Description SIG33 NoNo Yes Real-time event 33 (gdb) set pagination 0 (gdb) run Starting program: /usr/sbin/apache2 -k start -X [Thread debugging using libthread_db enabled] [New Thread 0x7fffe9619710 (LWP 1339)] [Thread 0x7fffe9619710 (LWP 1339) exited] Program received signal SIGSEGV, Segmentation fault. 0x73d98343 in _zend_mm_free_canary_int (heap=0x783fdca0, p=0x3700d1) at /build/buildd/php5-5.3.2/Zend/zend_alloc_canary.c:2090 2090SUHOSIN_MM_CHECK_CANARIES(mm_block, efree()); (gdb) backtrace full #0 0x73d98343 in _zend_mm_free_canary_int (heap=0x783fdca0, p=0x3700d1) at /build/buildd/php5-5.3.2/Zend/zend_alloc_canary.c:2090 p = 0x73d79bc0 H\203\354\bH\213GHH\205\300t\017\213\267\230 mm_block = 0x791a00d0 next_block = 0x73d79bc0 size = 4165624496 #1 0x7fffebee2761 in _php_pgsql_notice_ptr_dtor (ptr=0x783fdca0) at /build/buildd/php5-5.3.2/ext/pgsql/pgsql.c:835 notice = 0x787ad648 #2 0x73d84b98 in zend_hash_clean (ht=0x7fffec0f9168) at /build/buildd/php5-5.3.2/Zend/zend_hash.c:753 p = 0x79298b50 #3 0x7fffebee9410 in zm_deactivate_pgsql (type=-130032480, module_number=209) at /build/buildd/php5-5.3.2/ext/pgsql/pgsql.c:1034 No locals. #4 0x73d79bdc in module_registry_cleanup (module=0x783fdca0) at /build/buildd/php5-5.3.2/Zend/zend_API.c:2150 No locals. #5 0x73d84734 in zend_hash_reverse_apply (ht=0x744701c0, apply_func=0x73d79bc0 module_registry_cleanup) at /build/buildd/php5-5.3.2/Zend/zend_hash.c:957
Bug #52389 [Com]: Memory (de)allocation problem for pgsql notices
Edit report at http://bugs.php.net/bug.php?id=52389edit=1 ID: 52389 Comment by: jaromir dot dolecek at skype dot net Reported by:miroslav dot zacek at skype dot net Summary:Memory (de)allocation problem for pgsql notices Status: Feedback Type: Bug Package:PostgreSQL related Operating System: Linux (Kubuntu) PHP Version:5.3.2 Block user comment: N New Comment: This problem happens due to interaction with user session save handler and pgsql extension. Repeat script is included as next comment. So after further analysis, this is what happens: 1. request ends, PHP runs RSHUTDOWN method of individual modules in reverse order than loaded - i.e. pgsql (dynamically loaded) before session (which is builtin) 2. pgsql RSHUTDOWN is called, PGG(notices) is cleared 3. session RSHUTDOWN is called, which runs user session save method, invoking pgsql code 4. if sql query generates notice, message is added to PGG(notices) using non-persistent memory 5. new notice stays in PGG(notice) after RSHUTDOWN process is finished, the non-persistent memory is cleared automatically by PHP, leaving PGG(notices) with dangling pointer On next request, this is what happens: 1. when pgsql RSHUTDOWN is called, code tries to remove the stale entry 2. the pointer is no longer valid, so random memory is overwritten (either double free if the memory happens to point to newly allocated valid value, or just random memory) Problem happens only when using PHP as Apache module or FastCGI - it needs the same process to process at least two separate requests. That's also reason why the crash never happens for first request. Proper fix is for session code to not abuse RSHUTDOWN for running session store. Similar problem might happen for other modules with local deinicialization in RSHUTDOWN method. I know it's documented that session_write_close() should be called explicitly, but PHP interpreter should not allow this to happen - session code should not invoke user code in RSHUTDOWN. To make explicit and force people fix code, it should issue some PHP warning if session is still active in RSHUTDOWN. Bandaid fix for pgsql is included in pgsql-fixed.diff. Note it generates some memory leaks warnings with DEBUG, but that is not possible to avoid when session runs after pgsql cleanup. Previous Comments: [2010-10-18 12:56:41] jaromir dot dolecek at skype dot net I've uploaded revised patch - the previous version has crash problem with pg_last_error(), because _php_pgsql_trim_message() was also used in context, where non-persistent return value was expected I'll post the repeat PHP skript and some analysis shortly. [2010-08-26 11:35:41] miroslav dot zacek at skype dot net I tried to create a simple test that crashes but it is not so easy. More complex page with several requests and session in DB crashes (not always, several reloads are needed usually). I'll try to create it but I'm quite busy now so it won't be that fast. Sorry. [2010-08-14 01:13:49] fel...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Have you tried it without Suhosin? [2010-08-13 14:43:57] clint at ubuntu dot com I've not seen the segfault that Miroslav is reporting. However, I applied the patch to the latest version of php in Ubuntu (5.3.3- ubuntu4) and there was no problem running phppgadmin as ethan suggests. I would guess Ethan's problem is more likely this one: https://sourceforge.net/tracker/? func=detailaid=2954087group_id=37132atid=418980 Which basically says that phppgadmin won't support php 5.3 in their stable tree. [2010-08-03 00:04:45] ethan at remindercall dot com I've applied this patch to the 5.3.2 sources and it causes new problems - PHPPgAdmin doesn't even function with the patch applied. 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=52389 -- Edit this bug report at
Bug #52389 [Com]: Memory (de)allocation problem for pgsql notices
Edit report at http://bugs.php.net/bug.php?id=52389edit=1
ID: 52389
Comment by: jaromir dot dolecek at skype dot net
Reported by:miroslav dot zacek at skype dot net
Summary:Memory (de)allocation problem for pgsql notices
Status: Feedback
Type: Bug
Package:PostgreSQL related
Operating System: Linux (Kubuntu)
PHP Version:5.3.2
Block user comment: N
New Comment:
Trigger script (must replace DBNAME and USER with proper info):
?php
$c = pg_connect(host=localhost port=6001 dbname=DBNAME user=USER);
function nop() { }
function trigger_notice() {
global $c;
$rv2 = pg_query($c, 'SELECT * FROM foo()');
}
$rv = pg_query($c, 'CREATE OR REPLACE FUNCTION foo() RETURNS integer AS
$$
BEGIN
RAISE NOTICE \'foo\';
RETURN 3;
END
$$ LANGUAGE \'plpgsql\' VOLATILE');
session_set_save_handler('nop', 'nop', 'nop', 'trigger_notice', 'nop',
'nop');
session_start();
Previous Comments:
[2010-10-18 13:18:33] jaromir dot dolecek at skype dot net
This problem happens due to interaction with user session save handler
and pgsql extension. Repeat script is included as next comment.
So after further analysis, this is what happens:
1. request ends, PHP runs RSHUTDOWN method of individual modules in
reverse
order than loaded - i.e. pgsql (dynamically loaded) before session
(which is
builtin)
2. pgsql RSHUTDOWN is called, PGG(notices) is cleared
3. session RSHUTDOWN is called, which runs user session save method,
invoking
pgsql code
4. if sql query generates notice, message is added to PGG(notices) using
non-persistent memory
5. new notice stays in PGG(notice) after RSHUTDOWN process is finished,
the non-persistent memory is cleared automatically by PHP, leaving
PGG(notices) with
dangling pointer
On next request, this is what happens:
1. when pgsql RSHUTDOWN is called, code tries to remove the stale entry
2. the pointer is no longer valid, so random memory is overwritten
(either double free if the memory happens to point to newly allocated
valid value, or just
random memory)
Problem happens only when using PHP as Apache module or FastCGI - it
needs the same process to process at least two separate requests. That's
also reason why the
crash never happens for first request.
Proper fix is for session code to not abuse RSHUTDOWN for running
session store. Similar problem might happen for other modules with local
deinicialization in
RSHUTDOWN method.
I know it's documented that session_write_close() should be called
explicitly, but PHP interpreter should not allow this to happen -
session code should not
invoke user code in RSHUTDOWN. To make explicit and force people fix
code, it should issue some PHP warning if session is still active in
RSHUTDOWN.
Bandaid fix for pgsql is included in pgsql-fixed.diff.
Note it generates some memory leaks warnings with DEBUG, but that is not
possible to avoid when session runs after pgsql cleanup.
[2010-10-18 12:56:41] jaromir dot dolecek at skype dot net
I've uploaded revised patch - the previous version has crash problem
with
pg_last_error(), because _php_pgsql_trim_message() was also used in
context, where
non-persistent return value was expected
I'll post the repeat PHP skript and some analysis shortly.
[2010-08-26 11:35:41] miroslav dot zacek at skype dot net
I tried to create a simple test that crashes but it is not so easy. More
complex page with several requests and session in DB crashes (not
always, several reloads are needed usually). I'll try to create it but
I'm quite busy now so it won't be that fast. Sorry.
[2010-08-14 01:13:49] fel...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Have you tried it without Suhosin?
[2010-08-13 14:43:57] clint at ubuntu dot com
I've not seen the segfault that Miroslav is reporting.
However, I applied the patch to the latest version of php in Ubuntu
(5.3.3-
ubuntu4) and there was no problem running phppgadmin as ethan suggests.
I would guess Ethan's problem is more likely this one:
https://sourceforge.net/tracker/?
Bug #52389 [Fbk-Opn]: Memory (de)allocation problem for pgsql notices
Edit report at http://bugs.php.net/bug.php?id=52389edit=1
ID: 52389
User updated by:miroslav dot zacek at skype dot net
Reported by:miroslav dot zacek at skype dot net
Summary:Memory (de)allocation problem for pgsql notices
-Status: Feedback
+Status: Open
Type: Bug
Package:PostgreSQL related
Operating System: Linux (Kubuntu)
PHP Version:5.3.2
Block user comment: N
New Comment:
Thanks Jaromir :-)
Previous Comments:
[2010-10-18 13:19:45] jaromir dot dolecek at skype dot net
Trigger script (must replace DBNAME and USER with proper info):
?php
$c = pg_connect(host=localhost port=6001 dbname=DBNAME user=USER);
function nop() { }
function trigger_notice() {
global $c;
$rv2 = pg_query($c, 'SELECT * FROM foo()');
}
$rv = pg_query($c, 'CREATE OR REPLACE FUNCTION foo() RETURNS integer AS
$$
BEGIN
RAISE NOTICE \'foo\';
RETURN 3;
END
$$ LANGUAGE \'plpgsql\' VOLATILE');
session_set_save_handler('nop', 'nop', 'nop', 'trigger_notice', 'nop',
'nop');
session_start();
[2010-10-18 13:18:33] jaromir dot dolecek at skype dot net
This problem happens due to interaction with user session save handler
and pgsql extension. Repeat script is included as next comment.
So after further analysis, this is what happens:
1. request ends, PHP runs RSHUTDOWN method of individual modules in
reverse
order than loaded - i.e. pgsql (dynamically loaded) before session
(which is
builtin)
2. pgsql RSHUTDOWN is called, PGG(notices) is cleared
3. session RSHUTDOWN is called, which runs user session save method,
invoking
pgsql code
4. if sql query generates notice, message is added to PGG(notices) using
non-persistent memory
5. new notice stays in PGG(notice) after RSHUTDOWN process is finished,
the non-persistent memory is cleared automatically by PHP, leaving
PGG(notices) with
dangling pointer
On next request, this is what happens:
1. when pgsql RSHUTDOWN is called, code tries to remove the stale entry
2. the pointer is no longer valid, so random memory is overwritten
(either double free if the memory happens to point to newly allocated
valid value, or just
random memory)
Problem happens only when using PHP as Apache module or FastCGI - it
needs the same process to process at least two separate requests. That's
also reason why the
crash never happens for first request.
Proper fix is for session code to not abuse RSHUTDOWN for running
session store. Similar problem might happen for other modules with local
deinicialization in
RSHUTDOWN method.
I know it's documented that session_write_close() should be called
explicitly, but PHP interpreter should not allow this to happen -
session code should not
invoke user code in RSHUTDOWN. To make explicit and force people fix
code, it should issue some PHP warning if session is still active in
RSHUTDOWN.
Bandaid fix for pgsql is included in pgsql-fixed.diff.
Note it generates some memory leaks warnings with DEBUG, but that is not
possible to avoid when session runs after pgsql cleanup.
[2010-10-18 12:56:41] jaromir dot dolecek at skype dot net
I've uploaded revised patch - the previous version has crash problem
with
pg_last_error(), because _php_pgsql_trim_message() was also used in
context, where
non-persistent return value was expected
I'll post the repeat PHP skript and some analysis shortly.
[2010-08-26 11:35:41] miroslav dot zacek at skype dot net
I tried to create a simple test that crashes but it is not so easy. More
complex page with several requests and session in DB crashes (not
always, several reloads are needed usually). I'll try to create it but
I'm quite busy now so it won't be that fast. Sorry.
[2010-08-14 01:13:49] fel...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Have you tried it without Suhosin?
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=52389
--
Edit this bug
Bug #52413 [Com]: MySQLi build failure on OS X
Edit report at http://bugs.php.net/bug.php?id=52413edit=1 ID: 52413 Comment by: alwin dot roosen at webline dot be Reported by:ahar...@php.net Summary:MySQLi build failure on OS X Status: Closed Type: Bug Package:MySQLi related Operating System: Mac OS X 10.6.4 PHP Version:5.3.3 Assigned To:mysql Block user comment: N New Comment: Just want to confirm that the patch is working, was having the same issue on FreeBSD 7.3, mysql 5.0.90 and php 5.3.3 Previous Comments: [2010-08-13 12:09:30] ahar...@php.net Looks good to me; with that change, MySQLi builds fine on OS X against an external libmysqlclient. Thanks Andrey! [2010-08-13 11:57:54] and...@php.net Patch just committed, please use svn or wait at least 2h to get a snapshot from snaps.php.net, for testing. If everything is alright, fix will be part of 5.3.4 . Thanks! [2010-08-13 11:57:06] and...@php.net Automatic comment from SVN on behalf of andrey Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=302179 Log: Fix for bug #52413 MySQLi build failure on OS X [2010-07-23 13:42:06] ahar...@php.net The bottom line on this one is that we're now manually including a bunch more libmysql headers in a different order to 5.3.2, and one of the headers we're pulling in is my_global.h. my_global.h checks if HAVE_ULONG is #define'd, and if it's not, attempts to typedef unsigned long ulong. Obviously, if we've previously #define'd ulong to mean unsigned long -- say in php_config.h -- this doesn't work out so well. The quick and dirty fix would be to #define HAVE_ULONG 1 just before including my_global.h, but I suspect Andrey (or someone else who works on the various MySQL extensions) will likely have a better idea on this. [2010-07-23 13:25:48] ahar...@php.net r300436 looks like the culprit. 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=52413 -- Edit this bug report at http://bugs.php.net/bug.php?id=52413edit=1
[PHP-BUG] Bug #53096 [NEW]: imagecopyresized doesn't return TRUE or FALSE
From:
Operating system: Linux 2.6.35-ARCH
PHP version: 5.3.3
Package: GD related
Bug Type: Bug
Bug description:imagecopyresized doesn't return TRUE or FALSE
Description:
I'm getting about 650 pictures in bytes by soap and creating previews for
those
pictures. Script works perfectly on php 5.3.2-2 (Linux Debian testing), but
stops
unexpectedly on php 5.3.3 without any error.
I've found that script stops on function imagecopyresized. (pls, see test
script
example) - doesn't return anything.
Test script:
---
if(imagecopyresized($imageResized, $imageTmp, 0, 0, 0, 0, $newWidth,
$newHeight, $width, $height)){
echo imagecopyresized true;
}else{
echo imagecopyresized FALSE;
}
Expected result:
1. All pictures and previews stored. (1300 files for both).
2. function imagecopyresampled return something
Actual result:
--
1. Only about 880 files are stored.
2. function imagecopyresampled doesn't return anything
--
Edit bug report at http://bugs.php.net/bug.php?id=53096edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53096r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53096r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53096r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53096r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53096r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53096r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53096r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53096r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53096r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53096r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53096r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53096r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53096r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53096r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53096r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53096r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53096r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53096r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53096r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53096r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53096r=mysqlcfg
[PHP-BUG] Req #53097 [NEW]: Allow creating object without variable assignment and calling method inline
From:
Operating system:
PHP version: 5.3.3
Package: Scripting Engine problem
Bug Type: Feature/Change Request
Bug description:Allow creating object without variable assignment and calling
method inline
Description:
In other languages I can do things like this, but PHP5 barfs when I try to
do it:
print (new DateTime('now'))-format('Y-m-d H:i:s')
Instead I have to use a temporary variable:
$x = new DateTime('now');
print $x-format('Y-m-d H:i:s');
unset($x);
Test script:
---
php -r print (new DateTime('now'))-format('Y-m-d H:i:s')
Expected result:
The date+time stamp.
Actual result:
--
PHP Parse error: syntax error, unexpected T_OBJECT_OPERATOR in Command
line code on line 1
--
Edit bug report at http://bugs.php.net/bug.php?id=53097edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53097r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53097r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53097r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53097r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53097r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53097r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53097r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53097r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53097r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53097r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53097r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53097r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53097r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53097r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53097r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53097r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53097r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53097r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53097r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53097r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53097r=mysqlcfg
Req #53097 [Opn]: Allow creating object without variable assignment and calling method inline
Edit report at http://bugs.php.net/bug.php?id=53097edit=1
ID: 53097
Updated by: der...@php.net
Reported by:cmanley at xs4all dot nl
Summary:Allow creating object without variable assignment
and calling method inline
Status: Open
Type: Feature/Change Request
Package:Scripting Engine problem
PHP Version:5.3.3
Block user comment: N
New Comment:
As a workaround, you can do:
print date_create('now')-format('Y-m-d H:i:s'), \n;
Previous Comments:
[2010-10-18 14:59:35] cmanley at xs4all dot nl
Description:
In other languages I can do things like this, but PHP5 barfs when I try
to do it:
print (new DateTime('now'))-format('Y-m-d H:i:s')
Instead I have to use a temporary variable:
$x = new DateTime('now');
print $x-format('Y-m-d H:i:s');
unset($x);
Test script:
---
php -r print (new DateTime('now'))-format('Y-m-d H:i:s')
Expected result:
The date+time stamp.
Actual result:
--
PHP Parse error: syntax error, unexpected T_OBJECT_OPERATOR in Command
line code on line 1
--
Edit this bug report at http://bugs.php.net/bug.php?id=53097edit=1
[PHP-BUG] Bug #53098 [NEW]: stream_socket_client Memory Leak when using stream_context_create
From:
Operating system: Ubuntu
PHP version: 5.3SVN-2010-10-18 (snap)
Package: Sockets related
Bug Type: Bug
Bug description:stream_socket_client Memory Leak when using
stream_context_create
Description:
Using stream_socket_client on it's own works fine, but once using
stream_context_create with it it creates a memory leak of 2kb each time
which makes it unstable.
Test script:
---
?php
for ($i =0 ; $i 30 ; $i++)
{
$socket_options = array('socket' = array('bindto' = '127.0.0.1:0'));
$socket_context = stream_context_create($socket_options);
$fp=stream_socket_client('tcp://127.0.0.1:23', $error, $err, 5,
STREAM_CLIENT_ASYNC_CONNECT|STREAM_CLIENT_CONNECT, $socket_context);
unset($socket_context);
unset($socket_options);
unset ($fp);
unset ($error);
unset ($err);clea
echo memory_get_usage().\n;
}
?
Expected result:
648504
650400
650400
654000
650400
650400
650400
650400
650400
650400
650400
650400
650400
650400
650400
650400
650400
Actual result:
--
648504
650400
652200
654000
655864
657664
659464
661264
663064
664864
64
668464
670392
672192
673992
675792
677592
679392
681192
682992
684792
686592
688392
690192
691992
693792
695592
697392
699448
701248
--
Edit bug report at http://bugs.php.net/bug.php?id=53098edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53098r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53098r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53098r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53098r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53098r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53098r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53098r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53098r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53098r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53098r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53098r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53098r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53098r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53098r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53098r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53098r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53098r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53098r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53098r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53098r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53098r=mysqlcfg
[PHP-BUG] Bug #53099 [NEW]: ereg_replace uses 100% cpu and takes 10 minutes to execute.
From: Operating system: Ubuntu 9.10 PHP version: 5.3.3 Package: Regexps related Bug Type: Bug Bug description:ereg_replace uses 100% cpu and takes 10 minutes to execute. Description: I have written a mb_trim function in php which uses ereg_replace to trim strings in the same manner as trim() does. The function is available at http://php.net/manual/en/ref.mbstring.php Under the heading 'phpnet at rcpt dot at - 19-Aug-2010 02:46' Using the string excerpt from our production environment (http://pastebin.com/wmyjPmBV), ereg_replace appears to enter some sort of recursive loop, in my environment it takes 100% cpu for 20 minutes before finally returning the correct result. When the section which reads: array( \s,\t,\n,\r, \0, \x0B ) ...is changed to array( \s, \0, \x0B ) then ereg_replace returns promptly with the correct result. Test script: --- The function is available at http://php.net/manual/en/ref.mbstring.php Under the heading 'phpnet at rcpt dot at - 19-Aug-2010 02:46' It is also available here: http://pastebin.com/CCpaVXay The (serialized) string that causes the problem is: s:488:ISwans /I Wisely moving from the middle of July to the middle of autumn, this indoor, forward-thinking avant-rock weekend brings together all sorts of fiercely experimental noisemakers, from psychedelic-folk to death metal, with a hotly anticipated headline set from Michael Gira's New York noise inspiration Swans. Don't expect many stony-faced rock nerds, though. The organisers serve tea and cake throughout and they're promising other fun and games this year.; It is also available for download here: http://pastebin.com/wmyjPmBV You can execute the script with the following syntax: ?php mb_trim( $string ); Expected result: PHP will return the correct result quickly. Actual result: -- PHP will run at 100% CPU for 20 minutes. -- Edit bug report at http://bugs.php.net/bug.php?id=53099edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53099r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53099r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53099r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53099r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53099r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53099r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53099r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53099r=needscript Try newer version: http://bugs.php.net/fix.php?id=53099r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53099r=support Expected behavior: http://bugs.php.net/fix.php?id=53099r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53099r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53099r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53099r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53099r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53099r=dst IIS Stability: http://bugs.php.net/fix.php?id=53099r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53099r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53099r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53099r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53099r=mysqlcfg
Bug #44383 [Com]: PHP DateTime not converted to xsd:datetime
Edit report at http://bugs.php.net/bug.php?id=44383edit=1 ID: 44383 Comment by: aldekein at myevil dot info Reported by:kevin dot craft at gmail dot com Summary:PHP DateTime not converted to xsd:datetime Status: Open Type: Bug Package:SOAP related Operating System: * PHP Version:5.*, 6 (2009-08-07 Block user comment: N New Comment: It still does not work after 2.5 years in PHP 5.3.1 on Windows. Maybe this patch should be applied to official PHP branch? Previous Comments: [2009-08-07 15:23:57] david dot zuelke at bitextender dot com Updated patch and tests: http://pastie.org/575559 [2009-06-29 08:56:29] lsm...@php.net Reopening since we now have a patch. [2009-06-29 08:28:26] david dot zuelke at bitextender dot com We've created a patch to implement this. Description (with patch and tests for download): http://article.gmane.org/gmane.comp.php.devel/57369 Patch (in case gmane doesn't work): http://pastie.org/527755 Tests (in case gmane doesn't work): http://pastie.org/527762 [2008-06-30 12:00:56] r dot janssen at keensystems dot eu I am, too, looking for a solution for this problem. I can specify parameters as dateTime type but when generating the WSDL the generation stops and does nothing. [2008-05-13 04:40:11] barth at pbx-network dot de Anyone has a soluiton or workaround for this issue? How can a date/time been passed over to a webservice endpoint? 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=44383 -- Edit this bug report at http://bugs.php.net/bug.php?id=44383edit=1
Bug #53018 [Fbk-Opn]: file_get_contents does not follow 301 and 302 redirects with curlwrappers
Edit report at http://bugs.php.net/bug.php?id=53018edit=1 ID: 53018 User updated by:techs at remsys dot com Reported by:techs at remsys dot com -Summary:file_get_contents does not follow 301 and 302 redirects +Summary:file_get_contents does not follow 301 and 302 redirects with curlwrappers -Status: Feedback +Status: Open Type: Bug Package:Apache2 related Operating System: Linux x86_64 CentOS release 5.5 PHP Version:5.2.14 Block user comment: N New Comment: As a workaround we have recompiled php without --with-curlwrappers option and file_get_contents started to work as it should. We have latest curl on that server curl-7.15.5-9.el5 here is version info: curl 7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 Previous Comments: [2010-10-08 20:27:31] techs at remsys dot com Thank you for reply. Well same situation with max_redirects. It works only for cli. It seems SAPI ignore it and set to zero or 1. And yes both versions are comiled with curlwrappers. You can see phpinfo() here isonet.ru/test/pi.php I would really appreciate any other thoughts or suggestions. Thank you. [2010-10-08 05:07:37] ahar...@php.net The redirections are followed for me both in the CLI and Apache SAPIs; I can't see any obvious reason why one would be different to the other. Immediate thoughts: - Does your Apache script set any context options at any point? There is a HTTP context option called max_redirects which controls this behaviour -- if it's set to 0, then redirects aren't followed. - Did either (or both) builds have --with-curlwrappers enabled at build time? You can check that in the Configure Command line in phpinfo(). [2010-10-07 22:43:32] techs at remsys dot com Description: Function file_get_contents() does not follow 301 and 302 redirects sub apache module. It returns following: --8 --- HTMLHEADmeta http-equiv=content-type content=text/html;charset=utf-8 TITLE301 Moved/TITLE/HEADBODY H1301 Moved/H1 The document has moved A HREF=http://www.google.com/;here/A. /BODY/HTML --8 --- We got this situation on a 20 servers and even on php-5.2.13, but in the same time it works on others servers with same configuration. Mystery starts when we run this script from command line. It works fine with cli, wich is compiled with same options and use same php.ini. Test script: --- ?php echo file_get_contents(http://google.com;); Expected result: file_get_contents should follow redirects. Actual result: -- Now it doesn't in some cases. -- Edit this bug report at http://bugs.php.net/bug.php?id=53018edit=1
Bug #52404 [Asn]: All TTF Files are invalid [ALL PHP.NET]
Edit report at http://bugs.php.net/bug.php?id=52404edit=1 ID: 52404 Updated by: h...@php.net Reported by:h...@php.net Summary:All TTF Files are invalid [ALL PHP.NET] Status: Assigned Type: Bug Package:*General Issues PHP Version:Irrelevant Assigned To:rasmus Block user comment: N New Comment: I would if I could. I don't think I have commit access to all of the ttf files on the php.net svn. Previous Comments: [2010-07-27 01:54:48] ras...@php.net You may just have to re-import them into Subversion or something. All I did was flip the svn property so Subversion wouldn't mangle them. [2010-07-27 01:02:53] ka...@php.net Confirmed on Windows XP aswell (unreadable font files in the font viewer) Rasmus: You did this change, should it be reverted or do you have any easy fix on your mind? [2010-07-22 15:13:56] h...@php.net Description: All of the TTF files that are on PHP.net appear to be invalid/corrupt. A change that happened 12 months ago with the description of Fix TTF files appears to be where the problem lies. http://svn.php.net/viewvc?view=revisionrevision=284292 To fix this, this revision should be reverted to all files. On Windows, when you try to open any of these files it will say The requested file *.ttf was not a valid font file. Here at PHP, we get a different message when using the imagettfbbox() function... Could not read font. In the example below I am using the arial.ttf file which can be downloaded here: http://svn.php.net/viewvc/web/php/trunk/bin/arial.ttf?view=co Test script: --- ?php $font = 'fonts/arial.ttf'; $read = file_exists($font)?'Yes':'No'; echo \nbrDoes font '$font' exist? .$read; $read = is_readable($font)?'Yes':'No'; echo \nbrIs font '$font' readable? .$read; $test = @imagettfbbox(1, 1, $font, 1)?'Yes':'No'; echo \nbrIs font '$font' valid? .$test; echo \nbrWhat PHP version? .phpversion(); ? Expected result: Does font 'fonts/arial.ttf' exist? Yes Is font 'fonts/arial.ttf' readable? Yes Is font 'fonts/arial.ttf' valid? Yes What PHP version? 5.2.13 Actual result: -- Does font 'fonts/arial.ttf' exist? Yes Is font 'fonts/arial.ttf' readable? Yes Is font 'fonts/arial.ttf' valid? No What PHP version? 5.2.13 -- Edit this bug report at http://bugs.php.net/bug.php?id=52404edit=1
Bug #52403 [Opn]: imagettfbbox/imagettftext Could not read font error
Edit report at http://bugs.php.net/bug.php?id=52403edit=1 ID: 52403 Updated by: h...@php.net Reported by:h...@php.net Summary:imagettfbbox/imagettftext Could not read font error Status: Open Type: Bug Package:GD related Operating System: CentOS4 PHP Version:5.2.13 Block user comment: Y New Comment: To put it very simply, it incorrectly says Could not read font, when it should say Invalid font file. Could somebody fix this or do you need me to supply a patch? Previous Comments: [2010-07-27 14:56:55] h...@php.net To clarify: Expected result: Warning: imagettfbbox() [function.imagettfbbox]: Invalid font file in /home/share/www/dev/test/php/imagettfbbox.php on line 4 What PHP version? 5.2.13 Does font 'Vera.ttf' exist? Yes Is font 'Vera.ttf' readable? Yes Actual result: -- Warning: imagettfbbox() [function.imagettfbbox]: Could not read font in /home/share/www/dev/test/php/imagettfbbox.php on line 4 What PHP version? 5.2.13 Does font 'Vera.ttf' exist? Yes Is font 'Vera.ttf' readable? Yes [2010-07-27 10:57:18] h...@php.net Excuse me, but this is -NOT- the same bug. Just because it's simply related does not make it the same. The problem here is the error, not the TTF files, which is the problem described in the other bug report. Please check and try again. [2010-07-27 01:04:09] ka...@php.net Same issue as in bug #52404 [2010-07-22 14:24:49] h...@php.net Description: Using the Vera.ttf font, which is part of the Image_Text PEAR package results in an odd error... The font can be found here: http://svn.php.net/viewvc/pear/packages/Image_Text/trunk/tests/Vera.ttf?view=log The error given by imagettfbbox() is Could not read font. When tested with is_readable(), the font is indeed readable. When opening the Vera.ttf font file in windows, it produces the following error: The requested file Vera.ttf was not a valid font file. It would appear that the file may well be corrupt, not that it could not read. This error lead to a very confusing situation... I propose that the error should be more descriptive. Instead of Could not read font, consider Invalid font file. Test script: --- ?php $font = 'Vera.ttf'; $test = imagettfbbox(10, 10, $font, 'test'); echo \nbrWhat PHP version? .phpversion(); $read = file_exists($font)?'Yes':'No'; echo \nbrDoes font '$font' exist? .$read; $read = is_readable($font)?'Yes':'No'; echo \nbrIs font '$font' readable? .$read; ? Expected result: Warning: imagettfbbox() [function.imagettfbbox]: Could not read font in /home/share/www/dev/test/php/imagettfbbox.php on line 4 Actual result: -- Warning: imagettfbbox() [function.imagettfbbox]: Could not read font in /home/share/www/dev/test/php/imagettfbbox.php on line 4 What PHP version? 5.2.13 Does font 'Vera.ttf' exist? Yes Is font 'Vera.ttf' readable? Yes -- Edit this bug report at http://bugs.php.net/bug.php?id=52403edit=1
Req #53094 [Opn-Bgs]: Use '0' instead of '' as a result of converting boolean FALSE to string
Edit report at http://bugs.php.net/bug.php?id=53094edit=1
ID: 53094
Updated by: ras...@php.net
Reported by:php-bugs at majkl578 dot cz
Summary:Use '0' instead of '' as a result of converting
boolean FALSE to string
-Status: Open
+Status: Bogus
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: Irrelevant
PHP Version:Irrelevant
Block user comment: N
New Comment:
This would be extremely counterintuitive to most people since every
language I
know will return a zero-length string when boolean false is converted to
a string.
Having it return a non-zero length string would cause all sorts of
backward
compatibility problems as well.
Previous Comments:
[2010-10-18 10:30:42] php-bugs at majkl578 dot cz
Description:
I'd like to propose a change in converting booleans to string.
It'd be better if (string) FALSE returns '0' instead of empty string
('').
Why to do so?
a) More logical behavior.
b) Using booleans in output would be meaningful.
c) Backward-compatible change - as documentation says: This allows
conversion back and forth between boolean and string values. - this
behavior is not changed by this, because (bool) '0' is FALSE.
Test script:
---
?php
echo (string) FALSE; //nothing now, '0' requested
var_dump((bool) '0'); //FALSE, no change
var_dump((string) FALSE === '0'); //FALSE, TRUE requested
--
Edit this bug report at http://bugs.php.net/bug.php?id=53094edit=1
Bug #52403 [Opn-Bgs]: imagettfbbox/imagettftext Could not read font error
Edit report at http://bugs.php.net/bug.php?id=52403edit=1 ID: 52403 Updated by: paj...@php.net Reported by:h...@php.net Summary:imagettfbbox/imagettftext Could not read font error -Status: Open +Status: Bogus Type: Bug Package:GD related Operating System: CentOS4 PHP Version:5.2.13 -Block user comment: Y +Block user comment: N New Comment: The message is correct. As some fonts are supported by some freetype versions. It does not mean that the font file is invalid, but that ft (gd) could not read it. Previous Comments: [2010-10-18 18:32:39] h...@php.net To put it very simply, it incorrectly says Could not read font, when it should say Invalid font file. Could somebody fix this or do you need me to supply a patch? [2010-07-27 14:56:55] h...@php.net To clarify: Expected result: Warning: imagettfbbox() [function.imagettfbbox]: Invalid font file in /home/share/www/dev/test/php/imagettfbbox.php on line 4 What PHP version? 5.2.13 Does font 'Vera.ttf' exist? Yes Is font 'Vera.ttf' readable? Yes Actual result: -- Warning: imagettfbbox() [function.imagettfbbox]: Could not read font in /home/share/www/dev/test/php/imagettfbbox.php on line 4 What PHP version? 5.2.13 Does font 'Vera.ttf' exist? Yes Is font 'Vera.ttf' readable? Yes [2010-07-27 10:57:18] h...@php.net Excuse me, but this is -NOT- the same bug. Just because it's simply related does not make it the same. The problem here is the error, not the TTF files, which is the problem described in the other bug report. Please check and try again. [2010-07-27 01:04:09] ka...@php.net Same issue as in bug #52404 [2010-07-22 14:24:49] h...@php.net Description: Using the Vera.ttf font, which is part of the Image_Text PEAR package results in an odd error... The font can be found here: http://svn.php.net/viewvc/pear/packages/Image_Text/trunk/tests/Vera.ttf?view=log The error given by imagettfbbox() is Could not read font. When tested with is_readable(), the font is indeed readable. When opening the Vera.ttf font file in windows, it produces the following error: The requested file Vera.ttf was not a valid font file. It would appear that the file may well be corrupt, not that it could not read. This error lead to a very confusing situation... I propose that the error should be more descriptive. Instead of Could not read font, consider Invalid font file. Test script: --- ?php $font = 'Vera.ttf'; $test = imagettfbbox(10, 10, $font, 'test'); echo \nbrWhat PHP version? .phpversion(); $read = file_exists($font)?'Yes':'No'; echo \nbrDoes font '$font' exist? .$read; $read = is_readable($font)?'Yes':'No'; echo \nbrIs font '$font' readable? .$read; ? Expected result: Warning: imagettfbbox() [function.imagettfbbox]: Could not read font in /home/share/www/dev/test/php/imagettfbbox.php on line 4 Actual result: -- Warning: imagettfbbox() [function.imagettfbbox]: Could not read font in /home/share/www/dev/test/php/imagettfbbox.php on line 4 What PHP version? 5.2.13 Does font 'Vera.ttf' exist? Yes Is font 'Vera.ttf' readable? Yes -- Edit this bug report at http://bugs.php.net/bug.php?id=52403edit=1
Req #50244 [Com]: getopt() does not reset
Edit report at http://bugs.php.net/bug.php?id=50244edit=1 ID: 50244 Comment by: alexc223 at googlemail dot com Reported by:craig dot marvelley at boxuk dot com Summary:getopt() does not reset Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: Windows XP PHP Version:5.3.1 Block user comment: N New Comment: I can also confirm this on PHP 5.3.3 Previous Comments: [2009-11-20 14:37:31] craig dot marvelley at boxuk dot com Description: A bug that has been reported and fixed in the past regarding getopt not resetting after being called once has resurfaced. Here's the original bug: http://bonsai.php.net/bug.php?id=29714 The same behaviour is happening in 5.3.1 - once getopt has been called, subsequent calls ignore options not included in the original call. Reproduce code: --- php test.php -d hello -b world ?php $options = getopt(d:); print_r($options); $options = getopt(b:); print_r($options); Expected result: Array ( [d] = hello ) Array ( [b] = world ) Actual result: -- Array ( [d] = hello ) Array ( ) -- Edit this bug report at http://bugs.php.net/bug.php?id=50244edit=1
Bug #52987 [Com]: Losing amperstamp with xml_parse_into_struct function
Edit report at http://bugs.php.net/bug.php?id=52987edit=1
ID: 52987
Comment by: andre dot boily at mcccf dot gouv dot qc dot ca
Reported by:andre dot boily at mcccf dot gouv dot qc dot ca
Summary:Losing amperstamp with xml_parse_into_struct
function
Status: Feedback
Type: Bug
Package:XML related
Operating System: Linux - SUSE
PHP Version:5.2.14
Block user comment: N
New Comment:
I saw in the snapshot you've send me, the BUG is corrected in version
2.5.15.
- Fixed bug #45996 (libxml2 2.7 causes breakage with character data in
xml_parse()). (Rob)
Thanx!
Previous Comments:
[2010-10-07 04:13:02] ahar...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Works as expected for me on a current 5.2 build: the relevant bit of
output is:
[3]=
array(4) {
[tag]=
string(3) URL
[type]=
string(8) complete
[level]=
int(3)
[value]=
string(37) http://www.test.com?param1=1param2=2;
}
Note the decoded ampersand in the value.
[2010-10-04 22:05:58] andre dot boily at mcccf dot gouv dot qc dot ca
Description:
Running version: 5.2.14
After a lot of tests and reading, I experimenting a problem since we've
upgraded the PHP version from 5.2.6 to 5.2.14
The problem is when i'm trying to put a xml string in a array, i'm
loosing the amperstamp ()characters in the output of
xml_parse_into_struct function.
Maybe it's a new features that I can't understand, but it look like a
Bug.
Note: The Bug is in the URL tag in my XML structure.
Test script:
---
?php
$xmlValues = array();
$xmlIndex = array();
$parser = xml_parser_create();
// Case management option
xml_parser_set_option(
$parser,
XML_OPTION_CASE_FOLDING,
1
);
// White space management option
xml_parser_set_option(
$parser,
XML_OPTION_SKIP_WHITE,
0
);
xml_parser_set_option(
$parser,
XML_OPTION_TARGET_ENCODING,
UTF-8
);
$data = ?xml version='1.0'
encoding='utf-8'?COLLECTIONDOCUMENTTITRESome
Title/TITREURLhttp://www.test.com?param1=1amp;param2=2/URLDATE1285352820/DATE/DOCUMENT/COLLECTION;
xml_parse_into_struct(
$parser,
$data,
$xmlValues,
$xmlIndex
);
var_dump($xmlValues);
?
Expected result:
array(6) { [0]= array(3) { [tag]= string(10) COLLECTION
[type]= string(4) open [level]= int(1) } [1]= array(3) {
[tag]= string(8) DOCUMENT [type]= string(4) open [level]=
int(2) } [2]= array(4) { [tag]= string(5) TITRE [type]=
string(8) complete [level]= int(3) [value]= string(10) Some
Title } [3]= array(4) { [tag]= string(3) URL [type]=
string(8) complete [level]= int(3) [value]= string(36)
http://www.test.com?param1=1amp;param2=2; } [4]= array(3) {
[tag]= string(8) DOCUMENT [type]= string(5) close
[level]= int(2) } [5]= array(3) { [tag]= string(10)
COLLECTION [type]= string(5) close [level]= int(1) } }
Actual result:
--
array(6) { [0]= array(3) { [tag]= string(10) COLLECTION
[type]= string(4) open [level]= int(1) } [1]= array(3) {
[tag]= string(8) DOCUMENT [type]= string(4) open [level]=
int(2) } [2]= array(4) { [tag]= string(5) TITRE [type]=
string(8) complete [level]= int(3) [value]= string(10) Some
Title } [3]= array(4) { [tag]= string(3) URL [type]=
string(8) complete [level]= int(3) [value]= string(36)
http://www.test.com?param1=1param2=2; } [4]= array(3) { [tag]=
string(8) DOCUMENT [type]= string(5) close [level]= int(2) }
[5]= array(3) { [tag]= string(10) COLLECTION [type]=
string(5) close [level]= int(1) } }
--
Edit this bug report at http://bugs.php.net/bug.php?id=52987edit=1
[PHP-BUG] Req #53100 [NEW]: Add function to list available vars
From:
Operating system:
PHP version: 5.3.3
Package: Semaphore related
Bug Type: Feature/Change Request
Bug description:Add function to list available vars
Description:
It's not possible to get a list of available vars.
Test script:
---
shm_put_var($shm, 123, 'one');
ahm_put_var($shm, 456, 'two');
var_dump(shm_list_vars($shm));
Expected result:
array(2) {
[0]=
int(123)
[1]=
int(456)
}
*or*
array(2) {
[123]=
string(3)one
[456]=
string(3)two
}
Actual result:
--
PHP Fatal error: Call to undefined function shm_list_vars() in ...
--
Edit bug report at http://bugs.php.net/bug.php?id=53100edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53100r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53100r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53100r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53100r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53100r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53100r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53100r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53100r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53100r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53100r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53100r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53100r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53100r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53100r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53100r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53100r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53100r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53100r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53100r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53100r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53100r=mysqlcfg
Bug #52403 [Bgs]: imagettfbbox/imagettftext Could not read font error
Edit report at http://bugs.php.net/bug.php?id=52403edit=1 ID: 52403 Updated by: h...@php.net Reported by:h...@php.net Summary:imagettfbbox/imagettftext Could not read font error Status: Bogus Type: Bug Package:GD related Operating System: CentOS4 PHP Version:5.2.13 Block user comment: N New Comment: No, the message is ambiguous. Consider this... If GD is able to read the file, it is readable. If GD is unable to read the file, it is unreadable. We know the file is readable, that is not the problem. If GD is able to validate the file, it is valid. If GD is unable to validate the file, it is invalid. We do not know whether the file is valid or not. Alternatively, If GD is able to support the file, it is supported. If GD is unable to support the file, it is unsupported. We do not know whether the file is supported or not. To use read is too ambiguous in this context. Previous Comments: [2010-10-18 20:29:04] paj...@php.net The message is correct. As some fonts are supported by some freetype versions. It does not mean that the font file is invalid, but that ft (gd) could not read it. [2010-10-18 18:32:39] h...@php.net To put it very simply, it incorrectly says Could not read font, when it should say Invalid font file. Could somebody fix this or do you need me to supply a patch? [2010-07-27 14:56:55] h...@php.net To clarify: Expected result: Warning: imagettfbbox() [function.imagettfbbox]: Invalid font file in /home/share/www/dev/test/php/imagettfbbox.php on line 4 What PHP version? 5.2.13 Does font 'Vera.ttf' exist? Yes Is font 'Vera.ttf' readable? Yes Actual result: -- Warning: imagettfbbox() [function.imagettfbbox]: Could not read font in /home/share/www/dev/test/php/imagettfbbox.php on line 4 What PHP version? 5.2.13 Does font 'Vera.ttf' exist? Yes Is font 'Vera.ttf' readable? Yes [2010-07-27 10:57:18] h...@php.net Excuse me, but this is -NOT- the same bug. Just because it's simply related does not make it the same. The problem here is the error, not the TTF files, which is the problem described in the other bug report. Please check and try again. [2010-07-27 01:04:09] ka...@php.net Same issue as in bug #52404 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=52403 -- Edit this bug report at http://bugs.php.net/bug.php?id=52403edit=1
Bug #52403 [Bgs-Opn]: imagettfbbox/imagettftext Could not read font error
Edit report at http://bugs.php.net/bug.php?id=52403edit=1 ID: 52403 Updated by: h...@php.net Reported by:h...@php.net Summary:imagettfbbox/imagettftext Could not read font error -Status: Bogus +Status: Open Type: Bug Package:GD related Operating System: CentOS4 PHP Version:5.2.13 Block user comment: N Previous Comments: [2010-10-18 22:20:55] h...@php.net No, the message is ambiguous. Consider this... If GD is able to read the file, it is readable. If GD is unable to read the file, it is unreadable. We know the file is readable, that is not the problem. If GD is able to validate the file, it is valid. If GD is unable to validate the file, it is invalid. We do not know whether the file is valid or not. Alternatively, If GD is able to support the file, it is supported. If GD is unable to support the file, it is unsupported. We do not know whether the file is supported or not. To use read is too ambiguous in this context. [2010-10-18 20:29:04] paj...@php.net The message is correct. As some fonts are supported by some freetype versions. It does not mean that the font file is invalid, but that ft (gd) could not read it. [2010-10-18 18:32:39] h...@php.net To put it very simply, it incorrectly says Could not read font, when it should say Invalid font file. Could somebody fix this or do you need me to supply a patch? [2010-07-27 14:56:55] h...@php.net To clarify: Expected result: Warning: imagettfbbox() [function.imagettfbbox]: Invalid font file in /home/share/www/dev/test/php/imagettfbbox.php on line 4 What PHP version? 5.2.13 Does font 'Vera.ttf' exist? Yes Is font 'Vera.ttf' readable? Yes Actual result: -- Warning: imagettfbbox() [function.imagettfbbox]: Could not read font in /home/share/www/dev/test/php/imagettfbbox.php on line 4 What PHP version? 5.2.13 Does font 'Vera.ttf' exist? Yes Is font 'Vera.ttf' readable? Yes [2010-07-27 10:57:18] h...@php.net Excuse me, but this is -NOT- the same bug. Just because it's simply related does not make it the same. The problem here is the error, not the TTF files, which is the problem described in the other bug report. Please check and try again. 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=52403 -- Edit this bug report at http://bugs.php.net/bug.php?id=52403edit=1
Bug #53099 [Opn]: ereg_replace uses 100% cpu and takes 10 minutes to execute.
Edit report at http://bugs.php.net/bug.php?id=53099edit=1 ID: 53099 Updated by: fel...@php.net Reported by:phpnet at rcpt dot at Summary:ereg_replace uses 100% cpu and takes 10 minutes to execute. Status: Open Type: Bug -Package:Regexps related +Package:mbstring related Operating System: Ubuntu 9.10 PHP Version:5.3.3 Block user comment: N New Comment: s/ereg_replace/mb_ereg_replace/g :) Previous Comments: [2010-10-18 17:28:09] phpnet at rcpt dot at Description: I have written a mb_trim function in php which uses ereg_replace to trim strings in the same manner as trim() does. The function is available at http://php.net/manual/en/ref.mbstring.php Under the heading 'phpnet at rcpt dot at - 19-Aug-2010 02:46' Using the string excerpt from our production environment (http://pastebin.com/wmyjPmBV), ereg_replace appears to enter some sort of recursive loop, in my environment it takes 100% cpu for 20 minutes before finally returning the correct result. When the section which reads: array( \s,\t,\n,\r, \0, \x0B ) ...is changed to array( \s, \0, \x0B ) then ereg_replace returns promptly with the correct result. Test script: --- The function is available at http://php.net/manual/en/ref.mbstring.php Under the heading 'phpnet at rcpt dot at - 19-Aug-2010 02:46' It is also available here: http://pastebin.com/CCpaVXay The (serialized) string that causes the problem is: s:488:ISwans /I Wisely moving from the middle of July to the middle of autumn, this indoor, forward-thinking avant-rock weekend brings together all sorts of fiercely experimental noisemakers, from psychedelic-folk to death metal, with a hotly anticipated headline set from Michael Gira's New York noise inspiration Swans. Don't expect many stony-faced rock nerds, though. The organisers serve tea and cake throughout and they're promising other fun and games this year.; It is also available for download here: http://pastebin.com/wmyjPmBV You can execute the script with the following syntax: ?php mb_trim( $string ); Expected result: PHP will return the correct result quickly. Actual result: -- PHP will run at 100% CPU for 20 minutes. -- Edit this bug report at http://bugs.php.net/bug.php?id=53099edit=1
Bug #53098 [Opn-Bgs]: stream_socket_client Memory Leak when using stream_context_create
Edit report at http://bugs.php.net/bug.php?id=53098edit=1
ID: 53098
Updated by: fel...@php.net
Reported by:jayson dot cooke at ipeakmedia dot co dot uk
Summary:stream_socket_client Memory Leak when using
stream_context_create
-Status: Open
+Status: Bogus
Type: Bug
Package:Sockets related
Operating System: Ubuntu
PHP Version:5.3SVN-2010-10-18 (snap)
Block user comment: N
New Comment:
No mem leak detected in Valgrind.
btw, memory_get_usage(1) returns the same value.
Previous Comments:
[2010-10-18 17:15:21] jayson dot cooke at ipeakmedia dot co dot uk
Description:
Using stream_socket_client on it's own works fine, but once using
stream_context_create with it it creates a memory leak of 2kb each time
which makes it unstable.
Test script:
---
?php
for ($i =0 ; $i 30 ; $i++)
{
$socket_options = array('socket' = array('bindto' =
'127.0.0.1:0'));
$socket_context = stream_context_create($socket_options);
$fp=stream_socket_client('tcp://127.0.0.1:23', $error, $err, 5,
STREAM_CLIENT_ASYNC_CONNECT|STREAM_CLIENT_CONNECT, $socket_context);
unset($socket_context);
unset($socket_options);
unset ($fp);
unset ($error);
unset ($err);clea
echo memory_get_usage().\n;
}
?
Expected result:
648504
650400
650400
654000
650400
650400
650400
650400
650400
650400
650400
650400
650400
650400
650400
650400
650400
Actual result:
--
648504
650400
652200
654000
655864
657664
659464
661264
663064
664864
64
668464
670392
672192
673992
675792
677592
679392
681192
682992
684792
686592
688392
690192
691992
693792
695592
697392
699448
701248
--
Edit this bug report at http://bugs.php.net/bug.php?id=53098edit=1
Bug #45150 [Com]: MySQL functions cannot be used with 5.3.x on Vista when using localhost
Edit report at http://bugs.php.net/bug.php?id=45150edit=1 ID: 45150 Comment by: iswald at yahoo dot com Reported by:conor dot kerr_php at dev dot ceon dot net Summary:MySQL functions cannot be used with 5.3.x on Vista when using localhost Status: Bogus Type: Bug Package:MySQL related Operating System: Windows Vista PHP Version:5.3CVS-2008-07-23 (snap) Block user comment: N New Comment: Same problem, 127.0.0.1 works, but localhost times out in MySQL, though not SQL Server. Went to add 127.0.0.1 localhost to the hosts file, however, it was already there. Not Fixed. Needs better documentation at least, even if it is a MS problem. (PHP 5.3.3.0, MySQL 5.1.51, Windows Vista SP 2, no Apache) Previous Comments: [2010-09-11 16:32:18] zarlean at yahoo dot com I got this to work in Windows 7 (Apache 2.2, PHP 5.3.3, MySQL 5.1.44) by adding the line 127.0.0.1 localhost to the hosts file in C:/Windows/System32/drivers/etc/ [2010-09-06 11:18:20] u...@php.net Bogus AKA duplicate http://bugs.php.net/bug.php?id=48082 [2010-09-06 08:51:40] songchongzhan at gmail dot com Did you disable networking on windows. I use MySQL Query Browser connect to MySQL, it has MySQL Error Number 2003. Use mysqli connect to MySQL, it return like what you post:[2002]. And I use named pipe connect to MySQL by MySQL Query Browser, it is OK, by php 5.3.x does not support it util now. Try to open MySQL network connection. [2010-07-06 19:10:38] and...@php.net PLEASE READ THIS : http://blogs.iis.net/donraman/archive/2010/06/11/php-5-3-and-mysql-connectivity-problem.aspx [2010-05-11 08:30:30] kiewic at gmail dot com Same problem with Windows Vista Ultimate SP2. Why isn't this a bug? 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=45150 -- Edit this bug report at http://bugs.php.net/bug.php?id=45150edit=1
[PHP-BUG] Bug #53101 [NEW]: Date change
From: Operating system: Windows PHP version: 5.2.14 Package: *General Issues Bug Type: Bug Bug description:Date change Description: ?php echo date(H); ? Test script: --- In this is script, if you run with date octuber 16th, it put the actual hour. But if your put with date octuber 17th the result is the actual hour + 1. Can you check it(or confirm), because I had problem with this in my server. The hour in my server is an important parameter. Regards. -- Edit bug report at http://bugs.php.net/bug.php?id=53101edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53101r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53101r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53101r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53101r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53101r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53101r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53101r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53101r=needscript Try newer version: http://bugs.php.net/fix.php?id=53101r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53101r=support Expected behavior: http://bugs.php.net/fix.php?id=53101r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53101r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53101r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53101r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53101r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53101r=dst IIS Stability: http://bugs.php.net/fix.php?id=53101r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53101r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53101r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53101r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53101r=mysqlcfg
Doc-Bug #52003 [Opn]: Incorrect PDOStatement::execute() signature
Edit report at http://bugs.php.net/bug.php?id=52003edit=1
ID: 52003
Updated by: ka...@php.net
Reported by:v1d4l0k4 at gmail dot com
Summary:Incorrect PDOStatement::execute() signature
Status: Open
-Type: Documentation Problem
+Type: Bug
-Package:Documentation problem
+Package:PDO related
Operating System: Irrelevant
PHP Version:Irrelevant
-Assigned To:
+Assigned To:pierrick
Block user comment: N
New Comment:
Pierrick, why don't you commit that patch the src? And add a changelog
entry if reasonable for PDOStatement::execute() :)
Previous Comments:
[2010-06-06 06:13:42] pierr...@php.net
The following patch has been added/updated:
Patch Name: ZEND_ARG_ARRAY_INFO
Revision: 1275797622
URL:
http://bugs.php.net/patch-display.php?bug=52003patch=ZEND_ARG_ARRAY_INFOrevision=1275797622
[2010-06-05 22:53:10] v1d4l0k4 at gmail dot com
Description:
Manual says PDOStatement::execute() signature is:
bool PDOStatement::execute ([ array $input_parameters = array() ] )
But in fact it is:
bool PDOStatement::execute ([ $input_parameters = null ] )
Test script:
---
?php
class DBStatement extends PDOStatement
{
public function execute(array $input_parameters = array())
{
return parent::execute($input_parameters);
}
}
$PDO = new PDO('mysql:host=127.0.0.1', 'root', '');
$PDO-setAttribute(PDO::ATTR_STATEMENT_CLASS, array('DBStatement'));
Expected result:
No errors
Actual result:
--
Strict Standards: Declaration of DBStatement::execute() should be
compatible with that of PDOStatement::execute() in
/media/ext/Web/htdocs/test/bug.php on line 9
--
Edit this bug report at http://bugs.php.net/bug.php?id=52003edit=1
Bug #28319 [Com]: Query string parsing not respecting semicolon as a delimiter
Edit report at http://bugs.php.net/bug.php?id=28319edit=1 ID: 28319 Comment by: kaldari at gmail dot com Reported by:nick at careercast dot com Summary:Query string parsing not respecting semicolon as a delimiter Status: Bogus Type: Bug Package:CGI related Operating System: Linux PHP Version:4.3.4 Block user comment: N New Comment: Why is this bug marked as Bogus? Previous Comments: [2004-05-07 19:54:55] w...@php.net http://www.php.net/manual/en/configuration.directives.php#ini.arg-separator.input [2004-05-07 19:51:09] nick at careercast dot com Description: W3C spec indicates that valid separators for name value pairs are and ;. http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.2 We recommend that HTTP server implementors, and in particular, CGI implementors support the use of ; in place of to save authors the trouble of escaping characters in this manner. This becomes an issue when you are dealing with xml/xsl/xhtml, because you can no longer use: http://host/script.php?var1=bobvar2=jim instead, you have to use: http://host/script.php?var1=bobamp;var2=jim PHP should follow the W3C recommendation and support ; as a delimiter for name/value pairs in URLs Reproduce code: --- xmp ?php print_r ($_GET); ? /xmp And then call this script with this query string: ?var1=bob;var2=jim Expected result: Array ( [var1] = bob [var2] = jim ) Actual result: -- Array ( [var1] = bob;var2=jim ) -- Edit this bug report at http://bugs.php.net/bug.php?id=28319edit=1
Bug #48669 [Com]: PHP now includes GOTO
Edit report at http://bugs.php.net/bug.php?id=48669edit=1 ID: 48669 Comment by: phpbugs at ordisante dot com Reported by:iwannalive at hotmail dot com Summary:PHP now includes GOTO Status: Bogus Type: Bug Package:Reproducible crash Operating System: All PHP Version:5.3.0RC4 Block user comment: N New Comment: Why would you need GOTO for bug handling? We have a wonderful Exception system. It can do everything you want. Previous Comments: [2010-10-08 20:30:31] thehazard at gmail dot com Seriously, goto is awesome and in some cases, very useful and can make the code a lot more clean. Are bad/unexperienced programmers use 'goto' to create some crazy ugly mess? I have no doubt about it, but that doesn't mean that the feature itself is the problem. The problem is the programmer's inexperience, and it is not the place of the language to teach the programmer better programming practices. Goto is great, for example, for cleanups. You put some cleanup code in the end of a function and in its body you check for several test cases where things could go wrong. If something goes wrong, you signal the error and jump directly to the cleanup with 'goto', instead of having to create a big mess of if's to test if an error has happened or not on each step, to then decide whether your function should continue executing or not. It is a primitive in pretty much any architecture (cmp, jmp/jz, etc) and used extensively in the linux kernel, for example. Anyone who complains about goto being 'dangerous' is either a blind fad follower or just believes that the language should master the programmer (and not the other way around). [2010-07-14 01:02:40] risto78 at gmail dot com sounds like a valid bug to me ;) [2010-05-07 14:41:11] anil at ozselgin dot com It makes php more buggy and suitable only for small programs. Is there anybody out there like readable code. [2009-08-04 18:47:50] and...@php.net goto hell; [2009-06-23 23:56:29] der...@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 . 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=48669 -- Edit this bug report at http://bugs.php.net/bug.php?id=48669edit=1
Bug #28319 [Com]: Query string parsing not respecting semicolon as a delimiter
Edit report at http://bugs.php.net/bug.php?id=28319edit=1 ID: 28319 Comment by: kaldari at gmail dot com Reported by:nick at careercast dot com Summary:Query string parsing not respecting semicolon as a delimiter Status: Bogus Type: Bug Package:CGI related Operating System: Linux PHP Version:4.3.4 Block user comment: N New Comment: Ah, I found it. It's because you can set the arg separator used by PHP with the arg_separator.input directive in your php.ini file. The URL above is broken, by the way, which is why this wasn't evident. Previous Comments: [2010-10-19 07:11:25] kaldari at gmail dot com Why is this bug marked as Bogus? [2004-05-07 19:54:55] w...@php.net http://www.php.net/manual/en/configuration.directives.php#ini.arg-separator.input [2004-05-07 19:51:09] nick at careercast dot com Description: W3C spec indicates that valid separators for name value pairs are and ;. http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.2 We recommend that HTTP server implementors, and in particular, CGI implementors support the use of ; in place of to save authors the trouble of escaping characters in this manner. This becomes an issue when you are dealing with xml/xsl/xhtml, because you can no longer use: http://host/script.php?var1=bobvar2=jim instead, you have to use: http://host/script.php?var1=bobamp;var2=jim PHP should follow the W3C recommendation and support ; as a delimiter for name/value pairs in URLs Reproduce code: --- xmp ?php print_r ($_GET); ? /xmp And then call this script with this query string: ?var1=bob;var2=jim Expected result: Array ( [var1] = bob [var2] = jim ) Actual result: -- Array ( [var1] = bob;var2=jim ) -- Edit this bug report at http://bugs.php.net/bug.php?id=28319edit=1
