Bug #65088 [Com]: Generated configure script is malformed on OpenBSD
Edit report at https://bugs.php.net/bug.php?id=65088edit=1 ID: 65088 Comment by: glen at delfi dot ee Reported by:stolen dot data dot net at gmail dot com Summary:Generated configure script is malformed on OpenBSD Status: Closed Type: Bug Package:Compile Failure Operating System: OpenBSD 5.3 (possibly all BSDs) PHP Version:5.5.0 Assigned To:aharvey Block user comment: N Private report: N New Comment: this is actually old bug going back to 2006, fixed in pld, but seems never reached php.net http://git.pld-linux.org/? p=packages/php.git;a=commitdiff;h=0c510837964981255f8f3bdb0bd9473d404770a1 pld uses (used) pdksh as well at that time Previous Comments: [2013-06-23 18:07:42] ahar...@php.net Automatic comment on behalf of aharvey Revision: http://git.php.net/?p=php-src.git;a=commit;h=2531307be601b95a4aac38dc26dd2d27112b9291 Log: Fix bug #65088 (Generated configure script is malformed on OpenBSD). [2013-06-23 18:01:03] ahar...@php.net Editing the summary so that the news entry is more obvious. [2013-06-23 17:41:42] ahar...@php.net Terrific; thanks for that. I'll run a couple more tests quickly, and assuming they're OK, will push this. [2013-06-23 16:32:13] stolen dot data dot net at gmail dot com Backslash-escaping the quotes seems to be the issue, turning the quotes into literals causing broken substitution on both sh, ksh and bash. sdata@antikythera$ cd /home/sdata pwd /home/sdata sdata@antikythera$ cd /home/\sdata\ pwd ksh: cd: /home/sdata - No such file or directory [2013-06-23 16:14:25] stolen dot data dot net at gmail dot com Yes, I understand the quotation has to be reworked rather than removed (quick'n'dirty) - aharvey's supplied patch that changed the manner of quotation solved the problem, by the way. No modifications have been done to my sh binary, and same goes for my environment with the exception of setting LC_CTYPE to get proper UTF-8 support. The problem is identical whether I run the vanilla configure or the rebuilt one, without arguments, or with the arguments I use for my PHP build. I reported this problem already with PHP 5.4.0 on OpenBSD 5.0 - the PHP 5.3 branch did not show this problem on OpenBSD 5.0 or any other earlier version that I've been running for years, all of which use an unmodified environment. Quoting portion of a path - cd /some/path/somewhere - works just fine straight off the shell with sh, ksh and bash, just like expected. I tested this already over a year ago when when I found this issue the first time. Why it fails when executed inside the configure script confused me already back then. 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=65088 -- Edit this bug report at https://bugs.php.net/bug.php?id=65088edit=1
Bug #63228 [Csd]: -Werror=format-security error in lsapi code
Edit report at https://bugs.php.net/bug.php?id=63228edit=1 ID: 63228 User updated by:glen at delfi dot ee Reported by:glen at delfi dot ee Summary:-Werror=format-security error in lsapi code Status: Closed Type: Bug Package:Compile Failure PHP Version:5.4.7 Assigned To:gwang Block user comment: N Private report: N New Comment: thanks! finally! Previous Comments: [2013-01-08 03:48:42] ahar...@php.net Cherry picked and remerged, since this was clearly intended for 5.4: https://github.com/php/php-src/commit/9c52d09ebc62683f26338123bcda8068f162541d This has missed 5.4.11, but should be in PHP 5.4.12. [2013-01-08 03:47:43] ahar...@php.net Automatic comment on behalf of gwang Revision: http://git.php.net/?p=php-src.git;a=commit;h=9c52d09ebc62683f26338123bcda8068f162541d Log: sapi/litespeed/lsapi_main.c: Fix bug #63228 [2012-12-29 14:28:36] glen at delfi dot ee this is idiotic already. why are you closing this bug with description it is fixed when it is not?! as wrigint of this note (2012-12-29), downloads page says: PHP 5.4.10 (Current stable) Complete Source Code PHP 5.4.10 (tar.bz2) [10,885Kb] - 20 Dec 2012 md5: cb716b657a30570b9b468b9e7bc551a1 and the patch is NOT APPLIED in that release even if you commit is included in php repo, THE COMMIT IS NOT APPEARING in 5.4 series. re-merge the commit or cherry pick it! last commit to the file in 5.4 is 4 months ago, while your commit is 3 months old https://github.com/php/php-src/blob/PHP-5.4.10/sapi/litespeed/lsapi_main.c https://github.com/php/php-src/commits/PHP-5.4.10/sapi/litespeed/lsapi_main.c http://i.imgur.com/uqlx3.png [2012-12-28 17:04:44] gw...@php.net Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php [2012-12-18 07:39:31] glen at delfi dot ee step by step proof that it's not fixed: $ wget http://php.net/get/php-5.4.9.tar.bz2/from/this/mirror -O php- 5.4.9.tar.bz2 $ tar xjf php-5.4.9.tar.bz2 $ grep -n usage php-5.4.9/sapi/litespeed/lsapi_main.c 586:static void cli_usage( TSRMLS_D ) 588:static const char * usage = 606:php_printf( usage ); 744:cli_usage(TSRMLS_C); 788:cli_usage(TSRMLS_C); 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=63228 -- Edit this bug report at https://bugs.php.net/bug.php?id=63228edit=1
Bug #63228 [Csd-Asn]: -Werror=format-security error in lsapi code
Edit report at https://bugs.php.net/bug.php?id=63228edit=1 ID: 63228 User updated by:glen at delfi dot ee Reported by:glen at delfi dot ee Summary:-Werror=format-security error in lsapi code -Status: Closed +Status: Assigned Type: Bug Package:Compile Failure PHP Version:5.4.7 Assigned To:gwang Block user comment: N Private report: N New Comment: this is idiotic already. why are you closing this bug with description it is fixed when it is not?! as wrigint of this note (2012-12-29), downloads page says: PHP 5.4.10 (Current stable) Complete Source Code PHP 5.4.10 (tar.bz2) [10,885Kb] - 20 Dec 2012 md5: cb716b657a30570b9b468b9e7bc551a1 and the patch is NOT APPLIED in that release even if you commit is included in php repo, THE COMMIT IS NOT APPEARING in 5.4 series. re-merge the commit or cherry pick it! last commit to the file in 5.4 is 4 months ago, while your commit is 3 months old https://github.com/php/php-src/blob/PHP-5.4.10/sapi/litespeed/lsapi_main.c https://github.com/php/php-src/commits/PHP-5.4.10/sapi/litespeed/lsapi_main.c http://i.imgur.com/uqlx3.png Previous Comments: [2012-12-28 17:04:44] gw...@php.net Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php [2012-12-18 07:39:31] glen at delfi dot ee step by step proof that it's not fixed: $ wget http://php.net/get/php-5.4.9.tar.bz2/from/this/mirror -O php- 5.4.9.tar.bz2 $ tar xjf php-5.4.9.tar.bz2 $ grep -n usage php-5.4.9/sapi/litespeed/lsapi_main.c 586:static void cli_usage( TSRMLS_D ) 588:static const char * usage = 606:php_printf( usage ); 744:cli_usage(TSRMLS_C); 788:cli_usage(TSRMLS_C); [2012-12-17 17:57:50] glen at delfi dot ee hey! this is not funny! the commit is not appearing in 5.4.9 release tarball either, please reply where did you commit the fix instead closing it again silently... [2012-11-16 18:01:01] gw...@php.net Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php [2012-11-09 09:24:45] glen at delfi dot ee code still not fixed in 5.4.8, what branch did you fix?! :o 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=63228 -- Edit this bug report at https://bugs.php.net/bug.php?id=63228edit=1
Bug #63228 [Csd-Asn]: -Werror=format-security error in lsapi code
Edit report at https://bugs.php.net/bug.php?id=63228edit=1 ID: 63228 User updated by:glen at delfi dot ee Reported by:glen at delfi dot ee Summary:-Werror=format-security error in lsapi code -Status: Closed +Status: Assigned Type: Bug Package:Compile Failure PHP Version:5.4.7 Assigned To:gwang Block user comment: N Private report: N New Comment: hey! this is not funny! the commit is not appearing in 5.4.9 release tarball either, please reply where did you commit the fix instead closing it again silently... Previous Comments: [2012-11-16 18:01:01] gw...@php.net Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php [2012-11-09 09:24:45] glen at delfi dot ee code still not fixed in 5.4.8, what branch did you fix?! :o [2012-10-12 17:30:41] gw...@php.net Automatic comment on behalf of gwang Revision: http://git.php.net/?p=php-src.git;a=commit;h=22611b8d3774cff379cc51666842ab4b8a2eaf7f Log: sapi/litespeed/lsapi_main.c: Fix bug #63228 [2012-10-06 11:11:17] glen at delfi dot ee Description: php-5.4.7/sapi/litespeed/lsapi_main.c:606:5: error: format not a string literal and no format arguments [-Werror=format-security] full log: /bin/sh /home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7/libtool -- silent --preserve-dup-deps --mode=compile ccache x86_64-pld-linux-gcc - Isapi/litespeed/ -I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php- 5.4.7/sapi/litespeed/ -DPHP_ATOM_INC - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7/include - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7/main - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7 - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7/ext/date/lib - I/usr/include/libxml2 -I/usr/include/openssl -I/usr/include/enchant - I/usr/include/freetype2 -I/usr/include/imap - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php- 5.4.7/ext/mbstring/oniguruma -I/home/users/glen/rpm/packages/BUILD.x86_64- linux/php-5.4.7/ext/mbstring/libmbfl - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php- 5.4.7/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -I/usr/include/pspell - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7/TSRM - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7/Zend - DDEBUG_FASTCGI -DHAVE_STRNDUP -I/usr/include/xmlrpc-epi -I/usr/include -O2 - fwrapv -pipe -Wformat -Werror=format-security -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector -- param=ssp-buffer-size=4 -fPIC -march=x86-64 -gdwarf-4 -fno-debug-types-section - fvar-tracking-assignments -g2 -c /home/users/glen/rpm/packages/BUILD.x86_64- linux/php-5.4.7/sapi/litespeed/lsapi_main.c -o sapi/litespeed/lsapi_main.lo /home/users/glen/rpm/packages/BUILD.x86_64-linux/php- 5.4.7/sapi/litespeed/lsapi_main.c: In function 'cli_usage': /home/users/glen/rpm/packages/BUILD.x86_64-linux/php- 5.4.7/sapi/litespeed/lsapi_main.c:606:5: error: format not a string literal and no format arguments [-Werror=format-security] cc1: some warnings being treated as errors make: *** [sapi/litespeed/lsapi_main.lo] Error 1 make: *** Waiting for unfinished jobs -- Edit this bug report at https://bugs.php.net/bug.php?id=63228edit=1
Bug #63228 [Asn]: -Werror=format-security error in lsapi code
Edit report at https://bugs.php.net/bug.php?id=63228edit=1 ID: 63228 User updated by:glen at delfi dot ee Reported by:glen at delfi dot ee Summary:-Werror=format-security error in lsapi code Status: Assigned Type: Bug Package:Compile Failure PHP Version:5.4.7 Assigned To:gwang Block user comment: N Private report: N New Comment: step by step proof that it's not fixed: $ wget http://php.net/get/php-5.4.9.tar.bz2/from/this/mirror -O php- 5.4.9.tar.bz2 $ tar xjf php-5.4.9.tar.bz2 $ grep -n usage php-5.4.9/sapi/litespeed/lsapi_main.c 586:static void cli_usage( TSRMLS_D ) 588:static const char * usage = 606:php_printf( usage ); 744:cli_usage(TSRMLS_C); 788:cli_usage(TSRMLS_C); Previous Comments: [2012-12-17 17:57:50] glen at delfi dot ee hey! this is not funny! the commit is not appearing in 5.4.9 release tarball either, please reply where did you commit the fix instead closing it again silently... [2012-11-16 18:01:01] gw...@php.net Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php [2012-11-09 09:24:45] glen at delfi dot ee code still not fixed in 5.4.8, what branch did you fix?! :o [2012-10-12 17:30:41] gw...@php.net Automatic comment on behalf of gwang Revision: http://git.php.net/?p=php-src.git;a=commit;h=22611b8d3774cff379cc51666842ab4b8a2eaf7f Log: sapi/litespeed/lsapi_main.c: Fix bug #63228 [2012-10-06 11:11:17] glen at delfi dot ee Description: php-5.4.7/sapi/litespeed/lsapi_main.c:606:5: error: format not a string literal and no format arguments [-Werror=format-security] full log: /bin/sh /home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7/libtool -- silent --preserve-dup-deps --mode=compile ccache x86_64-pld-linux-gcc - Isapi/litespeed/ -I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php- 5.4.7/sapi/litespeed/ -DPHP_ATOM_INC - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7/include - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7/main - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7 - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7/ext/date/lib - I/usr/include/libxml2 -I/usr/include/openssl -I/usr/include/enchant - I/usr/include/freetype2 -I/usr/include/imap - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php- 5.4.7/ext/mbstring/oniguruma -I/home/users/glen/rpm/packages/BUILD.x86_64- linux/php-5.4.7/ext/mbstring/libmbfl - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php- 5.4.7/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -I/usr/include/pspell - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7/TSRM - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7/Zend - DDEBUG_FASTCGI -DHAVE_STRNDUP -I/usr/include/xmlrpc-epi -I/usr/include -O2 - fwrapv -pipe -Wformat -Werror=format-security -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector -- param=ssp-buffer-size=4 -fPIC -march=x86-64 -gdwarf-4 -fno-debug-types-section - fvar-tracking-assignments -g2 -c /home/users/glen/rpm/packages/BUILD.x86_64- linux/php-5.4.7/sapi/litespeed/lsapi_main.c -o sapi/litespeed/lsapi_main.lo /home/users/glen/rpm/packages/BUILD.x86_64-linux/php- 5.4.7/sapi/litespeed/lsapi_main.c: In function 'cli_usage': /home/users/glen/rpm/packages/BUILD.x86_64-linux/php- 5.4.7/sapi/litespeed/lsapi_main.c:606:5: error: format not a string literal and no format arguments [-Werror=format-security] cc1: some warnings being treated as errors make: *** [sapi/litespeed/lsapi_main.lo] Error 1 make: *** Waiting for unfinished jobs -- Edit this bug report at https://bugs.php.net/bug.php?id=63228edit=1
Bug #63228 [Csd-Asn]: -Werror=format-security error in lsapi code
Edit report at https://bugs.php.net/bug.php?id=63228edit=1 ID: 63228 User updated by:glen at delfi dot ee Reported by:glen at delfi dot ee Summary:-Werror=format-security error in lsapi code -Status: Closed +Status: Assigned Type: Bug Package:Compile Failure PHP Version:5.4.7 Assigned To:gwang Block user comment: N Private report: N New Comment: code still not fixed in 5.4.8, what branch did you fix?! :o Previous Comments: [2012-10-12 17:30:41] gw...@php.net Automatic comment on behalf of gwang Revision: http://git.php.net/?p=php-src.git;a=commit;h=22611b8d3774cff379cc51666842ab4b8a2eaf7f Log: sapi/litespeed/lsapi_main.c: Fix bug #63228 [2012-10-06 11:11:17] glen at delfi dot ee Description: php-5.4.7/sapi/litespeed/lsapi_main.c:606:5: error: format not a string literal and no format arguments [-Werror=format-security] full log: /bin/sh /home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7/libtool -- silent --preserve-dup-deps --mode=compile ccache x86_64-pld-linux-gcc - Isapi/litespeed/ -I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php- 5.4.7/sapi/litespeed/ -DPHP_ATOM_INC - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7/include - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7/main - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7 - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7/ext/date/lib - I/usr/include/libxml2 -I/usr/include/openssl -I/usr/include/enchant - I/usr/include/freetype2 -I/usr/include/imap - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php- 5.4.7/ext/mbstring/oniguruma -I/home/users/glen/rpm/packages/BUILD.x86_64- linux/php-5.4.7/ext/mbstring/libmbfl - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php- 5.4.7/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -I/usr/include/pspell - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7/TSRM - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7/Zend - DDEBUG_FASTCGI -DHAVE_STRNDUP -I/usr/include/xmlrpc-epi -I/usr/include -O2 - fwrapv -pipe -Wformat -Werror=format-security -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector -- param=ssp-buffer-size=4 -fPIC -march=x86-64 -gdwarf-4 -fno-debug-types-section - fvar-tracking-assignments -g2 -c /home/users/glen/rpm/packages/BUILD.x86_64- linux/php-5.4.7/sapi/litespeed/lsapi_main.c -o sapi/litespeed/lsapi_main.lo /home/users/glen/rpm/packages/BUILD.x86_64-linux/php- 5.4.7/sapi/litespeed/lsapi_main.c: In function 'cli_usage': /home/users/glen/rpm/packages/BUILD.x86_64-linux/php- 5.4.7/sapi/litespeed/lsapi_main.c:606:5: error: format not a string literal and no format arguments [-Werror=format-security] cc1: some warnings being treated as errors make: *** [sapi/litespeed/lsapi_main.lo] Error 1 make: *** Waiting for unfinished jobs -- Edit this bug report at https://bugs.php.net/bug.php?id=63228edit=1
[PHP-BUG] Bug #63228 [NEW]: -Werror=format-security error in lsapi code
From: glen at delfi dot ee Operating system: PHP version: 5.4.7 Package: Compile Failure Bug Type: Bug Bug description:-Werror=format-security error in lsapi code Description: php-5.4.7/sapi/litespeed/lsapi_main.c:606:5: error: format not a string literal and no format arguments [-Werror=format-security] full log: /bin/sh /home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7/libtool -- silent --preserve-dup-deps --mode=compile ccache x86_64-pld-linux-gcc - Isapi/litespeed/ -I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php- 5.4.7/sapi/litespeed/ -DPHP_ATOM_INC - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7/include - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7/main - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7 - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7/ext/date/lib - I/usr/include/libxml2 -I/usr/include/openssl -I/usr/include/enchant - I/usr/include/freetype2 -I/usr/include/imap - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php- 5.4.7/ext/mbstring/oniguruma -I/home/users/glen/rpm/packages/BUILD.x86_64- linux/php-5.4.7/ext/mbstring/libmbfl - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php- 5.4.7/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -I/usr/include/pspell - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7/TSRM - I/home/users/glen/rpm/packages/BUILD.x86_64-linux/php-5.4.7/Zend - DDEBUG_FASTCGI -DHAVE_STRNDUP -I/usr/include/xmlrpc-epi -I/usr/include -O2 - fwrapv -pipe -Wformat -Werror=format-security -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector -- param=ssp-buffer-size=4 -fPIC -march=x86-64 -gdwarf-4 -fno-debug-types-section - fvar-tracking-assignments -g2 -c /home/users/glen/rpm/packages/BUILD.x86_64- linux/php-5.4.7/sapi/litespeed/lsapi_main.c -o sapi/litespeed/lsapi_main.lo /home/users/glen/rpm/packages/BUILD.x86_64-linux/php- 5.4.7/sapi/litespeed/lsapi_main.c: In function 'cli_usage': /home/users/glen/rpm/packages/BUILD.x86_64-linux/php- 5.4.7/sapi/litespeed/lsapi_main.c:606:5: error: format not a string literal and no format arguments [-Werror=format-security] cc1: some warnings being treated as errors make: *** [sapi/litespeed/lsapi_main.lo] Error 1 make: *** Waiting for unfinished jobs -- Edit bug report at https://bugs.php.net/bug.php?id=63228edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63228r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63228r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63228r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63228r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63228r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63228r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63228r=needscript Try newer version: https://bugs.php.net/fix.php?id=63228r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63228r=support Expected behavior: https://bugs.php.net/fix.php?id=63228r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63228r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63228r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63228r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63228r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63228r=dst IIS Stability: https://bugs.php.net/fix.php?id=63228r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63228r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63228r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63228r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63228r=mysqlcfg
[PHP-BUG] Bug #62941 [NEW]: PHP_BINARY failing test under libtool build
From: glen at delfi dot ee Operating system: PLD Linux PHP version: 5.4.6 Package: Testing related Bug Type: Bug Bug description:PHP_BINARY failing test under libtool build Description: from https://bugs.php.net/bug.php?id=54514: [2012-08-23 20:57 UTC] glen at delfi dot ee could the test be improved not to depend that values match exactly? just the existence? because when the test is run from build time (from sourcetree instead of installed tree) the binary name is .libs/something due libtool: DIFF 001+ string(62) /home/users/glen/rpm/BUILD/x86_64-linux/php-5.4.6/sapi/cli/php 001- done 002+ string(71) /home/users/glen/rpm/BUILD/x86_64-linux/php- 5.4.6/sapi/cli/.libs/lt-php -- Edit bug report at https://bugs.php.net/bug.php?id=62941edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62941r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62941r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62941r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62941r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62941r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62941r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62941r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62941r=needscript Try newer version: https://bugs.php.net/fix.php?id=62941r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62941r=support Expected behavior: https://bugs.php.net/fix.php?id=62941r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62941r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62941r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62941r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62941r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62941r=dst IIS Stability: https://bugs.php.net/fix.php?id=62941r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62941r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62941r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62941r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62941r=mysqlcfg
Req #54514 [Com]: Get php binary path during script execution
Edit report at https://bugs.php.net/bug.php?id=54514edit=1 ID: 54514 Comment by: glen at delfi dot ee Reported by:frederic dot hardy at mageekbox dot net Summary:Get php binary path during script execution Status: Closed Type: Feature/Change Request Package:PHP options/info functions PHP Version:Irrelevant Assigned To:laruence Block user comment: N Private report: N New Comment: could the test be improved not to depend that values match exactly? just the existence? because when the test is run from build time (from sourcetree instead of installed tree) the binary name is .libs/something due libtool: DIFF 001+ string(62) /home/users/glen/rpm/BUILD/x86_64-linux/php-5.4.6/sapi/cli/php 001- done 002+ string(71) /home/users/glen/rpm/BUILD/x86_64-linux/php- 5.4.6/sapi/cli/.libs/lt-php Previous Comments: [2012-01-27 19:58:44] frozenf...@php.net Documented in http://svn.php.net/viewvc?view=revisionrevision=320582 [2011-12-07 10:37:36] larue...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. implement in 5.4, thanks [2011-12-07 10:32:56] larue...@php.net Automatic comment from SVN on behalf of laruence Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=320567 Log: Implemented FR #54514 (Get php binary path during script execution). [2011-12-07 08:57:46] patrickalla...@php.net PHP does provide a path to the binary directory: PHP_BINDIR However it is true it doesn't contain the executable itself. [2011-04-12 14:11:00] frederic dot hardy at mageekbox dot net Description: Currently, PHP does not provide any solution to retrieve PHP binary path in userland. There is a workaround with some *NIX shells like bash, which provide $_, available in $_SERVER['_'] in userland. However, it's not a reliable solution (cron task, etc.), and this hack is not available on Windows. So, a constant like PHP_BINARY (similar to PHP_VERSION and other PHP_* constants) seems to be a good solution. -- Edit this bug report at https://bugs.php.net/bug.php?id=54514edit=1
Bug #52078 [Asn]: fileinode overflow test ext/standard/tests/file/fileinode_variation3.phpt
Edit report at https://bugs.php.net/bug.php?id=52078edit=1 ID: 52078 User updated by:glen at delfi dot ee Reported by:glen at delfi dot ee Summary:fileinode overflow test ext/standard/tests/file/fileinode_variation3.phpt Status: Assigned Type: Bug Package:Filesystem function related Operating System: PLD Linux PHP Version:5.3.2 Assigned To:tyrael Block user comment: N Private report: N New Comment: i could supply the patches, if i get answer WHICH WAY TO GO! a) %i in formats like in initial patch? b) PHP_INT_SIZE check, like asked in comment #3? c) something else??? Previous Comments: [2012-02-06 22:50:44] tyr...@php.net applied the original patch to the 5.4 branch also. if you can come up with patches for the other tests I can also apply then soon, if not I will try to go through the affected tests, but that will take longer. [2012-02-06 22:47:22] tyr...@php.net Automatic comment from SVN on behalf of tyrael Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=323100 Log: merging the patch from bug #52078, fixes the test on disk with huge inode size(fileinode() can overflow and return negative values there). [2012-01-20 23:56:28] glen at delfi dot ee please note that the patch provided in bug was not complete (there are more tests suffering the same deficiency), because did not get any feedback to decide to proceed further. find -name '*.phpt' | xargs grep fileinode in source tree should give ideas what more to patch (and of course all inode related functions: getmyinode, stat, ...) [2012-01-19 19:09:44] tyr...@php.net I commited the %d-%i changes to trunk and 5.3, waiting for approval to commit it to 5.4 as well, I will keep the ticket open until. http://svn.php.net/viewvc?view=revisionrevision=322460 [2012-01-17 10:18:51] tyr...@php.net I will look into merging this, thanks for the patch and the heads up. 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=52078 -- Edit this bug report at https://bugs.php.net/bug.php?id=52078edit=1
Bug #52078 [Asn]: fileinode overflow test ext/standard/tests/file/fileinode_variation3.phpt
Edit report at https://bugs.php.net/bug.php?id=52078edit=1 ID: 52078 User updated by:glen at delfi dot ee Reported by:glen at delfi dot ee Summary:fileinode overflow test ext/standard/tests/file/fileinode_variation3.phpt Status: Assigned Type: Bug Package:Filesystem function related Operating System: PLD Linux PHP Version:5.3.2 Assigned To:tyrael Block user comment: N Private report: N New Comment: please note that the patch provided in bug was not complete (there are more tests suffering the same deficiency), because did not get any feedback to decide to proceed further. find -name '*.phpt' | xargs grep fileinode in source tree should give ideas what more to patch (and of course all inode related functions: getmyinode, stat, ...) Previous Comments: [2012-01-19 19:09:44] tyr...@php.net I commited the %d-%i changes to trunk and 5.3, waiting for approval to commit it to 5.4 as well, I will keep the ticket open until. http://svn.php.net/viewvc?view=revisionrevision=322460 [2012-01-17 10:18:51] tyr...@php.net I will look into merging this, thanks for the patch and the heads up. [2011-11-05 20:49:17] glen at delfi dot ee any interest of getting it fixed? i could supply patches, if i see any interest at all on this topic from upstream [2010-12-12 21:32:27] glen at delfi dot ee as you maybe have noted, one chunk takes different approach: if (PHP_INT_SIZE == 4) die(skip this test is for 32bit platform only (inodes overflow there)); maybe should rather skip overflowing tests there? [2010-12-12 21:31:01] glen at delfi dot ee i've kept it somewhat updated here: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/php/bug-52078-fileinode.patch 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=52078 -- Edit this bug report at https://bugs.php.net/bug.php?id=52078edit=1
Bug #60226 [Csd]: segfault when calling setCAPath
Edit report at https://bugs.php.net/bug.php?id=60226edit=1
ID: 60226
User updated by:glen at delfi dot ee
Reported by:glen at delfi dot ee
Summary:segfault when calling setCAPath
Status: Closed
Type: Bug
Package:oauth
Operating System: PLD Linux
PHP Version:5.3.8
Assigned To:felipe
Block user comment: N
Private report: N
New Comment:
svn link (for reference):
http://svn.php.net/viewvc/pecl/oauth/trunk/oauth.c?
r1=318824r2=318823pathrev=318824
Previous Comments:
[2011-11-06 13:43:13] fel...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
[2011-11-05 22:03:01] glen at delfi dot ee
Description:
$ cat tests/setCAPath.php
?php
$oauth = new OAuth('1', '2', OAUTH_SIG_METHOD_HMACSHA1, OAUTH_AUTH_TYPE_URI);
$o = $oauth-setCAPath('/etc/certs/ca-certificates.crt');
error_log(set path: $o);
this program causes segfault:
Program received signal SIGSEGV, Segmentation fault.
0x404d3afa in memcpy () from /lib/tls/libc.so.6
(gdb) bt
#0 0x404d3afa in memcpy () from /lib/tls/libc.so.6
#1 0x4018e635 in _estrndup () from /usr/lib/libphp_common-5.2.17.so
#2 0x41a9be2e in zim_oauth_setCAPath (ht=18, return_value=0x405b9628,
return_value_ptr=0x0, this_ptr=0x10, return_value_used=1, tsrm_ls=0x405bb0e8)
at /home/glen/rpm/pld/BUILD/php-pecl-oauth-1.2.2/oauth.c:2125
#3 0x401c80df in execute () from /usr/lib/libphp_common-5.2.17.so
#4 0x401c772c in execute () from /usr/lib/libphp_common-5.2.17.so
#5 0x401a9fe5 in zend_execute_scripts () from /usr/lib/libphp_common-5.2.17.so
#6 0x40162aa9 in php_execute_script () from /usr/lib/libphp_common-5.2.17.so
#7 0x0804b70d in main ()
(gdb)
--
Edit this bug report at https://bugs.php.net/bug.php?id=60226edit=1
Bug #52448 [Bgs]: ext/curl/tests/curl_error_basic.phpt fail
Edit report at https://bugs.php.net/bug.php?id=52448edit=1 ID: 52448 User updated by:glen at delfi dot ee Reported by:glen at delfi dot ee Summary:ext/curl/tests/curl_error_basic.phpt fail Status: Bogus Type: Bug Package:cURL related -Operating System: PLD Linux +Operating System: PHP Version:5.3.3 Block user comment: N Private report: N New Comment: ok, seems somebody finally wake up and commited the fix: http://svn.php.net/viewvc/php/php-src/trunk/ext/curl/tests/curl_error_basic.phpt? r1=296679r2=315940 Previous Comments: [2011-08-23 07:01:16] glen at delfi dot ee nothing is fixed, the patch i proposed still can be applied and if you looked at the bugreport, the error is dependant on curl library version, so if you want to depend on curl library output strings, you should be handling different curl version outputs please DO READ the previous notes what the bug is about, DO READ the proposed patch yet here i can't unmark bogus of the bug [2011-03-21 12:28:50] cataphr...@php.net Assuming it is already fixed as nothing shows up in http://gcov.php.net/viewer.php?version=PHP_5_3func=tests. [2010-07-27 10:15:00] glen at delfi dot ee to further illustrate that the error cames from curl library and is dependant on curl library version: $ curl fakeURL curl: (6) Couldn't resolve host 'fakeURL' $ curl --version curl 7.18.2 (i686-pld-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.7m zlib/1.2.4 libidn/1.10 libssh2/0.18 Protocols: tftp ftp telnet dict ldap http file https ftps scp sftp Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz $ curl fakeURL curl: (6) Could not resolve host: fakeURL (Domain name not found) $ curl --version curl 7.21.0 (x86_64-pld-linux-gnu) libcurl/7.21.0 GnuTLS/2.10.0 zlib/1.2.5 c- ares/1.6.0 libidn/1.19 libssh2/1.2.5 librtmp/2.2e Protocols: dict file ftp ftps http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz [2010-07-27 10:09:27] glen at delfi dot ee this concrete test test for library error code when trying to connect to unresolvable host. plz look the test code. and library error string pattern has changed, so either it must be updated (like i suggested a patch), or make it support various error formats. i.e the link you gave suggested how to setup webserver for tests, but this test does not connect to test webserver! [2010-07-27 04:34:58] srina...@php.net pl. look at the test script carefully. there is instruction on how to run this test script and also available at http://wiki.php.net/qa/temp/ext/curl if this convinces u ,pl. move this bug to bogus. 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=52448 -- Edit this bug report at https://bugs.php.net/bug.php?id=52448edit=1
Bug #52078 [Opn]: fileinode overflow test ext/standard/tests/file/fileinode_variation3.phpt
Edit report at https://bugs.php.net/bug.php?id=52078edit=1 ID: 52078 User updated by:glen at delfi dot ee Reported by:glen at delfi dot ee Summary:fileinode overflow test ext/standard/tests/file/fileinode_variation3.phpt Status: Open Type: Bug Package:Filesystem function related Operating System: PLD Linux PHP Version:5.3.2 Block user comment: N Private report: N New Comment: any interest of getting it fixed? i could supply patches, if i see any interest at all on this topic from upstream Previous Comments: [2010-12-12 21:32:27] glen at delfi dot ee as you maybe have noted, one chunk takes different approach: if (PHP_INT_SIZE == 4) die(skip this test is for 32bit platform only (inodes overflow there)); maybe should rather skip overflowing tests there? [2010-12-12 21:31:01] glen at delfi dot ee i've kept it somewhat updated here: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/php/bug-52078-fileinode.patch [2010-06-13 23:38:01] glen at delfi dot ee fix package [2010-06-13 23:29:48] glen at delfi dot ee Description: fileinode overflows on filesystem where inode count is huge. it is mentioned in comment of manual as well: http://php.net/manual/en/function.fileinode.php Test script: --- $ (t=`mktemp -d`; cd $t; php -r 'var_dump(fileinode(.));'; echo $t; ls -ldi $t) int(-2051936757) /home/users/glen/tmp/tmp.zLdoithBR0 2243030539 drwx-- 2 glen users 6 Jun 14 00:26 /home/users/glen/tmp/tmp.zLdoithBR0/ Expected result: test must be fixed to expect %i instead of %d. -- Edit this bug report at https://bugs.php.net/bug.php?id=52078edit=1
[PHP-BUG] Bug #60226 [NEW]: segfault when calling setCAPath
From:
Operating system: PLD Linux
PHP version: 5.3.8
Package: oauth
Bug Type: Bug
Bug description:segfault when calling setCAPath
Description:
$ cat tests/setCAPath.php
?php
$oauth = new OAuth('1', '2', OAUTH_SIG_METHOD_HMACSHA1,
OAUTH_AUTH_TYPE_URI);
$o = $oauth-setCAPath('/etc/certs/ca-certificates.crt');
error_log(set path: $o);
this program causes segfault:
Program received signal SIGSEGV, Segmentation fault.
0x404d3afa in memcpy () from /lib/tls/libc.so.6
(gdb) bt
#0 0x404d3afa in memcpy () from /lib/tls/libc.so.6
#1 0x4018e635 in _estrndup () from /usr/lib/libphp_common-5.2.17.so
#2 0x41a9be2e in zim_oauth_setCAPath (ht=18, return_value=0x405b9628,
return_value_ptr=0x0, this_ptr=0x10, return_value_used=1,
tsrm_ls=0x405bb0e8)
at /home/glen/rpm/pld/BUILD/php-pecl-oauth-1.2.2/oauth.c:2125
#3 0x401c80df in execute () from /usr/lib/libphp_common-5.2.17.so
#4 0x401c772c in execute () from /usr/lib/libphp_common-5.2.17.so
#5 0x401a9fe5 in zend_execute_scripts () from
/usr/lib/libphp_common-5.2.17.so
#6 0x40162aa9 in php_execute_script () from
/usr/lib/libphp_common-5.2.17.so
#7 0x0804b70d in main ()
(gdb)
--
Edit bug report at https://bugs.php.net/bug.php?id=60226edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60226r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60226r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60226r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60226r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60226r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60226r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60226r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60226r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60226r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60226r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60226r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60226r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60226r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60226r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60226r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60226r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60226r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60226r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60226r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60226r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60226r=mysqlcfg
Bug #39388 [Com]: provide --with-libzip-dir configure option to allow usage of system's libzip
Edit report at https://bugs.php.net/bug.php?id=39388edit=1 ID: 39388 Comment by: glen at delfi dot ee Reported by:crrodriguez at opensuse dot org Summary:provide --with-libzip-dir configure option to allow usage of system's libzip Status: Bogus Type: Bug Package:Zip Related Operating System: Linux PHP Version:5CVS-2006-11-05 (CVS) Assigned To:pajoye Block user comment: N Private report: N New Comment: i updated the patch to really link with system libzip and not to link with libz (as that it is libzip dependency not zip ext in case of system libzip) http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/php/system-libzip.patch? sortby=date i would reformat the patch indent if there's any interest it getting applied upstream, it's currently broken indent just to get diffs better to understand (and update with new upstream changes) Previous Comments: [2011-07-20 17:40:51] crrodriguez at opensuse dot org tcallawa at redhat dot com : Great, patches look OK, will try them asap in openSUSE packages. [2011-07-20 15:54:40] tcallawa at redhat dot com It doesn't look like 0.10 will work with PHP's zip extension out of the tarball, because it is still missing some necessary features that were never upstreamed (as far as I can tell). I've worked up a patch against 0.10 that adds the necessary functionality, and sent a copy to the libzip upstream for consideration. A copy of that patch can be found here: http://spot.fedorapeople.org/libzip-0.10-php-changes.patch Then, I reworked ext/zip/config.m4 to enable an option to use libzip (the system copy). That patch is here: http://spot.fedorapeople.org/php-5.3.6-libzip.patch I couldn't figure out a good way to test for overwrite support (the bits that the first patch add), so the configure tests will pass on a system libzip without the php changes applied, but I don't think the compile will succeed (it definitely won't work properly). [2011-04-06 08:33:48] oeriksson at mandriva dot com With the recent security flaws related to libzip it's desirable to enable this option. Isn't the latest http://www.nih.at/libzip/libzip-0.10.tar.bz2 going to work fine now? [2006-11-05 19:21:28] paj...@php.net There is no need of it. And no, you should *really* not use an external library. The version bundled have more fixes and features than the released lib. Most of them are already in the libzip cvs, other not. [2006-11-05 03:50:59] crrodriguez at opensuse dot org Description: Currently there is no --with-libzip-dir to easily allow distributions to use independantly packaged system libraries. Reproduce code: --- ./configure --help | grep zip Expected result: --enable-zipInclude Zip read/write support. --with-zlib-dir=DIR zip: Set the path to libz install prefix. --with-libzip=DIR zip : path to libzip sources if not using the bundled library. Actual result: -- --enable-zipInclude Zip read/write support. --with-zlib-dir=DIR zip: Set the path to libz install prefix. -- Edit this bug report at https://bugs.php.net/bug.php?id=39388edit=1
Bug #55479 [Opn]: ext/pcntl/tests failures
Edit report at https://bugs.php.net/bug.php?id=55479edit=1 ID: 55479 User updated by:glen at delfi dot ee Reported by:glen at delfi dot ee Summary:ext/pcntl/tests failures Status: Open Type: Bug Package:PCNTL related PHP Version:5.4.0alpha3 Block user comment: N Private report: N New Comment: i wouldn't call it workaround, but rather changes needed to get tests run standalone, i.e independant what is installed in system, which is important to get tests run unaffected by environment details i agree, that support from run-tests.php side would make tests simplier. would it be needed to document the interface somewhere? should i try to make such patch? Previous Comments: [2011-09-08 09:58:27] bj...@php.net That seems like a bad workaround which would need to be repeated in many places. run-tests maybe could export an environment variable which contained proper execute command..? [2011-08-27 14:42:56] glen at delfi dot ee i.e to be independant of php version installed in system while running tests, the following args need to be told when invoking php cli inside each .phpt: $args = array(-n, -d$extension_dir, -c$inipath, ...); where $extension_dir is ./modules and $inipath ./php-temp.ini, without doing so it would read /usr/lib/php for $extension_dir and /etc/php/php.ini for $inipath [2011-08-27 14:37:43] glen at delfi dot ee err, i know all that the bug is that make test is using modules from to-be-installed path, where could be installed other version of php so the patch is to enforce currently built version of php config and modules of php-cli that is invoked from tests itself make test itself already does the php invocation properly, but invoking $PHP_TEST_EXECUTABLE from tests should do the same. i've included patch for two tests i saw failing. i would proceed in other exts if i see interest in that. is it clear what i'm saying here? maybe just look at the patch as patch says more than i'm able to explain. [2011-08-26 15:22:04] ka...@php.net From the trace it looks like you are using some old dynamically linked libraries thats compiled to a different version that the one you are using (see the APINO). Packages like PCRE and SPL should be statically compiled anyway, although I don't reckon we have any issues using dynamically loaded ones. [2011-08-22 17:05:56] glen at delfi dot ee proposed patch: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/php/bug-test-pcntl- 55479.patch 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=55479 -- Edit this bug report at https://bugs.php.net/bug.php?id=55479edit=1
Bug #55479 [Fbk-Opn]: ext/pcntl/tests failures
Edit report at https://bugs.php.net/bug.php?id=55479edit=1 ID: 55479 User updated by:glen at delfi dot ee Reported by:glen at delfi dot ee Summary:ext/pcntl/tests failures -Status: Feedback +Status: Open Type: Bug Package:PCNTL related PHP Version:5.4.0alpha3 Block user comment: N Private report: N New Comment: err, i know all that the bug is that make test is using modules from to-be-installed path, where could be installed other version of php so the patch is to enforce currently built version of php config and modules of php-cli that is invoked from tests itself make test itself already does the php invocation properly, but invoking $PHP_TEST_EXECUTABLE from tests should do the same. i've included patch for two tests i saw failing. i would proceed in other exts if i see interest in that. is it clear what i'm saying here? maybe just look at the patch as patch says more than i'm able to explain. Previous Comments: [2011-08-26 15:22:04] ka...@php.net From the trace it looks like you are using some old dynamically linked libraries thats compiled to a different version that the one you are using (see the APINO). Packages like PCRE and SPL should be statically compiled anyway, although I don't reckon we have any issues using dynamically loaded ones. [2011-08-22 17:05:56] glen at delfi dot ee proposed patch: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/php/bug-test-pcntl- 55479.patch [2011-08-22 17:03:56] glen at delfi dot ee Description: there are ext/pcntl/tests failures due it using $TEST_PHP_EXECUTABLE which uses installed php config, but tests should be self-contained and use config extensions from BUILT codebase. for example if i have installed php 5.3 and i try to run tests on 5.4 i get errors: + /usr/bin/make -j16 test EXTENSION_DIR=modules PHP_TEST_SHARED_SYSTEM_EXTENSIONS= RUN_TESTS_SETTINGS=-q ext/pcntl/tests/pcntl_exec_2.phpt --show-out Build complete. Don't forget to run 'make test'. = PHP : /home/users/glen/rpm/BUILD.i686-linux/php-5.4.0alpha3/sapi/cli/php PHP_SAPI: cli PHP_VERSION : 5.4.0alpha3 ZEND_VERSION: 2.4.0 PHP_OS : Linux - Linux carme-pld-i686 3.0.0_nogrsecurity-0.3 #1 SMP Wed Jul 27 21:17:15 CEST 2011 i686 INI actual : /home/users/glen/rpm/BUILD.i686-linux/php-5.4.0alpha3/tmp-php.ini More .INIs : CWD : /home/users/glen/rpm/BUILD.i686-linux/php-5.4.0alpha3 Extra dirs : VALGRIND: Not used = Running selected tests. TEST 1/1 [ext/pcntl/tests/pcntl_exec_2.phpt] OUT ok PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/pcre.so' - /usr/lib/php/pcre.so: undefined symbol: php_addslashes_ex in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/spl.so' - /usr/lib/php/spl.so: undefined symbol: php_pcre_replace_impl in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/session.so' - /usr/lib/php/session.so: undefined symbol: php_get_output_start_filename in Unknown on line 0 PHP Warning: PHP Startup: bcmath: Unable to initialize module Module compiled with module API=20090626 PHPcompiled with module API=20100525 These options need to match in Unknown on line 0 -- Edit this bug report at https://bugs.php.net/bug.php?id=55479edit=1
Bug #55479 [Opn]: ext/pcntl/tests failures
Edit report at https://bugs.php.net/bug.php?id=55479edit=1 ID: 55479 User updated by:glen at delfi dot ee Reported by:glen at delfi dot ee Summary:ext/pcntl/tests failures Status: Open Type: Bug Package:PCNTL related PHP Version:5.4.0alpha3 Block user comment: N Private report: N New Comment: i.e to be independant of php version installed in system while running tests, the following args need to be told when invoking php cli inside each .phpt: $args = array(-n, -d$extension_dir, -c$inipath, ...); where $extension_dir is ./modules and $inipath ./php-temp.ini, without doing so it would read /usr/lib/php for $extension_dir and /etc/php/php.ini for $inipath Previous Comments: [2011-08-27 14:37:43] glen at delfi dot ee err, i know all that the bug is that make test is using modules from to-be-installed path, where could be installed other version of php so the patch is to enforce currently built version of php config and modules of php-cli that is invoked from tests itself make test itself already does the php invocation properly, but invoking $PHP_TEST_EXECUTABLE from tests should do the same. i've included patch for two tests i saw failing. i would proceed in other exts if i see interest in that. is it clear what i'm saying here? maybe just look at the patch as patch says more than i'm able to explain. [2011-08-26 15:22:04] ka...@php.net From the trace it looks like you are using some old dynamically linked libraries thats compiled to a different version that the one you are using (see the APINO). Packages like PCRE and SPL should be statically compiled anyway, although I don't reckon we have any issues using dynamically loaded ones. [2011-08-22 17:05:56] glen at delfi dot ee proposed patch: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/php/bug-test-pcntl- 55479.patch [2011-08-22 17:03:56] glen at delfi dot ee Description: there are ext/pcntl/tests failures due it using $TEST_PHP_EXECUTABLE which uses installed php config, but tests should be self-contained and use config extensions from BUILT codebase. for example if i have installed php 5.3 and i try to run tests on 5.4 i get errors: + /usr/bin/make -j16 test EXTENSION_DIR=modules PHP_TEST_SHARED_SYSTEM_EXTENSIONS= RUN_TESTS_SETTINGS=-q ext/pcntl/tests/pcntl_exec_2.phpt --show-out Build complete. Don't forget to run 'make test'. = PHP : /home/users/glen/rpm/BUILD.i686-linux/php-5.4.0alpha3/sapi/cli/php PHP_SAPI: cli PHP_VERSION : 5.4.0alpha3 ZEND_VERSION: 2.4.0 PHP_OS : Linux - Linux carme-pld-i686 3.0.0_nogrsecurity-0.3 #1 SMP Wed Jul 27 21:17:15 CEST 2011 i686 INI actual : /home/users/glen/rpm/BUILD.i686-linux/php-5.4.0alpha3/tmp-php.ini More .INIs : CWD : /home/users/glen/rpm/BUILD.i686-linux/php-5.4.0alpha3 Extra dirs : VALGRIND: Not used = Running selected tests. TEST 1/1 [ext/pcntl/tests/pcntl_exec_2.phpt] OUT ok PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/pcre.so' - /usr/lib/php/pcre.so: undefined symbol: php_addslashes_ex in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/spl.so' - /usr/lib/php/spl.so: undefined symbol: php_pcre_replace_impl in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/session.so' - /usr/lib/php/session.so: undefined symbol: php_get_output_start_filename in Unknown on line 0 PHP Warning: PHP Startup: bcmath: Unable to initialize module Module compiled with module API=20090626 PHPcompiled with module API=20100525 These options need to match in Unknown on line 0 -- Edit this bug report at https://bugs.php.net/bug.php?id=55479edit=1
Bug #52448 [Bgs]: ext/curl/tests/curl_error_basic.phpt fail
Edit report at https://bugs.php.net/bug.php?id=52448edit=1 ID: 52448 User updated by:glen at delfi dot ee Reported by:glen at delfi dot ee Summary:ext/curl/tests/curl_error_basic.phpt fail Status: Bogus Type: Bug Package:cURL related Operating System: PLD Linux PHP Version:5.3.3 Block user comment: N Private report: N New Comment: nothing is fixed, the patch i proposed still can be applied and if you looked at the bugreport, the error is dependant on curl library version, so if you want to depend on curl library output strings, you should be handling different curl version outputs please DO READ the previous notes what the bug is about, DO READ the proposed patch yet here i can't unmark bogus of the bug Previous Comments: [2011-03-21 12:28:50] cataphr...@php.net Assuming it is already fixed as nothing shows up in http://gcov.php.net/viewer.php?version=PHP_5_3func=tests. [2010-07-27 10:15:00] glen at delfi dot ee to further illustrate that the error cames from curl library and is dependant on curl library version: $ curl fakeURL curl: (6) Couldn't resolve host 'fakeURL' $ curl --version curl 7.18.2 (i686-pld-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.7m zlib/1.2.4 libidn/1.10 libssh2/0.18 Protocols: tftp ftp telnet dict ldap http file https ftps scp sftp Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz $ curl fakeURL curl: (6) Could not resolve host: fakeURL (Domain name not found) $ curl --version curl 7.21.0 (x86_64-pld-linux-gnu) libcurl/7.21.0 GnuTLS/2.10.0 zlib/1.2.5 c- ares/1.6.0 libidn/1.19 libssh2/1.2.5 librtmp/2.2e Protocols: dict file ftp ftps http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz [2010-07-27 10:09:27] glen at delfi dot ee this concrete test test for library error code when trying to connect to unresolvable host. plz look the test code. and library error string pattern has changed, so either it must be updated (like i suggested a patch), or make it support various error formats. i.e the link you gave suggested how to setup webserver for tests, but this test does not connect to test webserver! [2010-07-27 04:34:58] srina...@php.net pl. look at the test script carefully. there is instruction on how to run this test script and also available at http://wiki.php.net/qa/temp/ext/curl if this convinces u ,pl. move this bug to bogus. [2010-07-26 20:03:16] glen at delfi dot ee Description: the curl library error string has changed, trivial patch fixes that tested with curl version = 7.21.0 DIFF 002+ Error: Could not resolve host: fakeURL (Domain name not found) 002- Error: Couldn't resolve host 'fakeURL' Test script: --- $ TEST_PHP_EXECUTABLE=$(which php) php run-tests.php --show-all ext/curl/tests/curl_error_basic.phpt = PHP : /usr/bin/php PHP_SAPI: cli PHP_VERSION : 5.3.3 ZEND_VERSION: 2.3.0 PHP_OS : Linux - Linux carme-pld-i686 2.6.34.1-3 #1 SMP Tue Jul 6 16:15:11 CEST 2010 i686 INI actual : /etc/php/php-cli.ini More .INIs : /etc/php/conf.d/PCRE.ini,/etc/php/conf.d/SPL.ini,/etc/php/conf.d/bcmath.ini,/etc/php/conf.d/bz2.ini,/etc/php/conf.d/calendar.ini,/etc/php/conf.d/ctype.ini,/etc/php/conf.d/curl.ini,/etc/php/conf.d/dba.ini,/etc/php/conf.d/dom.ini,/etc/php/conf.d/ftp.ini,/etc/php/conf.d/gd.ini,/etc/php/conf.d/gettext.ini,/etc/php/conf.d/iconv.ini,/etc/php/conf.d/imap.ini,/etc/php/conf.d/ldap.ini,/etc/php/conf.d/mbstring.ini,/etc/php/conf.d/mcrypt.ini,/etc/php/conf.d/mysql.ini,/etc/php/conf.d/openssl.ini,/etc/php/conf.d/pgsql.ini,/etc/php/conf.d/posix.ini,/etc/php/conf.d/simplexml.ini,/etc/php/conf.d/soap.ini,/etc/php/conf.d/sockets.ini,/etc/php/conf.d/tidy.ini,/etc/php/conf.d/xml.ini,/etc/php/conf.d/xmlrpc.ini,/etc/php/conf.d/zlib.ini CWD : /home/users/glen/rpm/BUILD.i686-linux/php-5.3.3 Extra dirs : VALGRIND: Not used = Running selected tests. TEST 1/1 [ext/curl/tests/curl_error_basic.phpt] SKIP ?php if (!extension_loaded(curl)) print skip; ? DONE TEST ?php /* * Prototype: string curl_error(resource $ch) * Description: Returns a clear text error message for the last cURL operation. * Source:ext/curl/interface.c * Documentation: http://wiki.php.net/qa/temp/ext/curl */ // Fake URL to trigger an error $url
[PHP-BUG] Bug #55479 [NEW]: ext/pcntl/tests failures
From: Operating system: PHP version: 5.4.0alpha3 Package: PCNTL related Bug Type: Bug Bug description:ext/pcntl/tests failures Description: there are ext/pcntl/tests failures due it using $TEST_PHP_EXECUTABLE which uses installed php config, but tests should be self-contained and use config extensions from BUILT codebase. for example if i have installed php 5.3 and i try to run tests on 5.4 i get errors: + /usr/bin/make -j16 test EXTENSION_DIR=modules PHP_TEST_SHARED_SYSTEM_EXTENSIONS= RUN_TESTS_SETTINGS=-q ext/pcntl/tests/pcntl_exec_2.phpt --show-out Build complete. Don't forget to run 'make test'. = PHP : /home/users/glen/rpm/BUILD.i686-linux/php-5.4.0alpha3/sapi/cli/php PHP_SAPI: cli PHP_VERSION : 5.4.0alpha3 ZEND_VERSION: 2.4.0 PHP_OS : Linux - Linux carme-pld-i686 3.0.0_nogrsecurity-0.3 #1 SMP Wed Jul 27 21:17:15 CEST 2011 i686 INI actual : /home/users/glen/rpm/BUILD.i686-linux/php-5.4.0alpha3/tmp-php.ini More .INIs : CWD : /home/users/glen/rpm/BUILD.i686-linux/php-5.4.0alpha3 Extra dirs : VALGRIND: Not used = Running selected tests. TEST 1/1 [ext/pcntl/tests/pcntl_exec_2.phpt] OUT ok PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/pcre.so' - /usr/lib/php/pcre.so: undefined symbol: php_addslashes_ex in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/spl.so' - /usr/lib/php/spl.so: undefined symbol: php_pcre_replace_impl in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/session.so' - /usr/lib/php/session.so: undefined symbol: php_get_output_start_filename in Unknown on line 0 PHP Warning: PHP Startup: bcmath: Unable to initialize module Module compiled with module API=20090626 PHPcompiled with module API=20100525 These options need to match in Unknown on line 0 -- Edit bug report at https://bugs.php.net/bug.php?id=55479edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55479r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55479r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55479r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55479r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55479r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55479r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55479r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55479r=needscript Try newer version: https://bugs.php.net/fix.php?id=55479r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55479r=support Expected behavior: https://bugs.php.net/fix.php?id=55479r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55479r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55479r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55479r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55479r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55479r=dst IIS Stability: https://bugs.php.net/fix.php?id=55479r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55479r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55479r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55479r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55479r=mysqlcfg
Bug #55479 [Opn]: ext/pcntl/tests failures
Edit report at https://bugs.php.net/bug.php?id=55479edit=1 ID: 55479 User updated by:glen at delfi dot ee Reported by:glen at delfi dot ee Summary:ext/pcntl/tests failures Status: Open Type: Bug Package:PCNTL related PHP Version:5.4.0alpha3 Block user comment: N Private report: N New Comment: proposed patch: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/php/bug-test-pcntl- 55479.patch Previous Comments: [2011-08-22 17:03:56] glen at delfi dot ee Description: there are ext/pcntl/tests failures due it using $TEST_PHP_EXECUTABLE which uses installed php config, but tests should be self-contained and use config extensions from BUILT codebase. for example if i have installed php 5.3 and i try to run tests on 5.4 i get errors: + /usr/bin/make -j16 test EXTENSION_DIR=modules PHP_TEST_SHARED_SYSTEM_EXTENSIONS= RUN_TESTS_SETTINGS=-q ext/pcntl/tests/pcntl_exec_2.phpt --show-out Build complete. Don't forget to run 'make test'. = PHP : /home/users/glen/rpm/BUILD.i686-linux/php-5.4.0alpha3/sapi/cli/php PHP_SAPI: cli PHP_VERSION : 5.4.0alpha3 ZEND_VERSION: 2.4.0 PHP_OS : Linux - Linux carme-pld-i686 3.0.0_nogrsecurity-0.3 #1 SMP Wed Jul 27 21:17:15 CEST 2011 i686 INI actual : /home/users/glen/rpm/BUILD.i686-linux/php-5.4.0alpha3/tmp-php.ini More .INIs : CWD : /home/users/glen/rpm/BUILD.i686-linux/php-5.4.0alpha3 Extra dirs : VALGRIND: Not used = Running selected tests. TEST 1/1 [ext/pcntl/tests/pcntl_exec_2.phpt] OUT ok PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/pcre.so' - /usr/lib/php/pcre.so: undefined symbol: php_addslashes_ex in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/spl.so' - /usr/lib/php/spl.so: undefined symbol: php_pcre_replace_impl in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/session.so' - /usr/lib/php/session.so: undefined symbol: php_get_output_start_filename in Unknown on line 0 PHP Warning: PHP Startup: bcmath: Unable to initialize module Module compiled with module API=20090626 PHPcompiled with module API=20100525 These options need to match in Unknown on line 0 -- Edit this bug report at https://bugs.php.net/bug.php?id=55479edit=1
[PHP-BUG] Bug #54500 [NEW]: remove bogus ltdl linking
From: Operating system: PLD Linux PHP version: 5.3.6 Package: mcrypt related Bug Type: Bug Bug description:remove bogus ltdl linking Description: seems mcrypt adds bogus ltdl lib to linking. this php extension does not use ltdl, it uses mcrypt_module_open from mcrypt library, and mcrypt library links with ltdl, the -lltld in php extension is clearly superfluous the original commit from 2003: http://svn.php.net/viewvc?view=revisionrevision=114195 the author there either had no clue what he was doing or the mcrypt he used for linking was broken, as even that time the php extension used no symbols from libtool's ltdl library the patch removes ltdl linking -- Edit bug report at http://bugs.php.net/bug.php?id=54500edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54500r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54500r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54500r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54500r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54500r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54500r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54500r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54500r=needscript Try newer version: http://bugs.php.net/fix.php?id=54500r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54500r=support Expected behavior: http://bugs.php.net/fix.php?id=54500r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54500r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54500r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54500r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54500r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54500r=dst IIS Stability: http://bugs.php.net/fix.php?id=54500r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54500r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54500r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54500r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54500r=mysqlcfg
Bug #54500 [Opn]: remove bogus ltdl linking
Edit report at http://bugs.php.net/bug.php?id=54500edit=1 ID: 54500 User updated by:glen at delfi dot ee Reported by:glen at delfi dot ee Summary:remove bogus ltdl linking Status: Open Type: Bug Package:mcrypt related Operating System: PLD Linux PHP Version:5.3.6 Block user comment: N Private report: N New Comment: seems the original place the -lltdl snipped in is here: http://svn.php.net/viewvc?view=revisionrevision=30132 if that's any help for accepting patch Previous Comments: [2011-04-09 16:28:46] glen at delfi dot ee Description: seems mcrypt adds bogus ltdl lib to linking. this php extension does not use ltdl, it uses mcrypt_module_open from mcrypt library, and mcrypt library links with ltdl, the -lltld in php extension is clearly superfluous the original commit from 2003: http://svn.php.net/viewvc?view=revisionrevision=114195 the author there either had no clue what he was doing or the mcrypt he used for linking was broken, as even that time the php extension used no symbols from libtool's ltdl library the patch removes ltdl linking -- Edit this bug report at http://bugs.php.net/bug.php?id=54500edit=1
[PHP-BUG] Bug #54221 [NEW]: mysqli::get_warnings segfault when used in multi queries
From:
Operating system:
PHP version: 5.3.5
Package: MySQLi related
Bug Type: Bug
Bug description:mysqli::get_warnings segfault when used in multi queries
Description:
http://php.net/manual/en/mysqli.get-warnings.php
can't use mysqli::get_warnings with multi queries reliably as it will get
either
segfault or empty result.
the code is supposed to print 2 times warning:
Warning: 1050: Table 'a' already exists
Warning: 1050: Table 'a' already exists
but instead it segfaults (PHP 5.3.5).
also if i run queries where only one warning is printed. it will not
segfault.
segfault seems to happen in -next() call.
seems is because internally this is implemented as SHOW WARNINGS query
[1]
[1] http://svn.php.net/viewvc/php/php-
src/branches/PHP_5_3/ext/mysqli/mysqli_warning.c?annotate=306939#l76
segfault must be fixed, but regarding the usage, perhaps document that you
can't
use it sanely with multi queries, due limitations of mysql protocol, as
seems it
is problem in mysql protocol, that it returns warnings only from last of
the
multi query
Test script:
---
?php
$dbh = new mysqli(null, null, null, test);
if ($dbh-connect_error) {
die('Connect Error (' . $dbh-connect_errno . ') ' .
$dbh-connect_error);
}
$create = create temporary table if not exists a (a int4);
$query = $create;$create;$create;;
if ($dbh-multi_query($query)) {
do {
$sth = $dbh-store_result();
if ($dbh-warning_count) {
$e = $dbh-get_warnings();
do {
echo Warning: $e-errno: $e-message\n;
} while ($e-next());
}
} while ($dbh-next_result());
}
?
--
Edit bug report at http://bugs.php.net/bug.php?id=54221edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54221r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54221r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54221r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54221r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54221r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54221r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54221r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54221r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54221r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54221r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54221r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54221r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54221r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54221r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54221r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54221r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54221r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54221r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54221r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54221r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54221r=mysqlcfg
Bug #48820 [Com]: ttyname_r() configure test unreliable
Edit report at http://bugs.php.net/bug.php?id=48820edit=1
ID: 48820
Comment by: glen at delfi dot ee
Reported by:arekm at maven dot pl
Summary:ttyname_r() configure test unreliable
Status: No Feedback
Type: Bug
Package:POSIX related
Operating System: Linux
PHP Version:5.2.10, 5.3.0
Block user comment: N
Private report: N
New Comment:
The simpliest explanation how to build without terminal: run your build
job from
cron daemon [1] or just use /dev/null as input to configure (as arekm
noted) to
get same result
as of php-5.3.5/ext/posix/config.m4 the detection code is still wrong.
[1] http://en.wikipedia.org/wiki/Cron
Previous Comments:
[2009-07-15 01:00:00] 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-07 18:31:30] arekm at maven dot pl
I'm building using rpm and it doesn't provide terminal as stdin to
configure - ttyname_r() check fails.
[2009-07-07 15:34:31] j...@php.net
I feel a bit stupid for asking this..but how/why do you build in non
terminal..? :)
[2009-07-06 16:22:29] arekm at maven dot pl
Description:
ttyname_r() check done in configure is wrong because it relies on doing
build on a terminal. Building on non terminal causes failure.
Reproduce code:
---
This is test taken from configure:
[arekm@t400 ~/test/3]$ more a.c
#include unistd.h
int main(int argc, char *argv[])
{
char buf[64];
return ttyname_r(0, buf, 64) ? 1 : 0;
}
[arekm@t400 ~/test/3]$ gcc a.c
[arekm@t400 ~/test/3]$ ./a.out
[arekm@t400 ~/test/3]$ echo $?
0
success - we are on a terminal
[arekm@t400 ~/test/3]$ ./a.out /dev/null
zsh: exit 1 ./a.out /dev/null
[arekm@t400 ~/test/3]$ echo $?
1
[arekm@t400 ~/test/3]$
failure - we are not on terminal
--
Edit this bug report at http://bugs.php.net/bug.php?id=48820edit=1
Bug #52078 [Opn]: fileinode overflow test ext/standard/tests/file/fileinode_variation3.phpt
Edit report at http://bugs.php.net/bug.php?id=52078edit=1 ID: 52078 User updated by:glen at delfi dot ee Reported by:glen at delfi dot ee Summary:fileinode overflow test ext/standard/tests/file/fileinode_variation3.phpt Status: Open Type: Bug Package:Filesystem function related Operating System: PLD Linux PHP Version:5.3.2 Block user comment: N Private report: N New Comment: i've kept it somewhat updated here: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/php/bug-52078-fileinode.patch Previous Comments: [2010-06-13 23:38:01] glen at delfi dot ee fix package [2010-06-13 23:29:48] glen at delfi dot ee Description: fileinode overflows on filesystem where inode count is huge. it is mentioned in comment of manual as well: http://php.net/manual/en/function.fileinode.php Test script: --- $ (t=`mktemp -d`; cd $t; php -r 'var_dump(fileinode(.));'; echo $t; ls -ldi $t) int(-2051936757) /home/users/glen/tmp/tmp.zLdoithBR0 2243030539 drwx-- 2 glen users 6 Jun 14 00:26 /home/users/glen/tmp/tmp.zLdoithBR0/ Expected result: test must be fixed to expect %i instead of %d. -- Edit this bug report at http://bugs.php.net/bug.php?id=52078edit=1
Bug #52078 [Opn]: fileinode overflow test ext/standard/tests/file/fileinode_variation3.phpt
Edit report at http://bugs.php.net/bug.php?id=52078edit=1 ID: 52078 User updated by:glen at delfi dot ee Reported by:glen at delfi dot ee Summary:fileinode overflow test ext/standard/tests/file/fileinode_variation3.phpt Status: Open Type: Bug Package:Filesystem function related Operating System: PLD Linux PHP Version:5.3.2 Block user comment: N Private report: N New Comment: as you maybe have noted, one chunk takes different approach: if (PHP_INT_SIZE == 4) die(skip this test is for 32bit platform only (inodes overflow there)); maybe should rather skip overflowing tests there? Previous Comments: [2010-12-12 21:31:01] glen at delfi dot ee i've kept it somewhat updated here: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/php/bug-52078-fileinode.patch [2010-06-13 23:38:01] glen at delfi dot ee fix package [2010-06-13 23:29:48] glen at delfi dot ee Description: fileinode overflows on filesystem where inode count is huge. it is mentioned in comment of manual as well: http://php.net/manual/en/function.fileinode.php Test script: --- $ (t=`mktemp -d`; cd $t; php -r 'var_dump(fileinode(.));'; echo $t; ls -ldi $t) int(-2051936757) /home/users/glen/tmp/tmp.zLdoithBR0 2243030539 drwx-- 2 glen users 6 Jun 14 00:26 /home/users/glen/tmp/tmp.zLdoithBR0/ Expected result: test must be fixed to expect %i instead of %d. -- Edit this bug report at http://bugs.php.net/bug.php?id=52078edit=1
[PHP-BUG] Bug #52533 [NEW]: ext/curl/tests/curl_multi_getcontent_basic3.phpt broken due php.net/robots.txt
From:
Operating system:
PHP version: 5.3.3
Package: *General Issues
Bug Type: Bug
Bug description:ext/curl/tests/curl_multi_getcontent_basic3.phpt broken due
php.net/robots.txt
Description:
ext/curl/tests/curl_multi_getcontent_basic3.phpt test is broken due
php.net/robots.txt content change.
Test script:
---
test with --show-all
=
PHP : /home/users/glen/rpm/BUILD.i686-linux/php-5.3.3/sapi/cli/php
PHP_SAPI: cli
PHP_VERSION : 5.3.3
ZEND_VERSION: 2.3.0
PHP_OS : Linux - Linux carme-pld-i686 2.6.34.1-3 #1 SMP Tue Jul 6
16:15:11 CEST 2010 i686
INI actual : /home/users/glen/rpm/BUILD.i686-linux/php-5.3.3/tmp-php.ini
More .INIs :
CWD : /home/users/glen/rpm/BUILD.i686-linux/php-5.3.3
Extra dirs :
VALGRIND: Not used
=
Running selected tests.
TEST 1/1 [ext/curl/tests/curl_multi_getcontent_basic3.phpt]
SKIP
?php
if (!extension_loaded('curl')) print 'skip';
?
DONE
TEST
?php
//CURL_MULTI_GETCONTENT TEST
//CREATE RESOURCES
$ch1=curl_init();
$ch2=curl_init();
//SET URL AND OTHER OPTIONS
curl_setopt($ch1, CURLOPT_URL, http://php.net/robots.txt;);
curl_setopt($ch2, CURLOPT_URL,
file://.dirname(__FILE__)./curl_testdata2.txt);
curl_setopt($ch1, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch2, CURLOPT_RETURNTRANSFER, true);
//CREATE MULTIPLE CURL HANDLE
$mh=curl_multi_init();
//ADD THE 2 HANDLES
curl_multi_add_handle($mh,$ch1);
curl_multi_add_handle($mh,$ch2);
//EXECUTE
$running=0;
do {
curl_multi_exec($mh,$running);
} while ($running0);
$results1=curl_multi_getcontent($ch1);
$results2=curl_multi_getcontent($ch2);
//CLOSE
curl_multi_remove_handle($mh,$ch1);
curl_multi_remove_handle($mh,$ch2);
curl_multi_close($mh);
echo $results1;
echo $results2;
?
DONE
OUT
User-agent: *
Disallow: /backend/
Disallow: /distributions/
Disallow: /stats/
Disallow: /source.php
Disallow: /search.php
Disallow: /mod.php
Disallow: /manual/add-note.php
Disallow: /harming/humans
Disallow: /ignoring/human/orders
Disallow: /harm/to/self
CURL2
DONE
EXP
User-agent: *
Disallow: /backend/
Disallow: /distributions/
Disallow: /stats/
Disallow: /source.php
Disallow: /search.php
Disallow: /mod.php
Disallow: /manual/add-note.php
CURL2
DONE
DIFF
009+
010+ Disallow: /harming/humans
011+ Disallow: /ignoring/human/orders
012+ Disallow: /harm/to/self
013+
DONE
FAIL Curl_multi_getcontent() basic test with different sources (local
file/http) [ext/curl/tests/curl_multi_getcontent_basic3.phpt]
=
Number of tests :1 1
Tests skipped :0 ( 0.0%)
Tests warned:0 ( 0.0%) ( 0.0%)
Tests failed:1 (100.0%) (100.0%)
Expected fail :0 ( 0.0%) ( 0.0%)
Tests passed:0 ( 0.0%) ( 0.0%)
-
Time taken :1 seconds
=
=
FAILED TEST SUMMARY
-
Curl_multi_getcontent() basic test with different sources (local file/http)
[ext/curl/tests/curl_multi_getcontent_basic3.phpt]
=
make: [test] Error 1 (ignored)
--
Edit bug report at http://bugs.php.net/bug.php?id=52533edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52533r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52533r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52533r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52533r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52533r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52533r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52533r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52533r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52533r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52533r=support
Expected behavior:
http
Bug #52448 [Opn]: ext/curl/tests/curl_error_basic.phpt fail
Edit report at http://bugs.php.net/bug.php?id=52448edit=1 ID: 52448 User updated by:glen at delfi dot ee Reported by:glen at delfi dot ee Summary:ext/curl/tests/curl_error_basic.phpt fail Status: Open Type: Bug Package:cURL related Operating System: PLD Linux PHP Version:5.3.3 Block user comment: N New Comment: this concrete test test for library error code when trying to connect to unresolvable host. plz look the test code. and library error string pattern has changed, so either it must be updated (like i suggested a patch), or make it support various error formats. i.e the link you gave suggested how to setup webserver for tests, but this test does not connect to test webserver! Previous Comments: [2010-07-27 04:34:58] srina...@php.net pl. look at the test script carefully. there is instruction on how to run this test script and also available at http://wiki.php.net/qa/temp/ext/curl if this convinces u ,pl. move this bug to bogus. [2010-07-26 20:03:16] glen at delfi dot ee Description: the curl library error string has changed, trivial patch fixes that tested with curl version = 7.21.0 DIFF 002+ Error: Could not resolve host: fakeURL (Domain name not found) 002- Error: Couldn't resolve host 'fakeURL' Test script: --- $ TEST_PHP_EXECUTABLE=$(which php) php run-tests.php --show-all ext/curl/tests/curl_error_basic.phpt = PHP : /usr/bin/php PHP_SAPI: cli PHP_VERSION : 5.3.3 ZEND_VERSION: 2.3.0 PHP_OS : Linux - Linux carme-pld-i686 2.6.34.1-3 #1 SMP Tue Jul 6 16:15:11 CEST 2010 i686 INI actual : /etc/php/php-cli.ini More .INIs : /etc/php/conf.d/PCRE.ini,/etc/php/conf.d/SPL.ini,/etc/php/conf.d/bcmath.ini,/etc/php/conf.d/bz2.ini,/etc/php/conf.d/calendar.ini,/etc/php/conf.d/ctype.ini,/etc/php/conf.d/curl.ini,/etc/php/conf.d/dba.ini,/etc/php/conf.d/dom.ini,/etc/php/conf.d/ftp.ini,/etc/php/conf.d/gd.ini,/etc/php/conf.d/gettext.ini,/etc/php/conf.d/iconv.ini,/etc/php/conf.d/imap.ini,/etc/php/conf.d/ldap.ini,/etc/php/conf.d/mbstring.ini,/etc/php/conf.d/mcrypt.ini,/etc/php/conf.d/mysql.ini,/etc/php/conf.d/openssl.ini,/etc/php/conf.d/pgsql.ini,/etc/php/conf.d/posix.ini,/etc/php/conf.d/simplexml.ini,/etc/php/conf.d/soap.ini,/etc/php/conf.d/sockets.ini,/etc/php/conf.d/tidy.ini,/etc/php/conf.d/xml.ini,/etc/php/conf.d/xmlrpc.ini,/etc/php/conf.d/zlib.ini CWD : /home/users/glen/rpm/BUILD.i686-linux/php-5.3.3 Extra dirs : VALGRIND: Not used = Running selected tests. TEST 1/1 [ext/curl/tests/curl_error_basic.phpt] SKIP ?php if (!extension_loaded(curl)) print skip; ? DONE TEST ?php /* * Prototype: string curl_error(resource $ch) * Description: Returns a clear text error message for the last cURL operation. * Source:ext/curl/interface.c * Documentation: http://wiki.php.net/qa/temp/ext/curl */ // Fake URL to trigger an error $url = fakeURL; echo == Testing curl_error with a fake URL ==\n; // cURL handler $ch = curl_init($url); ob_start(); // start output buffering curl_exec($ch); echo Error: . curl_error($ch); curl_close($ch); ? DONE OUT == Testing curl_error with a fake URL == Error: Could not resolve host: fakeURL (Domain name not found) DONE EXP == Testing curl_error with a fake URL == Error: Couldn't resolve host 'fakeURL' DONE DIFF 002+ Error: Could not resolve host: fakeURL (Domain name not found) 002- Error: Couldn't resolve host 'fakeURL' DONE FAIL curl_error() function - basic test for curl_error using a fake url [ext/curl/tests/curl_error_basic.phpt] = Number of tests :1 1 Tests skipped :0 ( 0.0%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:1 (100.0%) (100.0%) Expected fail :0 ( 0.0%) ( 0.0%) Tests passed:0 ( 0.0%) ( 0.0%) - Time taken :0 seconds = = FAILED TEST SUMMARY - curl_error() function - basic test for curl_error using a fake url [ext/curl/tests/curl_error_basic.phpt
Bug #52448 [Opn]: ext/curl/tests/curl_error_basic.phpt fail
Edit report at http://bugs.php.net/bug.php?id=52448edit=1 ID: 52448 User updated by:glen at delfi dot ee Reported by:glen at delfi dot ee Summary:ext/curl/tests/curl_error_basic.phpt fail Status: Open Type: Bug Package:cURL related Operating System: PLD Linux PHP Version:5.3.3 Block user comment: N New Comment: to further illustrate that the error cames from curl library and is dependant on curl library version: $ curl fakeURL curl: (6) Couldn't resolve host 'fakeURL' $ curl --version curl 7.18.2 (i686-pld-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.7m zlib/1.2.4 libidn/1.10 libssh2/0.18 Protocols: tftp ftp telnet dict ldap http file https ftps scp sftp Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz $ curl fakeURL curl: (6) Could not resolve host: fakeURL (Domain name not found) $ curl --version curl 7.21.0 (x86_64-pld-linux-gnu) libcurl/7.21.0 GnuTLS/2.10.0 zlib/1.2.5 c- ares/1.6.0 libidn/1.19 libssh2/1.2.5 librtmp/2.2e Protocols: dict file ftp ftps http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz Previous Comments: [2010-07-27 10:09:27] glen at delfi dot ee this concrete test test for library error code when trying to connect to unresolvable host. plz look the test code. and library error string pattern has changed, so either it must be updated (like i suggested a patch), or make it support various error formats. i.e the link you gave suggested how to setup webserver for tests, but this test does not connect to test webserver! [2010-07-27 04:34:58] srina...@php.net pl. look at the test script carefully. there is instruction on how to run this test script and also available at http://wiki.php.net/qa/temp/ext/curl if this convinces u ,pl. move this bug to bogus. [2010-07-26 20:03:16] glen at delfi dot ee Description: the curl library error string has changed, trivial patch fixes that tested with curl version = 7.21.0 DIFF 002+ Error: Could not resolve host: fakeURL (Domain name not found) 002- Error: Couldn't resolve host 'fakeURL' Test script: --- $ TEST_PHP_EXECUTABLE=$(which php) php run-tests.php --show-all ext/curl/tests/curl_error_basic.phpt = PHP : /usr/bin/php PHP_SAPI: cli PHP_VERSION : 5.3.3 ZEND_VERSION: 2.3.0 PHP_OS : Linux - Linux carme-pld-i686 2.6.34.1-3 #1 SMP Tue Jul 6 16:15:11 CEST 2010 i686 INI actual : /etc/php/php-cli.ini More .INIs : /etc/php/conf.d/PCRE.ini,/etc/php/conf.d/SPL.ini,/etc/php/conf.d/bcmath.ini,/etc/php/conf.d/bz2.ini,/etc/php/conf.d/calendar.ini,/etc/php/conf.d/ctype.ini,/etc/php/conf.d/curl.ini,/etc/php/conf.d/dba.ini,/etc/php/conf.d/dom.ini,/etc/php/conf.d/ftp.ini,/etc/php/conf.d/gd.ini,/etc/php/conf.d/gettext.ini,/etc/php/conf.d/iconv.ini,/etc/php/conf.d/imap.ini,/etc/php/conf.d/ldap.ini,/etc/php/conf.d/mbstring.ini,/etc/php/conf.d/mcrypt.ini,/etc/php/conf.d/mysql.ini,/etc/php/conf.d/openssl.ini,/etc/php/conf.d/pgsql.ini,/etc/php/conf.d/posix.ini,/etc/php/conf.d/simplexml.ini,/etc/php/conf.d/soap.ini,/etc/php/conf.d/sockets.ini,/etc/php/conf.d/tidy.ini,/etc/php/conf.d/xml.ini,/etc/php/conf.d/xmlrpc.ini,/etc/php/conf.d/zlib.ini CWD : /home/users/glen/rpm/BUILD.i686-linux/php-5.3.3 Extra dirs : VALGRIND: Not used = Running selected tests. TEST 1/1 [ext/curl/tests/curl_error_basic.phpt] SKIP ?php if (!extension_loaded(curl)) print skip; ? DONE TEST ?php /* * Prototype: string curl_error(resource $ch) * Description: Returns a clear text error message for the last cURL operation. * Source:ext/curl/interface.c * Documentation: http://wiki.php.net/qa/temp/ext/curl */ // Fake URL to trigger an error $url = fakeURL; echo == Testing curl_error with a fake URL ==\n; // cURL handler $ch = curl_init($url); ob_start(); // start output buffering curl_exec($ch); echo Error: . curl_error($ch); curl_close($ch); ? DONE OUT == Testing curl_error with a fake URL == Error: Could not resolve host: fakeURL (Domain name not found) DONE EXP == Testing curl_error with a fake URL == Error: Couldn't resolve host 'fakeURL' DONE DIFF 002+ Error: Could not resolve host: fakeURL (Domain name not found) 002- Error: Couldn't resolve host 'fakeURL' DONE FAIL curl_error
[PHP-BUG] Bug #52447 [NEW]: FAIL getlastmod() and others [ext/standard/tests/file/statpage.phpt]
From: Operating system: PLD Linux PHP version: 5.3.3 Package: Filesystem function related Bug Type: Bug Bug description:FAIL getlastmod() and others [ext/standard/tests/file/statpage.phpt] Description: ext/standard/tests/file/statpage.phpt test fails, apparently because getmyinode() returns false, when the script is evaluated or feed from pipe, it so returns false: $ php -r 'var_dump(getmyinode());' bool(false) $ echo '?php var_dump(getmyinode());' | php bool(false) and i suppose this is how tests are run, because the test fails: + export NO_INTERACTION=1 REPORT_EXIT_STATUS=1 MALLOC_CHECK_=2 + unset TZ LANG LC_ALL + /usr/bin/make -j16 test EXTENSION_DIR=modules PHP_TEST_SHARED_SYSTEM_EXTENSIONS= RUN_TESTS_SETTINGS=-q --show-out --show-diff ext/standard/tests/file/statpage.phpt Build complete. Don't forget to run 'make test'. = PHP : /home/users/glen/rpm/BUILD.i686-linux/php-5.3.3/sapi/cli/php PHP_SAPI: cli PHP_VERSION : 5.3.3 ZEND_VERSION: 2.3.0 PHP_OS : Linux - Linux carme-pld-i686 2.6.34.1-3 #1 SMP Tue Jul 6 16:15:11 CEST 2010 i686 INI actual : /home/users/glen/rpm/BUILD.i686-linux/php-5.3.3/tmp-php.ini More .INIs : CWD : /home/users/glen/rpm/BUILD.i686-linux/php-5.3.3 Extra dirs : VALGRIND: Not used = Running selected tests. TEST 1/1 [ext/standard/tests/file/statpage.phpt] OUT int(1280163890) bool(false) int(1009) int(22286) int(1000) Done DONE DIFF 002+ bool(false) 005- int(%d) DONE FAIL getlastmod() and others [ext/standard/tests/file/statpage.phpt] = Number of tests :1 1 Tests skipped :0 ( 0.0%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:1 (100.0%) (100.0%) Expected fail :0 ( 0.0%) ( 0.0%) Tests passed:0 ( 0.0%) ( 0.0%) - Time taken :0 seconds = = FAILED TEST SUMMARY - getlastmod() and others [ext/standard/tests/file/statpage.phpt] = $ cat ext/standard/tests/file/statpage.phpt --TEST-- getlastmod() and others --FILE-- ?php var_dump(getlastmod()); var_dump(getmyinode()); var_dump(getmyuid()); var_dump(getmypid()); var_dump(getmygid()); echo Done\n; ? --EXPECTF-- int(%d) int(%i) int(%d) int(%d) int(%d) Done so this test must be removed (at least getmyinode() from it), as it is impossible to test what inode is when script is ran from pipe, and it does not test anything useful. also, i tried to find the script in svn, but no luck, it's only present in cvs? http://svn.php.net/viewvc/php/php-src/trunk/ext/standard/tests/file/ http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/standard/tests/file/ http://svn.php.net/viewvc/php/php-src/tags/php_5_3_3/ext/standard/tests/file/ http://cvs.php.net/viewvc.cgi/php-src/ext/standard/tests/file/statpage.phpt i'd appreachiate of info how release tarballs are and where to get latest source, because snapshots from http://qa.php.net also contain the test file, not in svn web. attached is patch which removes getmyinode() and it's result from test file Expected result: test things that are testable, remove bogus tests. -- Edit bug report at http://bugs.php.net/bug.php?id=52447edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52447r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52447r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52447r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52447r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52447r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52447r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52447r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52447r=needscript Try newer version: http://bugs.php.net/fix.php?id=52447r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52447r=support Expected behavior: http://bugs.php.net/fix.php?id=52447r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52447r=notenoughinfo Submitted twice
Bug #52447 [Opn]: FAIL getlastmod() and others [ext/standard/tests/file/statpage.phpt]
Edit report at http://bugs.php.net/bug.php?id=52447edit=1 ID: 52447 User updated by:glen at delfi dot ee Reported by:glen at delfi dot ee Summary:FAIL getlastmod() and others [ext/standard/tests/file/statpage.phpt] Status: Open Type: Bug Package:Filesystem function related Operating System: PLD Linux PHP Version:5.3.3 Block user comment: N New Comment: if you retry the test, you'll see that var_dump(getlastmod()); result is growing, i.e it is actually timestamp of when the test was run, not anything actual to the test script that was run. so another patch to remove getlastmod() call an result, leaving only irrelevant things to test, i.e as said earlier, the test is to be removed whatsoever Previous Comments: [2010-07-26 19:18:40] glen at delfi dot ee Description: ext/standard/tests/file/statpage.phpt test fails, apparently because getmyinode() returns false, when the script is evaluated or feed from pipe, it so returns false: $ php -r 'var_dump(getmyinode());' bool(false) $ echo '?php var_dump(getmyinode());' | php bool(false) and i suppose this is how tests are run, because the test fails: + export NO_INTERACTION=1 REPORT_EXIT_STATUS=1 MALLOC_CHECK_=2 + unset TZ LANG LC_ALL + /usr/bin/make -j16 test EXTENSION_DIR=modules PHP_TEST_SHARED_SYSTEM_EXTENSIONS= RUN_TESTS_SETTINGS=-q --show-out --show-diff ext/standard/tests/file/statpage.phpt Build complete. Don't forget to run 'make test'. = PHP : /home/users/glen/rpm/BUILD.i686-linux/php-5.3.3/sapi/cli/php PHP_SAPI: cli PHP_VERSION : 5.3.3 ZEND_VERSION: 2.3.0 PHP_OS : Linux - Linux carme-pld-i686 2.6.34.1-3 #1 SMP Tue Jul 6 16:15:11 CEST 2010 i686 INI actual : /home/users/glen/rpm/BUILD.i686-linux/php-5.3.3/tmp-php.ini More .INIs : CWD : /home/users/glen/rpm/BUILD.i686-linux/php-5.3.3 Extra dirs : VALGRIND: Not used = Running selected tests. TEST 1/1 [ext/standard/tests/file/statpage.phpt] OUT int(1280163890) bool(false) int(1009) int(22286) int(1000) Done DONE DIFF 002+ bool(false) 005- int(%d) DONE FAIL getlastmod() and others [ext/standard/tests/file/statpage.phpt] = Number of tests :1 1 Tests skipped :0 ( 0.0%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:1 (100.0%) (100.0%) Expected fail :0 ( 0.0%) ( 0.0%) Tests passed:0 ( 0.0%) ( 0.0%) - Time taken :0 seconds = = FAILED TEST SUMMARY - getlastmod() and others [ext/standard/tests/file/statpage.phpt] = $ cat ext/standard/tests/file/statpage.phpt --TEST-- getlastmod() and others --FILE-- ?php var_dump(getlastmod()); var_dump(getmyinode()); var_dump(getmyuid()); var_dump(getmypid()); var_dump(getmygid()); echo Done\n; ? --EXPECTF-- int(%d) int(%i) int(%d) int(%d) int(%d) Done so this test must be removed (at least getmyinode() from it), as it is impossible to test what inode is when script is ran from pipe, and it does not test anything useful. also, i tried to find the script in svn, but no luck, it's only present in cvs? http://svn.php.net/viewvc/php/php-src/trunk/ext/standard/tests/file/ http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/standard/tests/file/ http://svn.php.net/viewvc/php/php-src/tags/php_5_3_3/ext/standard/tests/file/ http://cvs.php.net/viewvc.cgi/php-src/ext/standard/tests/file/statpage.phpt i'd appreachiate of info how release tarballs are and where to get latest source, because snapshots from http://qa.php.net also contain the test file, not in svn web. attached is patch which removes getmyinode() and it's result from test file Expected result: test things that are testable, remove bogus tests. -- Edit this bug report at http://bugs.php.net/bug.php?id=52447edit=1
[PHP-BUG] Bug #52448 [NEW]: ext/curl/tests/curl_error_basic.phpt fail
From: Operating system: PLD Linux PHP version: 5.3.3 Package: cURL related Bug Type: Bug Bug description:ext/curl/tests/curl_error_basic.phpt fail Description: the curl library error string has changed, trivial patch fixes that tested with curl version = 7.21.0 DIFF 002+ Error: Could not resolve host: fakeURL (Domain name not found) 002- Error: Couldn't resolve host 'fakeURL' Test script: --- $ TEST_PHP_EXECUTABLE=$(which php) php run-tests.php --show-all ext/curl/tests/curl_error_basic.phpt = PHP : /usr/bin/php PHP_SAPI: cli PHP_VERSION : 5.3.3 ZEND_VERSION: 2.3.0 PHP_OS : Linux - Linux carme-pld-i686 2.6.34.1-3 #1 SMP Tue Jul 6 16:15:11 CEST 2010 i686 INI actual : /etc/php/php-cli.ini More .INIs : /etc/php/conf.d/PCRE.ini,/etc/php/conf.d/SPL.ini,/etc/php/conf.d/bcmath.ini,/etc/php/conf.d/bz2.ini,/etc/php/conf.d/calendar.ini,/etc/php/conf.d/ctype.ini,/etc/php/conf.d/curl.ini,/etc/php/conf.d/dba.ini,/etc/php/conf.d/dom.ini,/etc/php/conf.d/ftp.ini,/etc/php/conf.d/gd.ini,/etc/php/conf.d/gettext.ini,/etc/php/conf.d/iconv.ini,/etc/php/conf.d/imap.ini,/etc/php/conf.d/ldap.ini,/etc/php/conf.d/mbstring.ini,/etc/php/conf.d/mcrypt.ini,/etc/php/conf.d/mysql.ini,/etc/php/conf.d/openssl.ini,/etc/php/conf.d/pgsql.ini,/etc/php/conf.d/posix.ini,/etc/php/conf.d/simplexml.ini,/etc/php/conf.d/soap.ini,/etc/php/conf.d/sockets.ini,/etc/php/conf.d/tidy.ini,/etc/php/conf.d/xml.ini,/etc/php/conf.d/xmlrpc.ini,/etc/php/conf.d/zlib.ini CWD : /home/users/glen/rpm/BUILD.i686-linux/php-5.3.3 Extra dirs : VALGRIND: Not used = Running selected tests. TEST 1/1 [ext/curl/tests/curl_error_basic.phpt] SKIP ?php if (!extension_loaded(curl)) print skip; ? DONE TEST ?php /* * Prototype: string curl_error(resource $ch) * Description: Returns a clear text error message for the last cURL operation. * Source:ext/curl/interface.c * Documentation: http://wiki.php.net/qa/temp/ext/curl */ // Fake URL to trigger an error $url = fakeURL; echo == Testing curl_error with a fake URL ==\n; // cURL handler $ch = curl_init($url); ob_start(); // start output buffering curl_exec($ch); echo Error: . curl_error($ch); curl_close($ch); ? DONE OUT == Testing curl_error with a fake URL == Error: Could not resolve host: fakeURL (Domain name not found) DONE EXP == Testing curl_error with a fake URL == Error: Couldn't resolve host 'fakeURL' DONE DIFF 002+ Error: Could not resolve host: fakeURL (Domain name not found) 002- Error: Couldn't resolve host 'fakeURL' DONE FAIL curl_error() function - basic test for curl_error using a fake url [ext/curl/tests/curl_error_basic.phpt] = Number of tests :1 1 Tests skipped :0 ( 0.0%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:1 (100.0%) (100.0%) Expected fail :0 ( 0.0%) ( 0.0%) Tests passed:0 ( 0.0%) ( 0.0%) - Time taken :0 seconds = = FAILED TEST SUMMARY - curl_error() function - basic test for curl_error using a fake url [ext/curl/tests/curl_error_basic.phpt] = -- Edit bug report at http://bugs.php.net/bug.php?id=52448edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52448r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52448r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52448r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52448r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52448r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52448r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52448r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52448r=needscript Try newer version: http://bugs.php.net/fix.php?id=52448r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52448r=support Expected behavior: http://bugs.php.net/fix.php?id=52448r=notwrong Not enough info: http://bugs.php.net
[PHP-BUG] Bug #52078 [NEW]: fileinode overflow test ext/standard/tests/file/fileinode_variation3.phpt
From: Operating system: PLD Linux PHP version: 5.3.2 Package: *General Issues Bug Type: Bug Bug description:fileinode overflow test ext/standard/tests/file/fileinode_variation3.phpt Description: fileinode overflows on filesystem where inode count is huge. it is mentioned in comment of manual as well: http://php.net/manual/en/function.fileinode.php Test script: --- $ (t=`mktemp -d`; cd $t; php -r 'var_dump(fileinode(.));'; echo $t; ls -ldi $t) int(-2051936757) /home/users/glen/tmp/tmp.zLdoithBR0 2243030539 drwx-- 2 glen users 6 Jun 14 00:26 /home/users/glen/tmp/tmp.zLdoithBR0/ Expected result: test must be fixed to expect %i instead of %d. -- Edit bug report at http://bugs.php.net/bug.php?id=52078edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52078r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52078r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52078r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52078r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52078r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52078r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52078r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52078r=needscript Try newer version: http://bugs.php.net/fix.php?id=52078r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52078r=support Expected behavior: http://bugs.php.net/fix.php?id=52078r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52078r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52078r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52078r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52078r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52078r=dst IIS Stability: http://bugs.php.net/fix.php?id=52078r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52078r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52078r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52078r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52078r=mysqlcfg
Bug #52078 [Opn]: fileinode overflow test ext/standard/tests/file/fileinode_variation3.phpt
Edit report at http://bugs.php.net/bug.php?id=52078edit=1 ID: 52078 User updated by: glen at delfi dot ee Reported by: glen at delfi dot ee Summary: fileinode overflow test ext/standard/tests/file/fileinode_variation3.phpt Status: Open Type: Bug -Package: *General Issues +Package: Filesystem function related Operating System: PLD Linux PHP Version: 5.3.2 New Comment: fix package Previous Comments: [2010-06-13 23:29:48] glen at delfi dot ee Description: fileinode overflows on filesystem where inode count is huge. it is mentioned in comment of manual as well: http://php.net/manual/en/function.fileinode.php Test script: --- $ (t=`mktemp -d`; cd $t; php -r 'var_dump(fileinode(.));'; echo $t; ls -ldi $t) int(-2051936757) /home/users/glen/tmp/tmp.zLdoithBR0 2243030539 drwx-- 2 glen users 6 Jun 14 00:26 /home/users/glen/tmp/tmp.zLdoithBR0/ Expected result: test must be fixed to expect %i instead of %d. -- Edit this bug report at http://bugs.php.net/bug.php?id=52078edit=1
#48697 [Csd]: mb_internal_encoding() value gets reset by parse_str()
ID: 48697
User updated by: glen at delfi dot ee
Reported By: glen at delfi dot ee
Status: Closed
Bug Type: mbstring related
Operating System: PLD Linux
PHP Version: 5.2.10
Assigned To: moriyoshi
New Comment:
blah, why you never include scm commit in the bug? would be helpful
instead have to dig myself
Previous Comments:
[2009-09-14 04:12:54] moriyo...@php.net
Changed the summary again as it turned out mb_parse_str() has nothing
to do with this.
[2009-09-14 04:11:48] moriyo...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2009-09-14 04:11:29] s...@php.net
Automatic comment from SVN on behalf of moriyoshi
Revision: http://svn.php.net/viewvc/?view=revisionrevision=288301
Log: - Looks like bug #48697 has already been fixed in RC1.
[2009-09-14 00:09:48] moriyo...@php.net
Changed summary
[2009-07-09 07:21:49] ivan1986 at list dot ru
?php
echo mb_internal_encoding().\n;
mb_internal_encoding('utf-8');
echo mb_internal_encoding().\n;
parse_str('a=1b=2');
echo mb_internal_encoding().\n;
?
ISO-8859-1
UTF-8
ISO-8859-1
must by
ISO-8859-1
UTF-8
UTF-8
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/48697
--
Edit this bug report at http://bugs.php.net/?id=48697edit=1
#48697 [Csd]: mb_internal_encoding() value gets reset by parse_str()
ID: 48697 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee Status: Closed Bug Type: mbstring related Operating System: PLD Linux PHP Version: 5.2.10 Assigned To: moriyoshi New Comment: nevermind, disregard my last post, seems commit is posted to bug, just not mailed to bug subscribers... Previous Comments: [2009-09-14 05:18:41] glen at delfi dot ee blah, why you never include scm commit in the bug? would be helpful instead have to dig myself [2009-09-14 04:12:54] moriyo...@php.net Changed the summary again as it turned out mb_parse_str() has nothing to do with this. [2009-09-14 04:11:48] moriyo...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2009-09-14 04:11:29] s...@php.net Automatic comment from SVN on behalf of moriyoshi Revision: http://svn.php.net/viewvc/?view=revisionrevision=288301 Log: - Looks like bug #48697 has already been fixed in RC1. [2009-09-14 00:09:48] moriyo...@php.net Changed summary The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/48697 -- Edit this bug report at http://bugs.php.net/?id=48697edit=1
#48697 [NEW]: mb_internal_encoding() value gets reset in process
From: glen at delfi dot ee
Operating system: PLD Linux
PHP version: 5.2.10
PHP Bug Type: mbstring related
Bug description: mb_internal_encoding() value gets reset in process
Description:
setting mbstring internal encoding with mb_internal_encoding()
function gets reset at some point with 5.2.10, and mb_strtolower()
etc that are called without implicit charset will fail. (calling
mb_strtolower() with 2 arguments will succeed.
in other speak, such code fails:
echo mb_internal_encoding(); - prints ISO-8859-1
mb_internal_encoding('UTF-8');
echo mb_internal_encoding(); - prints UTF-8
... /// some code ///
echo mb_internal_encoding(); - prints ISO-8859-1
if i set the internal encoding via php.ini (ini_set() is fine too),
then the problem does not occour. ie such code works ok:
echo mb_internal_encoding(); - prints ISO-8859-1
ini_set(mbstring.internal_encoding, 'UTF-8');
echo mb_internal_encoding(); - prints UTF-8
... /// that same code ///
echo mb_internal_encoding(); - prints UTF-8
I have not yet able to create exact php code that is exact
reproducer, but the same php code, input data to php script, it
works with 5.2.9 and when reverting this commit:
http://www.mail-archive.com/php-cvs%40lists.php.net/msg40593.html
from brief looking i see that there is some inconsistency, that one
code sets the internal encoding from php.ini and the
mb_internal_encoding() function does not update php.ini setting.
--
Edit bug report at http://bugs.php.net/?id=48697edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48697r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48697r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48697r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48697r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48697r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48697r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48697r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48697r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48697r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48697r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48697r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48697r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48697r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48697r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48697r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48697r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48697r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48697r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48697r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48697r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48697r=mysqlcfg
#47806 [NEW]: mktime should return -1 or false on invalid args, but returns 943912800
From: glen at delfi dot ee Operating system: PLD Linux PHP version: 5.2.9 PHP Bug Type: Feature/Change Request Bug description: mktime should return -1 or false on invalid args, but returns 943912800 Description: http://php.net/mktime mktime() returns the Unix timestamp of the arguments given. If the arguments are invalid, the function returns FALSE (before PHP 5.1 it returned -1). but it returns Tue Nov 30 00:00:00 1999 +0200 instead when invalid input like null (or undefined) is used: php -r 'echo mktime(0, 0, 0, null, null, null), \n;' 943912800 ok, i understand if all params are 0, then it would make sense: The number of the year, may be a two or four digit value, with values between 0-69 mapping to 2000-2069 and 70-100 to 1970-2000. On systems where time_t is a 32bit signed integer, as most common today, the valid range for year is somewhere between 1901 and 2038. However, before PHP 5.1.0 this range was limited from 1970 to 2038 on some systems (e.g. Windows). Year as 0 is 2000, Month 0 is calculated as 12 of the last year, thus it gets December and 0 December is 30 November please make using undefined variables and nulls being invalid input (so that you must cast to int, to treat empty input as 0): php -r 'echo mktime(0, 0, 0, (int )$_GET['day'], (int )$_GET['month'], (int )$_GET['year']), \n;' -- Edit bug report at http://bugs.php.net/?id=47806edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47806r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47806r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47806r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47806r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47806r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47806r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47806r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47806r=needscript Try newer version: http://bugs.php.net/fix.php?id=47806r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47806r=support Expected behavior: http://bugs.php.net/fix.php?id=47806r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47806r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47806r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47806r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47806r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47806r=dst IIS Stability: http://bugs.php.net/fix.php?id=47806r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47806r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47806r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47806r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47806r=mysqlcfg
#47678 [NEW]: sqlite3 extension fails to load if sqlite is built without --enable-load-extens
From: glen at delfi dot ee Operating system: PLD Linux PHP version: 5.3CVS-2009-03-16 (snap) PHP Bug Type: SQLite related Bug description: sqlite3 extension fails to load if sqlite is built without --enable-load-extens Description: $ php -m /dev/null PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/sqlite3.so' - /usr/lib/php/sqlite3.so: undefined symbol: sqlite3_load_extension in Unknown on line 0 Expected result: should the whole method be disabled if system sqlite doesn't support it, or rather php method return false (failure?): public bool SQLite3::loadExtension( string $shared_library) -- Edit bug report at http://bugs.php.net/?id=47678edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47678r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47678r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47678r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47678r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47678r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47678r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47678r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47678r=needscript Try newer version: http://bugs.php.net/fix.php?id=47678r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47678r=support Expected behavior: http://bugs.php.net/fix.php?id=47678r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47678r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47678r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47678r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47678r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47678r=dst IIS Stability: http://bugs.php.net/fix.php?id=47678r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47678r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47678r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47678r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47678r=mysqlcfg
#47678 [Opn]: sqlite3 extension fails to load if sqlite is built without --enable-load-extens
ID: 47678 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee Status: Open Bug Type: SQLite related Operating System: PLD Linux PHP Version: 5.3CVS-2009-03-16 (snap) New Comment: here's my patch to handle the situation: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-sqlite3-loadext.patch http://php.net/manual/en/sqlite3.loadextension.php Previous Comments: [2009-03-16 19:06:09] glen at delfi dot ee Description: $ php -m /dev/null PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/sqlite3.so' - /usr/lib/php/sqlite3.so: undefined symbol: sqlite3_load_extension in Unknown on line 0 Expected result: should the whole method be disabled if system sqlite doesn't support it, or rather php method return false (failure?): public bool SQLite3::loadExtension( string $shared_library) -- Edit this bug report at http://bugs.php.net/?id=47678edit=1
#47678 [Asn]: sqlite3 extension fails to load if sqlite is built without --enable-load-extens
ID: 47678 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee Status: Assigned Bug Type: SQLite related Operating System: PLD Linux PHP Version: 5.3CVS-2009-03-16 (snap) Assigned To: scottmac New Comment: yep, against system library (external as you said) ps: there was small typo in patch, recheck the patch if you already downloaded it. Previous Comments: [2009-03-16 19:22:19] scott...@php.net I assume you're doing this against an external library? I'll need to look at a few other things that can be possibly omitted from the standard build. [2009-03-16 19:08:21] glen at delfi dot ee here's my patch to handle the situation: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-sqlite3-loadext.patch http://php.net/manual/en/sqlite3.loadextension.php [2009-03-16 19:06:09] glen at delfi dot ee Description: $ php -m /dev/null PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/sqlite3.so' - /usr/lib/php/sqlite3.so: undefined symbol: sqlite3_load_extension in Unknown on line 0 Expected result: should the whole method be disabled if system sqlite doesn't support it, or rather php method return false (failure?): public bool SQLite3::loadExtension( string $shared_library) -- Edit this bug report at http://bugs.php.net/?id=47678edit=1
#43224 [Opn]: support real graceful reload of fastcgi
ID: 43224 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee Status: Open Bug Type: Feature/Change Request Operating System: PLD Linux PHP Version: 5.2.5RC2 Assigned To: dmitry New Comment: ping? for now the patch only makes php-fcgi to close listening socket on SIGTERM, so if it continues to run, new processes are able to spawn to the same tcp port. http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-fcgi-graceful.patch?rev=1.8 Previous Comments: [2008-07-29 09:22:33] glen at delfi dot ee Didn't know about SIGQUIT, but ok, you can keep the signal handlers, but closing listening sockets on SIGTERM does not break process managers, it will do only good. as for original behaviour, if you have some long running request running and you terminate fcgi processes with SIGTERM you can not start new fcgi processes on same tcp port (as the socket is still in use) so to summarize signal handlers would be: SIGTERM, SIGUSR1 - graceful shutdown -- listening sockets are closed, processing continues until scripts finish SIGINT, SIGQUIT (, SIGKILL) - immediate shutdown -- listening sockets are closed, processes are terminated unconditionally whether they are idle or not. [2008-07-29 09:00:33] [EMAIL PROTECTED] FastCGI PHP SAPI supports only gracefull restart initiated by SIGTERM and SIGUSR1, however you still able to terminate worker processes with sending SIGINT/SIGQUIT to process group. I'm not going to change it as it may break behavior with some FastCGI managers. [2008-06-11 11:18:40] glen at delfi dot ee hi any progress with the patch? i can confirm that it works without problems since i initially created the patch. [2007-11-09 11:42:42] glen at delfi dot ee Description: currently (checked 5.3 and 5.2) php-fcgi when receiving terminating signal, finishes the request, ie does not terminate immedately. however it does not close the socket it is listening for incoming connections. and there's no way to make the process really terminate in a nice way. ie if you really want to terminate fcgi backend processes while not caring whether the request is finished or not you can do this only by sending SIGKILL, but it might be too brutal :) for the first problem i've created patch for unix (linux) platform, few testing shows that it really works. for the second problem i'd suggest to use SIGINT for graceful restart (close listening socket, end when php processing finishes) and SIGTERM would just close listening socket and abort php processing by making the child exit itself. patch for 5.2.4 (also 5.2.5RC2): http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-fcgi-graceful.patch?only_with_tag=MAIN patch for 5.3-snap: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-fcgi-graceful.patch?only_with_tag=DEVEL -- Edit this bug report at http://bugs.php.net/?id=43224edit=1
#43224 [Fbk-Opn]: support real graceful reload of fastcgi
ID: 43224 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee -Status: Feedback +Status: Open Bug Type: Feature/Change Request Operating System: PLD Linux PHP Version: 5.2.5RC2 Assigned To: dmitry New Comment: Didn't know about SIGQUIT, but ok, you can keep the signal handlers, but closing listening sockets on SIGTERM does not break process managers, it will do only good. as for original behaviour, if you have some long running request running and you terminate fcgi processes with SIGTERM you can not start new fcgi processes on same tcp port (as the socket is still in use) so to summarize signal handlers would be: SIGTERM, SIGUSR1 - graceful shutdown -- listening sockets are closed, processing continues until scripts finish SIGINT, SIGQUIT (, SIGKILL) - immediate shutdown -- listening sockets are closed, processes are terminated unconditionally whether they are idle or not. Previous Comments: [2008-07-29 09:00:33] [EMAIL PROTECTED] FastCGI PHP SAPI supports only gracefull restart initiated by SIGTERM and SIGUSR1, however you still able to terminate worker processes with sending SIGINT/SIGQUIT to process group. I'm not going to change it as it may break behavior with some FastCGI managers. [2008-06-11 11:18:40] glen at delfi dot ee hi any progress with the patch? i can confirm that it works without problems since i initially created the patch. [2007-11-09 11:42:42] glen at delfi dot ee Description: currently (checked 5.3 and 5.2) php-fcgi when receiving terminating signal, finishes the request, ie does not terminate immedately. however it does not close the socket it is listening for incoming connections. and there's no way to make the process really terminate in a nice way. ie if you really want to terminate fcgi backend processes while not caring whether the request is finished or not you can do this only by sending SIGKILL, but it might be too brutal :) for the first problem i've created patch for unix (linux) platform, few testing shows that it really works. for the second problem i'd suggest to use SIGINT for graceful restart (close listening socket, end when php processing finishes) and SIGTERM would just close listening socket and abort php processing by making the child exit itself. patch for 5.2.4 (also 5.2.5RC2): http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-fcgi-graceful.patch?only_with_tag=MAIN patch for 5.3-snap: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-fcgi-graceful.patch?only_with_tag=DEVEL -- Edit this bug report at http://bugs.php.net/?id=43224edit=1
#43224 [Asn]: support real graceful reload of fastcgi
ID: 43224 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee Status: Assigned Bug Type: Feature/Change Request Operating System: PLD Linux PHP Version: 5.2.5RC2 Assigned To: dmitry New Comment: hi any progress with the patch? i can confirm that it works without problems since i initially created the patch. Previous Comments: [2007-11-09 11:42:42] glen at delfi dot ee Description: currently (checked 5.3 and 5.2) php-fcgi when receiving terminating signal, finishes the request, ie does not terminate immedately. however it does not close the socket it is listening for incoming connections. and there's no way to make the process really terminate in a nice way. ie if you really want to terminate fcgi backend processes while not caring whether the request is finished or not you can do this only by sending SIGKILL, but it might be too brutal :) for the first problem i've created patch for unix (linux) platform, few testing shows that it really works. for the second problem i'd suggest to use SIGINT for graceful restart (close listening socket, end when php processing finishes) and SIGTERM would just close listening socket and abort php processing by making the child exit itself. patch for 5.2.4 (also 5.2.5RC2): http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-fcgi-graceful.patch?only_with_tag=MAIN patch for 5.3-snap: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-fcgi-graceful.patch?only_with_tag=DEVEL -- Edit this bug report at http://bugs.php.net/?id=43224edit=1
#43224 [NEW]: support real graceful reload of fastcgi
From: glen at delfi dot ee Operating system: PLD Linux PHP version: 5.2.5RC2 PHP Bug Type: CGI related Bug description: support real graceful reload of fastcgi Description: currently (checked 5.3 and 5.2) php-fcgi when receiving terminating signal, finishes the request, ie does not terminate immedately. however it does not close the socket it is listening for incoming connections. and there's no way to make the process really terminate in a nice way. ie if you really want to terminate fcgi backend processes while not caring whether the request is finished or not you can do this only by sending SIGKILL, but it might be too brutal :) for the first problem i've created patch for unix (linux) platform, few testing shows that it really works. for the second problem i'd suggest to use SIGINT for graceful restart (close listening socket, end when php processing finishes) and SIGTERM would just close listening socket and abort php processing by making the child exit itself. patch for 5.2.4 (also 5.2.5RC2): http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-fcgi-graceful.patch?only_with_tag=MAIN patch for 5.3-snap: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-fcgi-graceful.patch?only_with_tag=DEVEL -- Edit bug report at http://bugs.php.net/?id=43224edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43224r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43224r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43224r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43224r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43224r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43224r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43224r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43224r=needscript Try newer version:http://bugs.php.net/fix.php?id=43224r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43224r=support Expected behavior:http://bugs.php.net/fix.php?id=43224r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43224r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43224r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43224r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43224r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43224r=dst IIS Stability:http://bugs.php.net/fix.php?id=43224r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43224r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43224r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43224r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43224r=mysqlcfg
#42952 [Fbk-Opn]: soap cache file is created with insecure permissions on some configurations
ID: 42952 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee -Status: Feedback +Status: Open Bug Type: SOAP related Operating System: PLD Linux PHP Version: 5.2.4 Assigned To: dmitry New Comment: Do you mean different SAPI's like CLI? But different SAPI's have separate php.ini file, where they can define path suitable for them (writable). And in fact i've done that in our distribution. So you consider this distribution related issue? Previous Comments: [2007-11-01 12:39:30] [EMAIL PROTECTED] I am not sure it is a good patch. The same WSDL files may be used by different users and your patch will allow access to cache only to first user. [2007-10-12 16:55:27] glen at delfi dot ee here's patch to fix the problem: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-bug-42952.patch [2007-10-12 16:53:01] glen at delfi dot ee Description: soap cache file is created with insecure permissions on some configurations: -rw-rw-rw- 1 http http 67K Oct 12 19:10 wsdl-cf39a31ae8dbd9b9899539495756434d by default cache is enabled and cache directory is set to /tmp: http://ee.php.net/manual/en/ref.soap.php #ifdef ZEND_WIN32 f = open(fn,O_CREAT|O_WRONLY|O_EXCL|O_BINARY,S_IREAD|S_IWRITE); #else f = open(fn,O_CREAT|O_WRONLY|O_EXCL|O_BINARY,S_IREAD|S_IWRITE| S_IROTH|S_IWOTH|S_IRGRP|S_IWGRP); #endif probably in shared enviroments somebody could replace cache file with evil content and cause soap requests to be sent to infectected webserver capturing user passwords logins, depending on application. Reproduce code: --- create sample wsdl.xml from: http://www.roguewave.com/support/docs/leif/leif/html/soapworxug/A-1.html $ (rm -f /tmp/wsdl-*; umask 0; strace -ff -eopen php -r '$s = new SoapClient(/tmp/wsdl.xml);' 21|grep wsdl; ls -l /tmp/wsdl-*) open(/tmp/wsdl-d3d4b363f5423ee77d7e0342af8881c7, O_RDONLY) = -1 ENOENT (No such file or directory) open(/tmp/wsdl.xml, O_RDONLY) = 5 open(/tmp/wsdl-d3d4b363f5423ee77d7e0342af8881c7, O_WRONLY|O_CREAT|O_EXCL, 0666) = 5 -rw-rw-rw- 1 glen glen 488 2007-10-12 19:50 /tmp/wsdl-d3d4b363f5423ee77d7e0342af8881c7 -- Edit this bug report at http://bugs.php.net/?id=42952edit=1
#42952 [Fbk-Opn]: soap cache file is created with insecure permissions on some configurations
ID: 42952 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee -Status: Feedback +Status: Open Bug Type: SOAP related Operating System: PLD Linux PHP Version: 5.2.4 Assigned To: dmitry New Comment: So perhaps keep user id (getuid()) in the cache filename? Previous Comments: [2007-11-01 13:32:18] [EMAIL PROTECTED] Even one SAPI in shared environment will have the same issue. If you have several php-cgi processes with different UID, only one of them will own the cache file, and all others won't be able to access it. [2007-11-01 13:10:17] glen at delfi dot ee Do you mean different SAPI's like CLI? But different SAPI's have separate php.ini file, where they can define path suitable for them (writable). And in fact i've done that in our distribution. So you consider this distribution related issue? [2007-11-01 12:39:30] [EMAIL PROTECTED] I am not sure it is a good patch. The same WSDL files may be used by different users and your patch will allow access to cache only to first user. [2007-10-12 16:55:27] glen at delfi dot ee here's patch to fix the problem: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-bug-42952.patch [2007-10-12 16:53:01] glen at delfi dot ee Description: soap cache file is created with insecure permissions on some configurations: -rw-rw-rw- 1 http http 67K Oct 12 19:10 wsdl-cf39a31ae8dbd9b9899539495756434d by default cache is enabled and cache directory is set to /tmp: http://ee.php.net/manual/en/ref.soap.php #ifdef ZEND_WIN32 f = open(fn,O_CREAT|O_WRONLY|O_EXCL|O_BINARY,S_IREAD|S_IWRITE); #else f = open(fn,O_CREAT|O_WRONLY|O_EXCL|O_BINARY,S_IREAD|S_IWRITE| S_IROTH|S_IWOTH|S_IRGRP|S_IWGRP); #endif probably in shared enviroments somebody could replace cache file with evil content and cause soap requests to be sent to infectected webserver capturing user passwords logins, depending on application. Reproduce code: --- create sample wsdl.xml from: http://www.roguewave.com/support/docs/leif/leif/html/soapworxug/A-1.html $ (rm -f /tmp/wsdl-*; umask 0; strace -ff -eopen php -r '$s = new SoapClient(/tmp/wsdl.xml);' 21|grep wsdl; ls -l /tmp/wsdl-*) open(/tmp/wsdl-d3d4b363f5423ee77d7e0342af8881c7, O_RDONLY) = -1 ENOENT (No such file or directory) open(/tmp/wsdl.xml, O_RDONLY) = 5 open(/tmp/wsdl-d3d4b363f5423ee77d7e0342af8881c7, O_WRONLY|O_CREAT|O_EXCL, 0666) = 5 -rw-rw-rw- 1 glen glen 488 2007-10-12 19:50 /tmp/wsdl-d3d4b363f5423ee77d7e0342af8881c7 -- Edit this bug report at http://bugs.php.net/?id=42952edit=1
#42952 [Opn]: soap cache file is created with insecure permissions on some configurations
ID: 42952 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee Status: Open Bug Type: SOAP related Operating System: PLD Linux PHP Version: 5.2.4 Assigned To: dmitry New Comment: That would be fine (at least not closed as bogus). Distributions are free to backport changes they like :) Previous Comments: [2007-11-01 14:14:14] [EMAIL PROTECTED] I thought about it. It may be good for php-5.3.0, but I don't like to make such change in 5.2.* [2007-11-01 14:10:02] glen at delfi dot ee So perhaps keep user id (getuid()) in the cache filename? [2007-11-01 13:32:18] [EMAIL PROTECTED] Even one SAPI in shared environment will have the same issue. If you have several php-cgi processes with different UID, only one of them will own the cache file, and all others won't be able to access it. [2007-11-01 13:10:17] glen at delfi dot ee Do you mean different SAPI's like CLI? But different SAPI's have separate php.ini file, where they can define path suitable for them (writable). And in fact i've done that in our distribution. So you consider this distribution related issue? [2007-11-01 12:39:30] [EMAIL PROTECTED] I am not sure it is a good patch. The same WSDL files may be used by different users and your patch will allow access to cache only to first user. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/42952 -- Edit this bug report at http://bugs.php.net/?id=42952edit=1
#43074 [NEW]: structure has no member named `refcount'
From: glen at delfi dot ee Operating system: PLD Linux PHP version: 5.3CVS-2007-10-23 (snap) PHP Bug Type: Compile Failure Bug description: structure has no member named `refcount' Description: /home/glen/rpm/pld/BUILD/php5.3-200710230430/ext/sybase_ct/php_sybase_ct.c: In function `php_sybase_fetch_hash': /home/glen/rpm/pld/BUILD/php5.3-200710230430/ext/sybase_ct/php_sybase_ct.c:1802: error: structure has no member named `refcount' -- Edit bug report at http://bugs.php.net/?id=43074edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43074r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43074r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43074r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43074r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43074r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43074r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43074r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43074r=needscript Try newer version:http://bugs.php.net/fix.php?id=43074r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43074r=support Expected behavior:http://bugs.php.net/fix.php?id=43074r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43074r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43074r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43074r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43074r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43074r=dst IIS Stability:http://bugs.php.net/fix.php?id=43074r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43074r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43074r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43074r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43074r=mysqlcfg
#42952 [Opn]: soap cache file is created with insecure permissions on some configurations
ID: 42952 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee Status: Open Bug Type: SOAP related Operating System: PLD Linux PHP Version: 5.2.4 New Comment: here's patch to fix the problem: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-bug-42952.patch Previous Comments: [2007-10-12 16:53:01] glen at delfi dot ee Description: soap cache file is created with insecure permissions on some configurations: -rw-rw-rw- 1 http http 67K Oct 12 19:10 wsdl-cf39a31ae8dbd9b9899539495756434d by default cache is enabled and cache directory is set to /tmp: http://ee.php.net/manual/en/ref.soap.php #ifdef ZEND_WIN32 f = open(fn,O_CREAT|O_WRONLY|O_EXCL|O_BINARY,S_IREAD|S_IWRITE); #else f = open(fn,O_CREAT|O_WRONLY|O_EXCL|O_BINARY,S_IREAD|S_IWRITE| S_IROTH|S_IWOTH|S_IRGRP|S_IWGRP); #endif probably in shared enviroments somebody could replace cache file with evil content and cause soap requests to be sent to infectected webserver capturing user passwords logins, depending on application. Reproduce code: --- create sample wsdl.xml from: http://www.roguewave.com/support/docs/leif/leif/html/soapworxug/A-1.html $ (rm -f /tmp/wsdl-*; umask 0; strace -ff -eopen php -r '$s = new SoapClient(/tmp/wsdl.xml);' 21|grep wsdl; ls -l /tmp/wsdl-*) open(/tmp/wsdl-d3d4b363f5423ee77d7e0342af8881c7, O_RDONLY) = -1 ENOENT (No such file or directory) open(/tmp/wsdl.xml, O_RDONLY) = 5 open(/tmp/wsdl-d3d4b363f5423ee77d7e0342af8881c7, O_WRONLY|O_CREAT|O_EXCL, 0666) = 5 -rw-rw-rw- 1 glen glen 488 2007-10-12 19:50 /tmp/wsdl-d3d4b363f5423ee77d7e0342af8881c7 -- Edit this bug report at http://bugs.php.net/?id=42952edit=1
#42952 [NEW]: soap cache file is created with insecure permissions on some configurations
From: glen at delfi dot ee Operating system: PLD Linux PHP version: 5.2.4 PHP Bug Type: SOAP related Bug description: soap cache file is created with insecure permissions on some configurations Description: soap cache file is created with insecure permissions on some configurations: -rw-rw-rw- 1 http http 67K Oct 12 19:10 wsdl-cf39a31ae8dbd9b9899539495756434d by default cache is enabled and cache directory is set to /tmp: http://ee.php.net/manual/en/ref.soap.php #ifdef ZEND_WIN32 f = open(fn,O_CREAT|O_WRONLY|O_EXCL|O_BINARY,S_IREAD|S_IWRITE); #else f = open(fn,O_CREAT|O_WRONLY|O_EXCL|O_BINARY,S_IREAD|S_IWRITE| S_IROTH|S_IWOTH|S_IRGRP|S_IWGRP); #endif probably in shared enviroments somebody could replace cache file with evil content and cause soap requests to be sent to infectected webserver capturing user passwords logins, depending on application. Reproduce code: --- create sample wsdl.xml from: http://www.roguewave.com/support/docs/leif/leif/html/soapworxug/A-1.html $ (rm -f /tmp/wsdl-*; umask 0; strace -ff -eopen php -r '$s = new SoapClient(/tmp/wsdl.xml);' 21|grep wsdl; ls -l /tmp/wsdl-*) open(/tmp/wsdl-d3d4b363f5423ee77d7e0342af8881c7, O_RDONLY) = -1 ENOENT (No such file or directory) open(/tmp/wsdl.xml, O_RDONLY) = 5 open(/tmp/wsdl-d3d4b363f5423ee77d7e0342af8881c7, O_WRONLY|O_CREAT|O_EXCL, 0666) = 5 -rw-rw-rw- 1 glen glen 488 2007-10-12 19:50 /tmp/wsdl-d3d4b363f5423ee77d7e0342af8881c7 -- Edit bug report at http://bugs.php.net/?id=42952edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42952r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42952r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42952r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42952r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42952r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42952r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42952r=needscript Try newer version:http://bugs.php.net/fix.php?id=42952r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42952r=support Expected behavior:http://bugs.php.net/fix.php?id=42952r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42952r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42952r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42952r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42952r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42952r=dst IIS Stability:http://bugs.php.net/fix.php?id=42952r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42952r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42952r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42952r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42952r=mysqlcfg
#41881 [NEW]: date format in microtime
From: glen at schoenung dot us
Operating system: window xp sp2
PHP version: 5.2.3
PHP Bug Type: Date/time related
Bug description: date format in microtime
Description:
the format option for microtime does not seem to work
date('H:i:s.u', microtime(true))
will return something like
23:15:12.0
with 0 always the microtime
--
Edit bug report at http://bugs.php.net/?id=41881edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41881r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41881r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41881r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41881r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41881r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41881r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41881r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41881r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41881r=support
Expected behavior:http://bugs.php.net/fix.php?id=41881r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41881r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41881r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41881r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41881r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41881r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41881r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41881r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41881r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41881r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41881r=mysqlcfg
#41611 [NEW]: xmlrpc_server_call_method() causes segfault on x86_64 platform
From: glen at delfi dot ee Operating system: PLD Linux/x86_64 PHP version: 5.2.3 PHP Bug Type: XMLRPC-EPI related Bug description: xmlrpc_server_call_method() causes segfault on x86_64 platform Description: appears there's regression or the bug was not really fixed: http://bugs.php.net/bug.php?id=25428 17:22:58 glen[pts/[EMAIL PROTECTED] ~$ php xmlrpc-segv.php Segmentation fault 17:23:00 glen[pts/[EMAIL PROTECTED] ~$ cat xmlrpc-segv.php ? $request = xmlrpc_encode_request(system.listMethods, array()); $server = xmlrpc_server_create(); echo xmlrpc_server_call_method($server, $request, false); 17:23:02 glen[pts/[EMAIL PROTECTED] ~$ php -v PHP 5.2.3 (cli) (built: Jun 1 2007 08:53:57) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies also tested: PHP 5.2.3 - x86_64 - segfault PHP 5.2.2 - x86_64 - segfault PHP 5.2.1 - x86_64 - segfault PHP 5.2.1 - x86 - no segfault PHP 5.2.3 - x86 - no segfault also tested with php5.2-200706061230 as i tought it's first response i get to the bug to try the latest snap. and the problem is still there... ./configure \ --enable-debug \ --enable-maintainer-zts \ --enable-inline-optimization \ --with-xmlrpc=shared,/usr 17:38:35 glen[pts/[EMAIL PROTECTED] BUILD/php5.2-200706061230$ gdb ./sapi/cli/php GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-pld-linux...Using host libthread_db library /lib64/tls/libthread_db.so.1. (gdb) set args -dextension=xmlrpc.so -dextension_dir=modules /home/glen/xmlrpc-segv.php (gdb) run Starting program: /home/glen/rpm/pld/BUILD/php5.2-200706061230/sapi/cli/php -dextension=xmlrpc.so -dextension_dir=modules /home/glen/xmlrpc-segv.php Program received signal SIGSEGV, Segmentation fault. 0x2ba84931164b in simplestring_addn () from /usr/lib64/libxmlrpc.so.0 (gdb) bt #0 0x2ba84931164b in simplestring_addn () from /usr/lib64/libxmlrpc.so.0 #1 0x2ba84931224f in xml_elem_serialize_to_stream () from /usr/lib64/libxmlrpc.so.0 #2 0x003e6bf064cc in XML_GetFeatureList () from /usr/lib64/libexpat.so.0 #3 0x003e6bf0593d in XML_GetFeatureList () from /usr/lib64/libexpat.so.0 #4 0x003e6bf0843d in XML_GetFeatureList () from /usr/lib64/libexpat.so.0 #5 0x003e6bf0824b in XML_GetFeatureList () from /usr/lib64/libexpat.so.0 #6 0x003e6bf051b3 in XML_ParseBuffer () from /usr/lib64/libexpat.so.0 #7 0x003e6bf0511f in XML_Parse () from /usr/lib64/libexpat.so.0 #8 0x2ba8493123c0 in xml_elem_parse_buf () from /usr/lib64/libxmlrpc.so.0 #9 0x2ba849315163 in XMLRPC_REQUEST_FromXML () from /usr/lib64/libxmlrpc.so.0 #10 0x2ba8491ec593 in zif_xmlrpc_server_call_method (ht=3, return_value=0x2ba848e91570, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1, tsrm_ls=0x9db030) at /home/glen/rpm/pld/BUILD/php5.2-200706061230/ext/xmlrpc/xmlrpc-epi-php.c:1048 #11 0x0072bf88 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fa5d110, tsrm_ls=0x9db030) at /home/glen/rpm/pld/BUILD/php5.2-200706061230/Zend/zend_vm_execute.h:200 #12 0x007307ed in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x7fa5d110, tsrm_ls=0x9db030) at /home/glen/rpm/pld/BUILD/php5.2-200706061230/Zend/zend_vm_execute.h:1681 #13 0x0072b959 in execute (op_array=0x2ba848e90470, tsrm_ls=0x9db030) at /home/glen/rpm/pld/BUILD/php5.2-200706061230/Zend/zend_vm_execute.h:92 #14 0x00700787 in zend_execute_scripts (type=8, tsrm_ls=0x9db030, retval=0x0, file_count=3) at /home/glen/rpm/pld/BUILD/php5.2-200706061230/Zend/zend.c:1134 #15 0x00695033 in php_execute_script (primary_file=0x7fa5f860, tsrm_ls=0x9db030) at /home/glen/rpm/pld/BUILD/php5.2-200706061230/main/main.c:1794 #16 0x00787de9 in main (argc=4, argv=0x7fa5f9f8) at /home/glen/rpm/pld/BUILD/php5.2-200706061230/sapi/cli/php_cli.c:1151 (gdb) i'm also attaching backtrace from working x86 gdb (breakpoint on zif_xmlrpc_server_call_method): (gdb) bt #0 zif_xmlrpc_server_call_method (ht=3, return_value=0xb7bfdd40, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1, tsrm_ls=0x8474018) at /home/glen/rpm/pld/BUILD/php5.2-200706061230/ext/xmlrpc/xmlrpc-epi-php.c:1021 #1 0x08332a5a in zend_do_fcall_common_helper_SPEC (execute_data=0xbf853cb0, tsrm_ls=0x8474018) at /home/glen/rpm/pld/BUILD/php5.2-200706061230/Zend/zend_vm_execute.h:200 #2 0x08336a98 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xbf853cb0, tsrm_ls=0x8474018) at /home/glen/rpm/pld/BUILD/php5.2-200706061230/Zend/zend_vm_execute.h:1681 #3 0x08332568 in execute (op_array=0xb7bfd248, tsrm_ls=0x8474018
#41611 [Opn]: xmlrpc_server_call_method() causes segfault on x86_64 platform
ID: 41611 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee Status: Open Bug Type: XMLRPC-EPI related Operating System: PLD Linux/x86_64 PHP Version: 5.2.3 New Comment: also tested `alpha` architecture which has also 64bit cpu: [EMAIL PROTECTED] ~]$ php xmlrpc-segv.php *** glibc detected *** free(): invalid next size (fast): 0x000120151f40 *** Aborted [EMAIL PROTECTED] ~]$ arch alpha Previous Comments: [2007-06-06 14:42:34] glen at delfi dot ee Description: appears there's regression or the bug was not really fixed: http://bugs.php.net/bug.php?id=25428 17:22:58 glen[pts/[EMAIL PROTECTED] ~$ php xmlrpc-segv.php Segmentation fault 17:23:00 glen[pts/[EMAIL PROTECTED] ~$ cat xmlrpc-segv.php ? $request = xmlrpc_encode_request(system.listMethods, array()); $server = xmlrpc_server_create(); echo xmlrpc_server_call_method($server, $request, false); 17:23:02 glen[pts/[EMAIL PROTECTED] ~$ php -v PHP 5.2.3 (cli) (built: Jun 1 2007 08:53:57) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies also tested: PHP 5.2.3 - x86_64 - segfault PHP 5.2.2 - x86_64 - segfault PHP 5.2.1 - x86_64 - segfault PHP 5.2.1 - x86 - no segfault PHP 5.2.3 - x86 - no segfault also tested with php5.2-200706061230 as i tought it's first response i get to the bug to try the latest snap. and the problem is still there... ./configure \ --enable-debug \ --enable-maintainer-zts \ --enable-inline-optimization \ --with-xmlrpc=shared,/usr 17:38:35 glen[pts/[EMAIL PROTECTED] BUILD/php5.2-200706061230$ gdb ./sapi/cli/php GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-pld-linux...Using host libthread_db library /lib64/tls/libthread_db.so.1. (gdb) set args -dextension=xmlrpc.so -dextension_dir=modules /home/glen/xmlrpc-segv.php (gdb) run Starting program: /home/glen/rpm/pld/BUILD/php5.2-200706061230/sapi/cli/php -dextension=xmlrpc.so -dextension_dir=modules /home/glen/xmlrpc-segv.php Program received signal SIGSEGV, Segmentation fault. 0x2ba84931164b in simplestring_addn () from /usr/lib64/libxmlrpc.so.0 (gdb) bt #0 0x2ba84931164b in simplestring_addn () from /usr/lib64/libxmlrpc.so.0 #1 0x2ba84931224f in xml_elem_serialize_to_stream () from /usr/lib64/libxmlrpc.so.0 #2 0x003e6bf064cc in XML_GetFeatureList () from /usr/lib64/libexpat.so.0 #3 0x003e6bf0593d in XML_GetFeatureList () from /usr/lib64/libexpat.so.0 #4 0x003e6bf0843d in XML_GetFeatureList () from /usr/lib64/libexpat.so.0 #5 0x003e6bf0824b in XML_GetFeatureList () from /usr/lib64/libexpat.so.0 #6 0x003e6bf051b3 in XML_ParseBuffer () from /usr/lib64/libexpat.so.0 #7 0x003e6bf0511f in XML_Parse () from /usr/lib64/libexpat.so.0 #8 0x2ba8493123c0 in xml_elem_parse_buf () from /usr/lib64/libxmlrpc.so.0 #9 0x2ba849315163 in XMLRPC_REQUEST_FromXML () from /usr/lib64/libxmlrpc.so.0 #10 0x2ba8491ec593 in zif_xmlrpc_server_call_method (ht=3, return_value=0x2ba848e91570, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1, tsrm_ls=0x9db030) at /home/glen/rpm/pld/BUILD/php5.2-200706061230/ext/xmlrpc/xmlrpc-epi-php.c:1048 #11 0x0072bf88 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fa5d110, tsrm_ls=0x9db030) at /home/glen/rpm/pld/BUILD/php5.2-200706061230/Zend/zend_vm_execute.h:200 #12 0x007307ed in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x7fa5d110, tsrm_ls=0x9db030) at /home/glen/rpm/pld/BUILD/php5.2-200706061230/Zend/zend_vm_execute.h:1681 #13 0x0072b959 in execute (op_array=0x2ba848e90470, tsrm_ls=0x9db030) at /home/glen/rpm/pld/BUILD/php5.2-200706061230/Zend/zend_vm_execute.h:92 #14 0x00700787 in zend_execute_scripts (type=8, tsrm_ls=0x9db030, retval=0x0, file_count=3) at /home/glen/rpm/pld/BUILD/php5.2-200706061230/Zend/zend.c:1134 #15 0x00695033 in php_execute_script (primary_file=0x7fa5f860, tsrm_ls=0x9db030) at /home/glen/rpm/pld/BUILD/php5.2-200706061230/main/main.c:1794 #16 0x00787de9 in main (argc=4, argv=0x7fa5f9f8) at /home/glen/rpm/pld/BUILD/php5.2-200706061230/sapi/cli/php_cli.c:1151 (gdb) i'm also attaching backtrace from working x86 gdb (breakpoint on zif_xmlrpc_server_call_method): (gdb) bt #0 zif_xmlrpc_server_call_method (ht=3, return_value=0xb7bfdd40, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1, tsrm_ls=0x8474018) at /home/glen/rpm/pld/BUILD/php5.2-200706061230/ext/xmlrpc/xmlrpc-epi-php.c:1021 #1 0x08332a5a
#41611 [Fbk-Opn]: xmlrpc_server_call_method() causes segfault on x86_64 platform
ID: 41611 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee -Status: Feedback +Status: Open Bug Type: XMLRPC-EPI related Operating System: PLD Linux/x86_64 PHP Version: 5.2.3 New Comment: yes. appears that the bug is somewhere in xmlrpc-epi-0.51, as if compiled without system xmlrpc-epi (either statically or as module) it won't segfault. Previous Comments: [2007-06-06 14:57:11] [EMAIL PROTECTED] Does it matter if you compile the extension statically or not? I can't reproduce it on Linux x86_64 and the backtrace IMo shows that the problem is somewhere in libxmlrpc, not in PHP. [2007-06-06 14:49:38] glen at delfi dot ee also tested `alpha` architecture which has also 64bit cpu: [EMAIL PROTECTED] ~]$ php xmlrpc-segv.php *** glibc detected *** free(): invalid next size (fast): 0x000120151f40 *** Aborted [EMAIL PROTECTED] ~]$ arch alpha [2007-06-06 14:42:34] glen at delfi dot ee Description: appears there's regression or the bug was not really fixed: http://bugs.php.net/bug.php?id=25428 17:22:58 glen[pts/[EMAIL PROTECTED] ~$ php xmlrpc-segv.php Segmentation fault 17:23:00 glen[pts/[EMAIL PROTECTED] ~$ cat xmlrpc-segv.php ? $request = xmlrpc_encode_request(system.listMethods, array()); $server = xmlrpc_server_create(); echo xmlrpc_server_call_method($server, $request, false); 17:23:02 glen[pts/[EMAIL PROTECTED] ~$ php -v PHP 5.2.3 (cli) (built: Jun 1 2007 08:53:57) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies also tested: PHP 5.2.3 - x86_64 - segfault PHP 5.2.2 - x86_64 - segfault PHP 5.2.1 - x86_64 - segfault PHP 5.2.1 - x86 - no segfault PHP 5.2.3 - x86 - no segfault also tested with php5.2-200706061230 as i tought it's first response i get to the bug to try the latest snap. and the problem is still there... ./configure \ --enable-debug \ --enable-maintainer-zts \ --enable-inline-optimization \ --with-xmlrpc=shared,/usr 17:38:35 glen[pts/[EMAIL PROTECTED] BUILD/php5.2-200706061230$ gdb ./sapi/cli/php GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-pld-linux...Using host libthread_db library /lib64/tls/libthread_db.so.1. (gdb) set args -dextension=xmlrpc.so -dextension_dir=modules /home/glen/xmlrpc-segv.php (gdb) run Starting program: /home/glen/rpm/pld/BUILD/php5.2-200706061230/sapi/cli/php -dextension=xmlrpc.so -dextension_dir=modules /home/glen/xmlrpc-segv.php Program received signal SIGSEGV, Segmentation fault. 0x2ba84931164b in simplestring_addn () from /usr/lib64/libxmlrpc.so.0 (gdb) bt #0 0x2ba84931164b in simplestring_addn () from /usr/lib64/libxmlrpc.so.0 #1 0x2ba84931224f in xml_elem_serialize_to_stream () from /usr/lib64/libxmlrpc.so.0 #2 0x003e6bf064cc in XML_GetFeatureList () from /usr/lib64/libexpat.so.0 #3 0x003e6bf0593d in XML_GetFeatureList () from /usr/lib64/libexpat.so.0 #4 0x003e6bf0843d in XML_GetFeatureList () from /usr/lib64/libexpat.so.0 #5 0x003e6bf0824b in XML_GetFeatureList () from /usr/lib64/libexpat.so.0 #6 0x003e6bf051b3 in XML_ParseBuffer () from /usr/lib64/libexpat.so.0 #7 0x003e6bf0511f in XML_Parse () from /usr/lib64/libexpat.so.0 #8 0x2ba8493123c0 in xml_elem_parse_buf () from /usr/lib64/libxmlrpc.so.0 #9 0x2ba849315163 in XMLRPC_REQUEST_FromXML () from /usr/lib64/libxmlrpc.so.0 #10 0x2ba8491ec593 in zif_xmlrpc_server_call_method (ht=3, return_value=0x2ba848e91570, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1, tsrm_ls=0x9db030) at /home/glen/rpm/pld/BUILD/php5.2-200706061230/ext/xmlrpc/xmlrpc-epi-php.c:1048 #11 0x0072bf88 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fa5d110, tsrm_ls=0x9db030) at /home/glen/rpm/pld/BUILD/php5.2-200706061230/Zend/zend_vm_execute.h:200 #12 0x007307ed in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x7fa5d110, tsrm_ls=0x9db030) at /home/glen/rpm/pld/BUILD/php5.2-200706061230/Zend/zend_vm_execute.h:1681 #13 0x0072b959 in execute (op_array=0x2ba848e90470, tsrm_ls=0x9db030) at /home/glen/rpm/pld/BUILD/php5.2-200706061230/Zend/zend_vm_execute.h:92 #14 0x00700787 in zend_execute_scripts (type=8, tsrm_ls=0x9db030, retval=0x0, file_count=3) at /home/glen/rpm/pld/BUILD/php5.2-200706061230/Zend/zend.c:1134 #15 0x00695033 in php_execute_script (primary_file=0x7fa5f860, tsrm_ls
#41301 [Bgs]: Error in my_thread_global_end():
ID: 41301 User updated by: glen at aquarius dot com dot au Reported By: glen at aquarius dot com dot au Status: Bogus Bug Type: *Database Functions Operating System: win200 server PHP Version: 5.2.2 New Comment: The following comments have been made in the MySQL Bug reports for this bug: [14 May 3:34] Siew Pui Tong I have upgraded to PHP 5.2.2. I cfm that using libmysql.dll from 5.2.1, instead of 5.2.2 solved the pbm. -- [13 May 23:20] Nathan (York Networks) I started seeing this bug after upgrading from PHP 5.1.x to 5.2.2. Interestingly, copying the libmysql.dll from the 5.1.x version in to the 5.2.2 release appears to have resolved the issue at list until the underlying problem is addressed. - I have also changed the file and both phpBB3 and WordPress are now seemingly working fine. Previous Comments: [2007-05-09 16:32:52] [EMAIL PROTECTED] We don't call my_thread_init, or anything starting with my_thread: [EMAIL PROTECTED]:~/dev/php/php-5.2dev$ grep -r my_thread * [EMAIL PROTECTED]:~/dev/php/php-5.2dev$ [2007-05-09 15:55:45] glen at aquarius dot com dot au This is becoming a big issue over at MySQL Headquarters :-) Quite a number of programs utilising PHP and NOT commenting out the MySQL library are falling over. NOTE: You don't actually have to use MySQL - just having it enabled in PHP causes the problem as well. The latest: [9 May 17:43] Sergei Golubchik Strictly speaking, this is not MySQL bug. This is a client bug - a client application (PHP, probably) linked with libmysqlclient calls my_thread_init() but does not call my_thread_end() as appropriate (doesn't call at all or calls too late). MySQL client library detects this and issues a warning. On the other hand, we can just remove the check and let buggy applications to fail some other way. Not calling my_thread_end() is a guaranteed memory leak. Calling it too late could easily crash the application. [2007-05-06 22:54:31] glen at aquarius dot com dot au The problem is caused by MySQL and has been confirmed (Bug# 25621). It will apparently be fixed in the next release. In the meantime, if you are using PHP and do not use MySQL then you can disable MySQL by commenting out the reference at the end of php.ini eg: [PHP_MYSQL] ;extension=php_mysql.dll [2007-05-06 12:44:47] glen at aquarius dot com dot au Thanks for that - much appreciated. [2007-05-06 10:34:15] [EMAIL PROTECTED] Error in my_thread_global_end(): 5 threads didn't exit There is no such function nor error message in PHP. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/41301 -- Edit this bug report at http://bugs.php.net/?id=41301edit=1
#41301 [Bgs]: Error in my_thread_global_end():
ID: 41301 User updated by: glen at aquarius dot com dot au Reported By: glen at aquarius dot com dot au Status: Bogus Bug Type: *Database Functions Operating System: win200 server PHP Version: 5.2.2 New Comment: This is becoming a big issue over at MySQL Headquarters :-) Quite a number of programs utilising PHP and NOT commenting out the MySQL library are falling over. NOTE: You don't actually have to use MySQL - just having it enabled in PHP causes the problem as well. The latest: [9 May 17:43] Sergei Golubchik Strictly speaking, this is not MySQL bug. This is a client bug - a client application (PHP, probably) linked with libmysqlclient calls my_thread_init() but does not call my_thread_end() as appropriate (doesn't call at all or calls too late). MySQL client library detects this and issues a warning. On the other hand, we can just remove the check and let buggy applications to fail some other way. Not calling my_thread_end() is a guaranteed memory leak. Calling it too late could easily crash the application. Previous Comments: [2007-05-06 22:54:31] glen at aquarius dot com dot au The problem is caused by MySQL and has been confirmed (Bug# 25621). It will apparently be fixed in the next release. In the meantime, if you are using PHP and do not use MySQL then you can disable MySQL by commenting out the reference at the end of php.ini eg: [PHP_MYSQL] ;extension=php_mysql.dll [2007-05-06 12:44:47] glen at aquarius dot com dot au Thanks for that - much appreciated. [2007-05-06 10:34:15] [EMAIL PROTECTED] Error in my_thread_global_end(): 5 threads didn't exit There is no such function nor error message in PHP. [2007-05-06 07:55:36] glen at aquarius dot com dot au Description: I am installing phpBB3.0B5 and have tried using MySQL as well as MSSQL as their database servers. When using MySQL as the database, phpBB will not allow user access in IE but will when using Firefox. IE and Firefox work fine when using MSSql as the database. In either database scenario the following error appears at the foot of each phpBB page: Error in my_thread_global_end(): 5 threads didn't exit phpBB support do not think it's a bug in their software. Reproduce code: --- http://forums.aquarius.com.au will display the error message. -- Edit this bug report at http://bugs.php.net/?id=41301edit=1
#41301 [NEW]: Error in my_thread_global_end():
From: glen at aquarius dot com dot au Operating system: win200 server PHP version: 5.2.2 PHP Bug Type: *Database Functions Bug description: Error in my_thread_global_end(): Description: I am installing phpBB3.0B5 and have tried using MySQL as well as MSSQL as their database servers. When using MySQL as the database, phpBB will not allow user access in IE but will when using Firefox. IE and Firefox work fine when using MSSql as the database. In either database scenario the following error appears at the foot of each phpBB page: Error in my_thread_global_end(): 5 threads didn't exit phpBB support do not think it's a bug in their software. Reproduce code: --- http://forums.aquarius.com.au will display the error message. -- Edit bug report at http://bugs.php.net/?id=41301edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41301r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41301r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41301r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41301r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41301r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41301r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41301r=needscript Try newer version:http://bugs.php.net/fix.php?id=41301r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41301r=support Expected behavior:http://bugs.php.net/fix.php?id=41301r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41301r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41301r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41301r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41301r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41301r=dst IIS Stability:http://bugs.php.net/fix.php?id=41301r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41301r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41301r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41301r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41301r=mysqlcfg
#41301 [Bgs]: Error in my_thread_global_end():
ID: 41301 User updated by: glen at aquarius dot com dot au Reported By: glen at aquarius dot com dot au Status: Bogus Bug Type: *Database Functions Operating System: win200 server PHP Version: 5.2.2 New Comment: Thanks for that - much appreciated. Previous Comments: [2007-05-06 10:34:15] [EMAIL PROTECTED] Error in my_thread_global_end(): 5 threads didn't exit There is no such function nor error message in PHP. [2007-05-06 07:55:36] glen at aquarius dot com dot au Description: I am installing phpBB3.0B5 and have tried using MySQL as well as MSSQL as their database servers. When using MySQL as the database, phpBB will not allow user access in IE but will when using Firefox. IE and Firefox work fine when using MSSql as the database. In either database scenario the following error appears at the foot of each phpBB page: Error in my_thread_global_end(): 5 threads didn't exit phpBB support do not think it's a bug in their software. Reproduce code: --- http://forums.aquarius.com.au will display the error message. -- Edit this bug report at http://bugs.php.net/?id=41301edit=1
#41301 [Bgs]: Error in my_thread_global_end():
ID: 41301 User updated by: glen at aquarius dot com dot au Reported By: glen at aquarius dot com dot au Status: Bogus Bug Type: *Database Functions Operating System: win200 server PHP Version: 5.2.2 New Comment: The problem is caused by MySQL and has been confirmed (Bug# 25621). It will apparently be fixed in the next release. In the meantime, if you are using PHP and do not use MySQL then you can disable MySQL by commenting out the reference at the end of php.ini eg: [PHP_MYSQL] ;extension=php_mysql.dll Previous Comments: [2007-05-06 12:44:47] glen at aquarius dot com dot au Thanks for that - much appreciated. [2007-05-06 10:34:15] [EMAIL PROTECTED] Error in my_thread_global_end(): 5 threads didn't exit There is no such function nor error message in PHP. [2007-05-06 07:55:36] glen at aquarius dot com dot au Description: I am installing phpBB3.0B5 and have tried using MySQL as well as MSSQL as their database servers. When using MySQL as the database, phpBB will not allow user access in IE but will when using Firefox. IE and Firefox work fine when using MSSql as the database. In either database scenario the following error appears at the foot of each phpBB page: Error in my_thread_global_end(): 5 threads didn't exit phpBB support do not think it's a bug in their software. Reproduce code: --- http://forums.aquarius.com.au will display the error message. -- Edit this bug report at http://bugs.php.net/?id=41301edit=1
#34793 [Opn]: php-cli searches php.ini from current dir which can be abused
ID: 34793 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee Status: Open Bug Type: Feature/Change Request Operating System: PLD Linux PHP Version: 5.1.0RC1 New Comment: you should close this bug with message like RESOLVED in 5.2.0 Previous Comments: [2006-01-17 15:49:05] glen at delfi dot ee to put this into another light. how should i run php cli program, with *not* reading ./php.ini? a real live situation: i have a PHP program defined as CVS loginfo handler. CVS server accessed via ssh. now if i happen to commit php.ini in such CVS setup, the php.ini is first uploaded to cvs server and then a PHP program is executed in that directory (where commited files were uploaded). as the php.ini is not for the OS where the PHP program is ran. i get fatal error from PHP interpreter and no code is executed: # cvs ci -m '- disable zend, broken' php.ini Checking in php.ini; /usr/local/cvs/sw/apache/php.ini,v -- php.ini new revision: 1.7; previous revision: 1.6 done PHP Warning: PHP Startup: Unable to load dynamic library './pcre.so' - ./pcre.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: Unknown: failed to open stream: No such file or directory in Unknown on line 0 PHP Warning: Unknown: Failed opening '/www/vars.inc' for inclusion (include_path='.:/usr/share/pear') in Unknown on line 0 [2005-10-10 00:06:59] adamg at agmk dot net I believe this behaviour is wrong and PHP should be fixed not to look for php.ini in the current directory for the reasons described by glen. Ideally (as I see it) is a fixed location in /etc and (optionally) in home dir of user running the script. Why do you think this bug report is bogus? What are the reasons for keeping such behaviour? [2005-10-10 00:05:36] glen at delfi dot ee in fact i know that documentation says so. but that doesn't mean it supposed to be like this? can't you at least consider securing it, by adding some option to enable/disable this? so i changed category to feature request! [2005-10-09 19:14:38] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [2005-10-09 18:13:31] glen at delfi dot ee Description: php cli searches for php.ini from current dir, and when current directory appears to be world writable directory, then malicious user can put there php.ini loading malicious extension. php cli is used for example to install PEAR packages, and for PEAR install to succeed it needs to be run as root. Reproduce code: --- 1. create /tmp/php.ini containing [PHP] extension=/../../../tmp/malicious.so 2. create php extension and save it to /tmp/malicious.so 3. wait for root run any php-cli program in /tmp 4. your code in malicious.so gets executed. Expected result: php should not read php.ini from arbitary locations, it should read it only from hardcoded paths, or one specified from commandline. Actual result: -- $ strace -eopen php -m open(/etc/ld.so.cache, O_RDONLY) = 6 open(/usr/lib/libphp_common-5.1.0RC1.so, O_RDONLY) = 6 open(/lib/libcrypt.so.1, O_RDONLY)= 6 open(/lib/libm.so.6, O_RDONLY)= 6 open(/lib/libz.so.1, O_RDONLY)= 6 open(/lib/libresolv.so.2, O_RDONLY) = 6 open(/lib/libpthread.so.0, O_RDONLY) = 6 open(/usr/lib/libxml2.so.2, O_RDONLY) = 6 open(/lib/libdl.so.2, O_RDONLY) = 6 open(/lib/libhistory.so.5, O_RDONLY) = 6 open(/lib/libreadline.so.5, O_RDONLY) = 6 open(/lib/libncurses.so.5, O_RDONLY) = 6 open(/lib/libc.so.6, O_RDONLY)= 6 open(/lib/libtinfo.so.5, O_RDONLY)= 6 open(/etc/localtime, O_RDONLY)= 6 open(/tmp/php.ini, O_RDONLY) = 6 open(/tmp/php-cli.ini, O_RDONLY) = -1 ENOENT (No such file or directory) open(/etc/php/php-cli.ini, O_RDONLY) = 6 open(/etc/php/conf.d, O_RDONLY|O_NONBLOCK|O_LARGEFILE| O_DIRECTORY) = 6 open(/etc/php/conf.d/pcre.ini, O_RDONLY) = 6 open(/etc/php/conf.d/xml.ini, O_RDONLY) = 6 open(/usr/lib/php//../../../tmp/malicious.so, O_RDONLY) = 6 open(/usr/lib/php/pcre.so, O_RDONLY) = 6 -- Edit this bug report at http://bugs.php.net/?id=34793edit=1
#38567 [NEW]: file operations make loads of lstat64() calls and making code ineffective
From: glen at delfi dot ee
Operating system: PLD Linux
PHP version: 5.1.5
PHP Bug Type: Feature/Change Request
Bug description: file operations make loads of lstat64() calls and making code
ineffective
Description:
$ strace php -r 'for ($i=0;$i5;$i++)
{$fp=fopen(/home/glen/tmp/php/long/test/dir/is/here/$i,w);fclose($fp);}'
21 |grep /home
this will call lstat64() each time on:
/home
/home/glen
/home/glen/tmp
/home/glen/tmp/php
/home/glen/tmp/php/long
/home/glen/tmp/php/long/test
/home/glen/tmp/php/long/test/dir
/home/glen/tmp/php/long/test/dir/is
/home/glen/tmp/php/long/test/dir/is/here
while it should either don't do them at all or at least
cache the paths that haven't been altered (i only write to
last dir)
--
Edit bug report at http://bugs.php.net/?id=38567edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38567r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38567r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38567r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38567r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38567r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38567r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38567r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38567r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38567r=support
Expected behavior:http://bugs.php.net/fix.php?id=38567r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38567r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38567r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38567r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38567r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38567r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38567r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38567r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38567r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38567r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38567r=mysqlcfg
#38567 [Fbk-Opn]: file operations make loads of lstat64() calls and making code ineffective
ID: 38567
User updated by: glen at delfi dot ee
Reported By: glen at delfi dot ee
-Status: Feedback
+Status: Open
Bug Type: Feature/Change Request
Operating System: PLD Linux
PHP Version: 5.1.5
New Comment:
no changes. tried php5.2-200608231430
Previous Comments:
[2006-08-23 15:27:19] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-08-23 15:03:20] glen at delfi dot ee
Description:
$ strace php -r 'for ($i=0;$i5;$i++)
{$fp=fopen(/home/glen/tmp/php/long/test/dir/is/here/$i,w);fclose($fp);}'
21 |grep /home
this will call lstat64() each time on:
/home
/home/glen
/home/glen/tmp
/home/glen/tmp/php
/home/glen/tmp/php/long
/home/glen/tmp/php/long/test
/home/glen/tmp/php/long/test/dir
/home/glen/tmp/php/long/test/dir/is
/home/glen/tmp/php/long/test/dir/is/here
while it should either don't do them at all or at least
cache the paths that haven't been altered (i only write to
last dir)
--
Edit this bug report at http://bugs.php.net/?id=38567edit=1
#37094 [Fbk-Opn]: a patch to remove cflags from linker commands
ID: 37094 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee -Status: Feedback +Status: Open Bug Type: *Compile Issues Operating System: PLD Linux PHP Version: 5.1.2 New Comment: cleaning up. Previous Comments: [2006-04-16 08:37:04] [EMAIL PROTECTED] What is exactly the problem you're trying to fix by this patch? [2006-04-16 00:44:28] glen at delfi dot ee Description: this is purely cosmetic change, as the CFLAGS (include dirs, -DDEFINE-s have no effect at link time), but some compilers might warn that preprocessor flags used at link time. patch against 5.1.2: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-linkflags-clean.patch and 4.4.2: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php4-linkflags-clean.patch -- Edit this bug report at http://bugs.php.net/?id=37094edit=1
#37094 [NEW]: a patch to remove cflags from linker commands
From: glen at delfi dot ee Operating system: PLD Linux PHP version: 5.1.2 PHP Bug Type: *Compile Issues Bug description: a patch to remove cflags from linker commands Description: this is purely cosmetic change, as the CFLAGS (include dirs, -DDEFINE-s have no effect at link time), but some compilers might warn that preprocessor flags used at link time. patch against 5.1.2: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-linkflags-clean.patch and 4.4.2: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php4-linkflags-clean.patch -- Edit bug report at http://bugs.php.net/?id=37094edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37094r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37094r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37094r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37094r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37094r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37094r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37094r=needscript Try newer version:http://bugs.php.net/fix.php?id=37094r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37094r=support Expected behavior:http://bugs.php.net/fix.php?id=37094r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37094r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37094r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37094r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37094r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37094r=dst IIS Stability:http://bugs.php.net/fix.php?id=37094r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37094r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37094r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37094r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37094r=mysqlcfg
#34793 [Opn]: php-cli searches php.ini from current dir which can be abused
ID: 34793 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee Status: Open Bug Type: Feature/Change Request Operating System: PLD Linux PHP Version: 5.1.0RC1 New Comment: to put this into another light. how should i run php cli program, with *not* reading ./php.ini? a real live situation: i have a PHP program defined as CVS loginfo handler. CVS server accessed via ssh. now if i happen to commit php.ini in such CVS setup, the php.ini is first uploaded to cvs server and then a PHP program is executed in that directory (where commited files were uploaded). as the php.ini is not for the OS where the PHP program is ran. i get fatal error from PHP interpreter and no code is executed: # cvs ci -m '- disable zend, broken' php.ini Checking in php.ini; /usr/local/cvs/sw/apache/php.ini,v -- php.ini new revision: 1.7; previous revision: 1.6 done PHP Warning: PHP Startup: Unable to load dynamic library './pcre.so' - ./pcre.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: Unknown: failed to open stream: No such file or directory in Unknown on line 0 PHP Warning: Unknown: Failed opening '/www/vars.inc' for inclusion (include_path='.:/usr/share/pear') in Unknown on line 0 Previous Comments: [2005-10-10 00:06:59] adamg at agmk dot net I believe this behaviour is wrong and PHP should be fixed not to look for php.ini in the current directory for the reasons described by glen. Ideally (as I see it) is a fixed location in /etc and (optionally) in home dir of user running the script. Why do you think this bug report is bogus? What are the reasons for keeping such behaviour? [2005-10-10 00:05:36] glen at delfi dot ee in fact i know that documentation says so. but that doesn't mean it supposed to be like this? can't you at least consider securing it, by adding some option to enable/disable this? so i changed category to feature request! [2005-10-09 19:14:38] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [2005-10-09 18:13:31] glen at delfi dot ee Description: php cli searches for php.ini from current dir, and when current directory appears to be world writable directory, then malicious user can put there php.ini loading malicious extension. php cli is used for example to install PEAR packages, and for PEAR install to succeed it needs to be run as root. Reproduce code: --- 1. create /tmp/php.ini containing [PHP] extension=/../../../tmp/malicious.so 2. create php extension and save it to /tmp/malicious.so 3. wait for root run any php-cli program in /tmp 4. your code in malicious.so gets executed. Expected result: php should not read php.ini from arbitary locations, it should read it only from hardcoded paths, or one specified from commandline. Actual result: -- $ strace -eopen php -m open(/etc/ld.so.cache, O_RDONLY) = 6 open(/usr/lib/libphp_common-5.1.0RC1.so, O_RDONLY) = 6 open(/lib/libcrypt.so.1, O_RDONLY)= 6 open(/lib/libm.so.6, O_RDONLY)= 6 open(/lib/libz.so.1, O_RDONLY)= 6 open(/lib/libresolv.so.2, O_RDONLY) = 6 open(/lib/libpthread.so.0, O_RDONLY) = 6 open(/usr/lib/libxml2.so.2, O_RDONLY) = 6 open(/lib/libdl.so.2, O_RDONLY) = 6 open(/lib/libhistory.so.5, O_RDONLY) = 6 open(/lib/libreadline.so.5, O_RDONLY) = 6 open(/lib/libncurses.so.5, O_RDONLY) = 6 open(/lib/libc.so.6, O_RDONLY)= 6 open(/lib/libtinfo.so.5, O_RDONLY)= 6 open(/etc/localtime, O_RDONLY)= 6 open(/tmp/php.ini, O_RDONLY) = 6 open(/tmp/php-cli.ini, O_RDONLY) = -1 ENOENT (No such file or directory) open(/etc/php/php-cli.ini, O_RDONLY) = 6 open(/etc/php/conf.d, O_RDONLY|O_NONBLOCK|O_LARGEFILE| O_DIRECTORY) = 6 open(/etc/php/conf.d/pcre.ini, O_RDONLY) = 6 open(/etc/php/conf.d/xml.ini, O_RDONLY) = 6 open(/usr/lib/php//../../../tmp/malicious.so, O_RDONLY) = 6 open(/usr/lib/php/pcre.so, O_RDONLY) = 6 -- Edit this bug report at http://bugs.php.net/?id=34793edit=1
#35009 [Fbk-Opn]: mysql_pconnect() crashes on PHP-CLI when ZTS is enabled
ID: 35009 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee -Status: Feedback +Status: Open Bug Type: MySQL related Operating System: PLD Linux PHP Version: 5CVS-2005-10-28 (snap) New Comment: this dl() was for sake of the test. in real show the php.ini defines extension to load. and in fact, it crashes same way with using php.ini (i didn't want to overwrite system php.ini with this test) if it helps figuring out the leak, then replacing mysql_pconnect with mysql_connect call omits the crash. Previous Comments: [2005-11-06 04:05:04] [EMAIL PROTECTED] Note: dl() is not supported in multithreaded Web servers. So how could you load the shared extension? [2005-11-01 16:42:25] glen at delfi dot ee yes. appears so: $ ./configure --disable-all --with-mysql --enable-maintainer-zts --enable-debug $ make $ ./sapi/cli/php -r '$r = mysql_pconnect(heart);echo $r\n;'; echo rc=$? Resource id #4 rc=0 $ ./sapi/cli/php -m [PHP Modules] date mysql standard [Zend Modules] code used: php5-200510281630 [2005-11-01 11:39:45] [EMAIL PROTECTED] What if you configure the mysql extension as static, does it work then? [2005-10-28 20:49:51] glen at delfi dot ee same thing with php5-200510281630 $ ./sapi/cli/php -v PHP 5.1.0RC5-dev (cli) (built: Oct 28 2005 21:47:13) (DEBUG) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2005 Zend Technologies $ ./sapi/cli/php -r 'dl(mysql.so); mysql_pconnect();' Warning: mysql_pconnect(): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) in Command line code on line 1 /home/builder/rpm/BUILD/php5-200510281630/Zend/zend_hash.c(678) : ht=0x8264d78 is already destroyed /home/builder/rpm/BUILD/php5-200510281630/Zend/zend_hash.c(678) : ht=0x8264d78 is already destroyed /home/builder/rpm/BUILD/php5-200510281630/Zend/zend_hash.c(67) : Bailed out without a bailout address! $ [2005-10-28 19:54:46] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/35009 -- Edit this bug report at http://bugs.php.net/?id=35009edit=1
#35009 [Fbk-Opn]: mysql_pconnect() crashes on PHP-CLI when ZTS is enabled
ID: 35009 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee -Status: Feedback +Status: Open Bug Type: MySQL related Operating System: PLD Linux PHP Version: 5CVS-2005-10-28 (snap) New Comment: yes. appears so: $ ./configure --disable-all --with-mysql --enable-maintainer-zts --enable-debug $ make $ ./sapi/cli/php -r '$r = mysql_pconnect(heart);echo $r\n;'; echo rc=$? Resource id #4 rc=0 $ ./sapi/cli/php -m [PHP Modules] date mysql standard [Zend Modules] code used: php5-200510281630 Previous Comments: [2005-11-01 11:39:45] [EMAIL PROTECTED] What if you configure the mysql extension as static, does it work then? [2005-10-28 20:49:51] glen at delfi dot ee same thing with php5-200510281630 $ ./sapi/cli/php -v PHP 5.1.0RC5-dev (cli) (built: Oct 28 2005 21:47:13) (DEBUG) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2005 Zend Technologies $ ./sapi/cli/php -r 'dl(mysql.so); mysql_pconnect();' Warning: mysql_pconnect(): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) in Command line code on line 1 /home/builder/rpm/BUILD/php5-200510281630/Zend/zend_hash.c(678) : ht=0x8264d78 is already destroyed /home/builder/rpm/BUILD/php5-200510281630/Zend/zend_hash.c(678) : ht=0x8264d78 is already destroyed /home/builder/rpm/BUILD/php5-200510281630/Zend/zend_hash.c(67) : Bailed out without a bailout address! $ [2005-10-28 19:54:46] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-10-28 19:08:22] glen at delfi dot ee ok. this is quick way to see it, altho the error is different. $ ./configure --disable-all --with-mysql=shared --enable-maintainer-zts --enable-debug $ make $ ./sapi/cli/php -i |grep -i safe $ sudo mkdir -p /usr/local/lib/php/extensions/debug-zts-20041030/ $ sudo chown builder /usr/local/lib/php/extensions/debug-zts-20041030/ $ cp modules/mysql.so /usr/local/lib/php/extensions/debug-zts-20041030/ $ ./sapi/cli/php -r 'dl(mysql.so); mysql_pconnect();' Warning: mysql_pconnect(): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) in Command line code on line 1 /home/builder/rpm/BUILD/p/php5-STABLE-200510281434/Zend/zend_hash.c(678) : ht=0x9ce4a74 is already destroyed /home/builder/rpm/BUILD/p/php5-STABLE-200510281434/Zend/zend_hash.c(678) : ht=0x9ce4a74 is already destroyed /home/builder/rpm/BUILD/p/php5-STABLE-200510281434/Zend/zend_hash.c(67) : Bailed out without a bailout address! $ [2005-10-28 19:05:48] glen at delfi dot ee Description: $ php -r 'mysql_pconnect();' Segmentation fault you will need to specify proper auth strings for the connection to succeed. bug is present in php 4.4.0, php 5.0.5 with both ZTS enabled. on same system disabling ZTS with php 4.4.0 the crash didn't occour. also used php5-STABLE-200510281434 snapshot. and crash was reproducible. Reproduce code: --- $ gdb --args php -r 'mysql_pconnect();' GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as --host= --target=i686-pld-linux...Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) run Starting program: /usr/bin/php -r mysql_pconnect\(\)\; Program received signal SIGSEGV, Segmentation fault. 0xb7879948 in ?? () (gdb) bt #0 0xb7879948 in ?? () #1 0xb7f0d549 in plist_entry_destructor (ptr=0x80dbb00) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/Zend/zend_list.c:210 #2 0xb7f0b53f in zend_hash_apply_deleter (ht=0x8052c60, p=0x80e3f40) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/Zend/zend_hash.c:574 #3 0xb7f0b790 in zend_hash_graceful_reverse_destroy (ht=0x8052c60) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/Zend/zend_hash.c:640 #4 0xb7f0d665 in zend_destroy_rsrc_list (ht=0x8052c60, tsrm_ls=0x804f0a8) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/Zend/zend_list.c:240 #5 0xb7f0146a in zend_shutdown (tsrm_ls=0x804f0a8) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/Zend/zend.c:714 #6 0xb7eaa3e3 in php_module_shutdown (tsrm_ls=0x804f0a8) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/main/main.c:1529 #7 0x0804be44 in main (argc=3, argv
#35009 [NEW]: mysql_pconnect() crashes on PHP-CLI when ZTS is enabled
From: glen at delfi dot ee Operating system: PLD Linux PHP version: 5CVS-2005-10-28 (snap) PHP Bug Type: Reproducible crash Bug description: mysql_pconnect() crashes on PHP-CLI when ZTS is enabled Description: $ php -r 'mysql_pconnect();' Segmentation fault you will need to specify proper auth strings for the connection to succeed. bug is present in php 4.4.0, php 5.0.5 with both ZTS enabled. on same system disabling ZTS with php 4.4.0 the crash didn't occour. also used php5-STABLE-200510281434 snapshot. and crash was reproducible. Reproduce code: --- $ gdb --args php -r 'mysql_pconnect();' GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as --host= --target=i686-pld-linux...Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) run Starting program: /usr/bin/php -r mysql_pconnect\(\)\; Program received signal SIGSEGV, Segmentation fault. 0xb7879948 in ?? () (gdb) bt #0 0xb7879948 in ?? () #1 0xb7f0d549 in plist_entry_destructor (ptr=0x80dbb00) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/Zend/zend_list.c:210 #2 0xb7f0b53f in zend_hash_apply_deleter (ht=0x8052c60, p=0x80e3f40) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/Zend/zend_hash.c:574 #3 0xb7f0b790 in zend_hash_graceful_reverse_destroy (ht=0x8052c60) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/Zend/zend_hash.c:640 #4 0xb7f0d665 in zend_destroy_rsrc_list (ht=0x8052c60, tsrm_ls=0x804f0a8) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/Zend/zend_list.c:240 #5 0xb7f0146a in zend_shutdown (tsrm_ls=0x804f0a8) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/Zend/zend.c:714 #6 0xb7eaa3e3 in php_module_shutdown (tsrm_ls=0x804f0a8) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/main/main.c:1529 #7 0x0804be44 in main (argc=3, argv=0xbfcb04a4) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/sapi/cli/php_cli.c:1058 (gdb) -- Edit bug report at http://bugs.php.net/?id=35009edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35009r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=35009r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=35009r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=35009r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=35009r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35009r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=35009r=needscript Try newer version: http://bugs.php.net/fix.php?id=35009r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35009r=support Expected behavior: http://bugs.php.net/fix.php?id=35009r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35009r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35009r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=35009r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35009r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=35009r=dst IIS Stability: http://bugs.php.net/fix.php?id=35009r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35009r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35009r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35009r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=35009r=mysqlcfg
#35009 [Opn]: mysql_pconnect() crashes on PHP-CLI when ZTS is enabled
ID: 35009 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee Status: Open Bug Type: Reproducible crash Operating System: PLD Linux PHP Version: 5CVS-2005-10-28 (snap) New Comment: ok. this is quick way to see it, altho the error is different. $ ./configure --disable-all --with-mysql=shared --enable-maintainer-zts --enable-debug $ make $ ./sapi/cli/php -i |grep -i safe $ sudo mkdir -p /usr/local/lib/php/extensions/debug-zts-20041030/ $ sudo chown builder /usr/local/lib/php/extensions/debug-zts-20041030/ $ cp modules/mysql.so /usr/local/lib/php/extensions/debug-zts-20041030/ $ ./sapi/cli/php -r 'dl(mysql.so); mysql_pconnect();' Warning: mysql_pconnect(): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) in Command line code on line 1 /home/builder/rpm/BUILD/p/php5-STABLE-200510281434/Zend/zend_hash.c(678) : ht=0x9ce4a74 is already destroyed /home/builder/rpm/BUILD/p/php5-STABLE-200510281434/Zend/zend_hash.c(678) : ht=0x9ce4a74 is already destroyed /home/builder/rpm/BUILD/p/php5-STABLE-200510281434/Zend/zend_hash.c(67) : Bailed out without a bailout address! $ Previous Comments: [2005-10-28 19:05:48] glen at delfi dot ee Description: $ php -r 'mysql_pconnect();' Segmentation fault you will need to specify proper auth strings for the connection to succeed. bug is present in php 4.4.0, php 5.0.5 with both ZTS enabled. on same system disabling ZTS with php 4.4.0 the crash didn't occour. also used php5-STABLE-200510281434 snapshot. and crash was reproducible. Reproduce code: --- $ gdb --args php -r 'mysql_pconnect();' GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as --host= --target=i686-pld-linux...Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) run Starting program: /usr/bin/php -r mysql_pconnect\(\)\; Program received signal SIGSEGV, Segmentation fault. 0xb7879948 in ?? () (gdb) bt #0 0xb7879948 in ?? () #1 0xb7f0d549 in plist_entry_destructor (ptr=0x80dbb00) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/Zend/zend_list.c:210 #2 0xb7f0b53f in zend_hash_apply_deleter (ht=0x8052c60, p=0x80e3f40) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/Zend/zend_hash.c:574 #3 0xb7f0b790 in zend_hash_graceful_reverse_destroy (ht=0x8052c60) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/Zend/zend_hash.c:640 #4 0xb7f0d665 in zend_destroy_rsrc_list (ht=0x8052c60, tsrm_ls=0x804f0a8) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/Zend/zend_list.c:240 #5 0xb7f0146a in zend_shutdown (tsrm_ls=0x804f0a8) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/Zend/zend.c:714 #6 0xb7eaa3e3 in php_module_shutdown (tsrm_ls=0x804f0a8) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/main/main.c:1529 #7 0x0804be44 in main (argc=3, argv=0xbfcb04a4) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/sapi/cli/php_cli.c:1058 (gdb) -- Edit this bug report at http://bugs.php.net/?id=35009edit=1
#35009 [Fbk-Opn]: mysql_pconnect() crashes on PHP-CLI when ZTS is enabled
ID: 35009 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee -Status: Feedback +Status: Open Bug Type: MySQLi related Operating System: PLD Linux PHP Version: 5.0.5 New Comment: i already did check with *today*'s snapshot, and i looked cvs commits, there aren't nothing commited related to this topic today. in any case, i'll still rebuild with latest snap (2 hours newer snap) as you said. Previous Comments: [2005-10-28 19:54:46] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-10-28 19:08:22] glen at delfi dot ee ok. this is quick way to see it, altho the error is different. $ ./configure --disable-all --with-mysql=shared --enable-maintainer-zts --enable-debug $ make $ ./sapi/cli/php -i |grep -i safe $ sudo mkdir -p /usr/local/lib/php/extensions/debug-zts-20041030/ $ sudo chown builder /usr/local/lib/php/extensions/debug-zts-20041030/ $ cp modules/mysql.so /usr/local/lib/php/extensions/debug-zts-20041030/ $ ./sapi/cli/php -r 'dl(mysql.so); mysql_pconnect();' Warning: mysql_pconnect(): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) in Command line code on line 1 /home/builder/rpm/BUILD/p/php5-STABLE-200510281434/Zend/zend_hash.c(678) : ht=0x9ce4a74 is already destroyed /home/builder/rpm/BUILD/p/php5-STABLE-200510281434/Zend/zend_hash.c(678) : ht=0x9ce4a74 is already destroyed /home/builder/rpm/BUILD/p/php5-STABLE-200510281434/Zend/zend_hash.c(67) : Bailed out without a bailout address! $ [2005-10-28 19:05:48] glen at delfi dot ee Description: $ php -r 'mysql_pconnect();' Segmentation fault you will need to specify proper auth strings for the connection to succeed. bug is present in php 4.4.0, php 5.0.5 with both ZTS enabled. on same system disabling ZTS with php 4.4.0 the crash didn't occour. also used php5-STABLE-200510281434 snapshot. and crash was reproducible. Reproduce code: --- $ gdb --args php -r 'mysql_pconnect();' GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as --host= --target=i686-pld-linux...Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) run Starting program: /usr/bin/php -r mysql_pconnect\(\)\; Program received signal SIGSEGV, Segmentation fault. 0xb7879948 in ?? () (gdb) bt #0 0xb7879948 in ?? () #1 0xb7f0d549 in plist_entry_destructor (ptr=0x80dbb00) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/Zend/zend_list.c:210 #2 0xb7f0b53f in zend_hash_apply_deleter (ht=0x8052c60, p=0x80e3f40) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/Zend/zend_hash.c:574 #3 0xb7f0b790 in zend_hash_graceful_reverse_destroy (ht=0x8052c60) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/Zend/zend_hash.c:640 #4 0xb7f0d665 in zend_destroy_rsrc_list (ht=0x8052c60, tsrm_ls=0x804f0a8) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/Zend/zend_list.c:240 #5 0xb7f0146a in zend_shutdown (tsrm_ls=0x804f0a8) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/Zend/zend.c:714 #6 0xb7eaa3e3 in php_module_shutdown (tsrm_ls=0x804f0a8) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/main/main.c:1529 #7 0x0804be44 in main (argc=3, argv=0xbfcb04a4) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/sapi/cli/php_cli.c:1058 (gdb) -- Edit this bug report at http://bugs.php.net/?id=35009edit=1
#35009 [Opn]: mysql_pconnect() crashes on PHP-CLI when ZTS is enabled
ID: 35009 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee Status: Open -Bug Type: MySQLi related +Bug Type: MySQL related Operating System: PLD Linux PHP Version: 5.0.5 New Comment: same thing with php5-200510281630 $ ./sapi/cli/php -v PHP 5.1.0RC5-dev (cli) (built: Oct 28 2005 21:47:13) (DEBUG) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2005 Zend Technologies $ ./sapi/cli/php -r 'dl(mysql.so); mysql_pconnect();' Warning: mysql_pconnect(): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) in Command line code on line 1 /home/builder/rpm/BUILD/php5-200510281630/Zend/zend_hash.c(678) : ht=0x8264d78 is already destroyed /home/builder/rpm/BUILD/php5-200510281630/Zend/zend_hash.c(678) : ht=0x8264d78 is already destroyed /home/builder/rpm/BUILD/php5-200510281630/Zend/zend_hash.c(67) : Bailed out without a bailout address! $ Previous Comments: [2005-10-28 20:26:50] glen at delfi dot ee i already did check with *today*'s snapshot, and i looked cvs commits, there aren't nothing commited related to this topic today. in any case, i'll still rebuild with latest snap (2 hours newer snap) as you said. [2005-10-28 19:54:46] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-10-28 19:08:22] glen at delfi dot ee ok. this is quick way to see it, altho the error is different. $ ./configure --disable-all --with-mysql=shared --enable-maintainer-zts --enable-debug $ make $ ./sapi/cli/php -i |grep -i safe $ sudo mkdir -p /usr/local/lib/php/extensions/debug-zts-20041030/ $ sudo chown builder /usr/local/lib/php/extensions/debug-zts-20041030/ $ cp modules/mysql.so /usr/local/lib/php/extensions/debug-zts-20041030/ $ ./sapi/cli/php -r 'dl(mysql.so); mysql_pconnect();' Warning: mysql_pconnect(): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) in Command line code on line 1 /home/builder/rpm/BUILD/p/php5-STABLE-200510281434/Zend/zend_hash.c(678) : ht=0x9ce4a74 is already destroyed /home/builder/rpm/BUILD/p/php5-STABLE-200510281434/Zend/zend_hash.c(678) : ht=0x9ce4a74 is already destroyed /home/builder/rpm/BUILD/p/php5-STABLE-200510281434/Zend/zend_hash.c(67) : Bailed out without a bailout address! $ [2005-10-28 19:05:48] glen at delfi dot ee Description: $ php -r 'mysql_pconnect();' Segmentation fault you will need to specify proper auth strings for the connection to succeed. bug is present in php 4.4.0, php 5.0.5 with both ZTS enabled. on same system disabling ZTS with php 4.4.0 the crash didn't occour. also used php5-STABLE-200510281434 snapshot. and crash was reproducible. Reproduce code: --- $ gdb --args php -r 'mysql_pconnect();' GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as --host= --target=i686-pld-linux...Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) run Starting program: /usr/bin/php -r mysql_pconnect\(\)\; Program received signal SIGSEGV, Segmentation fault. 0xb7879948 in ?? () (gdb) bt #0 0xb7879948 in ?? () #1 0xb7f0d549 in plist_entry_destructor (ptr=0x80dbb00) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/Zend/zend_list.c:210 #2 0xb7f0b53f in zend_hash_apply_deleter (ht=0x8052c60, p=0x80e3f40) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/Zend/zend_hash.c:574 #3 0xb7f0b790 in zend_hash_graceful_reverse_destroy (ht=0x8052c60) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/Zend/zend_hash.c:640 #4 0xb7f0d665 in zend_destroy_rsrc_list (ht=0x8052c60, tsrm_ls=0x804f0a8) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/Zend/zend_list.c:240 #5 0xb7f0146a in zend_shutdown (tsrm_ls=0x804f0a8) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/Zend/zend.c:714 #6 0xb7eaa3e3 in php_module_shutdown (tsrm_ls=0x804f0a8) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/main/main.c:1529 #7 0x0804be44 in main (argc=3, argv=0xbfcb04a4) at /home/builder/rpm/BUILD/php5-STABLE-200510281434/sapi/cli/php_cli.c:1058 (gdb) -- Edit this bug report at http://bugs.php.net/?id=35009edit=1
#34793 [NEW]: php-cli searches php.ini from current dir which can be abused
From: glen at delfi dot ee Operating system: PLD Linux PHP version: 5.1.0RC1 PHP Bug Type: CGI related Bug description: php-cli searches php.ini from current dir which can be abused Description: php cli searches for php.ini from current dir, and when current directory appears to be world writable directory, then malicious user can put there php.ini loading malicious extension. php cli is used for example to install PEAR packages, and for PEAR install to succeed it needs to be run as root. Reproduce code: --- 1. create /tmp/php.ini containing [PHP] extension=/../../../tmp/malicious.so 2. create php extension and save it to /tmp/malicious.so 3. wait for root run any php-cli program in /tmp 4. your code in malicious.so gets executed. Expected result: php should not read php.ini from arbitary locations, it should read it only from hardcoded paths, or one specified from commandline. Actual result: -- $ strace -eopen php -m open(/etc/ld.so.cache, O_RDONLY) = 6 open(/usr/lib/libphp_common-5.1.0RC1.so, O_RDONLY) = 6 open(/lib/libcrypt.so.1, O_RDONLY)= 6 open(/lib/libm.so.6, O_RDONLY)= 6 open(/lib/libz.so.1, O_RDONLY)= 6 open(/lib/libresolv.so.2, O_RDONLY) = 6 open(/lib/libpthread.so.0, O_RDONLY) = 6 open(/usr/lib/libxml2.so.2, O_RDONLY) = 6 open(/lib/libdl.so.2, O_RDONLY) = 6 open(/lib/libhistory.so.5, O_RDONLY) = 6 open(/lib/libreadline.so.5, O_RDONLY) = 6 open(/lib/libncurses.so.5, O_RDONLY) = 6 open(/lib/libc.so.6, O_RDONLY)= 6 open(/lib/libtinfo.so.5, O_RDONLY)= 6 open(/etc/localtime, O_RDONLY)= 6 open(/tmp/php.ini, O_RDONLY) = 6 open(/tmp/php-cli.ini, O_RDONLY) = -1 ENOENT (No such file or directory) open(/etc/php/php-cli.ini, O_RDONLY) = 6 open(/etc/php/conf.d, O_RDONLY|O_NONBLOCK|O_LARGEFILE| O_DIRECTORY) = 6 open(/etc/php/conf.d/pcre.ini, O_RDONLY) = 6 open(/etc/php/conf.d/xml.ini, O_RDONLY) = 6 open(/usr/lib/php//../../../tmp/malicious.so, O_RDONLY) = 6 open(/usr/lib/php/pcre.so, O_RDONLY) = 6 -- Edit bug report at http://bugs.php.net/?id=34793edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34793r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34793r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34793r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34793r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34793r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34793r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34793r=needscript Try newer version: http://bugs.php.net/fix.php?id=34793r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34793r=support Expected behavior: http://bugs.php.net/fix.php?id=34793r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34793r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34793r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34793r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34793r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34793r=dst IIS Stability: http://bugs.php.net/fix.php?id=34793r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34793r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34793r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34793r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34793r=mysqlcfg
#34796 [NEW]: ftp module compiled with openssl extension enabled must be loaded after ssl lib
From: glen at delfi dot ee Operating system: PLD Linux PHP version: 5.1.0RC1 PHP Bug Type: *Compile Issues Bug description: ftp module compiled with openssl extension enabled must be loaded after ssl lib Description: if you configure your php with: --with-openssl=shared --enable-ftp=shared then ftp module is compiled with openssl related functions, but not linked, this causes ftp module loaded earlier in php.ini outputing missing SSL_ symbols $ php -m PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/ftp.so' - /usr/lib/php/ftp.so: undefined symbol: SSL_shutdown in Unknown on line 0 here's patch to fix it. http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/php-ftp-ssllibs.patch NB: applying this patch and compiling --without-openssl is not tested. otherwise it fixes the bug described earlier. -- Edit bug report at http://bugs.php.net/?id=34796edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34796r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34796r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34796r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34796r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34796r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34796r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34796r=needscript Try newer version: http://bugs.php.net/fix.php?id=34796r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34796r=support Expected behavior: http://bugs.php.net/fix.php?id=34796r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34796r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34796r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34796r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34796r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34796r=dst IIS Stability: http://bugs.php.net/fix.php?id=34796r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34796r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34796r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34796r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34796r=mysqlcfg
#34793 [Bgs-Opn]: php-cli searches php.ini from current dir which can be abused
ID: 34793 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee -Status: Bogus +Status: Open -Bug Type: CGI related +Bug Type: Feature/Change Request Operating System: PLD Linux PHP Version: 5.1.0RC1 New Comment: in fact i know that documentation says so. but that doesn't mean it supposed to be like this? can't you at least consider securing it, by adding some option to enable/disable this? so i changed category to feature request! Previous Comments: [2005-10-09 19:14:38] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [2005-10-09 18:13:31] glen at delfi dot ee Description: php cli searches for php.ini from current dir, and when current directory appears to be world writable directory, then malicious user can put there php.ini loading malicious extension. php cli is used for example to install PEAR packages, and for PEAR install to succeed it needs to be run as root. Reproduce code: --- 1. create /tmp/php.ini containing [PHP] extension=/../../../tmp/malicious.so 2. create php extension and save it to /tmp/malicious.so 3. wait for root run any php-cli program in /tmp 4. your code in malicious.so gets executed. Expected result: php should not read php.ini from arbitary locations, it should read it only from hardcoded paths, or one specified from commandline. Actual result: -- $ strace -eopen php -m open(/etc/ld.so.cache, O_RDONLY) = 6 open(/usr/lib/libphp_common-5.1.0RC1.so, O_RDONLY) = 6 open(/lib/libcrypt.so.1, O_RDONLY)= 6 open(/lib/libm.so.6, O_RDONLY)= 6 open(/lib/libz.so.1, O_RDONLY)= 6 open(/lib/libresolv.so.2, O_RDONLY) = 6 open(/lib/libpthread.so.0, O_RDONLY) = 6 open(/usr/lib/libxml2.so.2, O_RDONLY) = 6 open(/lib/libdl.so.2, O_RDONLY) = 6 open(/lib/libhistory.so.5, O_RDONLY) = 6 open(/lib/libreadline.so.5, O_RDONLY) = 6 open(/lib/libncurses.so.5, O_RDONLY) = 6 open(/lib/libc.so.6, O_RDONLY)= 6 open(/lib/libtinfo.so.5, O_RDONLY)= 6 open(/etc/localtime, O_RDONLY)= 6 open(/tmp/php.ini, O_RDONLY) = 6 open(/tmp/php-cli.ini, O_RDONLY) = -1 ENOENT (No such file or directory) open(/etc/php/php-cli.ini, O_RDONLY) = 6 open(/etc/php/conf.d, O_RDONLY|O_NONBLOCK|O_LARGEFILE| O_DIRECTORY) = 6 open(/etc/php/conf.d/pcre.ini, O_RDONLY) = 6 open(/etc/php/conf.d/xml.ini, O_RDONLY) = 6 open(/usr/lib/php//../../../tmp/malicious.so, O_RDONLY) = 6 open(/usr/lib/php/pcre.so, O_RDONLY) = 6 -- Edit this bug report at http://bugs.php.net/?id=34793edit=1
#34796 [Csd-Opn]: ftp module compiled with openssl extension enabled must be loaded after ssl lib
ID: 34796 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee -Status: Closed +Status: Open Bug Type: Compile Failure Operating System: PLD Linux PHP Version: 5.1.0RC1 New Comment: i updated the patch so it will work also with: --disable-openssl --enable-ftp=shared my test compile and run worked ok. get the patch from same URL. Previous Comments: [2005-10-09 22:40:05] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Fix will be in PHP 5.1 and above. [2005-10-09 22:01:49] glen at delfi dot ee Description: if you configure your php with: --with-openssl=shared --enable-ftp=shared then ftp module is compiled with openssl related functions, but not linked, this causes ftp module loaded earlier in php.ini outputing missing SSL_ symbols $ php -m PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/ftp.so' - /usr/lib/php/ftp.so: undefined symbol: SSL_shutdown in Unknown on line 0 here's patch to fix it. http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/php-ftp-ssllibs.patch NB: applying this patch and compiling --without-openssl is not tested. otherwise it fixes the bug described earlier. -- Edit this bug report at http://bugs.php.net/?id=34796edit=1
#34557 [NEW]: php -m exits with error 1
From: glen at delfi dot ee Operating system: PLD Linux PHP version: 5.0.5 PHP Bug Type: Feature/Change Request Bug description: php -m exits with error 1 Description: php -m is documented as: -m Show compiled in modules request to change it to exit 0, if there's no particular reason it to be 1. for example: in a schell script, which has set -e enabled, and running php -m terminates the script. the error exit code is really unexpected, because there's no errors (at least if there were they weren't printed). Reproduce code: --- $ php -m; echo EXIT: $? [PHP Modules] bcmath ftp libxml mhash pcre radius session SimpleXML SPL standard tokenizer xml zlib [Zend Modules] EXIT: 1 -- Edit bug report at http://bugs.php.net/?id=34557edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34557r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34557r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34557r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34557r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34557r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34557r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34557r=needscript Try newer version: http://bugs.php.net/fix.php?id=34557r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34557r=support Expected behavior: http://bugs.php.net/fix.php?id=34557r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34557r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34557r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34557r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34557r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34557r=dst IIS Stability: http://bugs.php.net/fix.php?id=34557r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34557r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34557r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34557r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34557r=mysqlcfg
#20737 [NEW]: PHP has Apache 2 support?
From: [EMAIL PROTECTED] Operating system: Red Hat Linux 7.3 PHP version: 4.3.0RC2 PHP Bug Type: *Configuration Issues Bug description: PHP has Apache 2 support? While configuring 4.3.0RC2 for Apache 2.0.43 (may as well try the latest with the latest, on my first attempt to compile PHP): --- checking for Apache 1.x module support via DSO through APXS... Sorry, I was not able to successfully run APXS. Possible reasons: 1. Perl is not installed; 2. Apache was not compiled with DSO support (--enable-module=so); 3. 'apxs' is not in your path. Try to use --with-apxs=/path/to/apxs The output of /opt/SOFTWARE/apache-2.0/httpd-2.0.43/support/apxs follows ./configure: /opt/SOFTWARE/apache-2.0/httpd-2.0.43/support/apxs: /usr/bin/perl: bad interpreter: Permission denied configure: error: Aborting -- Edit bug report at http://bugs.php.net/?id=20737edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20737r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20737r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20737r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20737r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20737r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20737r=support Expected behavior: http://bugs.php.net/fix.php?id=20737r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20737r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20737r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20737r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20737r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20737r=dst IIS Stability: http://bugs.php.net/fix.php?id=20737r=isapi
#20737 [Opn]: PHP has Apache 2 support?
ID: 20737 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Configuration Issues Operating System: Red Hat Linux 7.3 PHP Version: 4.3.0RC2 New Comment: Perl is configured (5.6.1). The directory for APXS is correct. Apache was configured with DSO support. Previous Comments: [2002-11-30 12:30:01] [EMAIL PROTECTED] While configuring 4.3.0RC2 for Apache 2.0.43 (may as well try the latest with the latest, on my first attempt to compile PHP): --- checking for Apache 1.x module support via DSO through APXS... Sorry, I was not able to successfully run APXS. Possible reasons: 1. Perl is not installed; 2. Apache was not compiled with DSO support (--enable-module=so); 3. 'apxs' is not in your path. Try to use --with-apxs=/path/to/apxs The output of /opt/SOFTWARE/apache-2.0/httpd-2.0.43/support/apxs follows ./configure: /opt/SOFTWARE/apache-2.0/httpd-2.0.43/support/apxs: /usr/bin/perl: bad interpreter: Permission denied configure: error: Aborting -- Edit this bug report at http://bugs.php.net/?id=20737edit=1
#20737 [Bgs-Opn]: PHP has Apache 2 support?
ID: 20737 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: *Configuration Issues Operating System: Red Hat Linux 7.3 PHP Version: 4.3.0RC2 New Comment: /usr/bin/perl -v gives appropriate response. Thus appears to be valid perl interpreter. Previous Comments: [2002-11-30 12:33:38] [EMAIL PROTECTED] /usr/bin/perl: bad interpreter: Permission denied says it all. Not a bug in PHP - bogus Derick [2002-11-30 12:32:28] [EMAIL PROTECTED] Perl is configured (5.6.1). The directory for APXS is correct. Apache was configured with DSO support. [2002-11-30 12:30:01] [EMAIL PROTECTED] While configuring 4.3.0RC2 for Apache 2.0.43 (may as well try the latest with the latest, on my first attempt to compile PHP): --- checking for Apache 1.x module support via DSO through APXS... Sorry, I was not able to successfully run APXS. Possible reasons: 1. Perl is not installed; 2. Apache was not compiled with DSO support (--enable-module=so); 3. 'apxs' is not in your path. Try to use --with-apxs=/path/to/apxs The output of /opt/SOFTWARE/apache-2.0/httpd-2.0.43/support/apxs follows ./configure: /opt/SOFTWARE/apache-2.0/httpd-2.0.43/support/apxs: /usr/bin/perl: bad interpreter: Permission denied configure: error: Aborting -- Edit this bug report at http://bugs.php.net/?id=20737edit=1
#20737 [Opn]: PHP has Apache 2 support?
ID: 20737 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Configuration Issues Operating System: Red Hat Linux 7.3 PHP Version: 4.3.0RC2 New Comment: And, regardless, assuming that PHP has Apache 2 support, the wording in the installation should be changed from ... Apache 1.x module ... No? It is somewhat misleading to someone hitting another bug and wondering whether Apache 2 is supported. Previous Comments: [2002-11-30 12:36:49] [EMAIL PROTECTED] /usr/bin/perl -v gives appropriate response. Thus appears to be valid perl interpreter. [2002-11-30 12:33:38] [EMAIL PROTECTED] /usr/bin/perl: bad interpreter: Permission denied says it all. Not a bug in PHP - bogus Derick [2002-11-30 12:32:28] [EMAIL PROTECTED] Perl is configured (5.6.1). The directory for APXS is correct. Apache was configured with DSO support. [2002-11-30 12:30:01] [EMAIL PROTECTED] While configuring 4.3.0RC2 for Apache 2.0.43 (may as well try the latest with the latest, on my first attempt to compile PHP): --- checking for Apache 1.x module support via DSO through APXS... Sorry, I was not able to successfully run APXS. Possible reasons: 1. Perl is not installed; 2. Apache was not compiled with DSO support (--enable-module=so); 3. 'apxs' is not in your path. Try to use --with-apxs=/path/to/apxs The output of /opt/SOFTWARE/apache-2.0/httpd-2.0.43/support/apxs follows ./configure: /opt/SOFTWARE/apache-2.0/httpd-2.0.43/support/apxs: /usr/bin/perl: bad interpreter: Permission denied configure: error: Aborting -- Edit this bug report at http://bugs.php.net/?id=20737edit=1
#20737 [Opn]: PHP has Apache 2 support?
ID: 20737 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Configuration Issues Operating System: Red Hat Linux 7.3 PHP Version: 4.3.0RC2 New Comment: Since I am commenting anyway, where can one get the PHP-Bug reporting system software. It is rather good. Previous Comments: [2002-11-30 12:39:59] [EMAIL PROTECTED] And, regardless, assuming that PHP has Apache 2 support, the wording in the installation should be changed from ... Apache 1.x module ... No? It is somewhat misleading to someone hitting another bug and wondering whether Apache 2 is supported. [2002-11-30 12:36:49] [EMAIL PROTECTED] /usr/bin/perl -v gives appropriate response. Thus appears to be valid perl interpreter. [2002-11-30 12:33:38] [EMAIL PROTECTED] /usr/bin/perl: bad interpreter: Permission denied says it all. Not a bug in PHP - bogus Derick [2002-11-30 12:32:28] [EMAIL PROTECTED] Perl is configured (5.6.1). The directory for APXS is correct. Apache was configured with DSO support. [2002-11-30 12:30:01] [EMAIL PROTECTED] While configuring 4.3.0RC2 for Apache 2.0.43 (may as well try the latest with the latest, on my first attempt to compile PHP): --- checking for Apache 1.x module support via DSO through APXS... Sorry, I was not able to successfully run APXS. Possible reasons: 1. Perl is not installed; 2. Apache was not compiled with DSO support (--enable-module=so); 3. 'apxs' is not in your path. Try to use --with-apxs=/path/to/apxs The output of /opt/SOFTWARE/apache-2.0/httpd-2.0.43/support/apxs follows ./configure: /opt/SOFTWARE/apache-2.0/httpd-2.0.43/support/apxs: /usr/bin/perl: bad interpreter: Permission denied configure: error: Aborting -- Edit this bug report at http://bugs.php.net/?id=20737edit=1
#18697 [Fbk-Opn]: HTTPS POST crashing
ID: 18697 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: cURL related Operating System: Linux PHP Version: 4.2.3 New Comment: Because this PHP/curl is on a production server with 200 websites, it's not that easy to get a chance to re-compile stuff without breaking scripts. I will re-compile curl with debug symbols at some point over the next few days. For your information: a curl HTTPS POST works fine from the command line. Previous Comments: [2002-10-12 09:46:43] [EMAIL PROTECTED] Compile curl also with debug symbols enabled.. [2002-10-12 09:46:19] [EMAIL PROTECTED] 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 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. As you can see, the bug is in curl itself. [2002-10-12 03:05:22] [EMAIL PROTECTED] Tried CVS snapshop but got exactly the same crash: (gdb) run -X Starting program: /usr/sbin/httpd -X (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x40512813 in RAND_add () from /usr/local/lib/libcurl.so.2 Cannot access memory at address 0x4000 [2002-10-12 02:21:37] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-12 02:10:12] [EMAIL PROTECTED] For your information, this is with libcurl 7.9.8 (OpenSSL 0.9.6). The crashes occur when POSTing to a https URL. curl works fine from the command line. Here is the backtrace output from gdb: Starting program: /usr/sbin/httpd -X (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x4048e813 in RAND_add () from /usr/local/lib/libcurl.so.2 Cannot access memory at address 0x4000 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/18697 -- Edit this bug report at http://bugs.php.net/?id=18697edit=1
#18697 [NoF-Opn]: HTTPS POST crashing
ID: 18697 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Open Bug Type: cURL related Operating System: Linux PHP Version: 4.2.3 New Comment: For your information, this is with libcurl 7.9.8 (OpenSSL 0.9.6). The crashes occur when POSTing to a https URL. curl works fine from the command line. Here is the backtrace output from gdb: Starting program: /usr/sbin/httpd -X (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x4048e813 in RAND_add () from /usr/local/lib/libcurl.so.2 Cannot access memory at address 0x4000 Previous Comments: [2002-09-26 19:51:00] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2002-09-09 05:35:46] [EMAIL PROTECTED] 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 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. [2002-09-09 05:31:19] [EMAIL PROTECTED] Well, just try it without... Derick [2002-09-09 05:29:24] [EMAIL PROTECTED] I also have Zend Optimizer v2.0.0 installed - maybe this could be causing problems? [2002-09-09 03:31:01] [EMAIL PROTECTED] This is still happening with 4.2.3. However, it only seems to occur when posting to HTTPS URL's. I am using libcurl 7.9.8 (SSL 0.9.3) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/18697 -- Edit this bug report at http://bugs.php.net/?id=18697edit=1
#18697 [Fbk-Opn]: HTTPS POST crashing
ID: 18697 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: cURL related Operating System: Linux PHP Version: 4.2.3 New Comment: Tried CVS snapshop but got exactly the same crash: (gdb) run -X Starting program: /usr/sbin/httpd -X (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x40512813 in RAND_add () from /usr/local/lib/libcurl.so.2 Cannot access memory at address 0x4000 Previous Comments: [2002-10-12 02:21:37] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-12 02:10:12] [EMAIL PROTECTED] For your information, this is with libcurl 7.9.8 (OpenSSL 0.9.6). The crashes occur when POSTing to a https URL. curl works fine from the command line. Here is the backtrace output from gdb: Starting program: /usr/sbin/httpd -X (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x4048e813 in RAND_add () from /usr/local/lib/libcurl.so.2 Cannot access memory at address 0x4000 [2002-09-26 19:51:00] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2002-09-09 05:35:46] [EMAIL PROTECTED] 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 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. [2002-09-09 05:31:19] [EMAIL PROTECTED] Well, just try it without... Derick The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/18697 -- Edit this bug report at http://bugs.php.net/?id=18697edit=1
Bug #17310: mail() function has problems with sendmail 8.12
From: [EMAIL PROTECTED] Operating system: FreeBSD 4.6-RC #5 PHP version: 4.2.1 PHP Bug Type: Mail related Bug description: mail() function has problems with sendmail 8.12 I recently upgraded my server to PHP 4.1.2 and sendmail 8.12. Once both upgrades were complete, I can no longer send mail using the PHP mail() function. sendmail 8.12 introduced a number a security features. Among these are the fact that the mail queue directory (/var/spool/mqueue) is now has the permissions 0700; i.e., it's not readable or writeable by anyone other than root. It *appears* (I'm not familiar with PHP internals) that the PHP mail() function attempts to chdir to the /var/spool/mqueue directory. When I attempt to send mail using PHP's mail() function, this is the usual result: May 20 08:07:10 virgil sendmail[667]: NOQUEUE: SYSER(www): can not chdir(/var/spool/mqueue/): Permission denied If I relax the permissions on the mqueue directory, that error goes away and a queue file is created; however, sendmail now reports that there is a bogus queue file in the mqueue directory, and refuses to send it (this is another of sendmail's new security features to prevent unauthorized mail). -- Edit bug report at http://bugs.php.net/?id=17310edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17310r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17310r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17310r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17310r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17310r=support Expected behavior: http://bugs.php.net/fix.php?id=17310r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17310r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17310r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17310r=globals
Bug #17310 Updated: mail() function has problems with sendmail 8.12
ID: 17310 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Mail related Operating System: FreeBSD 4.6-RC #5 PHP Version: 4.2.1 New Comment: Not true. I've confirmed all the sendmail settings, including the setuid bit for the sendmail group. For some reason, something in PHP is trying to chdir to /var/spool/mqueue, which is owned by root and does not have group/world read or write permissions. The problem ONLY occurs with PHP mail(). Previous Comments: [2002-05-20 12:35:30] [EMAIL PROTECTED] This is a configuration issue with Sendmail, not with PHP. PHP is just invoking the sendmail binary (which probably isn't setuid for /var/spool/mqueue). [2002-05-20 11:13:36] [EMAIL PROTECTED] I recently upgraded my server to PHP 4.1.2 and sendmail 8.12. Once both upgrades were complete, I can no longer send mail using the PHP mail() function. sendmail 8.12 introduced a number a security features. Among these are the fact that the mail queue directory (/var/spool/mqueue) is now has the permissions 0700; i.e., it's not readable or writeable by anyone other than root. It *appears* (I'm not familiar with PHP internals) that the PHP mail() function attempts to chdir to the /var/spool/mqueue directory. When I attempt to send mail using PHP's mail() function, this is the usual result: May 20 08:07:10 virgil sendmail[667]: NOQUEUE: SYSER(www): can not chdir(/var/spool/mqueue/): Permission denied If I relax the permissions on the mqueue directory, that error goes away and a queue file is created; however, sendmail now reports that there is a bogus queue file in the mqueue directory, and refuses to send it (this is another of sendmail's new security features to prevent unauthorized mail). -- Edit this bug report at http://bugs.php.net/?id=17310edit=1
Bug #17310 Updated: mail() function has problems with sendmail 8.12
ID: 17310 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Mail related Operating System: FreeBSD 4.6-RC #5 PHP Version: 4.2.1 New Comment: AAaarrgh. I believe you. I also believe what I'm seeing, which is that sendmail, when invoked by PHP, fails with the error. Perhaps it is a sendmail configuration problem, but I've checked and rechecked it over and over again, and everything appears to match the sendmail/SECURITY document. Previous Comments: [2002-05-20 12:52:18] [EMAIL PROTECTED] Nowhere in the mail() code do we do a chdir(). We fetch the sendmail_cmd as configured in the php.ini file, play a bit with the mail() function arguments to get them into the right format and then we open a pipe to the configured sendmail_cmd using a popen() call. Then we fprintf() the data to that open pipe and finally pclose(). If something is doing a chdir() it is not PHP. [2002-05-20 12:46:45] [EMAIL PROTECTED] Ok, let's see what we can do here. Btw, I still think it's an issue not related to PHP. However, try to strace the PHP binary and see if it's really doping the chdir() itself [2002-05-20 12:44:15] [EMAIL PROTECTED] Not true. I've confirmed all the sendmail settings, including the setuid bit for the sendmail group. For some reason, something in PHP is trying to chdir to /var/spool/mqueue, which is owned by root and does not have group/world read or write permissions. The problem ONLY occurs with PHP mail(). [2002-05-20 12:35:30] [EMAIL PROTECTED] This is a configuration issue with Sendmail, not with PHP. PHP is just invoking the sendmail binary (which probably isn't setuid for /var/spool/mqueue). [2002-05-20 11:13:36] [EMAIL PROTECTED] I recently upgraded my server to PHP 4.1.2 and sendmail 8.12. Once both upgrades were complete, I can no longer send mail using the PHP mail() function. sendmail 8.12 introduced a number a security features. Among these are the fact that the mail queue directory (/var/spool/mqueue) is now has the permissions 0700; i.e., it's not readable or writeable by anyone other than root. It *appears* (I'm not familiar with PHP internals) that the PHP mail() function attempts to chdir to the /var/spool/mqueue directory. When I attempt to send mail using PHP's mail() function, this is the usual result: May 20 08:07:10 virgil sendmail[667]: NOQUEUE: SYSER(www): can not chdir(/var/spool/mqueue/): Permission denied If I relax the permissions on the mqueue directory, that error goes away and a queue file is created; however, sendmail now reports that there is a bogus queue file in the mqueue directory, and refuses to send it (this is another of sendmail's new security features to prevent unauthorized mail). -- Edit this bug report at http://bugs.php.net/?id=17310edit=1
Bug #17310 Updated: mail() function has problems with sendmail 8.12
ID: 17310 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Mail related Operating System: FreeBSD 4.6-RC #5 PHP Version: 4.2.1 New Comment: thanks for your assistance. I guess it is a sendmail problem; I scrapped everything and did a make world to reinstall; it's still having problems. I get weirder problems depending upon the command line specified in php.ini. According to the sendmail docs, it's a setgid program, and you should invoke it with -Ac which uses submit.cf. However, THAT (which is supposedly the correct way to do thing) seems to cause some problem with NIS; I get repeated yp_match: RPC timed out errors when I do that. If I invoke sendmail with -t -i, it does not appear to respect the end of file; it reads anything input, and then hangs. Anyway, like you said, probably not a PHP problem, though Lord knows I have no idea what else to do. Been working about 16 hours trying to fix this one. Glen Previous Comments: [2002-05-20 13:44:04] [EMAIL PROTECTED] No doubts, not a PHP issue. [2002-05-20 13:38:01] [EMAIL PROTECTED] Try: su - nobody (or whatever your web user id is) and then run the sendmail command configured in your php.ini file. Most likely sendmail -t -i on a text file that has the various headers and a body in it. See if that works. My guess is that you will have the same problem in which case PHP is completely out of the picture. [2002-05-20 13:28:39] [EMAIL PROTECTED] AAaarrgh. I believe you. I also believe what I'm seeing, which is that sendmail, when invoked by PHP, fails with the error. Perhaps it is a sendmail configuration problem, but I've checked and rechecked it over and over again, and everything appears to match the sendmail/SECURITY document. [2002-05-20 12:52:18] [EMAIL PROTECTED] Nowhere in the mail() code do we do a chdir(). We fetch the sendmail_cmd as configured in the php.ini file, play a bit with the mail() function arguments to get them into the right format and then we open a pipe to the configured sendmail_cmd using a popen() call. Then we fprintf() the data to that open pipe and finally pclose(). If something is doing a chdir() it is not PHP. [2002-05-20 12:46:45] [EMAIL PROTECTED] Ok, let's see what we can do here. Btw, I still think it's an issue not related to PHP. However, try to strace the PHP binary and see if it's really doping the chdir() itself The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/17310 -- Edit this bug report at http://bugs.php.net/?id=17310edit=1
Bug #17310 Updated: mail() function has problems with sendmail 8.12
ID: 17310 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Mail related Operating System: FreeBSD 4.6-RC #5 PHP Version: 4.2.1 New Comment: Damn. I changed /usr/libexec/sendmail/sendmail from setgid to setuid and now everything's working like it's supposed to. Piece of shit software... Previous Comments: [2002-05-20 19:09:24] [EMAIL PROTECTED] thanks for your assistance. I guess it is a sendmail problem; I scrapped everything and did a make world to reinstall; it's still having problems. I get weirder problems depending upon the command line specified in php.ini. According to the sendmail docs, it's a setgid program, and you should invoke it with -Ac which uses submit.cf. However, THAT (which is supposedly the correct way to do thing) seems to cause some problem with NIS; I get repeated yp_match: RPC timed out errors when I do that. If I invoke sendmail with -t -i, it does not appear to respect the end of file; it reads anything input, and then hangs. Anyway, like you said, probably not a PHP problem, though Lord knows I have no idea what else to do. Been working about 16 hours trying to fix this one. Glen [2002-05-20 13:44:04] [EMAIL PROTECTED] No doubts, not a PHP issue. [2002-05-20 13:38:01] [EMAIL PROTECTED] Try: su - nobody (or whatever your web user id is) and then run the sendmail command configured in your php.ini file. Most likely sendmail -t -i on a text file that has the various headers and a body in it. See if that works. My guess is that you will have the same problem in which case PHP is completely out of the picture. [2002-05-20 13:28:39] [EMAIL PROTECTED] AAaarrgh. I believe you. I also believe what I'm seeing, which is that sendmail, when invoked by PHP, fails with the error. Perhaps it is a sendmail configuration problem, but I've checked and rechecked it over and over again, and everything appears to match the sendmail/SECURITY document. [2002-05-20 12:52:18] [EMAIL PROTECTED] Nowhere in the mail() code do we do a chdir(). We fetch the sendmail_cmd as configured in the php.ini file, play a bit with the mail() function arguments to get them into the right format and then we open a pipe to the configured sendmail_cmd using a popen() call. Then we fprintf() the data to that open pipe and finally pclose(). If something is doing a chdir() it is not PHP. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/17310 -- Edit this bug report at http://bugs.php.net/?id=17310edit=1
Bug #15755 Updated: Can't send MAIL
ID: 15755 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Mail related Operating System: Windows 98 PHP Version: 4.1.0 New Comment: I have seen something similar, but it turned out to be nothing at all PHP releated. The \n vs. \r\n makes the difference to some mail transports, and they will reject mail with plain LF characters. That is to say, if you are using \n and NOT \r\n, it will work for SOME destination email addresses but not others and it is entirely dependent on if you have a picky (that is, adhering to standards) or loose (non-standard but common) mail transport in between you and the email address you are sending to. Previous Comments: [2002-02-27 04:43:19] [EMAIL PROTECTED] The mail() function does not seem to work I am using PHP 4.1.0 under apache. This type of script not function: ?php mail([EMAIL PROTECTED], PHP Mail test, Line 1\nLine 2\nLine 3); ? but if i change in this ?php mail([EMAIL PROTECTED], PHP Mail test, Line 1\r\nLine 2\r\nLine 3); ? No problem append.. In php 4.0.6 no problem! This problem is tested only on Windows Platform -- Edit this bug report at http://bugs.php.net/?id=15755edit=1
Bug #12335 Updated: mail() function returns false but the email was sent.
ID: 12335
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Mail related
Operating System: Sun Solaris 2.6
PHP Version: 4.0.6
New Comment:
I am experiencing this behaviour on a Cobalt RaQ3 (Linux)
running PHP 4.1.2. The mail function always returns false,
regardless of whether the mail was sent or not:
if ( mail( '...', '...', '...' ) ) {
echo mail sent okay!;
}
else {
echo mail not sent!;
}
This code will always say mail not sent! whether the mail
has been sent or not.
Previous Comments:
[2002-01-15 03:46:40] [EMAIL PROTECTED]
I also has same trouble with Solaris8+PHP4.1.1+Apache1.3.22.
It seems that, pcloase(inside of mail.c) always return -1.
So php_mail function always return FALSE.
when I remove /usr/lib/sendmail and test mail().
Apache's error_log report that Apache cannot fork sendmail.
but sendmail=popen(...) still return not NULL and pclose()
return -1.
I think that mail.c must fix for apache I/F or not?
[2001-08-07 07:45:11] [EMAIL PROTECTED]
I found out, that the problem is not the EX_OK or EX_TEMPFAIL but the
sendmail return value.
Sendmail (the sendmail qmail wrapper) is returning the value -1 when I
call it with php 4.0.6.
When I call it with 4.0.4pl than 0 is returned.
What could be the reason for this behaviour?
[2001-08-01 05:20:35] [EMAIL PROTECTED]
I had a look on the mail.c sourcecode and I made a change. So I found
the part where the error appears.
But I do not know why, in version 4.0.4pl1 it is the same code and with
this version it works.
This is the extract from mail.c where the error appears:
ret = pclose(sendmail);
#if definded (EX_TEMPFAIL)
if ((ret != EX_OK)(ret != EX_TEMPFAIL)) {
#else
if (ret != EX_OK) {
#endif
return 0;
} else {
return 1;
}
If I change the 0 to 1 than I get true as response of the mail()
function.
So what could be the problem with EX_OK and EX_TEMPFAIL that the same
if query is working in 4.0.4pl1 and not
in 4.0.6? Who is EX_OK and EX_TEMPFAIL defined?
[2001-07-30 01:42:49] [EMAIL PROTECTED]
This was a misunderstanding.
I have the problems with version 4.0.6.
But this machine is not on the internet. Because it's our testmachine.
Our livesystem thats on the internet has version 4.0.4 and we want to
update this machine to 4.0.6 but we can't do
that as long as we have the problem with the mail function. The both
systems are exactly the same.
I wrote this only to explain why I can't put the test script on the
internet.
[2001-07-27 13:27:28] [EMAIL PROTECTED]
So which version of PHP are you using? In your comments
you say 4.0.4 but in the headers there is 4.0.6??
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/12335
--
Edit this bug report at http://bugs.php.net/?id=12335edit=1
