THIS IS A REPOST, PREVIOUS POST GOT CLOSED, MOVED TO SERVERFAULT AND CLOSED AGAIN. I think this post is a valid stackoverflow problem because i think its caused by some automake/compile/linking error. This is a programming problem not a server admin problem.
Cross compile PHP
https://serverfault.com/questions/418521/cross-compile-php
Start of post
I have downloaded the PHP 5.4.0 source, extracted it and moved into the source folder.
I do a configure with:
./configure --build=x86_64-unknown-linux-gnu --host=arm-linux-uclibcgnueabi --prefix=/usr/arm/www CC="arm-linux-uclibcgnueabi-gcc --sysroot=/toolchains/gnu_cortex-a9_tools/" --disable-libxml --disable-dom --without-iconv --without-openssl --disable-simplexml --disable-xml --disable-xmlreader --disable-xmlwriter --without-pear --without-sqlite3 --disable-pdo --without-pdo-sqlite --disable-phar --with-config-file-path=/etc/
Followed by
make
no errors, everything runs fine.
Next i do a make install.
make install
Again everything runs fine.
i move it to the target platform and run
/usr/arm/www/bin/php -v
PHP 5.4.0 (cli) (built: Aug 15 2012 16:07:41)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
I test a simple home page with my webserver and directly with php.
<?php echo "hello" ?>
# php index.php
hello
it works as expected.
next i test:
<?php
$output = shell_exec('ls -lart');
echo "<pre>$output</pre>";
?>
oh noes~
# php shell.php
Segmentation fault
I teset another script:
#!/bin/php
<?php
echo "hello";
$handle = fopen("info.txt", "r");
echo $handle;
?>
Same result:
# php index.php
helloSegmentation fault
do i have a php.ini?
# /usr/arm/www/bin/php --ini
Configuration File (php.ini) Path: /etc/
Loaded Configuration File: /etc/php.ini
yes, and no disabled functions.
testing strace /usr/arm/www/bin/php index.php
lstat("/srv/www/info.txt", {st_mode=S_IFREG|0644, st_size=20, ...}) = 0
open("/srv/www/info.txt", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=20, ...}) = 0
lseek(3, 10, SEEK_CUR) = 0
--- SIGSEGV (Segmentation fault) # 0 (0) ---
+++ killed by SIGSEGV +++
the file info.txt exists and it got premission to read/write to it.
Testing strace /usr/arm/www/bin/php shell.php
fcntl64(3, F_GETFL) = 0 (flags O_RDONLY)
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7e31fddc) = -1 EINVAL (Invalid argument)
vfork() = 3324
close(4) = 0
fstat(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
read(3, "total 24\n-rw-rw-r-- 1 1001 "..., 8192) = 468
read(3, ""..., 8192) = 0
--- SIGCHLD (Child exited) # 0 (0) ---
close(3) = 0
wait4(3324, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 3324
--- SIGSEGV (Segmentation fault) # 0 (0) ---
+++ killed by SIGSEGV +++
if i run the index.php through gdb it gives me:
Starting program: /usr/arm/www/bin/php index.php
hello
Program received signal SIGSEGV, Segmentation fault.
zend_do_fcall_common_helper_SPEC (execute_data=0x2ac7a040) at /home/maiden/Downloads/php-5.4.0/Zend/zend.h:391
391 /home/maiden/Downloads/php-5.4.0/Zend/zend.h: No such file or directory.
in /home/maiden/Downloads/php-5.4.0/Zend/zend.h
gdb gives me this from shell.php
Starting program: /usr/arm/www/bin/php shell.php
Program received signal SIGSEGV, Segmentation fault.
zend_do_fcall_common_helper_SPEC (execute_data=0x2ab76040) at /home/maiden/Downloads/php-5.4.0/Zend/zend.h:391
391 in /home/maiden/Downloads/php-5.4.0/Zend/zend.h
zend.h is located in /usr/arm/www/include/php/Zend/
obviously something went wrong during cross compilation. what have i missed? i do not find any configure flag to correct this and creating a symlink to the desired location removes the gdb output but php still segfaults.
Thanks for any help!
UPDATE:
# valgrind php test.php
==2181== Memcheck, a memory error detector
==2181== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==2181== Using Valgrind-3.8.0 and LibVEX; rerun with -h for copyright info
==2181== Command: php test.php
==2181==
==2181== Conditional jump or move depends on uninitialised value(s)
==2181== at 0x4004EC8: ??? (in /lib/ld-uClibc-0.9.30-nptl.so)
==2181==
==2181== Invalid read of size 4
==2181== at 0x4004D48: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.30-nptl.so)
==2181== Address 0x7d4cc304 is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes
==2181==
==2181== Invalid read of size 4
==2181== at 0x48C348C: __uClibc_main (in /lib/libuClibc-0.9.30-nptl.so)
==2181== Address 0x7d4cc554 is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes
==2181==
==2181== Invalid write of size 4
==2181== at 0x233010: __eqdf2 (ieee754-df.S:1120)
==2181== Address 0x7d4cb0bc is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes
==2181==
Warning: shell_exec(): Unable to execute 'ls -lart' in /test.php on line 3
==2181== Invalid read of size 4
==2181== at 0x1FF1AC: zend_do_fcall_common_helper_SPEC (zend.h:391)
==2181== by 0x1F3D17: execute (zend_vm_execute.h:410)
==2181== by 0x18B217: zend_execute_scripts (zend.c:1279)
==2181== by 0x1365BB: php_execute_script (main.c:2473)
==2181== by 0x22B52B: do_cli (php_cli.c:988)
==2181== by 0x22BD4B: main (php_cli.c:1364)
==2181== Address 0x8 is not stack'd, malloc'd or (recently) free'd
==2181==
Segmentation fault
Update2
re-run valgrind with memcheck, got about the same output as before but this was new:
php: can't resolve symbol '__libc_freeres'
Update3
While valgrind have failed me, i continued with gdb, i created the folder /home/maiden/..etc on my target system and copied over the content of my php/include folder and re-run gdb. now i get this error message:
(gdb) run index.php
Starting program: /bin/php index.php
hello
Program received signal SIGSEGV, Segmentation fault.
zend_do_fcall_common_helper_SPEC (execute_data=0x2ab34040) at /home/maiden/Downloads/php-5.4.5/Zend/zend.h:391
warning: Source file is more recent than executable.
391 return --pz->refcount__gc;
this is very similar to what sixeightzero wrote in the comments yesterday.
I have now tried PHP version 5.3.5, 5.4.0, 5.4.5 same error on all.
Update4
I downloaded a new toolchain for glibc, cross compiled a new busybox with glibc, created a chroot jail, cross compiled php with glibc instead of uclibc and tested it inside my chroot jail on my uclibc box, and it works! But i still need to get php to work in my uclibc environment....
i would check configure.log of uClibc to see if ARCH_USE_MMU and fork is enabled. if not vfork is replaced with fork which is likely to be used by shell_exec. the main problem with vfork is, parent and child uses same memory space which leads to weird crashes.
Related
I'm using PHP deployer which is a symlink based deployment tool which calls opcache:reset after deployment.
Recently I'm getting a segfault in my PHP-FPM processes after deployment.
This manifests as segfault entires in the PHP logs/memory exhausted warnings being output or 500/503 errors from Apache.
This has worked fine for years, so I'm stumped as to what has caused this to happen now.
I can reproduce this on every page refresh of an affected pool after the first segfault.
If I restart the PHP-FPM process, the page is served correctly the first time and then subsequently I get a segfault.
I suspect this is related to Opcache, since if I delete the Opcache cache files and restart PHP-FPM, the problem goes away. If I disable opcache.file_cache, again there is no problem. Note that I'm not exclusively using the file cache.
When I (unscientifically) checked the opcache version of files reported by PHP during the memory exhaustion error, I noticed they seemed to be truncated or missing data that existed in previous versions of the opcache file where the segfault did not occur. When I removed those specific opcache files and restarted PHP-FPM the problem went away. So it seems, I think, that the opcache files are getting corrupted between deploys.
Environment:
CentOS 7.9.2009
PHP 7.4.15
Each pool is configured to run under its own user
Opcache files are stored in /var/www/vhosts/[project]/opcache
SELinux is enabled
My opcache config:
zend_extension=opcache.so
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=96
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=4096
opcache.max_wasted_percentage=5
opcache.validate_timestamps=1
opcache.revalidate_path=0
opcache.revalidate_freq=2
opcache.max_file_size=0
The core dump:
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-120.el7
Copyright (C) 2013 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. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/php-fpm...Reading symbols from /usr/lib/debug/usr/sbin/php-fpm.debug...done.
done.
[New LWP 6221]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `php-fpm: pool cpsastag '.
Program terminated with signal 11, Segmentation fault.
#0 ZEND_BIND_STATIC_SPEC_CV_UNUSED_HANDLER () at /usr/src/debug/php-7.4.15/Zend/zend_vm_execute.h:46883
46883 zval *value;
(gdb) bt
#0 ZEND_BIND_STATIC_SPEC_CV_UNUSED_HANDLER () at /usr/src/debug/php-7.4.15/Zend/zend_vm_execute.h:46883
#1 0x00005559a7261159 in execute_ex (ex=0x0) at /usr/src/debug/php-7.4.15/Zend/zend_vm_execute.h:57657
#2 0x00005559a7266930 in zend_execute (op_array=0x7f03fb075000, return_value=<optimized out>) at /usr/src/debug/php-7.4.15/Zend/zend_vm_execute.h:57957
#3 0x00005559a71e1a63 in zend_execute_scripts (type=type#entry=8, retval=0x7f03fb016330, retval#entry=0x0, file_count=file_count#entry=3) at /usr/src/debug/php-7.4.15/Zend/zend.c:1679
#4 0x00005559a717fd00 in php_execute_script (primary_file=primary_file#entry=0x7ffd44c9b940) at /usr/src/debug/php-7.4.15/main/main.c:2621
#5 0x00005559a6fe582b in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/php-7.4.15/sapi/fpm/fpm/fpm_main.c:1939
(gdb)
SELinux audit.log
type=ANOM_ABEND msg=audit(1614726077.349:20549): auid=4294967295 uid=1010 gid=1011 ses=4294967295 subj=system_u:system_r:httpd_t:s0 pid=825 comm="php-fpm" reason="memory violation" sig=11
I'd really appreciate any pointers on what could be wrong or how to debug further.
I have gone through the whole process of downloading Oracle instant client, SDK, etc. in a Ubuntu Server 17.04. Then converted rpm packages to deb with alien, installed, set the paths, downloaded pecl oci8, compiled and installed (w/o errors), etc. and then added the line:
extension=/usr/lib/php/20151012/oci8.so
And restarted. When I check the /var/log/apache2/error.log I see:
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/20151012/oci8.so' - libmql1.so: cannot open shared object file: No such file or directory in Unknown on line 0
[Thu Jul 20 10:46:44.352631 2017] [mpm_prefork:notice] [pid 23450] AH00163: Apache/2.4.25 (Ubuntu) configured -- resuming normal operations
[Thu Jul 20 10:46:44.352717 2017] [core:notice] [pid 23450] AH00094: Command line: '/usr/sbin/apache2'
Does any one know what I could do to make it work?
I guess I have not selinux enabled or maybe it is a permissions problem?
Thanks
The solution is to put the ORACLE global variables NOT in /etc/environment but in the /etc/apache2/envvars
So, I've added these 2 lines at the end of /etc/apache2/envvars
export LD_LIBRARY_PATH=/usr/lib/oracle/12.2/client64/lib
export ORACLE_HOME=/usr/lib/oracle/12.2/client64
And all working great
As you still will have the same problem with php cli with the above solution, it would be better to add a new file /etc/ld.so.conf.d/oracle.conf with this content:
/usr/lib/oracle/12.2/client64/lib
Then run
sudo ldconfig
This way it works for apache and php cli and you do not need to change /etc/apache2/envvars
With Linux Ubuntu 18, if you're getting the same message, but its command line version:
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/20170718/oci8' when using php cli (= command line, as opposed to php as an apache module), all you need to do is to set LD_LIBRARY_PATH (not ORACLE_HOME), inside of /etc/environment, as shown below:
export LD_LIBRARY_PATH=/opt/oracle/instantclient_12_2
Next time you open a shell, the environment will declare this variable.
Note that the variable value needs to point to the folder that contains the lib*.so files.
Verification:
open a new console, and run
php -m | grep oci8
Today I've tried to install Xdebug, then Netbeans, Netbeans chrome extension etc. and suddenly my PHP script that creates new mysqli object doesn't work:
<?php
$connection = new mysqli('localhost', 'root','mysqlsamplepassword', 'Test_Database');
?>
When login credentials are wrong, I receive proper warning, but when they are OK web browser shows ERR_EMPTY_RESPONSE error. In apache.log I can find:
[Thu Jul 31 20:54:24.658848 2014] [core:notice] [pid 9797] AH00051: child pid 9814 exit signal Segmentation fault (11), possible coredump in /etc/apache2
Based on other stackoverflow questions covering this matter, I did backtracing by gdb:
(gdb) attach 9797
(...)
0x00007ff3d584fc13 in __select_nocancel ()
at ../sysdeps/unix/syscall-template.S:81
81 ../sysdeps/unix/syscall-template.S: There's no such file or directory
(gdb) backtrace full
#0 0x00007ff3d584fc13 in __select_nocancel ()
at ../sysdeps/unix/syscall-template.S:81
No locals.
#1 0x00007ff3d5d66d65 in apr_sleep ()
from /usr/lib/x86_64-linux-gnu/libapr-1.so.0
No symbol table info available.
#2 0x00007ff3d663a401 in ap_wait_or_timeout ()
No symbol table info available.
#3 0x00007ff3d2e92076 in ?? ()
from /usr/lib/apache2/modules/mod_mpm_prefork.so
No symbol table info available.
#4 0x00007ff3d663998e in ap_run_mpm ()
No symbol table info available.
#5 0x00007ff3d6633166 in main ()
No symbol table info available.
(gdb)
Unfortunatelly reinstalling apache2, php5-mysql didn't help. PDO extension works, but all my scripts are based on mysqli.
I installed latest php (5.6.0RC3, as I used development preview version) with this configure command:
./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql=mysqlnd --with-mysqli=mysqlnd
Unfortunatelly it didn't swap old php5 module. In etc/apache2/mods-enabled/php5.load I found what php module is loaded:
LoadModule php5_module /usr/lib/apache2/modules/libphp5.so
I changed this line to newely compilled libphp5.so path:
LoadModule php5_module /home/YourUsername/php-5.6.0RC3/libs/libphp5.so
but you can also overwrite this file to avert mess.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have downloaded the PHP 5.4.0 source, extracted it and moved into the source folder.
I do a configure with:
./configure --build=x86_64-unknown-linux-gnu --host=arm-linux-uclibcgnueabi --prefix=/usr/arm/www CC="arm-linux-uclibcgnueabi-gcc --sysroot=/toolchains/gnu_cortex-a9_tools/" --disable-libxml --disable-dom --without-iconv --without-openssl --disable-simplexml --disable-xml --disable-xmlreader --disable-xmlwriter --without-pear --without-sqlite3 --disable-pdo --without-pdo-sqlite --disable-phar --with-config-file-path=/etc/
Followed by
make
no errors, everything runs fine.
Next i do a make install.
make install
Again everything runs fine.
i move it to the target platform and run
/usr/arm/www/bin/php -v
PHP 5.4.0 (cli) (built: Aug 15 2012 16:07:41)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
I test a simple home page with my webserver and directly with php.
<?php echo "hello" ?>
# php index.php
hello
it works as expected.
next i test:
<?php
$output = shell_exec('ls -lart');
echo "<pre>$output</pre>";
?>
oh noes~
# php shell.php
Segmentation fault
I teset another script:
#!/bin/php
<?php
echo "hello";
$handle = fopen("info.txt", "r");
echo $handle;
?>
Same result:
# php index.php
helloSegmentation fault
do i have a php.ini?
# /usr/arm/www/bin/php --ini
Configuration File (php.ini) Path: /etc/
Loaded Configuration File: /etc/php.ini
yes, and no disabled functions.
testing strace /usr/arm/www/bin/php index.php
lstat("/srv/www/info.txt", {st_mode=S_IFREG|0644, st_size=20, ...}) = 0
open("/srv/www/info.txt", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=20, ...}) = 0
lseek(3, 10, SEEK_CUR) = 0
--- SIGSEGV (Segmentation fault) # 0 (0) ---
+++ killed by SIGSEGV +++
the file info.txt exists and it got premission to read/write to it.
Testing strace /usr/arm/www/bin/php shell.php
fcntl64(3, F_GETFL) = 0 (flags O_RDONLY)
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7e31fddc) = -1 EINVAL (Invalid argument)
vfork() = 3324
close(4) = 0
fstat(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
read(3, "total 24\n-rw-rw-r-- 1 1001 "..., 8192) = 468
read(3, ""..., 8192) = 0
--- SIGCHLD (Child exited) # 0 (0) ---
close(3) = 0
wait4(3324, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 3324
--- SIGSEGV (Segmentation fault) # 0 (0) ---
+++ killed by SIGSEGV +++
if i run the index.php through gdb it gives me:
Starting program: /usr/arm/www/bin/php index.php
hello
Program received signal SIGSEGV, Segmentation fault.
zend_do_fcall_common_helper_SPEC (execute_data=0x2ac7a040) at /home/maiden/Downloads/php-5.4.0/Zend/zend.h:391
391 /home/maiden/Downloads/php-5.4.0/Zend/zend.h: No such file or directory.
in /home/maiden/Downloads/php-5.4.0/Zend/zend.h
gdb gives me this from shell.php
Starting program: /usr/arm/www/bin/php shell.php
Program received signal SIGSEGV, Segmentation fault.
zend_do_fcall_common_helper_SPEC (execute_data=0x2ab76040) at /home/maiden/Downloads/php-5.4.0/Zend/zend.h:391
391 in /home/maiden/Downloads/php-5.4.0/Zend/zend.h
zend.h is located in /usr/arm/www/include/php/Zend/
obviously something went wrong during cross compilation. what have i missed? i do not find any configure flag to correct this and creating a symlink to the desired location removes the gdb output but php still segfaults.
Thanks for any help!
UPDATE:
# valgrind php test.php
==2181== Memcheck, a memory error detector
==2181== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==2181== Using Valgrind-3.8.0 and LibVEX; rerun with -h for copyright info
==2181== Command: php test.php
==2181==
==2181== Conditional jump or move depends on uninitialised value(s)
==2181== at 0x4004EC8: ??? (in /lib/ld-uClibc-0.9.30-nptl.so)
==2181==
==2181== Invalid read of size 4
==2181== at 0x4004D48: _dl_get_ready_to_run (in /lib/ld-uClibc-0.9.30-nptl.so)
==2181== Address 0x7d4cc304 is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes
==2181==
==2181== Invalid read of size 4
==2181== at 0x48C348C: __uClibc_main (in /lib/libuClibc-0.9.30-nptl.so)
==2181== Address 0x7d4cc554 is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes
==2181==
==2181== Invalid write of size 4
==2181== at 0x233010: __eqdf2 (ieee754-df.S:1120)
==2181== Address 0x7d4cb0bc is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes
==2181==
Warning: shell_exec(): Unable to execute 'ls -lart' in /test.php on line 3
==2181== Invalid read of size 4
==2181== at 0x1FF1AC: zend_do_fcall_common_helper_SPEC (zend.h:391)
==2181== by 0x1F3D17: execute (zend_vm_execute.h:410)
==2181== by 0x18B217: zend_execute_scripts (zend.c:1279)
==2181== by 0x1365BB: php_execute_script (main.c:2473)
==2181== by 0x22B52B: do_cli (php_cli.c:988)
==2181== by 0x22BD4B: main (php_cli.c:1364)
==2181== Address 0x8 is not stack'd, malloc'd or (recently) free'd
==2181==
Segmentation fault
Update2
re-run valgrind with memcheck, got about the same output as before but this was new:
php: can't resolve symbol '__libc_freeres'
Update3
While valgrind have failed me, i continued with gdb, i created the folder /home/maiden/..etc on my target system and copied over the content of my php/include folder and re-run gdb. now i get this error message:
(gdb) run index.php
Starting program: /bin/php index.php
hello
Program received signal SIGSEGV, Segmentation fault.
zend_do_fcall_common_helper_SPEC (execute_data=0x2ab34040) at /home/maiden/Downloads/php-5.4.5/Zend/zend.h:391
warning: Source file is more recent than executable.
391 return --pz->refcount__gc;
this is very similar to what sixeightzero wrote in the comments yesterday.
I have now tried PHP version 5.3.5, 5.4.0, 5.4.5 same error on all.
This topic have been CLOSED! :(
Continued on: https://serverfault.com/questions/418521/cross-compile-php [CLOSED]
and now on: Cross compile PHP with UCLIBC
I'm doing some PHP memory benchmarks and i would like to obtain the garbage collector statics.
I've followed this tutorial in the official doc: http://www.php.net/manual/en/features.gc.performance-considerations.php
I've reproduced the exact procedure wich is described, by recompiling PHP with this CFLAGS environment variable :
export CFLAGS=-DGC_BENCH=1
./config.nice
make clean
make
make install
I've done that with PHP 5.3.9 : http://fr.php.net/get/php-5.3.9.tar.bz2/from/a/mirror on a Debian Squeeze 6.0.4 64bits.
Then i tried to execute in command line the example script they provide php gc.php :
<?php
class Foo
{
public $var = '3.1415962654';
}
for ( $i = 0; $i <= 1000000; $i++ )
{
$a = new Foo;
$a->self = $a;
}
echo memory_get_peak_usage(), "\n";
?>
As they said, this should display at the end of the script, additional gc stats, for exemple :
GC Statistics
-------------
Runs: 110
Collected: 2072204
Root buffer length: 0
Root buffer peak: 10000
Possible Remove from Marked
Root Buffered buffer grey
-------- -------- ----------- ------
ZVAL 7175487 1491291 1241690 3611871
ZOBJ 28506264 1527980 677581 1025731
The fact is, this gc statistics aren't displayed.
It looks like that compiling PHP with this CFLAGS didn't made anything.
Did i missed something ?
I'm going on a hunch here as I've not confirmed this but, from reading the text on the GC link you provided, I don't get the impression that memory_get_peak_usage() should return additional information based on compiling PHP with the DGC_BENCH flag. The manual says it returns an int, so I suspect it always returns an int.
What it does say however is:
When you run the above example code again with the newly built PHP
binary, you will see the following being shown after PHP has finished
execution:
That isn't very clear, but I'm under the impression that the additional GC details will be printed to stdout or stderr rather than returned to memory_get_peak_usage() or being printed as additional output to your PHP script.
Try calling the newly built PHP executable from the command line and see if the GC information is printed to the console when the script finishes.
You can try calling it like: /path/to/custom/php testfile.php
I'm not sure it makes sense to output this information if you were running PHP as an Apache module or FastCGI handler so I suspect you may only be able to see it by calling your script from the console, but I could be totally wrong there.
UPDATE:
I've checked to make sure that the GC_BENCH compile flag is still active, and it is.
Zend/zend.c
905 #if GC_BENCH
906 fprintf(stderr, "GC Statistics\n");
907 fprintf(stderr, "-------------\n");
908 fprintf(stderr, "Runs: %d\n", GC_G(gc_runs));
909 fprintf(stderr, "Collected: %d\n", GC_G(collected));
910 fprintf(stderr, "Root buffer length: %d\n", GC_G(root_buf_length));
911 fprintf(stderr, "Root buffer peak: %d\n\n", GC_G(root_buf_peak));
912 fprintf(stderr, " Possible Remove from Marked\n");
913 fprintf(stderr, " Root Buffered buffer grey\n");
914 fprintf(stderr, " -------- -------- ----------- ------\n");
915 fprintf(stderr, "ZVAL %8d %8d %9d %8d\n", GC_G(zval_possible_root), GC_G(zval_buffered), GC_G(zval_remove_from_buffer), GC_G(zval_marked_grey));
916 fprintf(stderr, "ZOBJ %8d %8d %9d %8d\n", GC_G(zobj_possible_root), GC_G(zobj_buffered), GC_G(zobj_remove_from_buffer), GC_G(zobj_marked_grey));
917 #endif
Next, I compiled PHP 5.3.9 for Apache2 and CLI. Before deciding to install the test version, I ran the new PHP CLI app from the console:
./sapi/cli/php -v
PHP 5.3.9 (cli) (built: Feb 22 2012 19:03:02)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
GC Statistics
-------------
Runs: 0
Collected: 0
Root buffer length: 0
Root buffer peak: 7
Possible Remove from Marked
Root Buffered buffer grey
-------- -------- ----------- ------
ZVAL 15 7 7 0
ZOBJ 0 0 0 0
It has the GC output even though I didn't invoke PHP. Next I grep'd libphp5.so and saw that it DOES have the GC Statistics bit compiled into it so I decided to install it live and make a call from Apache. No GC output in the browser, error_log, access_log, or any other log files.
Now the interesting part, I created a test.php file which outputs a string and creates a frees a few variables...
root#vm:/php539# php test.php
This is a test
root#vm:/php539# php < test.php
This is a test
GC Statistics
-------------
Runs: 0
Collected: 0
Root buffer length: 0
Root buffer peak: 7
Possible Remove from Marked
Root Buffered buffer grey
-------- -------- ----------- ------
ZVAL 16 7 7 0
ZOBJ 0 0 0 0
root#vm:php539#
Conclusion:
When PHP is compiled with with GC_BENCH option, you will not have access to benchmark information when called from the browser, or when parsing PHP files by using the -f option or passing the name of the file to parse. You DO get benchmark information if you call php in interactive mode, or execute the script through PHP by reading it from stdin.