Passing NULL as the pointer to intl_error* will use the global error stack.
This is what we need to do instead of pushing it onto the temporary format object that is released.
When you do an assignment between two zvals (no, not zval*), you copy
all fields. This includes the additional u2 data. So that means for
example the Z_NEXT index gets copied, which in some cases can therefore
cause a cycle in zend_hash lookups.
Instead of doing an assignment, we should be doing a ZVAL_COPY (or
ZVAL_COPY_VALUE for non-refcounting cases). This avoids copying u2.
Closes GH-12086.
When you do an assignment between two zvals (no, not zval*), you copy
all fields. This includes the additional u2 data. So that means for
example the Z_NEXT index gets copied, which in some cases can therefore
cause a cycle in zend_hash lookups.
Instead of doing an assignment, we should be doing a ZVAL_COPY (or
ZVAL_COPY_VALUE for non-refcounting cases). This avoids copying u2.
Closes GH-12086.
We are experiencing an issue when building PHP with DTrace enabled with
SystemTap (see GH-11847).† The issue is caused by inappropriate use C
preprocessor detected by GNU Autoconf in our “configure” script. C
preprocessor configuration found by AC_PROG_CPP macro is portable only
to run on files with “.c” extension.‡ However, statically-defined tracing
is described by D programs with “.d” extension which causes the issue.
We experience this even on typical Linux distribution with GNU Compiler
Collection (GCC) unless we override the defaults detected by our
“configure” script.
Many major Linux distributions use SystemTap to provide “dtrace”
utility. It relies on both external C preprocessor and external C
compiler. C preprocessor can be customized via CPP environment variable.
Similarly, C compiler can be customized via CC environment variable. It
also allows customization of C compiler flags via CFLAGS environment
variable. We have recently aligned both CPP and CC environment variable
with C preprocessor and C compiler we use to build regular C source code
as provided by our “configure” script (see GH-11643).* We wanted to
allow cross-compilation on Linux for which this was the only blocker. C
compiler flags from CFLAGS_CLEAN macro have already been in place since
versions 5.4.20 and 5.5.4 from 2013-09-18.
We had modified all “dtrace” invocations in the same way to make it look
consistent. However, only the C compiler (CC environment variable) is
necessary to for cross-compilation. There have never been any reported
issue with the C preprocessor. We acknowledge it would be great to allow
C preprocessor customization as well. However, the implementation would
require a lot of effort to do correctly given the limitations of
AC_PROG_CPP macro from GNU Autoconf. This would be further complicated
by the fact that all DTrace implementations, not just SystemTap, allow C
preprocessor customization but Oracle DTrace, Open DTrace, and their
forks do it differently. Nevertheless, they all default to “cpp” utility
and they all have or had been working fine. Therefore, we believe simply
removing CPP stabilizes “dtrace” invocation on Linux systems with
SystemTap and aligns it with other system configurations on other
platforms, until someone comes with complete solution with custom “m4”
and “make” macros, while our build system on Linux with SystemTap
supports cross-compilation.
Fixes GH-11847
Closes GH-12083
† https://github.com/php/php-src/issues/11847
‡ https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/autoconf.html#index-AC_005fPROG_005fCPP-1
* https://github.com/php/php-src/issues/11643
We get the following errors:
profiling:./ext/pdo_oci/.libs/oci_statement.gcda:Cannot open
...
It seems these extensions were never tested for coverage. Having coverage here
would be nice, but since they are not actively worked on I don't want to
investigate the issue.
This was an error in thinking on my side. The reason these tests are
unrepeatable is because --repeat executes the same request in the same process,
and does not run the CLEAN section in between runs. This is not the case when
retrying tests.
We could potentially make CLEAN tests repeatable by including the CLEAN section
in the tested script. This does however not work for all tests (e.g. tests that
set open_basedir).
Closes GH-12072
Hopefully, intermittent test failures will be fixed by creating and using a separate database.
Furthermore, more meaningful test cases are added which also assert the output, as well as wildcard character based searching.
Because the error handler is invoked after the property is updated,
the error handler has the opportunity to remove it before the property
is returned.
Switching the order around fixes this issue. The comments mention that
the current ordering prevents overwriting the EG(std_property_info)
field in the error handler. EG(std_property_info) no longer exists as it
was removed in 7471c217. Back then a global was used to store the
returned property info, but as this is no longer the case there is no
longer a need to protect against overwriting a global.
Closes GH-12062.
clang and newer gcc releases support byte-sized atomic accesses on
riscv64 through inline builtins. In both cases the hard dependency on
libatomic added by GH-11321 isn't useful.
Stop using AC_CHECK_LIB() which is too naive to notice that libatomic
isn't needed. Instead, PHP_CHECK_FUNC() will retry the check with -latomic
if required.
Closes GH-11790
This change makes checked and opened file consistent in a way that it is
using real path for stat operation in the same way like it is used for
open.
Closes GH-12067
