Bug #62481 [Opn]: xdebug openssl_encrypt crash
Edit report at https://bugs.php.net/bug.php?id=62481&edit=1 ID: 62481 User updated by:bronze1man at gmail dot com Reported by:bronze1man at gmail dot com Summary:xdebug openssl_encrypt crash Status: Open Type: Bug Package:OpenSSL related Operating System: ubuntu 1204 -PHP Version:5.3.14 +PHP Version:5.3.10 Block user comment: N Private report: N New Comment: sorry,php version is 5.3.10 Previous Comments: [2012-07-04 15:08:58] a...@php.net You wrote 5.3.14 in the ticket, but 5.3.10 in the description ... what is correct? On 5.3.10-dotdeb it segfaults for me without xdebug too. With the 5.3.15-dev there are no issues with or without xdebug for me. Can you confirm that? [2012-07-04 13:53:04] bronze1man at gmail dot com Description: start xdebug openssl_encrypt an empty string ,then it will crash. php version: PHP 5.3.10-1ubuntu3.2 with Suhosin-Patch (cli) (built: Jun 13 2012 17:20:55) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans Test script: --- https://bugs.php.net/bug.php?id=62481&edit=1
Bug #62279 [Ana]: PHP-FPM chroot never-solved problems (extends #55322)
Edit report at https://bugs.php.net/bug.php?id=62279&edit=1 ID: 62279 Updated by: f...@php.net Reported by:nospam at bigalex dot it Summary:PHP-FPM chroot never-solved problems (extends #55322) Status: Analyzed Type: Bug Package:FPM related Operating System: Irrelevant PHP Version:Any Assigned To:fat Block user comment: N Private report: N New Comment: I used pseudo bash syntax but it'll be implemanted inside fpm (with C code) Previous Comments: [2012-07-04 16:48:00] nospam at bigalex dot it Thank your for your support but I'm sorry, I think I didn't understand your fix: does php-fpm chroot works starting it from bash, or how could it be implemented the way you said (from inside fpm I mean)? [2012-07-04 10:38:14] f...@php.net >From my point of view, I'd rather prefer to configure this on the web server side (if it's not possible with apache then switch to something else -- aka nginx for exemple. If apache does not suit well with fastcgi customizations, then ask apache guys :p) more seriously, I can understand the need. I'll try to look at this to dynamicaly adapt fastcgi variables from the chroot env. The following algorithm should work: for variable in all_fastcgi_variables; do if ($_SERVER[$var] =~ /^$chroot(.*)$/); then $_SERVER[$var] = $1; fi done or somehting more restrictive: for var in "DOCUMENT_ROOT" "SCRIPT_FILENAME" "PATH_TRANSLATED"]; do if ($_SERVER[$var] =~ /^$chroot(.*)$/); then $_SERVER[$var] = $1; fi end [2012-06-28 17:45:34] nospam at bigalex dot it In the meantime, I've already found a way to fix this behaviour: a proxy between PHP-FPM and Apache. I needed a caching proxy to be on top of Apache to cache php scripts (I don't care about static files because what really causes CPU and memory problems is having the php processes running), so I've thought to implement a fcgi proxy to be used among PHP-FPM and Apache. It does work and does a great job: I didn't need to implement anything about the HTTP protocol since there's already Apache caring about it; then, caching the results from PHP, I can avoid asking FPM to run the already cached pages, giving them away to Apache in an elegant manner. And, of course, the proxy does fix the wrong variables, removing the chrooted part and making the scripts able to work. I'm still trying to fix the sources, but since they appears complicated (read: messy), and there's no documentation about it or about debugging them, I don't think I will fix them before I have more time to spend or having a clue about reading the configuration values from fpm_main.c. Anyway, for anyone interested in it, the proxy has been made using python and flup server and client implementations. [2012-06-28 16:02:03] graham at wyenet dot net The symbolic trick does work (as long as the sym link is relative (ie ../../../chrootpath if you try to link directly from the root, then the symlink goes outside the jail and it will still fail). Anyway thats a very messy hack, and I agree with you, php-fpm creates the jails, so it should fix the PHP variables. Without the symlink, I just get file not found for all calls for scripts. If you change fix.cgi_pathinfo = 0 it will run the scripts, but the $_SERVER variables will still be wrong... Im sure most people would rather it was fixed so that the fix.cgi_pathinfo = 1 works, AND the variables are set correctly... But either way would be better than trying to hack in fixes with sym links, and/or preloading a fixup script. I did take a look at the fpm_main.c but also been unable to create my own patch for it at this time. Surely it cant be that hard to read the chroot path from the configuration file, and remove that from all appropriate server variables, or recreate the broken variables some other way. Symlink is good enough for a test environment, to see what other php functions break with the chroot, and to start building a system, but I wouldn't use that hack on a production web server. [2012-06-24 16:25:15] nospam at bigalex dot it I want to patch the sources, but can't find a way to get from the function init_request_info info fpm_main.c the chroot path. Since the documentation about it lacks, can anyone put me in the right direction? :P I think I need to get the configuration (or add a variable to the worker) about the current chroot location. A more safe way to handle it would be to get, from the father process, the child's chroot location and filter it b
Bug #62279 [Ana]: PHP-FPM chroot never-solved problems (extends #55322)
Edit report at https://bugs.php.net/bug.php?id=62279&edit=1 ID: 62279 User updated by:nospam at bigalex dot it Reported by:nospam at bigalex dot it Summary:PHP-FPM chroot never-solved problems (extends #55322) Status: Analyzed Type: Bug Package:FPM related Operating System: Irrelevant PHP Version:Any Assigned To:fat Block user comment: N Private report: N New Comment: Thank your for your support but I'm sorry, I think I didn't understand your fix: does php-fpm chroot works starting it from bash, or how could it be implemented the way you said (from inside fpm I mean)? Previous Comments: [2012-07-04 10:38:14] f...@php.net >From my point of view, I'd rather prefer to configure this on the web server side (if it's not possible with apache then switch to something else -- aka nginx for exemple. If apache does not suit well with fastcgi customizations, then ask apache guys :p) more seriously, I can understand the need. I'll try to look at this to dynamicaly adapt fastcgi variables from the chroot env. The following algorithm should work: for variable in all_fastcgi_variables; do if ($_SERVER[$var] =~ /^$chroot(.*)$/); then $_SERVER[$var] = $1; fi done or somehting more restrictive: for var in "DOCUMENT_ROOT" "SCRIPT_FILENAME" "PATH_TRANSLATED"]; do if ($_SERVER[$var] =~ /^$chroot(.*)$/); then $_SERVER[$var] = $1; fi end [2012-06-28 17:45:34] nospam at bigalex dot it In the meantime, I've already found a way to fix this behaviour: a proxy between PHP-FPM and Apache. I needed a caching proxy to be on top of Apache to cache php scripts (I don't care about static files because what really causes CPU and memory problems is having the php processes running), so I've thought to implement a fcgi proxy to be used among PHP-FPM and Apache. It does work and does a great job: I didn't need to implement anything about the HTTP protocol since there's already Apache caring about it; then, caching the results from PHP, I can avoid asking FPM to run the already cached pages, giving them away to Apache in an elegant manner. And, of course, the proxy does fix the wrong variables, removing the chrooted part and making the scripts able to work. I'm still trying to fix the sources, but since they appears complicated (read: messy), and there's no documentation about it or about debugging them, I don't think I will fix them before I have more time to spend or having a clue about reading the configuration values from fpm_main.c. Anyway, for anyone interested in it, the proxy has been made using python and flup server and client implementations. [2012-06-28 16:02:03] graham at wyenet dot net The symbolic trick does work (as long as the sym link is relative (ie ../../../chrootpath if you try to link directly from the root, then the symlink goes outside the jail and it will still fail). Anyway thats a very messy hack, and I agree with you, php-fpm creates the jails, so it should fix the PHP variables. Without the symlink, I just get file not found for all calls for scripts. If you change fix.cgi_pathinfo = 0 it will run the scripts, but the $_SERVER variables will still be wrong... Im sure most people would rather it was fixed so that the fix.cgi_pathinfo = 1 works, AND the variables are set correctly... But either way would be better than trying to hack in fixes with sym links, and/or preloading a fixup script. I did take a look at the fpm_main.c but also been unable to create my own patch for it at this time. Surely it cant be that hard to read the chroot path from the configuration file, and remove that from all appropriate server variables, or recreate the broken variables some other way. Symlink is good enough for a test environment, to see what other php functions break with the chroot, and to start building a system, but I wouldn't use that hack on a production web server. [2012-06-24 16:25:15] nospam at bigalex dot it I want to patch the sources, but can't find a way to get from the function init_request_info info fpm_main.c the chroot path. Since the documentation about it lacks, can anyone put me in the right direction? :P I think I need to get the configuration (or add a variable to the worker) about the current chroot location. A more safe way to handle it would be to get, from the father process, the child's chroot location and filter it before passing the variables to the child. Anyway, in both cases, there is lack of documentation and I've still been unable to patch anything, so suggestions would be really apprecia
Bug #61597 [Com]: SimpleXMLElement doesn't include both @attributes and textContent in properties
Edit report at https://bugs.php.net/bug.php?id=61597&edit=1
ID: 61597
Comment by: hugh at infomenta dot com
Reported by:drgroove at gmail dot com
Summary:SimpleXMLElement doesn't include both @attributes
and textContent in properties
Status: Open
Type: Bug
Package:SimpleXML related
Operating System: Mac OS X
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
I am having exactly the same problem and it is not feasible to add an extra tag
to all of my "text" entries.
Previous Comments:
[2012-04-13 01:59:42] ahar...@php.net
Ah, I see what you're getting at now. Thanks. It appears to be an issue with
the
get_properties and get_debug_info handlers for SimpleXMLElement.
This has been reported and closed as a duplicate before, but I think that was
mistaken, as we don't have an open bug for this at present that I can find.
[2012-04-12 19:51:23] jplyon dot csu at gmail dot com
another test:
$xml = <<<'EOX'
corn
EOX;
$doc = simplexml_load_string($xml);
echo $doc->asXML();
echo print_r($doc);
This is not a problem with loading for me - I am building my SimpleXML object
dynamically.
The output from asXML() is correct.
The output from print_r() is not.
The output using attributes() (in a more complex example) is not correct,
although this simple test does work.
I am experiencing this on various versions of PHP 5.3.X on Windows Vista and
Ubuntu 11.10.
(ubuntu)$ php -v
PHP 5.3.2-1ubuntu4.9 with Suhosin-Patch (cli) (built: May 3 2011 00:45:52)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Suhosin v0.9.29, Copyright (c) 2007, by SektionEins GmbH
(Windows)>php -v
PHP 5.3.8 (cli) (built: Sep 22 2011 20:51:51)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
[2012-04-02 06:41:26] ahar...@php.net
I can't reproduce this:
text content
EOX;
$doc = simplexml_load_string($xml);
printf("Text content: %s; attribute: %s\n", $doc->child, $doc->child['attr']);
?>
Outputs "Text content: text content; attribute: foo", as I'd expect. Are you
able to provide a reproduction script?
The SO discussion appears to be about JSON encoding only; given that
SimpleXMLElement doesn't support serialisation, I'd suggest that the same would
apply to JSON encoding.
[2012-04-02 03:37:26] drgroove at gmail dot com
Description:
When loading XML into SimpleXML, tags which have both attributes and text will
have their attributes dropped.
For example, loading this into SimpleXML:
Here is some text
Will cause 'attribute="value"' to be lost. If there is no text w/in a tag, but
attributes, the attributes and their values are preserved.
I'm not the only PHP developer to notice this bug; please see:
http://stackoverflow.com/questions/8563073/disappearing-attributes-in-php-simplexml-object
I didn't see this bug reported on php.net, however.
Test script:
---
See above.
Expected result:
Tags with both attributes and text should not have their attributes dropped.
--
Edit this bug report at https://bugs.php.net/bug.php?id=61597&edit=1
Bug #62481 [Com]: xdebug openssl_encrypt crash
Edit report at https://bugs.php.net/bug.php?id=62481&edit=1 ID: 62481 Comment by: a...@php.net Reported by:bronze1man at gmail dot com Summary:xdebug openssl_encrypt crash Status: Open Type: Bug Package:OpenSSL related Operating System: ubuntu 1204 PHP Version:5.3.14 Block user comment: N Private report: N New Comment: You wrote 5.3.14 in the ticket, but 5.3.10 in the description ... what is correct? On 5.3.10-dotdeb it segfaults for me without xdebug too. With the 5.3.15-dev there are no issues with or without xdebug for me. Can you confirm that? Previous Comments: [2012-07-04 13:53:04] bronze1man at gmail dot com Description: start xdebug openssl_encrypt an empty string ,then it will crash. php version: PHP 5.3.10-1ubuntu3.2 with Suhosin-Patch (cli) (built: Jun 13 2012 17:20:55) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans Test script: --- https://bugs.php.net/bug.php?id=62481&edit=1
[PHP-BUG] Bug #62481 [NEW]: xdebug openssl_encrypt crash
From: bronze1man at gmail dot com Operating system: ubuntu 1204 PHP version: 5.3.14 Package: OpenSSL related Bug Type: Bug Bug description:xdebug openssl_encrypt crash Description: start xdebug openssl_encrypt an empty string ,then it will crash. php version: PHP 5.3.10-1ubuntu3.2 with Suhosin-Patch (cli) (built: Jun 13 2012 17:20:55) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans Test script: --- https://bugs.php.net/bug.php?id=62481&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62481&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62481&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62481&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62481&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62481&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62481&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62481&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62481&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62481&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62481&r=support Expected behavior: https://bugs.php.net/fix.php?id=62481&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62481&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62481&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62481&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62481&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62481&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62481&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62481&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62481&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62481&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62481&r=mysqlcfg
Bug #62480 [Opn]: mbstring and mbregex won't compile
Edit report at https://bugs.php.net/bug.php?id=62480&edit=1 ID: 62480 User updated by:rs at bytecamp dot net Reported by:rs at bytecamp dot net Summary:mbstring and mbregex won't compile Status: Open Type: Bug Package:Compile Failure Operating System: FreeBSD 8.1-RELEASE-p12 PHP Version:5.4.4 Block user comment: N Private report: N New Comment: One thing to add: oniguruma-2.5.8 is installed on this machine (for ruby). Could this be the cause, because /usr/local/include is also in the list of include directories? Previous Comments: [2012-07-04 13:21:06] rs at bytecamp dot net Description: When enabling mbstring and mbregex, make will bail out with the following log: /bin/sh /tmp/php-5.4/php-5.4.4/libtool --silent --preserve-dup-deps --mode=compile cc -Iext/mbstring/ -I/tmp/php-5.4/php-5.4.4/ext/mbstring/ -DPHP_ATOM_INC -I/tmp/php-5.4/php-5.4.4/include -I/tmp/php-5.4/php-5.4.4/main -I/tmp/php-5.4/php-5.4.4 -I/tmp/php-5.4/php-5.4.4/ext/date/lib -I/tmp/php-5.4/php-5.4.4/ext/ereg/regex -I/usr/local/include/libxml2 -I/usr/local/include -I/tmp/php-5.4/php-5.4.4/ext/mbstring/oniguruma -I/tmp/php-5.4/php-5.4.4/ext/mbstring/libmbfl -I/tmp/php-5.4/php-5.4.4/ext/mbstring/libmbfl/mbfl -I/tmp/php-5.4/php-5.4.4/ext/sqlite3/libsqlite -I/tmp/php-5.4/php-5.4.4/TSRM -I/tmp/php-5.4/php-5.4.4/Zend-I/usr/local/include -g -O2 -fvisibility=hidden -c /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c -o ext/mbstring/mbstring.lo /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c: In function '_php_mb_compile_regex': /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:987: error: expected ')' before 'OnigUChar' /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:987: warning: cast from pointer to integer of different size /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:988: error: expected ')' before 'OnigUChar' /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:988: warning: cast from pointer to integer of different size /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:990: warning: passing argument 2 of 'onig_new' makes pointer from integer without a cast /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:990: warning: passing argument 3 of 'onig_new' makes pointer from integer without a cast /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:991: error: 'OnigUChar' undeclared (first use in this function) /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:991: error: (Each undeclared identifier is reported only once /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:991: error: for each function it appears in.) /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:991: error: expected ';' before 'err_str' /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:992: error: 'err_str' undeclared (first use in this function) /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c: In function '_php_mb_match_regex': /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1003: error: expected ')' before 'OnigUChar' /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1003: warning: cast from pointer to integer of different size /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1004: error: expected ')' before 'OnigUChar' /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1004: warning: cast from pointer to integer of different size /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1004: error: expected ')' before 'OnigUChar' /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1004: warning: cast from pointer to integer of different size /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1005: error: expected ')' before 'OnigUChar' /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1005: warning: cast from pointer to integer of different size /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1005: warning: passing argument 2 of 'onig_search' makes pointer from integer without a cast /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1005: warning: passing argument 3 of 'onig_search' makes pointer from integer without a cast /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1005: warning: passing argument 4 of 'onig_search' makes pointer from integer without a cast /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1005: warning: passing argument 5 of 'onig_search' makes pointer from integer without a cast *** Error code 1 Test script: --- ./configure --prefix=/usr/local/php-4.4-fail --enable-mbstring --enable-mbregex make -- Edit this bug report at https://bugs.php.net/bug.php?id=62480&edit=1
[PHP-BUG] Bug #62480 [NEW]: mbstring and mbregex won't compile
From: rs at bytecamp dot net Operating system: FreeBSD 8.1-RELEASE-p12 PHP version: 5.4.4 Package: Compile Failure Bug Type: Bug Bug description:mbstring and mbregex won't compile Description: When enabling mbstring and mbregex, make will bail out with the following log: /bin/sh /tmp/php-5.4/php-5.4.4/libtool --silent --preserve-dup-deps --mode=compile cc -Iext/mbstring/ -I/tmp/php-5.4/php-5.4.4/ext/mbstring/ -DPHP_ATOM_INC -I/tmp/php-5.4/php-5.4.4/include -I/tmp/php-5.4/php-5.4.4/main -I/tmp/php-5.4/php-5.4.4 -I/tmp/php-5.4/php-5.4.4/ext/date/lib -I/tmp/php-5.4/php-5.4.4/ext/ereg/regex -I/usr/local/include/libxml2 -I/usr/local/include -I/tmp/php-5.4/php-5.4.4/ext/mbstring/oniguruma -I/tmp/php-5.4/php-5.4.4/ext/mbstring/libmbfl -I/tmp/php-5.4/php-5.4.4/ext/mbstring/libmbfl/mbfl -I/tmp/php-5.4/php-5.4.4/ext/sqlite3/libsqlite -I/tmp/php-5.4/php-5.4.4/TSRM -I/tmp/php-5.4/php-5.4.4/Zend -I/usr/local/include -g -O2 -fvisibility=hidden -c /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c -o ext/mbstring/mbstring.lo /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c: In function '_php_mb_compile_regex': /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:987: error: expected ')' before 'OnigUChar' /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:987: warning: cast from pointer to integer of different size /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:988: error: expected ')' before 'OnigUChar' /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:988: warning: cast from pointer to integer of different size /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:990: warning: passing argument 2 of 'onig_new' makes pointer from integer without a cast /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:990: warning: passing argument 3 of 'onig_new' makes pointer from integer without a cast /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:991: error: 'OnigUChar' undeclared (first use in this function) /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:991: error: (Each undeclared identifier is reported only once /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:991: error: for each function it appears in.) /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:991: error: expected ';' before 'err_str' /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:992: error: 'err_str' undeclared (first use in this function) /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c: In function '_php_mb_match_regex': /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1003: error: expected ')' before 'OnigUChar' /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1003: warning: cast from pointer to integer of different size /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1004: error: expected ')' before 'OnigUChar' /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1004: warning: cast from pointer to integer of different size /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1004: error: expected ')' before 'OnigUChar' /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1004: warning: cast from pointer to integer of different size /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1005: error: expected ')' before 'OnigUChar' /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1005: warning: cast from pointer to integer of different size /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1005: warning: passing argument 2 of 'onig_search' makes pointer from integer without a cast /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1005: warning: passing argument 3 of 'onig_search' makes pointer from integer without a cast /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1005: warning: passing argument 4 of 'onig_search' makes pointer from integer without a cast /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1005: warning: passing argument 5 of 'onig_search' makes pointer from integer without a cast *** Error code 1 Test script: --- ./configure --prefix=/usr/local/php-4.4-fail --enable-mbstring --enable-mbregex make -- Edit bug report at https://bugs.php.net/bug.php?id=62480&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62480&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62480&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62480&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62480&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62480&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62480&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62480&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62480&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62480&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62480&r=support Expected behavior: https://bugs.php.net/fix.php?id=62480&r=notwrong Not enough info:
Bug #62479 [Opn]: PDO-psql cannot connect if password contains spaces
Edit report at https://bugs.php.net/bug.php?id=62479&edit=1 ID: 62479 User updated by:brice at bmaron dot net Reported by:brice at bmaron dot net Summary:PDO-psql cannot connect if password contains spaces Status: Open Type: Bug Package:PDO related Operating System: Linux- Debian Stable PHP Version:5.3.14 Block user comment: N Private report: N New Comment: It seems to be a pdo-psql only ... not affecting other drivers like mysql Previous Comments: [2012-07-04 08:56:06] brice at bmaron dot net Description: When you try to connect to a Postgresql database with a password containing 1 or more spaces, pdo will fail to connect. You must escape yourself the user & password and put it into the dsn to make it work. It may also be true for other databases ... it's not tested Test script: --- https://gist.github.com/3046155 Expected result: See a connection and no error for both tries Actual result: -- See an error for the first one and a correct result for the second one -- Edit this bug report at https://bugs.php.net/bug.php?id=62479&edit=1
Bug #48885 [Com]: finfo returns mime type + charset when FILEINFO_MIME is used
Edit report at https://bugs.php.net/bug.php?id=48885&edit=1
ID: 48885
Comment by: soccertux at gmail dot com
Reported by:majkl578 at gmail dot com
Summary:finfo returns mime type + charset when FILEINFO_MIME
is used
Status: Closed
Type: Bug
Package:Filesystem function related
Operating System: Linux Debian
PHP Version:5.3.0
Block user comment: N
Private report: N
New Comment:
Found this issue because we're experiencing a problem while downloading an
image
from a PHP server using a java client.
[quote paj...@php.net]
For the binary data, the charset will obviously be set to binary:
image/gif; charset=binary
[/quote]
First binary is not a charset! The official charsets can be found here
http://www.iana.org/assignments/character-sets and binary is not in this list.
>From rfc http://www.ietf.org/rfc/rfc2046.txt
A critical parameter that may be specified in the Content-Type field for
"text/plain" data is the character set.
Again not for binary blobs... Java is failing on this because binary is an
unsupported set.
Previous Comments:
[2009-11-15 20:47:50] majkl578 at gmail dot com
scottmac: Thank you, the constant you've added works like a charm.
philip: On my Debian server, libmagic1 library is in version 4.26-1.
mohdyusuf: try this:
--
$obj = new finfo(FILEINFO_MIME_TYPE);
echo $obj->file('/tmp/whatever');
--
Thank you.
[2009-10-24 07:08:13] mohdyusuf at gmail dot com
I used to do a direct comparison, for example
if($mimeInfo = 'image/jpeg') ...
But then, with this changes, the comparison broke. Fortunately I have a custom
findStr() function that does the job.
if(findStr('image/jpeg',$mimeInfo)) ...
this solved my problem easily.
[2009-08-04 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2009-07-27 05:26:20] phi...@php.net
Which version of libmagic changed this? It should be added to the docs.
Also, the docs don't mention how to link to libmagic nor mention that a
bundled version is used [by default]. What's the situation? The only
option I see with './configure --help' is --disable-fileinfo ...
[2009-07-27 03:16:33] s...@php.net
Automatic comment from SVN on behalf of scottmac
Revision: http://svn.php.net/viewvc/?view=revision&revision=286383
Log: Update documentation to reflect change with the internal libmagic updates.
See bug #48885
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=48885
--
Edit this bug report at https://bugs.php.net/bug.php?id=48885&edit=1
Req #62216 [Opn->Ana]: Add PID to php-fpm init.d script
Edit report at https://bugs.php.net/bug.php?id=62216&edit=1 ID: 62216 Updated by: f...@php.net Reported by:jasmin_z at hotmail dot com Summary:Add PID to php-fpm init.d script -Status: Open +Status: Analyzed Type: Feature/Change Request Package:FPM related Operating System: Debian 6 PHP Version:5.4.3 -Assigned To: +Assigned To:fat Block user comment: N Private report: N Previous Comments: [2012-06-03 16:20:28] jasmin_z at hotmail dot com Description: sapi/fpm/init.d.php-fpm file provided with current PHP build used for init.d script in Debian is missing PID option causing init script to look as it failed: # /etc/init.d/php-fpm start Starting php-fpm ... failed Replacing following line in php-fpm init.d file: php_opts="--fpm-config $php_fpm_CONF" to: php_opts="--fpm-config $php_fpm_CONF --pid $php_fpm_PID" fixes the issue! -- Edit this bug report at https://bugs.php.net/bug.php?id=62216&edit=1
Bug #62279 [Opn->Ana]: PHP-FPM chroot never-solved problems (extends #55322)
Edit report at https://bugs.php.net/bug.php?id=62279&edit=1 ID: 62279 Updated by: f...@php.net Reported by:nospam at bigalex dot it Summary:PHP-FPM chroot never-solved problems (extends #55322) -Status: Open +Status: Analyzed Type: Bug Package:FPM related Operating System: Irrelevant PHP Version:Any -Assigned To: +Assigned To:fat Block user comment: N Private report: N New Comment: >From my point of view, I'd rather prefer to configure this on the web server side (if it's not possible with apache then switch to something else -- aka nginx for exemple. If apache does not suit well with fastcgi customizations, then ask apache guys :p) more seriously, I can understand the need. I'll try to look at this to dynamicaly adapt fastcgi variables from the chroot env. The following algorithm should work: for variable in all_fastcgi_variables; do if ($_SERVER[$var] =~ /^$chroot(.*)$/); then $_SERVER[$var] = $1; fi done or somehting more restrictive: for var in "DOCUMENT_ROOT" "SCRIPT_FILENAME" "PATH_TRANSLATED"]; do if ($_SERVER[$var] =~ /^$chroot(.*)$/); then $_SERVER[$var] = $1; fi end Previous Comments: [2012-06-28 17:45:34] nospam at bigalex dot it In the meantime, I've already found a way to fix this behaviour: a proxy between PHP-FPM and Apache. I needed a caching proxy to be on top of Apache to cache php scripts (I don't care about static files because what really causes CPU and memory problems is having the php processes running), so I've thought to implement a fcgi proxy to be used among PHP-FPM and Apache. It does work and does a great job: I didn't need to implement anything about the HTTP protocol since there's already Apache caring about it; then, caching the results from PHP, I can avoid asking FPM to run the already cached pages, giving them away to Apache in an elegant manner. And, of course, the proxy does fix the wrong variables, removing the chrooted part and making the scripts able to work. I'm still trying to fix the sources, but since they appears complicated (read: messy), and there's no documentation about it or about debugging them, I don't think I will fix them before I have more time to spend or having a clue about reading the configuration values from fpm_main.c. Anyway, for anyone interested in it, the proxy has been made using python and flup server and client implementations. [2012-06-28 16:02:03] graham at wyenet dot net The symbolic trick does work (as long as the sym link is relative (ie ../../../chrootpath if you try to link directly from the root, then the symlink goes outside the jail and it will still fail). Anyway thats a very messy hack, and I agree with you, php-fpm creates the jails, so it should fix the PHP variables. Without the symlink, I just get file not found for all calls for scripts. If you change fix.cgi_pathinfo = 0 it will run the scripts, but the $_SERVER variables will still be wrong... Im sure most people would rather it was fixed so that the fix.cgi_pathinfo = 1 works, AND the variables are set correctly... But either way would be better than trying to hack in fixes with sym links, and/or preloading a fixup script. I did take a look at the fpm_main.c but also been unable to create my own patch for it at this time. Surely it cant be that hard to read the chroot path from the configuration file, and remove that from all appropriate server variables, or recreate the broken variables some other way. Symlink is good enough for a test environment, to see what other php functions break with the chroot, and to start building a system, but I wouldn't use that hack on a production web server. [2012-06-24 16:25:15] nospam at bigalex dot it I want to patch the sources, but can't find a way to get from the function init_request_info info fpm_main.c the chroot path. Since the documentation about it lacks, can anyone put me in the right direction? :P I think I need to get the configuration (or add a variable to the worker) about the current chroot location. A more safe way to handle it would be to get, from the father process, the child's chroot location and filter it before passing the variables to the child. Anyway, in both cases, there is lack of documentation and I've still been unable to patch anything, so suggestions would be really appreciated! :) [2012-06-09 17:45:35] nospam at bigalex dot it Edited the php version, since it affects avery version. [2012-06-09 17:43:39]
Bug #62418 [Opn->Fbk]: php-fpm master process crashes
Edit report at https://bugs.php.net/bug.php?id=62418&edit=1 ID: 62418 Updated by: f...@php.net Reported by:php at scratchspace dot com Summary:php-fpm master process crashes -Status: Open +Status: Feedback Type: Bug Package:FPM related Operating System: CentOS 6.2 x86_x64 PHP Version:5.3.14 Block user comment: N Private report: N New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. If you were able to give us a complete and detailed stack trace it would be useful. thx Previous Comments: [2012-06-27 20:10:08] ras...@php.net Not sure. Many people out there run with epoll without problems. [2012-06-27 18:28:14] php at scratchspace dot com We've been up and running for 24 hours with "events.mechanism = poll" and no problems. Let's give it a couple of days to be sure this workaround works. Is this issue specific to epoll and the way we have php-fpm configured (to use minimal resources), or is this is a bug in php-fpm that can ultimately be fixed? [2012-06-26 06:10:02] ras...@php.net Could you check if it is related to epoll? In your php-fpm.conf file, set: events.mechanism = poll to try with "poll" instead. You can also try setting it to "select" [2012-06-26 05:56:45] php at scratchspace dot com Description: php-fpm master process crashes randomly on lightly loaded server running nginx/0.8.54 with various CMS applications. It is unknown how to reproduce the crash, but occurs in both php 5.3.13 and 5.3.14. Actual result: -- 5.3.14 backtrace Core was generated by `php-fpm:'. Program terminated with signal 11, Segmentation fault. #0 0x016b5300 in ?? () #1 0x006e02f3 in fpm_event_epoll_wait (queue=, timeout=) at /usr/src/debug/php-5.3.14/sapi/fpm/fpm/events/epoll.c:143 #2 0x006d508f in fpm_event_loop (err=0) at /usr/src/debug/php- 5.3.14/sapi/fpm/fpm/fpm_events.c:401 #3 0x006d01f7 in fpm_run (max_requests=0x7fffd103136c) at /usr/src/debug/php-5.3.14/sapi/fpm/fpm/fpm.c:110 #4 0x006d79a4 in main (argc=1, argv=0x7fffd10334d8) at /usr/src/debug/php-5.3.14/sapi/fpm/fpm/fpm_main.c:1778 -- Edit this bug report at https://bugs.php.net/bug.php?id=62418&edit=1
Bug #54654 [Fbk->Opn]: pdo_oci connection after some time begin except error
Edit report at https://bugs.php.net/bug.php?id=54654&edit=1
ID: 54654
User updated by:mikhail dot v dot gavrilov at gmail dot com
Reported by:mikhail dot v dot gavrilov at gmail dot com
Summary:pdo_oci connection after some time begin except
error
-Status: Feedback
+Status: Open
Type: Bug
Package:PDO related
Operating System: CentOS 5.6
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Sorry, I am already write patch and fix it here:
https://bugs.php.net/bug.php?id=55768
Previous Comments:
[2012-06-26 22:34:57] s...@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 ,
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.
[2011-05-04 10:29:20] mikhail dot v dot gavrilov at gmail dot com
Description:
pdo_oci connection after some time begin except follow error: SQLSTATE[HY000]:
General error: 3114 OCIStmtExecute: Error while trying to retrieve text for
error ORA-03114
(/builddir/build/BUILD/php-5.3.6/ext/pdo_oci/oci_statement.c:148)
Test script:
---
$db = new PDO('oci:dbname=my-sid', 'user', 'pass', array(
PDO::ATTR_PERSISTENT => true,
PDO::ATTR_AUTOCOMMIT => false,
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION)
);
--
Edit this bug report at https://bugs.php.net/bug.php?id=54654&edit=1
[PHP-BUG] Bug #62479 [NEW]: PDO-psql cannot connect if password contains spaces
From: brice at bmaron dot net Operating system: Linux- Debian Stable PHP version: 5.3.14 Package: PDO related Bug Type: Bug Bug description:PDO-psql cannot connect if password contains spaces Description: When you try to connect to a Postgresql database with a password containing 1 or more spaces, pdo will fail to connect. You must escape yourself the user & password and put it into the dsn to make it work. It may also be true for other databases ... it's not tested Test script: --- https://gist.github.com/3046155 Expected result: See a connection and no error for both tries Actual result: -- See an error for the first one and a correct result for the second one -- Edit bug report at https://bugs.php.net/bug.php?id=62479&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62479&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62479&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62479&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62479&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62479&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62479&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62479&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62479&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62479&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62479&r=support Expected behavior: https://bugs.php.net/fix.php?id=62479&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62479&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62479&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62479&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62479&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62479&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62479&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62479&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62479&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62479&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62479&r=mysqlcfg
Bug #18556 [Com]: Setting locale to 'tr_TR' lowercases class names
Edit report at https://bugs.php.net/bug.php?id=18556&edit=1 ID: 18556 Comment by: maar...@php.net Reported by:spud at nothingness dot org Summary:Setting locale to 'tr_TR' lowercases class names Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Linux (RedHat 7.2) PHP Version:5CVS, 4CVS (2005-10-04) Assigned To:dmitry Block user comment: N Private report: N New Comment: @ stormbyte, I just made 2 separate more explicit tests, one for tr_TR.iso8859-9 and one for tr_TR.UTF-8 and they do have the same outcome: tr_TR.iso8859-9 - http://3v4l.org/o5YCk tr_TR.UTF-8 - http://3v4l.org/F2gEb 3v4l.org uses a 'vanilla' PHP setup, be free to play with phpinfo() and the likes to see for yourself. Previous Comments: [2012-07-03 17:05:03] stormbyte at gmail dot com The problem: output: thIs Is just a test So if it is using the same function internally to do the tolower on class names, it will not find them. A workarround would be use toupper instead of tolower in zend_internal namespace handling, despite the correct fix would be to use independent identifyers (??) [2012-07-03 16:53:08] stormbyte at gmail dot com maar...@php.net: They don't seem to be running vanilla PHP installations. I've compiled php-5.4.4 from Gentoo and do not appear to be fixed to me, even in 5.4.4. Can you try on a vanilla PHP? [2012-07-03 16:42:22] stormbyte at gmail dot com It is not fixed in 5.4.4 as some stated above. Tested with php 5.4.4 Testcase: '; $class = 'PharFileInfo'; echo 'Locale: '.setlocale(LC_ALL, '0').""; echo "$class exists? ".var_export(class_exists($class), true).""; echo 'Locale: '.setlocale(LC_ALL, 'tr_TR.UTF-8').""; echo "$class exists? ".var_export(class_exists($class), true).""; >? Output with nginx+spawnFCGI: Starting... Locale: C PharFileInfo exists? true Locale: tr_TR.UTF-8 PharFileInfo exists? false Output with cli (php -f test.php): Starting...Locale: CPharFileInfo exists? trueLocale: tr_TR.UTF-8PharFileInfo exists? false [2012-07-03 09:58:31] maar...@php.net Appears to be fixed since >= 5.4.0 See http://3v4l.org/lahi5 for proof: --- Output for 5.4.0 - 5.4.4 Instantiating an infoBlob with a lowercase iFooInstantiating an InfoBlob with an uppercase IFoo Output for 5.0.0 - 5.0.5, 5.1.0 - 5.1.6, 5.2.0 - 5.2.17, 5.3.0 - 5.3.14 Instantiating an infoBlob with a lowercase iFooInstantiating an InfoBlob with an uppercase I Fatal error: Class 'InfoBlob' not found in /in/lahi5 on line 25 Process exited with code 255. --- Can't find it in the changelogs though. [2012-07-03 09:02:01] shevegen at gmail dot com There are other languages one could use, other than 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 https://bugs.php.net/bug.php?id=18556 -- Edit this bug report at https://bugs.php.net/bug.php?id=18556&edit=1
Req #47875 [Com]: No option to set HTML input encoding
Edit report at https://bugs.php.net/bug.php?id=47875&edit=1
ID: 47875
Comment by: julien at go-on-web dot com
Reported by:thomas dot koch at ymc dot ch
Summary:No option to set HTML input encoding
Status: Open
Type: Feature/Change Request
Package:DOM XML related
Operating System: Debian Lenny
PHP Version:5.2.9
Block user comment: N
Private report: N
New Comment:
I have another test case for you, using HTML5 :
Test case with simple accent (é) : é
HTML;
$doc = new DomDocument( 1.0, 'UTF-8' );
$doc->loadHTML( $html );
var_dump( $doc->getElementById('accent')->textContent );
//=> string(40) "Test case with simple accent (é) : é"
//
// -
// SUCCESS CASE (but invalid html5)
$html = <<
Test case with simple accent (é) : é
HTML;
$doc = new DomDocument( 1.0, 'UTF-8' );
$doc->loadHTML( $html );
var_dump( $doc->getElementById('accent')->textContent );
//=> string(38) "Test case with simple accent (é) : é"
// -
?>
Regards,
Julien
Previous Comments:
[2009-04-02 09:07:32] thomas dot koch at ymc dot ch
Description:
Enhancement request.
I need a possibility to indicate the html input encoding (as parsed from the
HTTP headers) when parsing a html string with DOMDocument::loadHTML. Using
loadHTMLFile is not always an option.
libxml2 honors the content-type meta tag, but this may not always be present.
How should the input encoding be indicated? In DOMDocument::__construct() or in
DOMDocument::encoding or is that both the same?
One could look in libxml2/HTMLparser.c#5580, function
htmlCreateFileParserCtxt(const char *filename, const char *encoding)
There the encoding is set by first building a "charset=$encoding" string and
passing it to htmlCheckEncoding, which in turn parses the encoding out of the
string again. This may be worth cleaning up together with upstream.
Reproduce code:
---
http://www.w3.org/TR/REC-html40/loose.dtd";>
süÃ
EOT;
$dom = new DOMDocument;
var_dump( $dom->loadHTML( $html ) );
$elem = $dom->getElementById( 'umlaut' );
echo $elem->textContent;
--
Edit this bug report at https://bugs.php.net/bug.php?id=47875&edit=1
