[PHP-BUG] Bug #61354 [NEW]: htmlentities and htmlspecialchars do not working with default_charset ini set
From: Operating system: Linux/Windows/ PHP version: 5.4.0 Package: Strings related Bug Type: Bug Bug description:htmlentities and htmlspecialchars do not working with default_charset ini set Description: I am using php 5.4, i got a trouble with htmlspecialchars, htmlentities. php 5.4 default charset is utf-8. i thought htmlspecialchars, htmlentities may be using utf-8 as default encoding, but even i configured default_charset in my php.ini , the htmlspecialchars and htmlentities still stupid using utf-8. this is a bad expirence, my project is a little big, htmlspecialchars using every where, almost 3 million called. i had no chance to specified encoding by hand. add encoding to each call of htmlspecialchars and htmlentities not possible, it is a huge change for me . for another solution, why not php let htmlspecialchars using encoding by php.ini settings? is it a better way? is it friendly to users? sorry for my bad english. Test script: --- ææ¯æµè¯'; echo htmlspecialchars($string); echo htmlspecialchars($string, NULL, 'GB2312'); Expected result: htmlspecialchars should using charset defined by php.ini default_charset. -- Edit bug report at https://bugs.php.net/bug.php?id=61354&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61354&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61354&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61354&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61354&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61354&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61354&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61354&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61354&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61354&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61354&r=support Expected behavior: https://bugs.php.net/fix.php?id=61354&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61354&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61354&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61354&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61354&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61354&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61354&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61354&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61354&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61354&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61354&r=mysqlcfg
Bug #61354 [Com]: htmlentities and htmlspecialchars doesn't respect the default_charset
Edit report at https://bugs.php.net/bug.php?id=61354&edit=1 ID: 61354 Comment by: hufeng1987 at gmail dot com Reported by:hufeng1987 at gmail dot com Summary:htmlentities and htmlspecialchars doesn't respect the default_charset Status: Not a bug Type: Bug Package:Strings related Operating System: Linux/Windows/ PHP Version:5.4.0 Block user comment: N Private report: N New Comment: if this was not a bug, why this change blocked our old project? in previous PHP under php 5.4 , we could using htmlspecialchars as simple: htmlspecialchars($string); and this call should not broken the string. but now, under php 5.4, the default encoding change to utf-8. which may broken old codes. it is impossible to rewrite old code ,add charset encoding specified. Previous Comments: [2012-03-12 05:47:19] ras...@php.net There is some confusion around this point. The default_charset in your php.ini file is meant to be the output encoding. What you specify here is what ends up in the HTTP Content-type response header. You should be able to change that without messing up your internal runtime encoding which is why setting that does not automatically change the internal encoding used by htmlspecialchars/htmlentities. You can force it to look at it by setting the 3rd arg (the encoding) arg of the htmlspecialchars() call to "" (and empty string). This is documented on the http://php.net/htmlspecialchars page. But, like I mentioned, you should be able to change your output encoding separately from your internal runtime encoding, so we don't suggest doing this. The safest approach is to explicitly set your encoding on your htmlspecialchars() calls. There times when you get data from sources that have different encodings so two htmlspecialchars() calls in the same app may need to use different encodings. ---- [2012-03-12 03:03:35] hufeng1987 at gmail dot com Description: I am using php 5.4, i got a trouble with htmlspecialchars, htmlentities. php 5.4 default charset is utf-8. i thought htmlspecialchars, htmlentities may be using utf-8 as default encoding, but even i configured default_charset in my php.ini , the htmlspecialchars and htmlentities still stupid using utf-8. this is a bad expirence, my project is a little big, htmlspecialchars using every where, almost 3 million called. i had no chance to specified encoding by hand. add encoding to each call of htmlspecialchars and htmlentities not possible, it is a huge change for me . for another solution, why not php let htmlspecialchars using encoding by php.ini settings? is it a better way? is it friendly to users? sorry for my bad english. Test script: --- ææ¯æµè¯'; echo htmlspecialchars($string); echo htmlspecialchars($string, NULL, 'GB2312'); Expected result: htmlspecialchars should using charset defined by php.ini default_charset. -- Edit this bug report at https://bugs.php.net/bug.php?id=61354&edit=1
Bug #61354 [Com]: htmlentities and htmlspecialchars doesn't respect the default_charset
Edit report at https://bugs.php.net/bug.php?id=61354&edit=1 ID: 61354 Comment by: hufeng1987 at gmail dot com Reported by:hufeng1987 at gmail dot com Summary:htmlentities and htmlspecialchars doesn't respect the default_charset Status: Not a bug Type: Bug Package:Strings related Operating System: Linux/Windows/ PHP Version:5.4.0 Block user comment: N Private report: N New Comment: may be you are right , php 5.4 should have utf-8 as the default encoding. but , as production enviroment, this will cause more accident. why not php wisely handle default_charset ? that will free us from recoding. Previous Comments: [2012-03-12 06:04:35] ras...@php.net What do you mean it is impossible to rewrite old code? In previous versions htmlspecialchars() didn't respect the default_charset ini setting either. It only looks at that setting if you pass an empty string as the encoding. The change in PHP 5.4 was simply to switch from ISO-8859-1 to UTF8 when you do not specify a charset. [2012-03-12 05:56:17] hufeng1987 at gmail dot com if this was not a bug, why this change blocked our old project? in previous PHP under php 5.4 , we could using htmlspecialchars as simple: htmlspecialchars($string); and this call should not broken the string. but now, under php 5.4, the default encoding change to utf-8. which may broken old codes. it is impossible to rewrite old code ,add charset encoding specified. [2012-03-12 05:47:19] ras...@php.net There is some confusion around this point. The default_charset in your php.ini file is meant to be the output encoding. What you specify here is what ends up in the HTTP Content-type response header. You should be able to change that without messing up your internal runtime encoding which is why setting that does not automatically change the internal encoding used by htmlspecialchars/htmlentities. You can force it to look at it by setting the 3rd arg (the encoding) arg of the htmlspecialchars() call to "" (and empty string). This is documented on the http://php.net/htmlspecialchars page. But, like I mentioned, you should be able to change your output encoding separately from your internal runtime encoding, so we don't suggest doing this. The safest approach is to explicitly set your encoding on your htmlspecialchars() calls. There times when you get data from sources that have different encodings so two htmlspecialchars() calls in the same app may need to use different encodings. ---- [2012-03-12 03:03:35] hufeng1987 at gmail dot com Description: I am using php 5.4, i got a trouble with htmlspecialchars, htmlentities. php 5.4 default charset is utf-8. i thought htmlspecialchars, htmlentities may be using utf-8 as default encoding, but even i configured default_charset in my php.ini , the htmlspecialchars and htmlentities still stupid using utf-8. this is a bad expirence, my project is a little big, htmlspecialchars using every where, almost 3 million called. i had no chance to specified encoding by hand. add encoding to each call of htmlspecialchars and htmlentities not possible, it is a huge change for me . for another solution, why not php let htmlspecialchars using encoding by php.ini settings? is it a better way? is it friendly to users? sorry for my bad english. Test script: --- ææ¯æµè¯'; echo htmlspecialchars($string); echo htmlspecialchars($string, NULL, 'GB2312'); Expected result: htmlspecialchars should using charset defined by php.ini default_charset. -- Edit this bug report at https://bugs.php.net/bug.php?id=61354&edit=1
Bug #61354 [Com]: htmlentities and htmlspecialchars doesn't respect the default_charset
Edit report at https://bugs.php.net/bug.php?id=61354&edit=1 ID: 61354 Comment by: hufeng1987 at gmail dot com Reported by:hufeng1987 at gmail dot com Summary:htmlentities and htmlspecialchars doesn't respect the default_charset Status: Not a bug Type: Bug Package:Strings related Operating System: Linux/Windows/ PHP Version:5.4.0 Block user comment: N Private report: N New Comment: When your project using GB2312 as default charset encoding, when you upgrade to php 5.4, you will find htmlspecialchars will not working as usual. if you want them working correctly, you should replace following code with new: old code: htmlspecialchars($string); new code: htmlspecialchars($string, NULL, 'GB2312'); recoding the full project is a huge work. especially when the project is old. Previous Comments: [2012-03-12 06:05:54] hufeng1987 at gmail dot com may be you are right , php 5.4 should have utf-8 as the default encoding. but , as production enviroment, this will cause more accident. why not php wisely handle default_charset ? that will free us from recoding. [2012-03-12 06:04:35] ras...@php.net What do you mean it is impossible to rewrite old code? In previous versions htmlspecialchars() didn't respect the default_charset ini setting either. It only looks at that setting if you pass an empty string as the encoding. The change in PHP 5.4 was simply to switch from ISO-8859-1 to UTF8 when you do not specify a charset. ---- [2012-03-12 05:56:17] hufeng1987 at gmail dot com if this was not a bug, why this change blocked our old project? in previous PHP under php 5.4 , we could using htmlspecialchars as simple: htmlspecialchars($string); and this call should not broken the string. but now, under php 5.4, the default encoding change to utf-8. which may broken old codes. it is impossible to rewrite old code ,add charset encoding specified. [2012-03-12 05:47:19] ras...@php.net There is some confusion around this point. The default_charset in your php.ini file is meant to be the output encoding. What you specify here is what ends up in the HTTP Content-type response header. You should be able to change that without messing up your internal runtime encoding which is why setting that does not automatically change the internal encoding used by htmlspecialchars/htmlentities. You can force it to look at it by setting the 3rd arg (the encoding) arg of the htmlspecialchars() call to "" (and empty string). This is documented on the http://php.net/htmlspecialchars page. But, like I mentioned, you should be able to change your output encoding separately from your internal runtime encoding, so we don't suggest doing this. The safest approach is to explicitly set your encoding on your htmlspecialchars() calls. There times when you get data from sources that have different encodings so two htmlspecialchars() calls in the same app may need to use different encodings. -------- [2012-03-12 03:03:35] hufeng1987 at gmail dot com Description: I am using php 5.4, i got a trouble with htmlspecialchars, htmlentities. php 5.4 default charset is utf-8. i thought htmlspecialchars, htmlentities may be using utf-8 as default encoding, but even i configured default_charset in my php.ini , the htmlspecialchars and htmlentities still stupid using utf-8. this is a bad expirence, my project is a little big, htmlspecialchars using every where, almost 3 million called. i had no chance to specified encoding by hand. add encoding to each call of htmlspecialchars and htmlentities not possible, it is a huge change for me . for another solution, why not php let htmlspecialchars using encoding by php.ini settings? is it a better way? is it friendly to users? sorry for my bad english. Test script: --- ææ¯æµè¯'; echo htmlspecialchars($string); echo htmlspecialchars($string, NULL, 'GB2312'); Expected result: htmlspecialchars should using charset defined by php.ini default_charset. -- Edit this bug report at https://bugs.php.net/bug.php?id=61354&edit=1
Bug #61354 [Nab]: htmlentities and htmlspecialchars doesn't respect the default_charset
Edit report at https://bugs.php.net/bug.php?id=61354&edit=1 ID: 61354 User updated by:hufeng1987 at gmail dot com Reported by:hufeng1987 at gmail dot com Summary:htmlentities and htmlspecialchars doesn't respect the default_charset Status: Not a bug Type: Bug Package:Strings related Operating System: Linux/Windows/ PHP Version:5.4.0 Block user comment: N Private report: N New Comment: though php 5.4.6 released, but these problem still exists. do you really care the php developers? Previous Comments: [2012-08-08 12:16:25] giodev at panozzo dot it Yes, this is a HUGE problem for us also. We migrate a single server with a single homemade application and we lost 3-4 hours to fix all htmlspecialchars() and htmlentities() to force encoding back to ISO-8859-1. And really, under these conditions we will never migrate other apps/servers to PHP 5.4. Too much work to be done not only by us, but also by external contractors and customer of hosting services. It's a big cost both for us and for our customers. [2012-08-08 11:30:35] aheckmann at m-s dot de We also have the problem with broken php code in 5.4. It is really a huge amount of work, to switch old projects. We scanned our source files and found over 25.000 lines with htmlspecialchars(), not only written by us, also in many 3rd party libraries. So we also can not switch these projects to php 5.4. A solution to set the default encoding vi php.ini/ini_set() back to iso8859-1 would be great. [2012-05-19 16:46:03] wxiaoguang at gmail dot com I consider this as a bug, too. My old code using charsets other than utf-8/ISO-8859-1 is totally broken by php5.4's new htmlspecialchars. in php5.3: ISO-8859-1 doesn't break any charset. in php5.4: gbk/gb2312 characters are broken and I get empty strings after htmlspecialchars. It's impossible to find all htmlspecialchars and add the 'utf-8' parameter to them in old projects. As a result, I can not upgrade to php5.4 [2012-04-11 15:37:09] moonwalker at hotbox dot ru Actually, it's a bug. Or at least a lack of customizability. You're forcing thousands of PHP developers to move to UTF-8 (and urgently patch their legacy code) and don't give a choice of default encoding in certain cases. It would much better not to force determine_charset() in ext/standard/html.c to return hardcoded cs_utf_8 as default encoding (WTF?) but use default_charset option value for example. At least it WILL BE CONFIGURABLE without a need to rewrite all existing htmlspecialchars() / htmlspecialchars_decode() / html_entity_decode() calls. Holy crap, you're just wasted so much time with that. [2012-03-12 19:29:38] tokul at users dot sourceforge dot net > if you want them working correctly, you should replace following code > with new: > old code: > > htmlspecialchars($string); > > new code: > > htmlspecialchars($string, NULL, 'GB2312'); htmlspecialchars($string, ENT_COMPAT, 'GB2312'); Default is to sanitize double quotes. 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=61354 -- Edit this bug report at https://bugs.php.net/bug.php?id=61354&edit=1
Bug #61354 [Nab]: htmlentities and htmlspecialchars doesn't respect the default_charset
Edit report at https://bugs.php.net/bug.php?id=61354&edit=1 ID: 61354 User updated by:hufeng1987 at gmail dot com Reported by:hufeng1987 at gmail dot com Summary:htmlentities and htmlspecialchars doesn't respect the default_charset Status: Not a bug Type: Bug Package:Strings related Operating System: Linux/Windows/ PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Please fix it as soon as possible. Previous Comments: [2013-01-05 03:53:35] leaflet at leafok dot com I am facing the same problem. After upgrading to PHP 5.4.10 in the product environment, all the GB2312 encoding data on the page became blank. This badly influenced the whole site. It is undoubtedly a backward compatible issue. Wish it could be resolved soon. [2012-12-28 17:36:29] rudibr at gmail dot com This is a serious backward incompatibility (and not even listed as such). I am also not able to upgrade to 5.4 because of this, and have advised all of my clients which I provide server consulting to do not upgrade as well. No defaults of any kind should be changed arbitrarily , without notice and without possibility of customization. It breaks code, and makes everyone affected very uneasy on any future relases. Like all here I hope this get the serious attention it should have gotten already. [2012-11-28 09:28:16] x dot bazilio at gmail dot com This is a bug. Just upgraded php and got empty string on many projects. I cant't change code in CMS, because i am not a developer of CMS. I am using CMS fore develop web sites. [2012-08-27 17:04:46] goodwaiter at gmail dot com because use htmlspecialchars($text,NULL,""); can make works fine; so php Developer can fix this bug in this easy way: just make "omitted encoding" works like encoding with "", and all things will be ok. [2012-08-27 16:37:32] goodwaiter at gmail dot com another fix way in code is that: use htmlspecialchars($text,NULL,"") not need to add "utf8" "cp936", or other in "", just leave "" blank, it will use the current page's encoding like no this 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 https://bugs.php.net/bug.php?id=61354 -- Edit this bug report at https://bugs.php.net/bug.php?id=61354&edit=1
Bug #61354 [Nab]: htmlentities and htmlspecialchars doesn't respect the default_charset
Edit report at https://bugs.php.net/bug.php?id=61354&edit=1 ID: 61354 User updated by:hufeng1987 at gmail dot com Reported by:hufeng1987 at gmail dot com Summary:htmlentities and htmlspecialchars doesn't respect the default_charset Status: Not a bug Type: Bug Package:Strings related Operating System: Linux/Windows/ PHP Version:5.4.0 Block user comment: N Private report: N New Comment: you made one step, but kill the php programmer. do you know how much more code need to rewrite and check? if your change broken user programm, it's your lost, not the user's lost. Previous Comments: [2013-01-05 04:20:02] ras...@php.net You will need to update your code to be compatible with PHP 5.4 either by explicitly providing the charset, or by passing in "" to pick up the default one. Anything short of that is a security issue. Code that didn't do this in PHP 5.3 is potentially insecure depending on which charset is being used, so no, nothing will be fixed here. We will not revert to 5.3 behaviour. ---- [2013-01-05 03:55:08] hufeng1987 at gmail dot com Please fix it as soon as possible. [2013-01-05 03:53:35] leaflet at leafok dot com I am facing the same problem. After upgrading to PHP 5.4.10 in the product environment, all the GB2312 encoding data on the page became blank. This badly influenced the whole site. It is undoubtedly a backward compatible issue. Wish it could be resolved soon. [2012-12-28 17:36:29] rudibr at gmail dot com This is a serious backward incompatibility (and not even listed as such). I am also not able to upgrade to 5.4 because of this, and have advised all of my clients which I provide server consulting to do not upgrade as well. No defaults of any kind should be changed arbitrarily , without notice and without possibility of customization. It breaks code, and makes everyone affected very uneasy on any future relases. Like all here I hope this get the serious attention it should have gotten already. [2012-11-28 09:28:16] x dot bazilio at gmail dot com This is a bug. Just upgraded php and got empty string on many projects. I cant't change code in CMS, because i am not a developer of CMS. I am using CMS fore develop web sites. 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=61354 -- Edit this bug report at https://bugs.php.net/bug.php?id=61354&edit=1
Bug #61354 [Nab]: htmlentities and htmlspecialchars doesn't respect the default_charset
Edit report at https://bugs.php.net/bug.php?id=61354&edit=1 ID: 61354 User updated by:hufeng1987 at gmail dot com Reported by:hufeng1987 at gmail dot com Summary:htmlentities and htmlspecialchars doesn't respect the default_charset Status: Not a bug Type: Bug Package:Strings related Operating System: Linux/Windows/ PHP Version:5.4.0 Block user comment: N Private report: N New Comment: pass null and empty string that could improve security? no sense.. Previous Comments: [2013-01-05 09:53:01] x dot bazilio at gmail dot com Please, fix it. It is so simple to provide default params. Wy should we put NULL and empty string? Where is security problem to not put NULL and empty string if they are will be default values of that params? [2013-01-05 04:40:26] ras...@php.net Code that is currently likely to be insecure, yes. We only make changes like this when we are forced to for security reasons. [2013-01-05 04:26:39] hufeng1987 at gmail dot com you made one step, but kill the php programmer. do you know how much more code need to rewrite and check? if your change broken user programm, it's your lost, not the user's lost. [2013-01-05 04:20:02] ras...@php.net You will need to update your code to be compatible with PHP 5.4 either by explicitly providing the charset, or by passing in "" to pick up the default one. Anything short of that is a security issue. Code that didn't do this in PHP 5.3 is potentially insecure depending on which charset is being used, so no, nothing will be fixed here. We will not revert to 5.3 behaviour. ---- [2013-01-05 03:55:08] hufeng1987 at gmail dot com Please fix it as soon as possible. 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=61354 -- Edit this bug report at https://bugs.php.net/bug.php?id=61354&edit=1
[PHP-BUG] Bug #63950 [NEW]: Lot's of memory leaks detected
From: hufeng1987 at gmail dot com Operating system: CentOS 5.8 PHP version: 5.4.10 Package: FPM related Bug Type: Bug Bug description:Lot's of memory leaks detected Description: System Linux localhost.localdomain 2.6.18-308.el5 #1 SMP Tue Feb 21 20:06:06 EST 2012 x86_64 Build Date Jan 8 2013 17:40:04 Configure Command'./configure' '--prefix=/usr/local/webserver/php-with- debug' '--with-iconv-dir=/usr/local' '--with-freetype-dir' '--with-jpeg-dir' '-- with-png-dir' '--with-zlib' '--with-libxml-dir=/usr' '--enable-xml' '--disable- rpath' '--enable-bcmath' '--enable-shmop' '--enable-sysvsem' '--enable-inline- optimization' '--with-curl' '--with-curlwrappers' '--enable-mbregex' '--enable- fpm' '--enable-mbstring' '--with-gd' '--enable-gd-native-ttf' '--with-openssl' '-- enable-pcntl' '--enable-sockets' '--enable-zip' '--with-mcrypt' '--with-pdo- mysql=mysqlnd' '--with-mysql=mysqlnd' '--enable-mysqlnd' '--enable-debug' Expected result: no memory leaks Actual result: -- [09-Jan-2013 16:40:10] WARNING: [pool www] child 2332 said into stderr: "Last leak repeated 608 times" [09-Jan-2013 16:40:10] WARNING: [pool www] child 2332 said into stderr: "[Wed Jan 9 16:40:10 2013] Script: '-'" [09-Jan-2013 16:40:10] WARNING: [pool www] child 2332 said into stderr: "/root/soft/phpall/cache/APC-3.1.13/apc_zend.c(38) : Freeing 0x19D020A8 (25 bytes), script=-" [09-Jan-2013 16:40:10] WARNING: [pool www] child 2332 said into stderr: "Last leak repeated 4958 times" [09-Jan-2013 16:40:10] WARNING: [pool www] child 2332 said into stderr: "[Wed Jan 9 16:40:10 2013] Script: '-'" [09-Jan-2013 16:40:10] WARNING: [pool www] child 2332 said into stderr: "/root/soft/phpall/cache/APC-3.1.13/apc_compile.c(219) : Freeing 0x19D086A0 (32 bytes), script=-" [09-Jan-2013 16:40:10] WARNING: [pool www] child 2332 said into stderr: "Last leak repeated 55 times" [09-Jan-2013 16:40:10] WARNING: [pool www] child 2332 said into stderr: "[Wed Jan 9 16:40:10 2013] Script: '-'" [09-Jan-2013 16:40:10] WARNING: [pool www] child 2332 said into stderr: "/root/soft/phpall/php-5.4.10/Zend/zend_hash.c(324) : Freeing 0x19D08890 (72 bytes), script=-" [09-Jan-2013 16:40:10] WARNING: [pool www] child 2332 said into stderr: "Last leak repeated 941 times" [09-Jan-2013 16:40:10] WARNING: [pool www] child 2332 said into stderr: "[Wed Jan 9 16:40:10 2013] Script: '-'" [09-Jan-2013 16:40:10] WARNING: [pool www] child 2332 said into stderr: "/root/soft/phpall/php-5.4.10/Zend/zend_compile.c(114) : Freeing 0x19D08B80 (70 bytes), script=-" [09-Jan-2013 16:40:10] WARNING: [pool www] child 2332 said into stderr: "Last leak repeated 200 times" [09-Jan-2013 16:40:10] WARNING: [pool www] child 2332 said into stderr: "[Wed Jan 9 16:40:10 2013] Script: '-'" [09-Jan-2013 16:40:10] WARNING: [pool www] child 2332 said into stderr: "/root/soft/phpall/cache/APC-3.1.13/apc_compile.c(1787) : Freeing 0x19D0A140 (240 bytes), script=-" [09-Jan-2013 16:40:10] WARNING: [pool www] child 2332 said into stderr: "Last leak repeated 1486 times" [09-Jan-2013 16:40:10] WARNING: [pool www] child 2332 said into stderr: "[Wed Jan 9 16:40:10 2013] Script: '-'" [09-Jan-2013 16:40:10] WARNING: [pool www] child 2332 said into stderr: "/root/soft/phpall/php-5.4.10/Zend/zend_hash.c(893) : Freeing 0x19D0CF18 (64 bytes), script=-" [09-Jan-2013 16:40:10] WARNING: [pool www] child 2332 said into stderr: "/root/soft/phpall/php-5.4.10/Zend/zend_hash.c(339) : Actual location (location was relayed)" [09-Jan-2013 16:40:10] WARNING: [pool www] child 2332 said into stderr: "Last leak repeated 908 times" [09-Jan-2013 16:40:10] WARNING: [pool www] child 2332 said into stderr: "[Wed Jan 9 16:40:10 2013] Script: '-'" [09-Jan-2013 16:40:10] WARNING: [pool www] child 2332 said into stderr: "/root/soft/phpall/php-5.4.10/Zend/zend_hash.c(450) : Freeing 0x19CCD2B8 (128 bytes), script=-" [09-Jan-2013 16:40:10] WARNING: [pool www] child 2332 said into stderr: "Last leak repeated 32 times" [09-Jan-2013 16:40:10] WARNING: [pool www] child 2332 said into stderr: "[Wed Jan 9 16:40:10 2013] Script: '-'" [09-Jan-2013 16:40:10] WARNING: [pool www] child 2332 said into stderr: "/root/soft/phpall/php-5.4.10/Zend/zend_compile.c(2867) : Freeing 0x19CDF848 (240 bytes),
Bug #63950 [Com]: Lot's of memory leaks detected
Edit report at https://bugs.php.net/bug.php?id=63950&edit=1 ID: 63950 Comment by: hufeng1987 at gmail dot com Reported by:hufeng1987 at gmail dot com Summary:Lot's of memory leaks detected Status: Feedback Type: Bug Package:FPM related Operating System: CentOS 5.8 PHP Version:5.4.10 Block user comment: N Private report: N New Comment: i hope i could locate which code occurred these leak. but i failed because it run's too much more code. million lines of code running. any suggestion help me find out the bad code? i tried my hard to find it out ,but still got nothing. -- [09-Jan-2013 16:49:52.459798] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "/root/soft/phpall/php- 5.4.10/Zend/zend_hash.c(339) : Actual location (location was relayed)" [09-Jan-2013 16:49:52.459810] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "Last leak repeated 849 times" [09-Jan-2013 16:49:52.459822] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "[Wed Jan 9 16:49:52 2013] Script: '-'" [09-Jan-2013 16:49:52.459835] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "/root/soft/phpall/cache/APC- 3.1.13/apc_compile.c(219) : Freeing 0x100EF5C0 (32 bytes), script=-" [09-Jan-2013 16:49:52.459848] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "Last leak repeated 53 times" [09-Jan-2013 16:49:52.459860] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "[Wed Jan 9 16:49:52 2013] Script: '-'" [09-Jan-2013 16:49:52.459872] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "/root/soft/phpall/php- 5.4.10/Zend/zend_compile.c(114) : Freeing 0x100F0648 (54 bytes), script=-" [09-Jan-2013 16:49:52.459885] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "Last leak repeated 182 times" [09-Jan-2013 16:49:52.459897] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "[Wed Jan 9 16:49:52 2013] Script: '-'" [09-Jan-2013 16:49:52.459909] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "/root/soft/phpall/php- 5.4.10/Zend/zend_compile.c(2867) : Freeing 0x100F17C8 (240 bytes), script=-" [09-Jan-2013 16:49:52.459924] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "/root/soft/phpall/php- 5.4.10/Zend/zend_hash.c(236) : Actual location (location was relayed)" [09-Jan-2013 16:49:52.459935] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "Last leak repeated 9 times" [09-Jan-2013 16:49:52.459947] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "[Wed Jan 9 16:49:52 2013] Script: '-'" [09-Jan-2013 16:49:52.459958] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "/root/soft/phpall/php- 5.4.10/Zend/zend_hash.c(450) : Freeing 0x100F29B0 (128 bytes), script=-" [09-Jan-2013 16:49:52.459969] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "Last leak repeated 29 times" [09-Jan-2013 16:49:52.459980] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "[Wed Jan 9 16:49:52 2013] Script: '-'" [09-Jan-2013 16:49:52.459991] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "/root/soft/phpall/php- 5.4.10/Zend/zend_vm_execute.h(380) : Freeing 0x100F4198 (56 bytes), script=-" [09-Jan-2013 16:49:52.460002] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "/root/soft/phpall/php- 5.4.10/Zend/zend_alloc.c(2529) : Actual location (location was relayed)" [09-Jan-2013 16:49:52.460013] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "Last leak repeated 471 times" [09-Jan-2013 16:49:52.460024] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "[Wed Jan 9 16:49:52 2013] Script: '-'" [09-Jan-2013 16:49:52.460035] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "/root/soft/phpall/php- 5.4.10/Zend/zend_compile.c(3309)
Bug #63950 [Com]: Lot's of memory leaks detected
Edit report at https://bugs.php.net/bug.php?id=63950&edit=1 ID: 63950 Comment by: hufeng1987 at gmail dot com Reported by:hufeng1987 at gmail dot com Summary:Lot's of memory leaks detected Status: Feedback Type: Bug Package:FPM related Operating System: CentOS 5.8 PHP Version:5.4.10 Block user comment: N Private report: N New Comment: i found following log -- ==3523== ==3523== HEAP SUMMARY: ==3523== in use at exit: 1,712 bytes in 15 blocks ==3523== total heap usage: 997,631 allocs, 997,616 frees, 333,021,308 bytes allocated ==3523== ==3523== Searching for pointers to 15 not-freed blocks ==3523== Checked 966,304 bytes ==3523== ==3523== 96 (16 direct, 80 indirect) bytes in 1 blocks are definitely lost in loss record 10 of 15 ==3523==at 0x4A0610C: malloc (vg_replace_malloc.c:195) ==3523==by 0x8CDA128: ??? ==3523==by 0x8CF21A9: ??? ==3523==by 0x8CDD617: ??? ==3523==by 0x8CDE041: ??? ==3523==by 0x99D775: zend_startup_module_ex (zend_API.c:1661) ==3523==by 0x9A96D2: zend_hash_apply (zend_hash.c:716) ==3523==by 0x99DCBB: zend_startup_modules (zend_API.c:1788) ==3523==by 0x8FDEC1: php_module_startup (main.c:2200) ==3523==by 0xAFAA5B: php_cli_startup (php_cli.c:414) ==3523==by 0xAFD368: main (php_cli.c:1344) ==3523== ==3523== LEAK SUMMARY: ==3523==definitely lost: 16 bytes in 1 blocks ==3523==indirectly lost: 80 bytes in 1 blocks ==3523== possibly lost: 0 bytes in 0 blocks ==3523==still reachable: 1,616 bytes in 13 blocks ==3523== suppressed: 0 bytes in 0 blocks ==3523== Reachable blocks (those to which a pointer was found) are not shown. ==3523== To see them, rerun with: --leak-check=full --show-reachable=yes ==3523== ==3523== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 33 from 6) --3523-- --3523-- used_suppression: 29 zlib-1.2.x trickyness (1a): See http://www.zlib.net/zlib_faq.html#faq36 --3523-- used_suppression: 4 dl-hack3 ==3523== ==3523== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 33 from 6) Previous Comments: [2013-01-09 08:57:51] paj...@php.net An easy way to provide more info is to run php under valgrind. It could help to locate the issue (for obvious ones). But at the end we may need something to reproduce it. [2013-01-09 08:52:53] hufeng1987 at gmail dot com i hope i could locate which code occurred these leak. but i failed because it run's too much more code. million lines of code running. any suggestion help me find out the bad code? i tried my hard to find it out ,but still got nothing. -- [09-Jan-2013 16:49:52.459798] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "/root/soft/phpall/php- 5.4.10/Zend/zend_hash.c(339) : Actual location (location was relayed)" [09-Jan-2013 16:49:52.459810] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "Last leak repeated 849 times" [09-Jan-2013 16:49:52.459822] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "[Wed Jan 9 16:49:52 2013] Script: '-'" [09-Jan-2013 16:49:52.459835] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "/root/soft/phpall/cache/APC- 3.1.13/apc_compile.c(219) : Freeing 0x100EF5C0 (32 bytes), script=-" [09-Jan-2013 16:49:52.459848] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "Last leak repeated 53 times" [09-Jan-2013 16:49:52.459860] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "[Wed Jan 9 16:49:52 2013] Script: '-'" [09-Jan-2013 16:49:52.459872] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "/root/soft/phpall/php- 5.4.10/Zend/zend_compile.c(114) : Freeing 0x100F0648 (54 bytes), script=-" [09-Jan-2013 16:49:52.459885] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "Last leak repeated 182 times" [09-Jan-2013 16:49:52.459897] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "[Wed Jan 9 16:49:52 2013] Script: '-'" [09-Jan-2013 16:49:52.459909] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "/root/soft/phpall/php- 5.4.10/Zend/zend_compile.c(2867) : Freeing 0x100
Bug #63950 [Com]: Lot's of memory leaks detected
Edit report at https://bugs.php.net/bug.php?id=63950&edit=1 ID: 63950 Comment by: hufeng1987 at gmail dot com Reported by:hufeng1987 at gmail dot com Summary:Lot's of memory leaks detected Status: Feedback Type: Bug Package:FPM related Operating System: CentOS 5.8 PHP Version:5.4.10 Block user comment: N Private report: N New Comment: it's this APC bug? some times it cause PHP segmentation fault Previous Comments: [2013-01-09 15:44:21] ras...@php.net The Valgrind output looks normal. There are a couple of intentional at-exit leaks in APC. These are not relevant since they aren't per-request. It is simply memory only allocated at process startup and not freed, relying instead on process exit to clear it. [2013-01-09 09:10:52] hufeng1987 at gmail dot com i found following log -- ==3523== ==3523== HEAP SUMMARY: ==3523== in use at exit: 1,712 bytes in 15 blocks ==3523== total heap usage: 997,631 allocs, 997,616 frees, 333,021,308 bytes allocated ==3523== ==3523== Searching for pointers to 15 not-freed blocks ==3523== Checked 966,304 bytes ==3523== ==3523== 96 (16 direct, 80 indirect) bytes in 1 blocks are definitely lost in loss record 10 of 15 ==3523==at 0x4A0610C: malloc (vg_replace_malloc.c:195) ==3523==by 0x8CDA128: ??? ==3523==by 0x8CF21A9: ??? ==3523==by 0x8CDD617: ??? ==3523==by 0x8CDE041: ??? ==3523==by 0x99D775: zend_startup_module_ex (zend_API.c:1661) ==3523==by 0x9A96D2: zend_hash_apply (zend_hash.c:716) ==3523==by 0x99DCBB: zend_startup_modules (zend_API.c:1788) ==3523==by 0x8FDEC1: php_module_startup (main.c:2200) ==3523==by 0xAFAA5B: php_cli_startup (php_cli.c:414) ==3523==by 0xAFD368: main (php_cli.c:1344) ==3523== ==3523== LEAK SUMMARY: ==3523==definitely lost: 16 bytes in 1 blocks ==3523==indirectly lost: 80 bytes in 1 blocks ==3523== possibly lost: 0 bytes in 0 blocks ==3523==still reachable: 1,616 bytes in 13 blocks ==3523== suppressed: 0 bytes in 0 blocks ==3523== Reachable blocks (those to which a pointer was found) are not shown. ==3523== To see them, rerun with: --leak-check=full --show-reachable=yes ==3523== ==3523== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 33 from 6) --3523-- --3523-- used_suppression: 29 zlib-1.2.x trickyness (1a): See http://www.zlib.net/zlib_faq.html#faq36 --3523-- used_suppression: 4 dl-hack3 ==3523== ==3523== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 33 from 6) [2013-01-09 08:57:51] paj...@php.net An easy way to provide more info is to run php under valgrind. It could help to locate the issue (for obvious ones). But at the end we may need something to reproduce it. [2013-01-09 08:52:53] hufeng1987 at gmail dot com i hope i could locate which code occurred these leak. but i failed because it run's too much more code. million lines of code running. any suggestion help me find out the bad code? i tried my hard to find it out ,but still got nothing. -- [09-Jan-2013 16:49:52.459798] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "/root/soft/phpall/php- 5.4.10/Zend/zend_hash.c(339) : Actual location (location was relayed)" [09-Jan-2013 16:49:52.459810] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "Last leak repeated 849 times" [09-Jan-2013 16:49:52.459822] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "[Wed Jan 9 16:49:52 2013] Script: '-'" [09-Jan-2013 16:49:52.459835] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "/root/soft/phpall/cache/APC- 3.1.13/apc_compile.c(219) : Freeing 0x100EF5C0 (32 bytes), script=-" [09-Jan-2013 16:49:52.459848] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "Last leak repeated 53 times" [09-Jan-2013 16:49:52.459860] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "[Wed Jan 9 16:49:52 2013] Script: '-'" [09-Jan-2013 16:49:52.459872] WARNING: pid 2813, fpm_stdio_child_said(), line 166: [pool www] child 2815 said into stderr: "/root/soft/phpall/php- 5.4.10/Zend/zend_compile.c(114) : Freeing 0x100F0648 (54 by
Bug #63950 [Fbk->Opn]: Lot's of memory leaks detected
Edit report at https://bugs.php.net/bug.php?id=63950&edit=1 ID: 63950 User updated by:hufeng1987 at gmail dot com Reported by:hufeng1987 at gmail dot com Summary:Lot's of memory leaks detected -Status: Feedback +Status: Open Type: Bug Package:FPM related Operating System: CentOS 5.8 PHP Version:5.4.10 Block user comment: N Private report: N New Comment: i have configured the core dump environment. still waiting for the core dump. it's not always segfault, i hope i could catch it . I want to ask, if some code cause php segfault, it's code's problem or the php's problem? should we fixed it by change the code ? or need to fixed by php upstream? Previous Comments: [2013-01-10 04:42:43] larue...@php.net could you please give us the backtrace of the segfault you mentioned? ---- [2013-01-09 23:52:53] hufeng1987 at gmail dot com it's this APC bug? some times it cause PHP segmentation fault [2013-01-09 15:44:21] ras...@php.net The Valgrind output looks normal. There are a couple of intentional at-exit leaks in APC. These are not relevant since they aren't per-request. It is simply memory only allocated at process startup and not freed, relying instead on process exit to clear it. -------- [2013-01-09 09:10:52] hufeng1987 at gmail dot com i found following log -- ==3523== ==3523== HEAP SUMMARY: ==3523== in use at exit: 1,712 bytes in 15 blocks ==3523== total heap usage: 997,631 allocs, 997,616 frees, 333,021,308 bytes allocated ==3523== ==3523== Searching for pointers to 15 not-freed blocks ==3523== Checked 966,304 bytes ==3523== ==3523== 96 (16 direct, 80 indirect) bytes in 1 blocks are definitely lost in loss record 10 of 15 ==3523==at 0x4A0610C: malloc (vg_replace_malloc.c:195) ==3523==by 0x8CDA128: ??? ==3523==by 0x8CF21A9: ??? ==3523==by 0x8CDD617: ??? ==3523==by 0x8CDE041: ??? ==3523==by 0x99D775: zend_startup_module_ex (zend_API.c:1661) ==3523==by 0x9A96D2: zend_hash_apply (zend_hash.c:716) ==3523==by 0x99DCBB: zend_startup_modules (zend_API.c:1788) ==3523==by 0x8FDEC1: php_module_startup (main.c:2200) ==3523==by 0xAFAA5B: php_cli_startup (php_cli.c:414) ==3523==by 0xAFD368: main (php_cli.c:1344) ==3523== ==3523== LEAK SUMMARY: ==3523==definitely lost: 16 bytes in 1 blocks ==3523==indirectly lost: 80 bytes in 1 blocks ==3523== possibly lost: 0 bytes in 0 blocks ==3523==still reachable: 1,616 bytes in 13 blocks ==3523== suppressed: 0 bytes in 0 blocks ==3523== Reachable blocks (those to which a pointer was found) are not shown. ==3523== To see them, rerun with: --leak-check=full --show-reachable=yes ==3523== ==3523== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 33 from 6) --3523-- --3523-- used_suppression: 29 zlib-1.2.x trickyness (1a): See http://www.zlib.net/zlib_faq.html#faq36 --3523-- used_suppression: 4 dl-hack3 ==3523== ==3523== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 33 from 6) [2013-01-09 08:57:51] paj...@php.net An easy way to provide more info is to run php under valgrind. It could help to locate the issue (for obvious ones). But at the end we may need something to reproduce it. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63950 -- Edit this bug report at https://bugs.php.net/bug.php?id=63950&edit=1
Bug #63950 [Com]: Lot's of memory leaks detected
Edit report at https://bugs.php.net/bug.php?id=63950&edit=1 ID: 63950 Comment by: hufeng1987 at gmail dot com Reported by:hufeng1987 at gmail dot com Summary:Lot's of memory leaks detected Status: Feedback Type: Bug Package:FPM related Operating System: CentOS 5.8 PHP Version:5.4.10 Block user comment: N Private report: N New Comment: After disabled APC extension. the memory leaks reporting stopped. what is the matter? we really need APC , production environment need APC to boost the PHP performanceï¼ Previous Comments: [2013-01-10 05:58:00] paj...@php.net Disable APC and try again, that will clear this last question. [2013-01-10 05:10:48] larue...@php.net it depends on what the codes is, and whether it is a known issue. [2013-01-10 04:46:55] hufeng1987 at gmail dot com i have configured the core dump environment. still waiting for the core dump. it's not always segfault, i hope i could catch it . I want to ask, if some code cause php segfault, it's code's problem or the php's problem? should we fixed it by change the code ? or need to fixed by php upstream? [2013-01-10 04:42:43] larue...@php.net could you please give us the backtrace of the segfault you mentioned? ---- [2013-01-09 23:52:53] hufeng1987 at gmail dot com it's this APC bug? some times it cause PHP segmentation fault 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=63950 -- Edit this bug report at https://bugs.php.net/bug.php?id=63950&edit=1
Bug #63950 [Com]: Lot's of memory leaks detected
Edit report at https://bugs.php.net/bug.php?id=63950&edit=1 ID: 63950 Comment by: hufeng1987 at gmail dot com Reported by:hufeng1987 at gmail dot com Summary:Lot's of memory leaks detected Status: Feedback Type: Bug Package:FPM related Operating System: CentOS 5.8 PHP Version:5.4.10 Block user comment: N Private report: N New Comment: I tried upgrade apc to 3.1.14. but failed at make test - = TIME END 2013-01-10 14:34:30 = TEST RESULT SUMMARY - Exts skipped:0 Exts tested : 42 - Number of tests : 5655 Tests skipped :1 ( 1.8%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:6 ( 10.7%) ( 10.9%) Expected fail :0 ( 0.0%) ( 0.0%) Tests passed: 49 ( 87.5%) ( 89.1%) - Time taken : 39 seconds = = FAILED TEST SUMMARY - APC: classes with namespaces (php 5.3) [tests/apc53_001.phpt] APC: global spaces (php 5.3) [tests/apc53_002.phpt] APC: closures (php 5.3) [tests/apc53_004.phpt] APC: apc_store/fetch with objects [tests/apc_002.phpt] APC: apc_store/fetch with objects (php 5.3) [tests/apc_003b.phpt] APC: APCIterator formats [tests/iterator_006.phpt] = You may have found a problem in PHP. This report can be automatically sent to the PHP QA team at http://qa.php.net/reports and http://news.php.net/php.qa.reports This gives us a better understanding of PHP's behavior. If you don't want to send the report immediately you can choose option "s" to save it. You can then email it to qa-repo...@lists.php.net later. Do you want to send this report now? [Yns]: Y Please enter your email address. (Your address will be mangled so that it will not go out on any mailinglist in plain text): hufeng1...@gmail.com Posting to http://qa.php.net/buildtest-process.php Thank you for helping to make PHP better. Previous Comments: ---- [2013-01-10 06:23:05] hufeng1987 at gmail dot com After disabled APC extension. the memory leaks reporting stopped. what is the matter? we really need APC , production environment need APC to boost the PHP performanceï¼ [2013-01-10 05:58:00] paj...@php.net Disable APC and try again, that will clear this last question. [2013-01-10 05:10:48] larue...@php.net it depends on what the codes is, and whether it is a known issue. ---- [2013-01-10 04:46:55] hufeng1987 at gmail dot com i have configured the core dump environment. still waiting for the core dump. it's not always segfault, i hope i could catch it . I want to ask, if some code cause php segfault, it's code's problem or the php's problem? should we fixed it by change the code ? or need to fixed by php upstream? [2013-01-10 04:42:43] larue...@php.net could you please give us the backtrace of the segfault you mentioned? 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=63950 -- Edit this bug report at https://bugs.php.net/bug.php?id=63950&edit=1
[PHP-BUG] Bug #63964 [NEW]: PHP 5.4.10 build with clang 3.2 failed
From: hufeng1987 at gmail dot com Operating system: CentOS 5.8 PHP version: 5.4.10 Package: *General Issues Bug Type: Bug Bug description:PHP 5.4.10 build with clang 3.2 failed Description: when i try to build PHP 5.4.10 using clang 3.2 , i got failed in the compile progress. Actual result: -- /usr/data/php-5.4.10/sapi/cli/php_cli_server.c:(.text+0x240): multiple definition of `strtod' ext/date/php_date.o:/usr/data/php-5.4.10/ext/date/php_date.c:(.text+0x0): first defined here sapi/cli/php_cli_server.o: In function `strtof': /usr/data/php-5.4.10/sapi/cli/php_cli_server.c:(.text+0x2d0): multiple definition of `strtof' ext/date/php_date.o:/usr/data/php-5.4.10/ext/date/php_date.c:(.text+0x90): first defined here sapi/cli/php_cli_server.o: In function `strtol': /usr/data/php-5.4.10/sapi/cli/php_cli_server.c:(.text+0x270): multiple definition of `strtol' ext/date/php_date.o:/usr/data/php-5.4.10/ext/date/php_date.c:(.text+0x30): first defined here sapi/cli/php_cli_server.o: In function `strtold': /usr/data/php-5.4.10/sapi/cli/php_cli_server.c:(.text+0x300): multiple definition of `strtold' ext/date/php_date.o:/usr/data/php-5.4.10/ext/date/php_date.c:(.text+0xc0): first defined here sapi/cli/php_cli_server.o: In function `strtoll': /usr/data/php-5.4.10/sapi/cli/php_cli_server.c:(.text+0x390): multiple definition of `strtoll' ext/date/php_date.o:/usr/data/php-5.4.10/ext/date/php_date.c:(.text+0x150): first defined here sapi/cli/php_cli_server.o: In function `strtoq': /usr/data/php-5.4.10/sapi/cli/php_cli_server.c:(.text+0x330): multiple definition of `strtoq' ext/date/php_date.o:/usr/data/php-5.4.10/ext/date/php_date.c:(.text+0xf0): first defined here sapi/cli/php_cli_server.o: In function `strtoul': /usr/data/php-5.4.10/sapi/cli/php_cli_server.c:(.text+0x2a0): multiple definition of `strtoul' ext/date/php_date.o:/usr/data/php-5.4.10/ext/date/php_date.c:(.text+0x60): first defined here sapi/cli/php_cli_server.o: In function `strtoull': /usr/data/php-5.4.10/sapi/cli/php_cli_server.c:(.text+0x3c0): multiple definition of `strtoull' ext/date/php_date.o:/usr/data/php-5.4.10/ext/date/php_date.c:(.text+0x180): first defined here sapi/cli/php_cli_server.o: In function `strtouq': /usr/data/php-5.4.10/sapi/cli/php_cli_server.c:(.text+0x360): multiple definition of `strtouq' ext/date/php_date.o:/usr/data/php-5.4.10/ext/date/php_date.c:(.text+0x120): first defined here sapi/cli/php_cli_server.o: In function `tolower': /usr/data/php-5.4.10/sapi/cli/php_cli_server.c:(.text+0x910): multiple definition of `tolower' ext/date/php_date.o:/usr/data/php-5.4.10/ext/date/php_date.c:(.text+0x810): first defined here sapi/cli/php_cli_server.o: In function `toupper': /usr/data/php-5.4.10/sapi/cli/php_cli_server.c:(.text+0x940): multiple definition of `toupper' ext/date/php_date.o:/usr/data/php-5.4.10/ext/date/php_date.c:(.text+0x840): first defined here sapi/cli/php_cli_server.o: In function `vprintf': /usr/data/php-5.4.10/sapi/cli/php_cli_server.c:(.text+0x0): multiple definition of `vprintf' ext/date/php_date.o:/usr/data/php-5.4.10/ext/date/php_date.c:(.text+0x620): first defined here clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [sapi/cli/php] Error 1 -- Edit bug report at https://bugs.php.net/bug.php?id=63964&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63964&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63964&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63964&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63964&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63964&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63964&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63964&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63964&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63964&r=support Expected behavior: https://bugs.php.net/fix.php?id=63964&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63964&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63964&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63964&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63964&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63964&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63964&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63964&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63964&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63964&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63964&r=mysqlcfg
Bug #63964 [Com]: PHP 5.4.10 build with clang 3.2 failed
Edit report at https://bugs.php.net/bug.php?id=63964&edit=1 ID: 63964 Comment by: hufeng1987 at gmail dot com Reported by:hufeng1987 at gmail dot com Summary:PHP 5.4.10 build with clang 3.2 failed Status: Open Type: Bug Package:*General Issues Operating System: CentOS 5.8 PHP Version:5.4.10 Block user comment: N Private report: N New Comment: ./configure --enable-inline-optimization --enable-mbstring --with-mysql --with- zlib --with-pdo-pgsql --with-bz2 --enable-zip --enable-fpm --with-mcrypt --with-gd --with-openssl --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd --with-pcre-dir -- with-curl --with-pear --with-freetype-dir=/usr/lib --without-pdo-sqlite --without- sqlite3 Previous Comments: [2013-01-11 07:38:21] hufeng1987 at gmail dot com Description: when i try to build PHP 5.4.10 using clang 3.2 , i got failed in the compile progress. Actual result: -- /usr/data/php-5.4.10/sapi/cli/php_cli_server.c:(.text+0x240): multiple definition of `strtod' ext/date/php_date.o:/usr/data/php-5.4.10/ext/date/php_date.c:(.text+0x0): first defined here sapi/cli/php_cli_server.o: In function `strtof': /usr/data/php-5.4.10/sapi/cli/php_cli_server.c:(.text+0x2d0): multiple definition of `strtof' ext/date/php_date.o:/usr/data/php-5.4.10/ext/date/php_date.c:(.text+0x90): first defined here sapi/cli/php_cli_server.o: In function `strtol': /usr/data/php-5.4.10/sapi/cli/php_cli_server.c:(.text+0x270): multiple definition of `strtol' ext/date/php_date.o:/usr/data/php-5.4.10/ext/date/php_date.c:(.text+0x30): first defined here sapi/cli/php_cli_server.o: In function `strtold': /usr/data/php-5.4.10/sapi/cli/php_cli_server.c:(.text+0x300): multiple definition of `strtold' ext/date/php_date.o:/usr/data/php-5.4.10/ext/date/php_date.c:(.text+0xc0): first defined here sapi/cli/php_cli_server.o: In function `strtoll': /usr/data/php-5.4.10/sapi/cli/php_cli_server.c:(.text+0x390): multiple definition of `strtoll' ext/date/php_date.o:/usr/data/php-5.4.10/ext/date/php_date.c:(.text+0x150): first defined here sapi/cli/php_cli_server.o: In function `strtoq': /usr/data/php-5.4.10/sapi/cli/php_cli_server.c:(.text+0x330): multiple definition of `strtoq' ext/date/php_date.o:/usr/data/php-5.4.10/ext/date/php_date.c:(.text+0xf0): first defined here sapi/cli/php_cli_server.o: In function `strtoul': /usr/data/php-5.4.10/sapi/cli/php_cli_server.c:(.text+0x2a0): multiple definition of `strtoul' ext/date/php_date.o:/usr/data/php-5.4.10/ext/date/php_date.c:(.text+0x60): first defined here sapi/cli/php_cli_server.o: In function `strtoull': /usr/data/php-5.4.10/sapi/cli/php_cli_server.c:(.text+0x3c0): multiple definition of `strtoull' ext/date/php_date.o:/usr/data/php-5.4.10/ext/date/php_date.c:(.text+0x180): first defined here sapi/cli/php_cli_server.o: In function `strtouq': /usr/data/php-5.4.10/sapi/cli/php_cli_server.c:(.text+0x360): multiple definition of `strtouq' ext/date/php_date.o:/usr/data/php-5.4.10/ext/date/php_date.c:(.text+0x120): first defined here sapi/cli/php_cli_server.o: In function `tolower': /usr/data/php-5.4.10/sapi/cli/php_cli_server.c:(.text+0x910): multiple definition of `tolower' ext/date/php_date.o:/usr/data/php-5.4.10/ext/date/php_date.c:(.text+0x810): first defined here sapi/cli/php_cli_server.o: In function `toupper': /usr/data/php-5.4.10/sapi/cli/php_cli_server.c:(.text+0x940): multiple definition of `toupper' ext/date/php_date.o:/usr/data/php-5.4.10/ext/date/php_date.c:(.text+0x840): first defined here sapi/cli/php_cli_server.o: In function `vprintf': /usr/data/php-5.4.10/sapi/cli/php_cli_server.c:(.text+0x0): multiple definition of `vprintf' ext/date/php_date.o:/usr/data/php-5.4.10/ext/date/php_date.c:(.text+0x620): first defined here clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [sapi/cli/php] Error 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=63964&edit=1
