Bug #61268 [Csd]: --enable-dtrace leads make to clobber Zend/zend_dtrace.d
Edit report at https://bugs.php.net/bug.php?id=61268&edit=1 ID: 61268 User updated by:mike at harschsystems dot com Reported by:mike at harschsystems dot com Summary:--enable-dtrace leads make to clobber Zend/zend_dtrace.d Status: Closed Type: Bug Package:Compile Failure Operating System: solaris PHP Version:5.4.0 Assigned To:dsp Block user comment: N Private report: N New Comment: Building on solaris/illumos is still broken per the description in bug 62692. I don't know how it reached 'verified' state but it needs to be re-opened and evaluated. Previous Comments: [2013-08-05 22:50:43] s...@php.net The fix for this bug has been committed. 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. [2013-08-05 16:05:25] mike at harschsystems dot com The suggested patch does appear to fix the clobber problem on illumos. This clears the way to hit bug 62692 (which also breaks dtrace on solaris-based systems). Let's fix the issue of not applying the 'dtrace -G' step to the files in Zend/.libs so that we can reach a working state for dtrace on solaris. [2013-08-03 01:14:49] s...@php.net After some investigation, I think the easiest patch is below. This has only been tested on Linux in one install scenario. I'll continuing testing after the weekend. diff --git a/acinclude.m4 b/acinclude.m4 index 07b1f8e..01eabf2 100644 --- a/acinclude.m4 +++ b/acinclude.m4 @@ -2962,8 +2962,12 @@ dnl DTrace objects esac dnl Generate Makefile.objects entries +dnl The empty $ac_provsrc command stops an implicit circular dependency +dnl triggering which lead to the .d file being overwritten with GNU make (Bug 61268) cat>>Makefile.objects< \$[]@ [2013-08-03 01:14:49] s...@php.net Related To: Bug #61268 [2013-07-23 10:54:27] eugene at zhegan dot in Still there on 5.5.1. 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=61268 -- Edit this bug report at https://bugs.php.net/bug.php?id=61268&edit=1
Bug #61268 [Asn]: --enable-dtrace leads make to clobber Zend/zend_dtrace.d
Edit report at https://bugs.php.net/bug.php?id=61268&edit=1 ID: 61268 User updated by:mike at harschsystems dot com Reported by:mike at harschsystems dot com Summary:--enable-dtrace leads make to clobber Zend/zend_dtrace.d Status: Assigned Type: Bug Package:Compile Failure Operating System: solaris PHP Version:5.4.0 Assigned To:dsp Block user comment: N Private report: N New Comment: The suggested patch does appear to fix the clobber problem on illumos. This clears the way to hit bug 62692 (which also breaks dtrace on solaris-based systems). Let's fix the issue of not applying the 'dtrace -G' step to the files in Zend/.libs so that we can reach a working state for dtrace on solaris. Previous Comments: [2013-08-03 01:14:49] s...@php.net After some investigation, I think the easiest patch is below. This has only been tested on Linux in one install scenario. I'll continuing testing after the weekend. diff --git a/acinclude.m4 b/acinclude.m4 index 07b1f8e..01eabf2 100644 --- a/acinclude.m4 +++ b/acinclude.m4 @@ -2962,8 +2962,12 @@ dnl DTrace objects esac dnl Generate Makefile.objects entries +dnl The empty $ac_provsrc command stops an implicit circular dependency +dnl triggering which lead to the .d file being overwritten with GNU make (Bug 61268) cat>>Makefile.objects< \$[]@ [2013-08-03 01:14:49] s...@php.net Related To: Bug #61268 [2013-07-23 10:54:27] eugene at zhegan dot in Still there on 5.5.1. -------- [2013-02-18 16:11:27] mike at harschsystems dot com Change from closed to assigned. -------- [2013-02-18 16:10:16] mike at harschsystems dot com This bug should not be closed unless someone can confirm that the broken behavior has been corrected. The issue is described in detail below. The requested feedback was provided and the issue was reproduced by multiple people on several versions. 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=61268 -- Edit this bug report at https://bugs.php.net/bug.php?id=61268&edit=1
Bug #61268 [Csd->Asn]: --enable-dtrace leads make to clobber Zend/zend_dtrace.d
Edit report at https://bugs.php.net/bug.php?id=61268&edit=1 ID: 61268 User updated by:mike at harschsystems dot com Reported by:mike at harschsystems dot com Summary:--enable-dtrace leads make to clobber Zend/zend_dtrace.d -Status: Closed +Status: Assigned Type: Bug Package:Compile Failure Operating System: solaris PHP Version:5.4.0 Assigned To:dsp Block user comment: N Private report: N New Comment: Change from closed to assigned. Previous Comments: [2013-02-18 16:10:16] mike at harschsystems dot com This bug should not be closed unless someone can confirm that the broken behavior has been corrected. The issue is described in detail below. The requested feedback was provided and the issue was reproduced by multiple people on several versions. [2013-02-18 00:35:43] php-bugs at lists dot php dot net 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. [2012-12-09 16:57:50] mike at harschsystems dot com This bug is still present in 5.5.0 alpha 1. I just reproduced it on Oracle Solaris 11.1. You must run the configure script with '--enable-dtrace' to trigger the failure (and be using gnu make as mentioned already). mharsch@eleven:~/tmp/php-5.5.0alpha1$ uname -a SunOS eleven 5.11 11.1 i86pc i386 i86pc mharsch@eleven:~/tmp/php-5.5.0alpha1$ gmake --version GNU Make 3.82 Built for i386-pc-solaris2.11 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. [2012-11-16 05:48:47] d...@php.net I see what the problem is but cannot reproduce it myself with 5.5.0alpha1. Please try the 5.5.0alpha snapshots from http://downloads.php.net/dsp and provide me with 'uname -a' and 'gmake --version'. ./configure && gmake works fine for me on $ uname -a SunOS foo 5.11 11.0 i86pc i386 i86pc Solaris which is a Oracle Solaris 5.11. $ gmake -- version GNU Make 3.81 ---------------- [2012-05-08 04:35:50] mike at harschsystems dot com I've seen the same failing behavior on 5.4.1 as well. It's worth noting that gmake exhibits this failure mode while regular (non-GNU) make works fine. So, the 2 workarounds are: 1.) run gmake with the '-r' option or 2.) run non-GNU make instead of gmake 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=61268 -- Edit this bug report at https://bugs.php.net/bug.php?id=61268&edit=1
Bug #61268 [NoF->Csd]: --enable-dtrace leads make to clobber Zend/zend_dtrace.d
Edit report at https://bugs.php.net/bug.php?id=61268&edit=1 ID: 61268 User updated by:mike at harschsystems dot com Reported by:mike at harschsystems dot com Summary:--enable-dtrace leads make to clobber Zend/zend_dtrace.d -Status: No Feedback +Status: Closed Type: Bug Package:Compile Failure Operating System: solaris PHP Version:5.4.0 Assigned To:dsp Block user comment: N Private report: N New Comment: This bug should not be closed unless someone can confirm that the broken behavior has been corrected. The issue is described in detail below. The requested feedback was provided and the issue was reproduced by multiple people on several versions. Previous Comments: [2013-02-18 00:35:43] php-bugs at lists dot php dot net 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. [2012-12-09 16:57:50] mike at harschsystems dot com This bug is still present in 5.5.0 alpha 1. I just reproduced it on Oracle Solaris 11.1. You must run the configure script with '--enable-dtrace' to trigger the failure (and be using gnu make as mentioned already). mharsch@eleven:~/tmp/php-5.5.0alpha1$ uname -a SunOS eleven 5.11 11.1 i86pc i386 i86pc mharsch@eleven:~/tmp/php-5.5.0alpha1$ gmake --version GNU Make 3.82 Built for i386-pc-solaris2.11 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. [2012-11-16 05:48:47] d...@php.net I see what the problem is but cannot reproduce it myself with 5.5.0alpha1. Please try the 5.5.0alpha snapshots from http://downloads.php.net/dsp and provide me with 'uname -a' and 'gmake --version'. ./configure && gmake works fine for me on $ uname -a SunOS foo 5.11 11.0 i86pc i386 i86pc Solaris which is a Oracle Solaris 5.11. $ gmake -- version GNU Make 3.81 ---------------- [2012-05-08 04:35:50] mike at harschsystems dot com I've seen the same failing behavior on 5.4.1 as well. It's worth noting that gmake exhibits this failure mode while regular (non-GNU) make works fine. So, the 2 workarounds are: 1.) run gmake with the '-r' option or 2.) run non-GNU make instead of gmake [2012-04-22 13:13:01] alasdairrr at gmail dot com I can confirm I'm seeing this problem too on both Solaris 10 and SmartOS. 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=61268 -- Edit this bug report at https://bugs.php.net/bug.php?id=61268&edit=1
Bug #61268 [Com]: --enable-dtrace leads make to clobber Zend/zend_dtrace.d
Edit report at https://bugs.php.net/bug.php?id=61268&edit=1 ID: 61268 Comment by: mike at harschsystems dot com Reported by:mike at harschsystems dot com Summary:--enable-dtrace leads make to clobber Zend/zend_dtrace.d Status: Feedback Type: Bug Package:Compile Failure Operating System: solaris PHP Version:5.4.0 Assigned To:dsp Block user comment: N Private report: N New Comment: This bug is still present in 5.5.0 alpha 1. I just reproduced it on Oracle Solaris 11.1. You must run the configure script with '--enable-dtrace' to trigger the failure (and be using gnu make as mentioned already). mharsch@eleven:~/tmp/php-5.5.0alpha1$ uname -a SunOS eleven 5.11 11.1 i86pc i386 i86pc mharsch@eleven:~/tmp/php-5.5.0alpha1$ gmake --version GNU Make 3.82 Built for i386-pc-solaris2.11 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Previous Comments: [2012-11-16 05:48:47] d...@php.net I see what the problem is but cannot reproduce it myself with 5.5.0alpha1. Please try the 5.5.0alpha snapshots from http://downloads.php.net/dsp and provide me with 'uname -a' and 'gmake --version'. ./configure && gmake works fine for me on $ uname -a SunOS foo 5.11 11.0 i86pc i386 i86pc Solaris which is a Oracle Solaris 5.11. $ gmake -- version GNU Make 3.81 ------------ [2012-05-08 04:35:50] mike at harschsystems dot com I've seen the same failing behavior on 5.4.1 as well. It's worth noting that gmake exhibits this failure mode while regular (non-GNU) make works fine. So, the 2 workarounds are: 1.) run gmake with the '-r' option or 2.) run non-GNU make instead of gmake [2012-04-22 13:13:01] alasdairrr at gmail dot com I can confirm I'm seeing this problem too on both Solaris 10 and SmartOS. ---------------- [2012-03-03 20:19:39] mike at harschsystems dot com Description: 5.4.0 bundle configured with only one option: --enable-dtrace The configure script runs fine and the build finishes without error. However, the next invocation of make (probably from trying to run 'make install') fails with the following error: [jack@fjpe6maa ~/php-5.4.0]$ make install gcc /home/jack/php-5.4.0/Zend/zend_dtrace.d.o -o /home/jack/php- 5.4.0/Zend/zend_dtrace.d Undefined first referenced symbol in file main/usr/lib/crt1.o php_request_startup /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_execute_internal /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_execute /home/jack/php-5.4.0/Zend/zend_dtrace.d.o php_request_shutdown/home/jack/php-5.4.0/Zend/zend_dtrace.d.o zend_throw_exception_internal /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_compile_file /home/jack/php-5.4.0/Zend/zend_dtrace.d.o $dtrace185178.ZEND_CATCH_SPEC_CONST_CV_HANDLER /home/jack/php- 5.4.0/Zend/zend_dtrace.d.o zend_error_noreturn /home/jack/php-5.4.0/Zend/zend_dtrace.d.o ld: fatal: symbol referencing errors. No output written to /home/jack/php- 5.4.0/Zend/zend_dtrace.d collect2: ld returned 1 exit status make: *** [/home/jack/php-5.4.0/Zend/zend_dtrace.d] Error 1 What's happening here is that make has determined that the file Zend/zend_dtrace.d is out of date and must be rebuilt. It matches a built-in implicit rule that ends up running: gcc /home/jack/php-5.4.0/Zend/zend_dtrace.d.o -o /home/jack/php- 5.4.0/Zend/zend_dtrace.d This command fails with the error that you see, but it also clobbers zend_dtrace.d Here's a bit more detail from 'make -d': Prerequisite `/home/jack/php-5.4.0/Zend/zend_dtrace.d.o' is newer than target `/home/jack/php-5.4.0/Zend/zend_dtrace.d'. Must remake target `/home/jack/php-5.4.0/Zend/zend_dtrace.d'. Invoking builtin recipe to update target `/home/jack/php- 5.4.0/Zend/zend_dtrace.d'. gcc /home/jack/php-5.4.0/Zend/zend_dtrace.d.o -o /home/jack/php- 5.4.0/Zend/zend_dtrace.d Putting child 80bdaa0 (/home/jack/php-5.4.0/Zend/zend_dtrace.d) PID 5104 on the chain. Live child 80bdaa0 (/home/jack/php-5.4.0/Zend/zend_dtrace.d) PID 5104 Undefined first referenced symbol in file main
Bug #61268 [Com]: --enable-dtrace leads make to clobber Zend/zend_dtrace.d
Edit report at https://bugs.php.net/bug.php?id=61268&edit=1 ID: 61268 Comment by: mike at harschsystems dot com Reported by:mike at harschsystems dot com Summary:--enable-dtrace leads make to clobber Zend/zend_dtrace.d Status: Open Type: Bug Package:Compile Failure Operating System: solaris PHP Version:5.4.0 Block user comment: N Private report: N New Comment: I've seen the same failing behavior on 5.4.1 as well. It's worth noting that gmake exhibits this failure mode while regular (non-GNU) make works fine. So, the 2 workarounds are: 1.) run gmake with the '-r' option or 2.) run non-GNU make instead of gmake Previous Comments: [2012-04-22 13:13:01] alasdairrr at gmail dot com I can confirm I'm seeing this problem too on both Solaris 10 and SmartOS. ---- [2012-03-03 20:19:39] mike at harschsystems dot com Description: 5.4.0 bundle configured with only one option: --enable-dtrace The configure script runs fine and the build finishes without error. However, the next invocation of make (probably from trying to run 'make install') fails with the following error: [jack@fjpe6maa ~/php-5.4.0]$ make install gcc /home/jack/php-5.4.0/Zend/zend_dtrace.d.o -o /home/jack/php- 5.4.0/Zend/zend_dtrace.d Undefined first referenced symbol in file main/usr/lib/crt1.o php_request_startup /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_execute_internal /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_execute /home/jack/php-5.4.0/Zend/zend_dtrace.d.o php_request_shutdown/home/jack/php-5.4.0/Zend/zend_dtrace.d.o zend_throw_exception_internal /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_compile_file /home/jack/php-5.4.0/Zend/zend_dtrace.d.o $dtrace185178.ZEND_CATCH_SPEC_CONST_CV_HANDLER /home/jack/php- 5.4.0/Zend/zend_dtrace.d.o zend_error_noreturn /home/jack/php-5.4.0/Zend/zend_dtrace.d.o ld: fatal: symbol referencing errors. No output written to /home/jack/php- 5.4.0/Zend/zend_dtrace.d collect2: ld returned 1 exit status make: *** [/home/jack/php-5.4.0/Zend/zend_dtrace.d] Error 1 What's happening here is that make has determined that the file Zend/zend_dtrace.d is out of date and must be rebuilt. It matches a built-in implicit rule that ends up running: gcc /home/jack/php-5.4.0/Zend/zend_dtrace.d.o -o /home/jack/php- 5.4.0/Zend/zend_dtrace.d This command fails with the error that you see, but it also clobbers zend_dtrace.d Here's a bit more detail from 'make -d': Prerequisite `/home/jack/php-5.4.0/Zend/zend_dtrace.d.o' is newer than target `/home/jack/php-5.4.0/Zend/zend_dtrace.d'. Must remake target `/home/jack/php-5.4.0/Zend/zend_dtrace.d'. Invoking builtin recipe to update target `/home/jack/php- 5.4.0/Zend/zend_dtrace.d'. gcc /home/jack/php-5.4.0/Zend/zend_dtrace.d.o -o /home/jack/php- 5.4.0/Zend/zend_dtrace.d Putting child 80bdaa0 (/home/jack/php-5.4.0/Zend/zend_dtrace.d) PID 5104 on the chain. Live child 80bdaa0 (/home/jack/php-5.4.0/Zend/zend_dtrace.d) PID 5104 Undefined first referenced symbol in file main/usr/lib/crt1.o php_request_startup /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_execute_internal /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_execute /home/jack/php-5.4.0/Zend/zend_dtrace.d.o $dtrace187054.ZEND_CATCH_SPEC_CONST_CV_HANDLER /home/jack/php- 5.4.0/Zend/zend_dtrace.d.o php_request_shutdown/home/jack/php-5.4.0/Zend/zend_dtrace.d.o zend_throw_exception_internal /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_compile_file /home/jack/php-5.4.0/Zend/zend_dtrace.d.o zend_error_noreturn /home/jack/php-5.4.0/Zend/zend_dtrace.d.o ld: fatal: symbol referencing errors. No output written to /home/jack/php- 5.4.0/Zend/zend_dtrace.d collect2: ld returned 1 exit status Reaping losing child 80bdaa0 PID 5104 make: *** [/home/jack/php-5.4.0/Zend/zend_dtrace.d] Error 1 I was able to work-around this issue by disabling built-in implicit rules with 'make -r'. Obviously, I had to recover the clobbered file before this worked. The offending Makefile may be seen here: http://harschsystems.com/bugs/php- 54_sol_dtrace/Makefile.txt For reference: On solaris (and solaris-derived) systems, the compilation of USDT dtrace probes goes something like this: $ dtrace -h -o foo_provider.h -s fo
[PHP-BUG] Bug #61268 [NEW]: --enable-dtrace leads make to clobber Zend/zend_dtrace.d
From: Operating system: solaris PHP version: 5.4.0 Package: Compile Failure Bug Type: Bug Bug description:--enable-dtrace leads make to clobber Zend/zend_dtrace.d Description: 5.4.0 bundle configured with only one option: --enable-dtrace The configure script runs fine and the build finishes without error. However, the next invocation of make (probably from trying to run 'make install') fails with the following error: [jack@fjpe6maa ~/php-5.4.0]$ make install gcc /home/jack/php-5.4.0/Zend/zend_dtrace.d.o -o /home/jack/php- 5.4.0/Zend/zend_dtrace.d Undefined first referenced symbol in file main/usr/lib/crt1.o php_request_startup /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_execute_internal /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_execute /home/jack/php-5.4.0/Zend/zend_dtrace.d.o php_request_shutdown /home/jack/php-5.4.0/Zend/zend_dtrace.d.o zend_throw_exception_internal /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_compile_file /home/jack/php-5.4.0/Zend/zend_dtrace.d.o $dtrace185178.ZEND_CATCH_SPEC_CONST_CV_HANDLER /home/jack/php- 5.4.0/Zend/zend_dtrace.d.o zend_error_noreturn /home/jack/php-5.4.0/Zend/zend_dtrace.d.o ld: fatal: symbol referencing errors. No output written to /home/jack/php- 5.4.0/Zend/zend_dtrace.d collect2: ld returned 1 exit status make: *** [/home/jack/php-5.4.0/Zend/zend_dtrace.d] Error 1 What's happening here is that make has determined that the file Zend/zend_dtrace.d is out of date and must be rebuilt. It matches a built-in implicit rule that ends up running: gcc /home/jack/php-5.4.0/Zend/zend_dtrace.d.o -o /home/jack/php- 5.4.0/Zend/zend_dtrace.d This command fails with the error that you see, but it also clobbers zend_dtrace.d Here's a bit more detail from 'make -d': Prerequisite `/home/jack/php-5.4.0/Zend/zend_dtrace.d.o' is newer than target `/home/jack/php-5.4.0/Zend/zend_dtrace.d'. Must remake target `/home/jack/php-5.4.0/Zend/zend_dtrace.d'. Invoking builtin recipe to update target `/home/jack/php- 5.4.0/Zend/zend_dtrace.d'. gcc /home/jack/php-5.4.0/Zend/zend_dtrace.d.o -o /home/jack/php- 5.4.0/Zend/zend_dtrace.d Putting child 80bdaa0 (/home/jack/php-5.4.0/Zend/zend_dtrace.d) PID 5104 on the chain. Live child 80bdaa0 (/home/jack/php-5.4.0/Zend/zend_dtrace.d) PID 5104 Undefined first referenced symbol in file main/usr/lib/crt1.o php_request_startup /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_execute_internal /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_execute /home/jack/php-5.4.0/Zend/zend_dtrace.d.o $dtrace187054.ZEND_CATCH_SPEC_CONST_CV_HANDLER /home/jack/php- 5.4.0/Zend/zend_dtrace.d.o php_request_shutdown /home/jack/php-5.4.0/Zend/zend_dtrace.d.o zend_throw_exception_internal /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_compile_file /home/jack/php-5.4.0/Zend/zend_dtrace.d.o zend_error_noreturn /home/jack/php-5.4.0/Zend/zend_dtrace.d.o ld: fatal: symbol referencing errors. No output written to /home/jack/php- 5.4.0/Zend/zend_dtrace.d collect2: ld returned 1 exit status Reaping losing child 80bdaa0 PID 5104 make: *** [/home/jack/php-5.4.0/Zend/zend_dtrace.d] Error 1 I was able to work-around this issue by disabling built-in implicit rules with 'make -r'. Obviously, I had to recover the clobbered file before this worked. The offending Makefile may be seen here: http://harschsystems.com/bugs/php- 54_sol_dtrace/Makefile.txt For reference: On solaris (and solaris-derived) systems, the compilation of USDT dtrace probes goes something like this: $ dtrace -h -o foo_provider.h -s foo_provider.d >> Generates header file $ gcc -c foo_src.c $ dtrace -G -o foo_provider.o -s foo_provider.d foo_src.o >> Generates object file $ gcc -o a.out foo_provider.o foo_src.o For more detail, see: http://dtrace.org/blogs/dap/2011/12/13/usdt-providers- redux/ This test system is running an Illumos variant (derived from OpenSolaris). gmake 3.82 This bug deals with the same part of the build system as another bug I filed back in the 5.3 dev branch: https://bugs.php.net/bug.php?id=53338 As these were the only 2 times I've tried compiling php with dtrace, I'd say there should be better test coverage of solaris + --enable-dtrace. Expected result: make shouldn't delete source files Actual result: -- make deletes a source file, rendering the build system inoperable. -- Edit bug report at https://bugs.php.net/bug.php?id=61268&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61268&r=trysnapshot54 Try a snapshot (PHP 5.3):
[PHP-BUG] Req #53348 [NEW]: building with apxs can fail when compiler doesn't match apr library
From: Operating system: Solaris and others PHP version: trunk-SVN-2010-11-18 (SVN) Package: Compile Failure Bug Type: Feature/Change Request Bug description:building with apxs can fail when compiler doesn't match apr library Description: The build system uses the apr-1-config command to retrieve flags from the apr library to use for building shared object targets (e.g. sapi/apache2handler/config.m4). If however, the compiler used to build the apr library was different (and supports different flags) than your current compiler, you may end up with incompatible compiler flags in your Makefile for these targets. This problem manifests itself in Solaris when trying to build php using gcc, while trying to use the binary version of apache shipped with your distribution (which was compiled with sun's forte compiler 'cc'). The first symptom from the user's perspective is the following compile failure: mkdir sapi/apache2handler/.libs cc -DSSL_EXPERIMENTAL -DSSL_ENGINE -I/usr/apache2/2.2/include -DSOLARIS2=11 - D_POSIX_PTHREAD_SEMANTICS -mt -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 - I/usr/apr/1.3/include -I/usr/apr-util/1.3/include - I/wd/builds/sfw/proto/root_i386/usr/include -Isapi/apache2handler/ - I/var/tmp/php-trunk/sapi/apache2handler/ -DPHP_ATOM_INC -I/var/tmp/php- trunk/include -I/var/tmp/php-trunk/main -I/var/tmp/php-trunk -I/var/tmp/php- trunk/ext/date/lib -I/var/tmp/php-trunk/ext/ereg/regex -I/usr/include/libxml2 - I/usr/X11/include -I/usr/include/freetype2 -I/var/tmp/php- trunk/ext/mbstring/oniguruma -I/var/tmp/php-trunk/ext/mbstring/libmbfl - I/var/tmp/php-trunk/ext/mbstring/libmbfl/mbfl -I/var/tmp/php- trunk/ext/sqlite3/libsqlite -I/usr/include/tidy -I/var/tmp/php-trunk/TSRM - I/var/tmp/php-trunk/Zend -D_POSIX_PTHREAD_SEMANTICS -I/usr/include -g -O0 -Wall -c /var/tmp/php-trunk/sapi/apache2handler/mod_php5.c -fPIC -DPIC -o sapi/apache2handler/.libs/mod_php5.o cc1: error: invalid option `t' make: *** [sapi/apache2handler/mod_php5.lo] Error 1 The error is coming from the "-mt" flag, which gcc doesn't understand. It turns out, "-mt" is a valid sun forte 'cc' flag. Where did this come from? Looking at sapi/apache2handler/config.m4, we see the build system asking apr for cpp flags like this: $ apxs -q APR_CONFIG /usr/apr/1.3/bin/apr-1-config $ apr-1-config --cppflags --includes -DSOLARIS2=11 -D_POSIX_PTHREAD_SEMANTICS -mt -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -I/usr/apr/1.3/include Asking apr about compiler it's built with shows the problem (it's not gcc): $ apr-1-config --cc cc -m32 In this case, some googling revealed that "-mt" is equivalent to "-D_REENTRANT", so manually replacing these flags in the Makefile works around the problem. It would be nice if the build system did a check to see if `APR_CONFIG --cc` matches the current compiler - and warns you if there is a mismatch. Also, it would be nice to have an override switch to specify the flags to use manually, rather than deriving them from apr. Test script: --- This problem is reproducible on solaris when trying to compile php with gcc, and using --with-apxs2 pointing to an apache binary built with sun's cc rather than gcc (as is the case if using the ips packages available for opensolaris, etc). -- Edit bug report at http://bugs.php.net/bug.php?id=53348&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53348&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53348&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53348&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53348&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53348&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53348&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53348&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53348&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53348&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53348&r=support Expected behavior: http://bugs.php.net/fix.php?id=53348&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53348&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53348&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53348&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53348&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53348&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53348&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53348
Bug #37651 [Com]: buildconf fails with error code 1
Edit report at http://bugs.php.net/bug.php?id=37651&edit=1 ID: 37651 Comment by: mike at harschsystems dot com Reported by:ktrinczek at bfs dot de Summary:buildconf fails with error code 1 Status: Bogus Type: Bug Package:Compile Failure Operating System: Solaris 10 PHP Version:5CVS-2006-05-31 (snap) Block user comment: N Private report: N New Comment: buildconf expects the gnu version of the 'find' command - which accepts the -not flag. The root user on solaris (by default) doesn't have gfind in it's PATH: # which find /usr/bin/find whereas (at least on modern solaris distributions), regular users have gfind in their path by default: $ which find /usr/gnu/bin/find Previous Comments: [2006-06-01 10:48:41] ktrinczek at bfs dot de That was it. BUILDCONF runs through. But what's doing make here? /bin/sh /tmp/php5.2-200605311030/libtool --silent --preserve-dup-deps --mode=compile gcc -I"/usr/local/include" -Iext/iconv/ -I/tmp/php5.2-200605311030/ext/iconv/ -DPHP_ATOM_INC -I/tmp/php5.2-200605311030/include -I/tmp/php5.2-200605311030/main -I/tmp/php5.2-200605311030 -I/usr/local/include/libxml2 -I/opt/csw/include -I/usr/local/include -I/tmp/php5.2-200605311030/ext/date/lib -I/tmp/php5.2-200605311030/ext/mbstring/oniguruma -I/tmp/php5.2-200605311030/ext/mbstring/libmbfl -I/tmp/php5.2-200605311030/ext/mbstring/libmbfl/mbfl -I/usr/sfw/include/mysql -I/tmp/php5.2-200605311030/TSRM -I/tmp/php5.2-200605311030/Zend -D_POSIX_PTHREAD_SEMANTICS -I/usr/local/include -g -O2 -c /tmp/php5.2-200605311030/ext/iconv/iconv.c -o ext/iconv/iconv.lo /tmp/php5.2-200605311030/ext/iconv/iconv.c: In function `_php_iconv_appendl': /tmp/php5.2-200605311030/ext/iconv/iconv.c:254: warning: passing arg 2 of `libiconv' from incompatible pointer type /tmp/php5.2-200605311030/ext/iconv/iconv.c: In function `php_iconv_string': /tmp/php5.2-200605311030/ext/iconv/iconv.c:414: warning: passing arg 2 of `libiconv' from incompatible pointer type /tmp/php5.2-200605311030/ext/iconv/iconv.c: In function `_php_iconv_strlen': /tmp/php5.2-200605311030/ext/iconv/iconv.c:528: warning: passing arg 2 of `libiconv' from incompatible pointer type /tmp/php5.2-200605311030/ext/iconv/iconv.c: In function `_php_iconv_substr': /tmp/php5.2-200605311030/ext/iconv/iconv.c:641: warning: passing arg 2 of `libiconv' from incompatible pointer type /tmp/php5.2-200605311030/ext/iconv/iconv.c: In function `_php_iconv_strpos': /tmp/php5.2-200605311030/ext/iconv/iconv.c:772: warning: passing arg 2 of `libiconv' from incompatible pointer type /tmp/php5.2-200605311030/ext/iconv/iconv.c: In function `_php_iconv_mime_encode': /tmp/php5.2-200605311030/ext/iconv/iconv.c:1021: warning: passing arg 2 of `libiconv' from incompatible pointer type /tmp/php5.2-200605311030/ext/iconv/iconv.c:1121: warning: passing arg 2 of `libiconv' from incompatible pointer type /tmp/php5.2-200605311030/ext/iconv/iconv.c: In function `php_iconv_stream_filter_append_bucket': /tmp/php5.2-200605311030/ext/iconv/iconv.c:2379: warning: passing arg 2 of `libiconv' from incompatible pointer type /tmp/php5.2-200605311030/ext/iconv/iconv.c:2458: warning: passing arg 2 of `libiconv' from incompatible pointer type /bin/sh /tmp/php5.2-200605311030/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/ldap/ -I/tmp/php5.2-200605311030/ext/ldap/ -DPHP_ATOM_INC -I/tmp/php5.2-200605311030/include -I/tmp/php5.2-200605311030/main -I/tmp/php5.2-200605311030 -I/usr/local/include/libxml2 -I/opt/csw/include -I/usr/local/include -I/tmp/php5.2-200605311030/ext/date/lib -I/tmp/php5.2-200605311030/ext/mbstring/oniguruma -I/tmp/php5.2-200605311030/ext/mbstring/libmbfl -I/tmp/php5.2-200605311030/ext/mbstring/libmbfl/mbfl -I/usr/sfw/include/mysql -I/tmp/php5.2-200605311030/TSRM -I/tmp/php5.2-200605311030/Zend -D_POSIX_PTHREAD_SEMANTICS -I/usr/local/include -g -O2 -c /tmp/php5.2-200605311030/ext/ldap/ldap.c -o ext/ldap/ldap.lo /tmp/php5.2-200605311030/ext/ldap/ldap.c: In function `_php_sasl_setdefs': /tmp/php5.2-200605311030/ext/ldap/ldap.c:506: warning: assignment makes pointer from integer without a cast /tmp/php5.2-200605311030/ext/ldap/ldap.c:507: warning: pointer/integer type mismatch in conditional expression /tmp/php5.2-200605311030/ext/ldap/ldap.c:508: warning: pointer/integer type mismatch in conditional expression /tmp/php5.2-200605311030/ext/ldap/ldap.c:509: warning: pointer/integer type mismatch in conditional expression /tmp/php5.2-200605311030/ext/ldap/ldap.c:510: warning: pointer/integer type mismatch in conditional expression /tmp/php5.2-200605311030/ext/ldap/ldap.c:511: warning: pointer/integer type mismatch in conditional expression /tmp
Bug #53338 [Asn]: DTrace build config broken by Rev 305329
Edit report at http://bugs.php.net/bug.php?id=53338&edit=1 ID: 53338 User updated by:mike at harschsystems dot com Reported by:mike at harschsystems dot com Summary:DTrace build config broken by Rev 305329 Status: Assigned Type: Bug Package:Compile Failure Operating System: Solaris and OS X PHP Version:trunk-SVN-2010-11-18 (snap) Assigned To:jani Block user comment: N Private report: N New Comment: 2.) I think it was main/main.c which includes zend_dtrace.h which includes zend_dtrace_gen.h, but this problem seems to be fixed by placing the 'dtrace -h' line earlier in the Makefile (which now seems to be the case as of 201011181330). 3.) http://pastebin.com/33TJyLC2 - see line 498. I was able to work around this problem by changing the following line in acinclude.m4: dtrace -h -C -s $ac_srcdir[$]ac_provsrc -o \$[]@ && \$(SED) -ibak 's,PHP_,DTRACE_,g' \$[]@ to dtrace -h -C -s $abs_srcdir/[$]ac_provsrc -o \$[]@ && \$(SED) -ibak 's,PHP_,DTRACE_,g' \$[]@ Once this is fixed, the build appears to work on both Solaris and OS X using Rev 305487. Previous Comments: [2010-11-18 14:37:45] d...@php.net 1) So providerdesc.o is only build and linked with when under Solaris? yes because dtrace on Solaris generates stubs that need to be compiled in. On Mac OS the necessary switch to generate providerdesc.o doesn't exist on Mac OS. [2010-11-18 11:11:38] j...@php.net Automatic comment from SVN on behalf of jani Revision: http://svn.php.net/viewvc/?view=revision&revision=305487 Log: - Fixed DTrace support in MacOSX (bug #53338) [2010-11-18 09:53:03] j...@php.net 1) So providerdesc.o is only build and linked with when under Solaris? 2) What in Makefile did depend on the header file before it was created? 3) I need the generated Makefile you got with current trunk (without your patch!) [2010-11-18 09:44:09] j...@php.net Me break, me fix. :) ---------------- [2010-11-18 06:39:42] mike at harschsystems dot com I can't seem to upload the patch file. Please refer to the patch file contents here: http://pastebin.com/SZnvz3L0 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=53338 -- Edit this bug report at http://bugs.php.net/bug.php?id=53338&edit=1
Bug #53338 [Opn]: DTrace build config broken by Rev 305329
Edit report at http://bugs.php.net/bug.php?id=53338&edit=1 ID: 53338 User updated by:mike at harschsystems dot com Reported by:mike at harschsystems dot com Summary:DTrace build config broken by Rev 305329 Status: Open Type: Bug Package:Compile Failure Operating System: Solaris and OS X PHP Version:trunk-SVN-2010-11-18 (snap) Block user comment: N Private report: N New Comment: I can't seem to upload the patch file. Please refer to the patch file contents here: http://pastebin.com/SZnvz3L0 Previous Comments: [2010-11-18 06:30:14] mike at harschsystems dot com Description: The changes made in Rev 305329 break the --enable-dtrace configuration option on both Solaris and OS X. The main problems I was able to identify are: 1.) The steps required to build DTrace-enabled binaries are different on Solaris and OS X (see references below). 305329 removed the platform check that allowed OS X to bypass the extra linking step required by Solaris (dtrace -G -s ...). 2.) The generation of the DTrace header file (zend_dtrace_gen.h via 'dtrace -h ...') was moved to Makefile (from configure) - this broke various targets that depended on the header file prior to it's generation (late in the Makefile). 3.) A typo (I think) in the path variable used to generate the DTrace targets injected junk into the pathnames, breaking the build. The included patch file "dtrace_build.patch" may be applied to Rev 305455 to resolve these issues. It essentially re-enlists some of the functionality that existed prior to 305329. This has been tested on both OS X and Solaris. Examples of how to build DTrace USDT probes on Solaris, see: http://dtrace.org/blogs/ahl/2006/05/08/user-land-tracing-gets-better-and-better/ and http://blogs.sun.com/dap/entry/writing_a_dtrace_usdt_provider For the relevant documentation on OS X, see the dtrace(1M) man page: http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/ man1/dtrace.1.html Expected result: --enable-dtrace should configure and build on platforms that have DTrace (Solaris and OS X - maybe FreeBSD?) Actual result: -- --enable-dtrace fails on both platforms for the reasons mentioned in the Description section. -- Edit this bug report at http://bugs.php.net/bug.php?id=53338&edit=1
[PHP-BUG] Bug #53338 [NEW]: DTrace build config broken by Rev 305329
From: Operating system: Solaris and OS X PHP version: trunk-SVN-2010-11-18 (snap) Package: Compile Failure Bug Type: Bug Bug description:DTrace build config broken by Rev 305329 Description: The changes made in Rev 305329 break the --enable-dtrace configuration option on both Solaris and OS X. The main problems I was able to identify are: 1.) The steps required to build DTrace-enabled binaries are different on Solaris and OS X (see references below). 305329 removed the platform check that allowed OS X to bypass the extra linking step required by Solaris (dtrace -G -s ...). 2.) The generation of the DTrace header file (zend_dtrace_gen.h via 'dtrace -h ...') was moved to Makefile (from configure) - this broke various targets that depended on the header file prior to it's generation (late in the Makefile). 3.) A typo (I think) in the path variable used to generate the DTrace targets injected junk into the pathnames, breaking the build. The included patch file "dtrace_build.patch" may be applied to Rev 305455 to resolve these issues. It essentially re-enlists some of the functionality that existed prior to 305329. This has been tested on both OS X and Solaris. Examples of how to build DTrace USDT probes on Solaris, see: http://dtrace.org/blogs/ahl/2006/05/08/user-land-tracing-gets-better-and-better/ and http://blogs.sun.com/dap/entry/writing_a_dtrace_usdt_provider For the relevant documentation on OS X, see the dtrace(1M) man page: http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/ man1/dtrace.1.html Expected result: --enable-dtrace should configure and build on platforms that have DTrace (Solaris and OS X - maybe FreeBSD?) Actual result: -- --enable-dtrace fails on both platforms for the reasons mentioned in the Description section. -- Edit bug report at http://bugs.php.net/bug.php?id=53338&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53338&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53338&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53338&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53338&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53338&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53338&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53338&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53338&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53338&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53338&r=support Expected behavior: http://bugs.php.net/fix.php?id=53338&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53338&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53338&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53338&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53338&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53338&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53338&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53338&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53338&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53338&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53338&r=mysqlcfg
Bug #53306 [Asn]: php crashes with segfault when DTrace "exception-thrown" probe fires
Edit report at http://bugs.php.net/bug.php?id=53306&edit=1
ID: 53306
User updated by:mike at harschsystems dot com
Reported by:mike at harschsystems dot com
Summary:php crashes with segfault when DTrace
"exception-thrown" probe fires
Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: Mac OS X and Solaris
PHP Version:trunk-SVN-2010-11-13 (snap)
Assigned To:dsp
Block user comment: N
New Comment:
With the patch in place, I can use the following DTrace script to see
exceptions
getting thrown and caught (differentiating those with null input from
those with
valid pointers):
#!/usr/sbin/dtrace -s
#pragma D option quiet
php*:::exception-thrown
/arg0 == NULL/
{
printf("PHP Exception Thrown. Classname: Unknown\n");
}
php*:::exception-thrown
/arg0 != NULL/
{
printf("PHP Exception Thrown. ");
printf("Classname: %s\n", copyinstr(arg0));
}
php*:::exception-caught
{
printf("PHP Exception Caught. ");
printf("Classname: %s\n", copyinstr(arg0));
}
Running this script with the trivial exception script mentioned in this
bug,
produces the following output:
# ./php_exception.d
PHP Exception Thrown. Classname: Exception
PHP Exception Thrown. Classname: Unknown
PHP Exception Caught. Classname: Exception
^C
So, we see that 2 exceptions are being thrown (one with a valid pointer
and one
with a null pointer), and one exception is caught.
Previous Comments:
----------------
[2010-11-13 23:25:12] mike at harschsystems dot com
sorry, just uploaded patch file "exception_fix2.patch"
[2010-11-13 23:19:49] fel...@php.net
Where is the patch?
----------------
[2010-11-13 23:12:55] mike at harschsystems dot com
Description:
When DTrace is present, and a DTrace consumer has enabled the
"php*:::exception-
thrown" probe, php will crash when the probe fires, due to a null
reference passed
to zend_get_object_classname() from within the probe context. The code
within the
DTrace probe context (inside zend_throw_exception_internal() ) doesn't
check that
the 'exception' argument is non-NULL. The test described here obviously
creates
an instance where 'exception' is NULL, and when the enabled probe fires
- the
enabled code calls zend_get_object_classname() with a null argument,
resulting in
the segfault.
Test script:
---
In order to reproduce this, you must be running on a system that
supports DTrace (OS X, Solaris, FreeBSD?), and php must have been built
with --enable-dtrace.
The following script will trigger the exception codepath we're
interested in:
Test for PHP Exceptions
attempting to call my_func with my_arg == 0';
my_func(0);
echo 'this will not be executed';
} catch (Exception $e) {
echo "caught exception: " . $e->getMessage();
}
?>
This will run fine when DTrace hasn't enabled the exception-thrown
probe, but if we run the following command (as root) at the time that
the above script is requested, php will crash.
# dtrace -n 'php*:::exception-thrown {}'
The attached patch shows how the problem could be avoided - though I'd
like to hear from someone familiar with the Zend framework - to see if
there may be an upstream bug that's causing the NULL value to come into
zend_throw_exception_internal() in the first place. If this is expected
behavior, we should anticipate it and provide appropriate handling
within the DTrace probe.
Expected result:
PHP shouldn't crash.
Actual result:
--
PHP crashes as shown:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0008
0x00010156818b in zend_get_object_classname (object=0x0,
class_name=0x7fff5fbfeb60,
class_name_len=0x7fff5fbfeb6c) at
/Users/michaelharsch/Desktop/php-trunk-
201011131530/Zend/zend_API.c:253
253 if (Z_OBJ_HT_P(object)->get_class_name == NULL ||
(gdb) bt
#0 0x00010156818b in zend_get_object_classname (object=0x0,
class_name=0x7fff5fbfeb60,
class_name_len=0x7fff5fbfeb6c) at
/Users/michaelharsch/Desktop/php-trunk-
201011131530/Zend/zend_API.c:253
#1 0x000101589e2e in zend_throw_exception_internal (exception=0x0)
at
/Users/michaelharsch/Desktop/php-trunk-
201011131530/Zend/zend_exceptions.c:90
#2 0x0001015a6543 in zend_do_fcall_common_helper_SPEC
(execute_data=0x10051a0d8) at zend_vm_execute.h:7
Bug #53306 [Com]: php crashes with segfault when DTrace "exception-thrown" probe fires
Edit report at http://bugs.php.net/bug.php?id=53306&edit=1
ID: 53306
Comment by: mike at harschsystems dot com
Reported by:mike at harschsystems dot com
Summary:php crashes with segfault when DTrace
"exception-thrown" probe fires
Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: Mac OS X and Solaris
PHP Version:trunk-SVN-2010-11-13 (snap)
Block user comment: N
New Comment:
sorry, just uploaded patch file "exception_fix2.patch"
Previous Comments:
[2010-11-13 23:19:49] fel...@php.net
Where is the patch?
----
[2010-11-13 23:12:55] mike at harschsystems dot com
Description:
When DTrace is present, and a DTrace consumer has enabled the
"php*:::exception-
thrown" probe, php will crash when the probe fires, due to a null
reference passed
to zend_get_object_classname() from within the probe context. The code
within the
DTrace probe context (inside zend_throw_exception_internal() ) doesn't
check that
the 'exception' argument is non-NULL. The test described here obviously
creates
an instance where 'exception' is NULL, and when the enabled probe fires
- the
enabled code calls zend_get_object_classname() with a null argument,
resulting in
the segfault.
Test script:
---
In order to reproduce this, you must be running on a system that
supports DTrace (OS X, Solaris, FreeBSD?), and php must have been built
with --enable-dtrace.
The following script will trigger the exception codepath we're
interested in:
Test for PHP Exceptions
attempting to call my_func with my_arg == 0';
my_func(0);
echo 'this will not be executed';
} catch (Exception $e) {
echo "caught exception: " . $e->getMessage();
}
?>
This will run fine when DTrace hasn't enabled the exception-thrown
probe, but if we run the following command (as root) at the time that
the above script is requested, php will crash.
# dtrace -n 'php*:::exception-thrown {}'
The attached patch shows how the problem could be avoided - though I'd
like to hear from someone familiar with the Zend framework - to see if
there may be an upstream bug that's causing the NULL value to come into
zend_throw_exception_internal() in the first place. If this is expected
behavior, we should anticipate it and provide appropriate handling
within the DTrace probe.
Expected result:
PHP shouldn't crash.
Actual result:
--
PHP crashes as shown:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0008
0x00010156818b in zend_get_object_classname (object=0x0,
class_name=0x7fff5fbfeb60,
class_name_len=0x7fff5fbfeb6c) at
/Users/michaelharsch/Desktop/php-trunk-
201011131530/Zend/zend_API.c:253
253 if (Z_OBJ_HT_P(object)->get_class_name == NULL ||
(gdb) bt
#0 0x00010156818b in zend_get_object_classname (object=0x0,
class_name=0x7fff5fbfeb60,
class_name_len=0x7fff5fbfeb6c) at
/Users/michaelharsch/Desktop/php-trunk-
201011131530/Zend/zend_API.c:253
#1 0x000101589e2e in zend_throw_exception_internal (exception=0x0)
at
/Users/michaelharsch/Desktop/php-trunk-
201011131530/Zend/zend_exceptions.c:90
#2 0x0001015a6543 in zend_do_fcall_common_helper_SPEC
(execute_data=0x10051a0d8) at zend_vm_execute.h:735
#3 0x0001015acc98 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x10051a0d8) at zend_vm_execute.h:2015
#4 0x0001015a4075 in execute (op_array=0x10054f030) at
zend_vm_execute.h:410
#5 0x00010154e6e5 in dtrace_execute (op_array=0x10054f030) at
/Users/michaelharsch/Desktop/php-trunk-
201011131530/Zend/zend_dtrace.c:75
#6 0x0001015674c6 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at
/Users/michaelharsch/Desktop/php-trunk-201011131530/Zend/zend.c:1195
#7 0x0001014d28e3 in php_execute_script
(primary_file=0x7fff5fbff810) at
/Users/michaelharsch/Desktop/php-trunk-
201011131530/main/main.c:2340
#8 0x0001016a39c5 in php_handler (r=0x10098a2a8) at
/Users/michaelharsch/Desktop/php-trunk-
201011131530/sapi/apache2handler/sapi_apache2.c:667
#9 0x000121db in ap_run_handler ()
#10 0x00012aba in ap_invoke_handler ()
#11 0x00010002f738 in ap_process_request ()
#12 0x00010002bfa9 in ap_process_http_connection ()
#13 0x000100013737 in ap_run_process_connection ()
#14 0x000100013bd1 in ap_process_connection ()
#15 0x0001000363f2 in child_main ()
#16 0x0001000364dc in make_child ()
#17 0x000100036aaf in ap_mpm_ru
[PHP-BUG] Bug #53306 [NEW]: php crashes with segfault when DTrace "exception-thrown" probe fires
From:
Operating system: Mac OS X and Solaris
PHP version: trunk-SVN-2010-11-13 (snap)
Package: Reproducible crash
Bug Type: Bug
Bug description:php crashes with segfault when DTrace "exception-thrown" probe
fires
Description:
When DTrace is present, and a DTrace consumer has enabled the
"php*:::exception-
thrown" probe, php will crash when the probe fires, due to a null reference
passed
to zend_get_object_classname() from within the probe context. The code
within the
DTrace probe context (inside zend_throw_exception_internal() ) doesn't
check that
the 'exception' argument is non-NULL. The test described here obviously
creates
an instance where 'exception' is NULL, and when the enabled probe fires -
the
enabled code calls zend_get_object_classname() with a null argument,
resulting in
the segfault.
Test script:
---
In order to reproduce this, you must be running on a system that supports
DTrace (OS X, Solaris, FreeBSD?), and php must have been built with
--enable-dtrace.
The following script will trigger the exception codepath we're interested
in:
Test for PHP Exceptions
attempting to call my_func with my_arg == 0';
my_func(0);
echo 'this will not be executed';
} catch (Exception $e) {
echo "caught exception: " . $e->getMessage();
}
?>
This will run fine when DTrace hasn't enabled the exception-thrown probe,
but if we run the following command (as root) at the time that the above
script is requested, php will crash.
# dtrace -n 'php*:::exception-thrown {}'
The attached patch shows how the problem could be avoided - though I'd like
to hear from someone familiar with the Zend framework - to see if there may
be an upstream bug that's causing the NULL value to come into
zend_throw_exception_internal() in the first place. If this is expected
behavior, we should anticipate it and provide appropriate handling within
the DTrace probe.
Expected result:
PHP shouldn't crash.
Actual result:
--
PHP crashes as shown:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0008
0x00010156818b in zend_get_object_classname (object=0x0,
class_name=0x7fff5fbfeb60,
class_name_len=0x7fff5fbfeb6c) at /Users/michaelharsch/Desktop/php-trunk-
201011131530/Zend/zend_API.c:253
253 if (Z_OBJ_HT_P(object)->get_class_name == NULL ||
(gdb) bt
#0 0x00010156818b in zend_get_object_classname (object=0x0,
class_name=0x7fff5fbfeb60,
class_name_len=0x7fff5fbfeb6c) at /Users/michaelharsch/Desktop/php-trunk-
201011131530/Zend/zend_API.c:253
#1 0x000101589e2e in zend_throw_exception_internal (exception=0x0) at
/Users/michaelharsch/Desktop/php-trunk-
201011131530/Zend/zend_exceptions.c:90
#2 0x0001015a6543 in zend_do_fcall_common_helper_SPEC
(execute_data=0x10051a0d8) at zend_vm_execute.h:735
#3 0x0001015acc98 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x10051a0d8) at zend_vm_execute.h:2015
#4 0x0001015a4075 in execute (op_array=0x10054f030) at
zend_vm_execute.h:410
#5 0x00010154e6e5 in dtrace_execute (op_array=0x10054f030) at
/Users/michaelharsch/Desktop/php-trunk-
201011131530/Zend/zend_dtrace.c:75
#6 0x0001015674c6 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at
/Users/michaelharsch/Desktop/php-trunk-201011131530/Zend/zend.c:1195
#7 0x0001014d28e3 in php_execute_script (primary_file=0x7fff5fbff810)
at
/Users/michaelharsch/Desktop/php-trunk-
201011131530/main/main.c:2340
#8 0x0001016a39c5 in php_handler (r=0x10098a2a8) at
/Users/michaelharsch/Desktop/php-trunk-
201011131530/sapi/apache2handler/sapi_apache2.c:667
#9 0x000121db in ap_run_handler ()
#10 0x00012aba in ap_invoke_handler ()
#11 0x00010002f738 in ap_process_request ()
#12 0x00010002bfa9 in ap_process_http_connection ()
#13 0x000100013737 in ap_run_process_connection ()
#14 0x000100013bd1 in ap_process_connection ()
#15 0x0001000363f2 in child_main ()
#16 0x0001000364dc in make_child ()
#17 0x000100036aaf in ap_mpm_run ()
#18 0x0001a821 in main ()
--
Edit bug report at http://bugs.php.net/bug.php?id=53306&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53306&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53306&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53306&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53306&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53306&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53306&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53306&r=needtrace
Nee
