Hi,
It looks like nothing critical has popped up since RC4.
So it looks like we will be sending the final stable release to the
mirrors next Wednesday and announce the release on Thursday barring
any critical issues emerging in the next days. In the mean time test
test test. If issues are found/fixed please send the patches to
internals for review. Based on the importance and risk of the patch
will then be applied, however the next 2 days should really be focused
on testing to make sure we do not have critical issues, minor issues
can always be fixed in 5.3.1 and we better release with known minor
issues than big unknown issues caused by a last minute fix.
Another focus area should be the migration guide and other
documentation updates:
http://docs.php.net/migration53
regards,
Johannes and Lukas
Hi,
It looks like nothing critical has popped up since RC4.
So it looks like we will be sending the final stable release to the
mirrors next Wednesday and announce the release on Thursday barring any
critical issues emerging in the next days. In the mean time test test
test. If issues are found/fixed please send the patches to internals for
review. Based on the importance and risk of the patch will then be
applied, however the next 2 days should really be focused on testing to
make sure we do not have critical issues, minor issues can always be
fixed in 5.3.1 and we better release with known minor issues than big
unknown issues caused by a last minute fix.Another focus area should be the migration guide and other documentation
updates:
http://docs.php.net/migration53regards,
Johannes and Lukas
Johannes and Lukas,
Did you hear about crashes under Solaris and MacOSX, and compiler failures
under all *BSD systems?
They were posted against RC3 and the problems are still the same in RC4.
Affected systems: Solaris 8, FreeBSD 6, NetBSD 3, OpenBSD 4, MacOSX/Darwin
(unknown, per http://darkrainfall.org/php_test_results_valgrind.txt)
As the VERY least, you may want to mention gcc version that the sources are
compatible with and platforms the resulted binaries won't run.
Did you hear about crashes under Solaris and MacOSX, and compiler failures
under all *BSD systems?
They were posted against RC3 and the problems are still the same in RC4.
We fixed several compile failures recently (both FreeBSD related and
GCC2), it probably didn't make it into RC4 though.
-Hannes
Did you hear about crashes under Solaris and MacOSX, and compiler
failures
under all *BSD systems?
They were posted against RC3 and the problems are still the same in RC4.We fixed several compile failures recently (both FreeBSD related and
GCC2), it probably didn't make it into RC4 though.
As of php5.3-200906221030, the problem under *BSD platforms that I'm talking
about is still the same.
Did you hear about crashes under Solaris and MacOSX, and compiler
failures
under all *BSD systems?
They were posted against RC3 and the problems are still the same in RC4.We fixed several compile failures recently (both FreeBSD related and
GCC2), it probably didn't make it into RC4 though.As of php5.3-200906221030, the problem under *BSD platforms that I'm talking
about is still the same.
I see no compile failure bug reports against FreeBSD in the bugtracker...
I successfully built a snapshot on 4.11-STABLE FreeBSD (gcc 2.95.4)
3hours ago, you'll have to be slightly more specific.
-Hannes
Did you hear about crashes under Solaris and MacOSX, and compiler
failures
under all *BSD systems?
They were posted against RC3 and the problems are still the same in
RC4.We fixed several compile failures recently (both FreeBSD related and
GCC2), it probably didn't make it into RC4 though.As of php5.3-200906221030, the problem under *BSD platforms that I'm
talking
about is still the same.I see no compile failure bug reports against FreeBSD in the bugtracker...
I successfully built a snapshot on 4.11-STABLE FreeBSD (gcc 2.95.4)
3hours ago, you'll have to be slightly more specific.
Did you hear about crashes under Solaris and MacOSX, and compiler
failures
under all *BSD systems?
They were posted against RC3 and the problems are still the same in
RC4.We fixed several compile failures recently (both FreeBSD related and
GCC2), it probably didn't make it into RC4 though.As of php5.3-200906221030, the problem under *BSD platforms that I'm
talking
about is still the same.I see no compile failure bug reports against FreeBSD in the bugtracker...
I successfully built a snapshot on 4.11-STABLE FreeBSD (gcc 2.95.4)
3hours ago, you'll have to be slightly more specific.
NetBSD 3/x86 crashed:
/bin/sh
/home/jvlad/php/php5.3-200906221030/libtool --silent --preserve-dup-deps --mode=compile
gcc -I/home/jvlad/php/php5.3-200906221030/ext/fileinfo/libmagic -Iext/fileinfo/
-I/home/jvlad/php/php5.3-200906221030/ext/fileinfo/ -DPHP_ATOM_INC -I/home/jvlad/php/php5.3-200906221030/include
-I/home/jvlad/php/php5.3-200906221030/main -I/home/jvlad/php/php5.3-200906221030
-I/home/jvlad/php/php5.3-200906221030/ext/date/lib -I/home/jvlad/php/php5.3-200906221030/ext/ereg/regex
-I/home/jvlad/php/install/include/libxml2 -I/home/jvlad/php/php5.3-200906221030/ext/sqlite3/libsqlite
-I/home/jvlad/php/php5.3-200906221030/TSRM -I/home/jvlad/php/php5.3-200906221030/Zend
-I/usr/pkg/include -I/usr/include -g -O2 -c
/home/jvlad/php/php5.3-200906221030/ext/fileinfo/libmagic/apprentice.c -o
ext/fileinfo/libmagic/apprentice.lo
gcc: Internal error: Killed (program cc1)
Please submit a full bug report.
See URL:http://www.netbsd.org/Misc/send-pr.html for instructions.
*** Error code 1
OpenBSD 4/x86 hanged:
/bin/sh
/home/jvlad/php/php5.3-200906221030/libtool --silent --preserve-dup-deps --mode=compile
gcc -I/home/jvlad/php/php5.3-200906221030/ext/fileinfo/libmagic -Iext/fileinfo/
-I/home/jvlad/php/php5.3-200906221030/ext/fileinfo/ -DPHP_ATOM_INC -I/home/jvlad/php/php5.3-200906221030/include
-I/home/jvlad/php/php5.3-200906221030/main -I/home/jvlad/php/php5.3-200906221030
-I/home/jvlad/php/php5.3-200906221030/ext/date/lib -I/home/jvlad/php/php5.3-200906221030/ext/ereg/regex
-I/home/jvlad/php/install/include/libxml2 -I/usr/local/include -I/home/jvlad/php/php5.3-200906221030/ext/sqlite3/libsqlite
-I/home/jvlad/php/php5.3-200906221030/TSRM -I/home/jvlad/php/php5.3-200906221030/Zend
-I/usr/local/include -g -O2 -c
/home/jvlad/php/php5.3-200906221030/ext/fileinfo/libmagic/apprentice.
c -o ext/fileinfo/libmagic/apprentice.lo
(I waited for 10+minutes and it did not go on)
Did you hear about crashes under Solaris and MacOSX, and compiler
failures
under all *BSD systems?
They were posted against RC3 and the problems are still the same in
RC4.We fixed several compile failures recently (both FreeBSD related and
GCC2), it probably didn't make it into RC4 though.As of php5.3-200906221030, the problem under *BSD platforms that I'm
talking
about is still the same.I see no compile failure bug reports against FreeBSD in the bugtracker...
I successfully built a snapshot on 4.11-STABLE FreeBSD (gcc 2.95.4)
3hours ago, you'll have to be slightly more specific.
php5.3-200906221030 fails under Solaris 8/sparc:
Generating phar.php
*** Error code 138
make: Fatal error: Command failed for target `ext/phar/phar.php'
As of php5.3-200906221030, the problem under *BSD platforms that I'm
talking
about is still the same.I see no compile failure bug reports against FreeBSD in the bugtracker...
I successfully built a snapshot on 4.11-STABLE FreeBSD (gcc 2.95.4)
3hours ago, you'll have to be slightly more specific.php5.3-200906221030 fails under Solaris 8/sparc:
Generating phar.php
*** Error code 138
make: Fatal error: Command failed for target `ext/phar/phar.php'
next run of "make install" produces:
$ make install
Generating phar.phar
make: *** [ext/phar/phar.phar] Bus Error (core dumped)
2009/6/23 jvlad dmda@yandex.ru:
As of php5.3-200906221030, the problem under *BSD platforms that I'm
talking
about is still the same.I see no compile failure bug reports against FreeBSD in the bugtracker...
I successfully built a snapshot on 4.11-STABLE FreeBSD (gcc 2.95.4)
3hours ago, you'll have to be slightly more specific.php5.3-200906221030 fails under Solaris 8/sparc:
Generating phar.php
*** Error code 138
make: Fatal error: Command failed for target `ext/phar/phar.php'next run of "make install" produces:
$ make install
Generating phar.phar
make: *** [ext/phar/phar.phar] Bus Error (core dumped)
System information, compiler, and trace would be a plus here, cc'd Greg
--
--
regrads,
Kalle Sommer Nielsen
kalle@php.net
Generating phar.php
*** Error code 138
make: Fatal error: Command failed for target `ext/phar/phar.php'next run of "make install" produces:
$ make install
Generating phar.phar
make: *** [ext/phar/phar.phar] Bus Error (core dumped)System information, compiler, and trace would be a plus here, cc'd Greg
Please check all the info here:
http://marc.info/?l=php-internals&m=124524798321210&w=2
here: http://marc.info/?l=php-internals&m=124524798321212&w=2
and here: http://marc.info/?l=php-internals&m=124524798321213&w=2
hope it helps.
jvlad wrote:
Generating phar.php
*** Error code 138
make: Fatal error: Command failed for target `ext/phar/phar.php'next run of "make install" produces:
$ make install
Generating phar.phar
make: *** [ext/phar/phar.phar] Bus Error (core dumped)
System information, compiler, and trace would be a plus here, cc'd GregPlease check all the info here:
http://marc.info/?l=php-internals&m=124524798321210&w=2
here: http://marc.info/?l=php-internals&m=124524798321212&w=2
and here: http://marc.info/?l=php-internals&m=124524798321213&w=2
Hi,
I just ran a make install of PHP 5.3 on Solaris 32-bit:
cellog@t2000-010131:~/php5$ gcc -v
Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.11/3.4.3/specs
Configured with:
/gates/sfwnv/builds/sfwnv-gate/usr/src/cmd/gcc/gcc-3.4.3/configure
--prefix=/usr/sfw --with-as=/usr/ccs/bin/as --without-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld
--enable-languages=c,c++,f77,objc --enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-20050802)
cellog@t2000-010131:~/php5$ uname -a
SunOS t2000-010131 5.11 snv_101 sun4v sparc SUNW,Sun-Fire-T200 Solaris
I was unable to reproduce the bus error, or any other problems.
My best guess is that you have a problem related to libxml (I see you
are using a custom one), as that is the only substantive difference
between the default and your configure line. gcc 3.4.2 could also be
the issue, perhaps 3.4.3 fixes the problem.
In any case, if you can find a simple build with your tools that fails,
we can help. I'm sorry I'm unable to help you, bus error is a serious
issue, but it's probably impossible to debug without direct access to
your machine.
You might try using gdb, start it up, and run with:
-n -dshort_open_tag=0 -dsafe_mode=0 -dopen_basedir=
-derror_reporting=1803 -dmemory_limit=-1 -ddetect_unicode=0
install-pear-nozlib.phar -d /export/home/jvlad/testpear -b
/export/home/jvlad/testpear/bin
that way you can inspect variables when the bus error happens
Greg
Hi,
I just ran a make install of PHP 5.3 on Solaris 32-bit:
cellog@t2000-010131:~/php5$ gcc -v
Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.11/3.4.3/specs
Configured with:
/gates/sfwnv/builds/sfwnv-gate/usr/src/cmd/gcc/gcc-3.4.3/configure
--prefix=/usr/sfw --with-as=/usr/ccs/bin/as --without-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld
--enable-languages=c,c++,f77,objc --enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-20050802)
cellog@t2000-010131:~/php5$ uname -a
SunOS t2000-010131 5.11 snv_101 sun4v sparc SUNW,Sun-Fire-T200 Solaris
This is different platform.
Mine is 64bit Solaris version 8, not 11 like yours:
$ uname -a
SunOS qx 5.8 Generic_108528-11 sun4u sparc SUNW,UltraSPARC-IIi-cEngine
php was complied without -m64 and therefore it is 32bit.
My best guess is that you have a problem related to libxml (I see you
are using a custom one), as that is the only substantive difference
between the default and your configure line. gcc 3.4.2 could also be
the issue, perhaps 3.4.3 fixes the problem.
no, libxml is not a problem.
Once again, I'm building php on this machine since php version 4.2.0,
always quite successfull, except php 5.3 :)
You might try using gdb, start it up, and run with:
-n -dshort_open_tag=0 -dsafe_mode=0 -dopen_basedir=
-derror_reporting=1803 -dmemory_limit=-1 -ddetect_unicode=0
install-pear-nozlib.phar -d /export/home/jvlad/testpear -b
/export/home/jvlad/testpear/binthat way you can inspect variables when the bus error happens
I can inspect them even without these parameters.
the following command is enough:
gdb --core ./core sapi/cli/php
What do you want me to check?
Regarding the crash point
bt:
(gdb) bt
#0 0x002e7d80 in ZEND_FE_RESET_SPEC_TMP_HANDLER (execute_data=0x861cc0)
at
/export/home/jvlad/php/php5.3-200906221030/Zend/zend_vm_execute.h:5371
#1 0x002d92a0 in execute (op_array=0x70bd90)
at /export/home/jvlad/php/php5.3-200906221030/Zend/zend_vm_execute.h:104
#2 0x002b8d48 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /export/home/jvlad/php/php5.3-200906221030/Zend/zend.c:1188
#3 0x00266444 in php_execute_script (primary_file=0xffbef9a0)
at /export/home/jvlad/php/php5.3-200906221030/main/main.c:2196
#4 0x003447d4 in main (argc=31, argv=0xffbefa5c)
at /export/home/jvlad/php/php5.3-200906221030/sapi/cli/php_cli.c:1188
#0 corresponds to the following line:
ALLOC_ZVAL(tmp);
INIT_PZVAL_COPY(tmp, array_ptr);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
print array_ptr
$1 = (zval *) 0x861d14
(gdb) print *array_ptr
$2 = {value = {lval = 7461040, dval = 1.5883854881154093e-306, str = {val =
0x71d8b0 "",
len = 0}, ht = 0x71d8b0, obj = {handle = 7461040, handlers = 0x0}},
refcount__gc = 0,
type = 4 '\004', is_ref__gc = 0 '\0'}
print tmp
Cannot access memory at address 0xfffffff0
Let know if you want me to check the other variables.
jvlad wrote:
Hi,
I just ran a make install of PHP 5.3 on Solaris 32-bit:
cellog@t2000-010131:~/php5$ gcc -v
Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.11/3.4.3/specs
Configured with:
/gates/sfwnv/builds/sfwnv-gate/usr/src/cmd/gcc/gcc-3.4.3/configure
--prefix=/usr/sfw --with-as=/usr/ccs/bin/as --without-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld
--enable-languages=c,c++,f77,objc --enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-20050802)
cellog@t2000-010131:~/php5$ uname -a
SunOS t2000-010131 5.11 snv_101 sun4v sparc SUNW,Sun-Fire-T200 SolarisThis is different platform.
Mine is 64bit Solaris version 8, not 11 like yours:
$ uname -a
SunOS qx 5.8 Generic_108528-11 sun4u sparc SUNW,UltraSPARC-IIi-cEngine
php was complied without -m64 and therefore it is 32bit.My best guess is that you have a problem related to libxml (I see you
are using a custom one), as that is the only substantive difference
between the default and your configure line. gcc 3.4.2 could also be
the issue, perhaps 3.4.3 fixes the problem.no, libxml is not a problem.
Once again, I'm building php on this machine since php version 4.2.0,
always quite successfull, except php 5.3 :)You might try using gdb, start it up, and run with:
-n -dshort_open_tag=0 -dsafe_mode=0 -dopen_basedir=
-derror_reporting=1803 -dmemory_limit=-1 -ddetect_unicode=0
install-pear-nozlib.phar -d /export/home/jvlad/testpear -b
/export/home/jvlad/testpear/binthat way you can inspect variables when the bus error happens
I can inspect them even without these parameters.
the following command is enough:
gdb --core ./core sapi/cli/php
What do you want me to check?Regarding the crash point
bt:
(gdb) bt
#0 0x002e7d80 in ZEND_FE_RESET_SPEC_TMP_HANDLER (execute_data=0x861cc0)
at
/export/home/jvlad/php/php5.3-200906221030/Zend/zend_vm_execute.h:5371
#1 0x002d92a0 in execute (op_array=0x70bd90)
at /export/home/jvlad/php/php5.3-200906221030/Zend/zend_vm_execute.h:104
#2 0x002b8d48 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /export/home/jvlad/php/php5.3-200906221030/Zend/zend.c:1188
#3 0x00266444 in php_execute_script (primary_file=0xffbef9a0)
at /export/home/jvlad/php/php5.3-200906221030/main/main.c:2196
#4 0x003447d4 in main (argc=31, argv=0xffbefa5c)
at /export/home/jvlad/php/php5.3-200906221030/sapi/cli/php_cli.c:1188#0 corresponds to the following line:
ALLOC_ZVAL(tmp);
INIT_PZVAL_COPY(tmp, array_ptr);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^print array_ptr
$1 = (zval *) 0x861d14
(gdb) print *array_ptr
$2 = {value = {lval = 7461040, dval = 1.5883854881154093e-306, str = {val =
0x71d8b0 "",
len = 0}, ht = 0x71d8b0, obj = {handle = 7461040, handlers = 0x0}},
refcount__gc = 0,
type = 4 '\004', is_ref__gc = 0 '\0'}
print tmp
Cannot access memory at address 0xfffffff0Let know if you want me to check the other variables.
can you run the custom gdb dumpbt so we can see which line of
install-pear-nozlib.phar is triggering the error?
Greg
can you run the custom gdb dumpbt so we can see which line of
install-pear-nozlib.phar is triggering the error?
(gdb) dump_bt executor_globals.current_execute_data
[0x00861cc0] ???
/export/home/jvlad/php/php5.3-200906221030/ext/phar/phar.php:10
jvlad wrote:
can you run the custom gdb dumpbt so we can see which line of
install-pear-nozlib.phar is triggering the error?(gdb) dump_bt executor_globals.current_execute_data
[0x00861cc0] ???
/export/home/jvlad/php/php5.3-200906221030/ext/phar/phar.php:10
Hi,
Thanks. The line in question is the first line of the generated
(non-phar) phar.php script which is the foreach line in:
<?php
foreach (array("SPL", "Reflection", "Phar") as $ext) {
if (!extension_loaded($ext)) {
echo "$argv[0] requires PHP extension $ext.\n"
exit(1);
}
}
?>
Could you try running sapi/cli/php passing in a simple script with those
contents and verify you still get the bus error?
Thanks,
Greg
Hi,
Thanks. The line in question is the first line of the generated
(non-phar) phar.php script which is the foreach line in:<?php
foreach (array("SPL", "Reflection", "Phar") as $ext) {
if (!extension_loaded($ext)) {
echo "$argv[0] requires PHP extension $ext.\n"
exit(1);
}
}
?>Could you try running sapi/cli/php passing in a simple script with those
contents and verify you still get the bus error?
Core was generated by `./php 1.php'.
Program terminated with signal 10, Bus error.
#0 0x002e7d80 in ZEND_FE_RESET_SPEC_TMP_HANDLER (execute_data=0x861cc0)
at
/export/home/jvlad/php/php5.3-200906221030/Zend/zend_vm_execute.h:5371
5371 INIT_PZVAL_COPY(tmp, array_ptr);
(gdb) bt
#0 0x002e7d80 in ZEND_FE_RESET_SPEC_TMP_HANDLER (execute_data=0x861cc0)
at
/export/home/jvlad/php/php5.3-200906221030/Zend/zend_vm_execute.h:5371
#1 0x002d92a0 in execute (op_array=0x70bd90)
at /export/home/jvlad/php/php5.3-200906221030/Zend/zend_vm_execute.h:104
#2 0x002b8d48 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /export/home/jvlad/php/php5.3-200906221030/Zend/zend.c:1188
#3 0x00266444 in php_execute_script (primary_file=0xffbefbf0)
at /export/home/jvlad/php/php5.3-200906221030/main/main.c:2196
#4 0x003447d4 in main (argc=2, argv=0xffbefcac)
at /export/home/jvlad/php/php5.3-200906221030/sapi/cli/php_cli.c:1188
(gdb) p array_ptr
$1 = (zval *) 0x861d14
(gdb) p *array_ptr
$2 = {value = {lval = 7458416, dval = 1.5848218932638939e-306, str = {val =
0x71ce70 "",
len = 0}, ht = 0x71ce70, obj = {handle = 7458416, handlers = 0x0}},
refcount__gc = 0,
type = 4 '\004', is_ref__gc = 0 '\0'}
(gdb) p tmp
Cannot access memory at address 0xfffffff0
(gdb) dump_bt executor_globals.current_execute_data
[0x00861cc0] ??? /export/home/jvlad/php/php5.3-200906221030/sapi/cli/1.php:2
(gdb)q
$cat 1.php
<?php
foreach (array("SPL", "Reflection", "Phar") as $ext) {
if (!extension_loaded($ext)) {
echo "$argv[0] requires PHP extension $ext.\n";
exit(1);
}
}
?
jvlad wrote:
Hi,
Thanks. The line in question is the first line of the generated
(non-phar) phar.php script which is the foreach line in:<?php
foreach (array("SPL", "Reflection", "Phar") as $ext) {
if (!extension_loaded($ext)) {
echo "$argv[0] requires PHP extension $ext.\n"
exit(1);
}
}
?>Could you try running sapi/cli/php passing in a simple script with those
contents and verify you still get the bus error?
Hi,
This is helpful, looks like a real Zend Engine issue, tmp is not being
properly initialized by INIT_ZVAL apparently. Open a bug report with
those contents, perhaps Dmitry (or someone else equally smart) can take
a look.
Greg
Core was generated by `./php 1.php'.
Program terminated with signal 10, Bus error.
#0 0x002e7d80 in ZEND_FE_RESET_SPEC_TMP_HANDLER (execute_data=0x861cc0)
at
/export/home/jvlad/php/php5.3-200906221030/Zend/zend_vm_execute.h:5371
5371 INIT_PZVAL_COPY(tmp, array_ptr);
(gdb) bt
#0 0x002e7d80 in ZEND_FE_RESET_SPEC_TMP_HANDLER (execute_data=0x861cc0)
at
/export/home/jvlad/php/php5.3-200906221030/Zend/zend_vm_execute.h:5371
#1 0x002d92a0 in execute (op_array=0x70bd90)
at /export/home/jvlad/php/php5.3-200906221030/Zend/zend_vm_execute.h:104
#2 0x002b8d48 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /export/home/jvlad/php/php5.3-200906221030/Zend/zend.c:1188
#3 0x00266444 in php_execute_script (primary_file=0xffbefbf0)
at /export/home/jvlad/php/php5.3-200906221030/main/main.c:2196
#4 0x003447d4 in main (argc=2, argv=0xffbefcac)
at /export/home/jvlad/php/php5.3-200906221030/sapi/cli/php_cli.c:1188
(gdb) p array_ptr
$1 = (zval *) 0x861d14
(gdb) p *array_ptr
$2 = {value = {lval = 7458416, dval = 1.5848218932638939e-306, str = {val =
0x71ce70 "",
len = 0}, ht = 0x71ce70, obj = {handle = 7458416, handlers = 0x0}},
refcount__gc = 0,
type = 4 '\004', is_ref__gc = 0 '\0'}
(gdb) p tmp
Cannot access memory at address 0xfffffff0
(gdb) dump_bt executor_globals.current_execute_data
[0x00861cc0] ??? /export/home/jvlad/php/php5.3-200906221030/sapi/cli/1.php:2
(gdb)q
$cat 1.php
<?php
foreach (array("SPL", "Reflection", "Phar") as $ext) {
if (!extension_loaded($ext)) {
echo "$argv[0] requires PHP extension $ext.\n";
exit(1);
}
}
?
Did you hear about crashes under Solaris and MacOSX, and compiler
failures
under all *BSD systems?
They were posted against RC3 and the problems are still the same in
RC4.We fixed several compile failures recently (both FreeBSD related and
GCC2), it probably didn't make it into RC4 though.As of php5.3-200906221030, the problem under *BSD platforms that I'm
talking
about is still the same.I see no compile failure bug reports against FreeBSD in the bugtracker...
I successfully built a snapshot on 4.11-STABLE FreeBSD (gcc 2.95.4)
3hours ago, you'll have to be slightly more specific.
php5.3-200906221030 make produces suspecious output under FreeBSD 6/amd64:
Generating phar.php
Generating phar.phar
pear: not found
^^^^^^^^^^^^
Pear package PHP_Archive or Archive.php class file not found.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
pharcommand.inc
invertedregexiterator.inc
clicommand.inc
directorygraphiterator.inc
directorytreeiterator.inc
phar.inc
Build complete.
Don't forget to run 'make test'.
jvlad wrote:
Did you hear about crashes under Solaris and MacOSX, and compiler
failures
under all *BSD systems?
They were posted against RC3 and the problems are still the same in
RC4.
We fixed several compile failures recently (both FreeBSD related and
GCC2), it probably didn't make it into RC4 though.As of php5.3-200906221030, the problem under *BSD platforms that I'm
talking
about is still the same.
I see no compile failure bug reports against FreeBSD in the bugtracker...I successfully built a snapshot on 4.11-STABLE FreeBSD (gcc 2.95.4)
3hours ago, you'll have to be slightly more specific.php5.3-200906221030 make produces suspecious output under FreeBSD 6/amd64:
Generating phar.php
Generating phar.phar
pear: not found
^^^^^^^^^^^^
Pear package PHP_Archive or Archive.php class file not found.
This is not suspicious. It is self-explanatory, not a problem, not a
bug. Do not pass Go. Do not collect $200.
Greg
php5.3-200906221030 make produces suspecious output under FreeBSD
6/amd64:Generating phar.php
Generating phar.phar
pear: not found
^^^^^^^^^^^^
Pear package PHP_Archive or Archive.php class file not found.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^This is not suspicious. It is self-explanatory, not a problem, not a
bug. Do not pass Go. Do not collect $200.
Greg, your answer is even more suspicious. If "Class file not found" is
neither a problem, nor a bug, what is it?
Why does it appear in the output? Doesn't "pear: not found" mean that make
tried to run pear in the $PATH and shell produced this error in the stderr?
Shouldn't it run $prefix/bin/pear only? What's about PHP_Archive? Shouldn't
it be there in the sources?
In other words, I see two bugs there:
- PHP depends on the system-wide installed pear and tries to run it.
- One or many files are missed in the package producing the "Archive.php
class file not found" error.
jvlad wrote:
php5.3-200906221030 make produces suspecious output under FreeBSD
6/amd64:Generating phar.php
Generating phar.phar
pear: not found
^^^^^^^^^^^^
Pear package PHP_Archive or Archive.php class file not found.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is not suspicious. It is self-explanatory, not a problem, not a
bug. Do not pass Go. Do not collect $200.Greg, your answer is even more suspicious. If "Class file not found" is
neither a problem, nor a bug, what is it?
Why does it appear in the output? Doesn't "pear: not found" mean that make
tried to run pear in the $PATH and shell produced this error in the stderr?
Shouldn't it run $prefix/bin/pear only? What's about PHP_Archive? Shouldn't
it be there in the sources?In other words, I see two bugs there:
- PHP depends on the system-wide installed pear and tries to run it.
- One or many files are missed in the package producing the "Archive.php
class file not found" error.
- you're wrong, PHP does not depend on system-wide installed pear, it
will simply use it if present - nothing is missing. see http://pear.php.net/PHP_Archive
If installed, phar.phar will function (partially) without the phar
extension being present.
In other words, not a problem, not a bug.
Greg
Greg Beaver wrote:
jvlad wrote:
php5.3-200906221030 make produces suspecious output under FreeBSD
6/amd64:Generating phar.php
Generating phar.phar
pear: not found
^^^^^^^^^^^^
Pear package PHP_Archive or Archive.php class file not found.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is not suspicious. It is self-explanatory, not a problem, not a
bug. Do not pass Go. Do not collect $200.
Greg, your answer is even more suspicious. If "Class file not found" is
neither a problem, nor a bug, what is it?
Why does it appear in the output? Doesn't "pear: not found" mean that make
tried to run pear in the $PATH and shell produced this error in the stderr?
Shouldn't it run $prefix/bin/pear only? What's about PHP_Archive? Shouldn't
it be there in the sources?In other words, I see two bugs there:
- PHP depends on the system-wide installed pear and tries to run it.
- One or many files are missed in the package producing the "Archive.php
class file not found" error.
- you're wrong, PHP does not depend on system-wide installed pear, it
will simply use it if present- nothing is missing. see http://pear.php.net/PHP_Archive
If installed, phar.phar will function (partially) without the phar
extension being present.In other words, not a problem, not a bug.
Greg,
Can the messages be enhanced e.g. explaining what will happen in these
cases? For example "pear: not found. Using XXX instead" would help
users for #1.
Chris
--
Email: christopher.jones@oracle.com
Twitter: http://twitter.com/ghrd
On Tue, Jun 23, 2009 at 12:39 AM, Christopher
Joneschristopher.jones@oracle.com wrote:
Can the messages be enhanced e.g. explaining what will happen in these
cases? For example "pear: not found. Using XXX instead" would help
users for #1.
Agreed, I answered questions from many users already, they thought
something went wrong :)
--
Pierre
- you're wrong, PHP does not depend on system-wide installed pear, it
will simply use it if present- nothing is missing. see http://pear.php.net/PHP_Archive
If installed, phar.phar will function (partially) without the phar
extension being present.In other words, not a problem, not a bug.
Greg,
Can the messages be enhanced e.g. explaining what will happen in these
cases? For example "pear: not found. Using XXX instead" would help
users for #1.
As far as I understand "pear: not found" is a shell message thrown into
output (stderr?) when make tried to run non-existing system's pear.
- you're wrong, PHP does not depend on system-wide installed
pear, it
will simply use it if present- nothing is missing. see http://pear.php.net/PHP_Archive
If installed, phar.phar will function (partially) without the phar
extension being present.In other words, not a problem, not a bug.
Greg,
Can the messages be enhanced e.g. explaining what will happen in
these
cases? For example "pear: not found. Using XXX instead" would help
users for #1.As far as I understand "pear: not found" is a shell message thrown
into
output (stderr?) when make tried to run non-existing system's pear.
if someone has a safe looking patch to improve this, we can consider
including it in 5.3.0
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
In other words, I see two bugs there:
- PHP depends on the system-wide installed pear and tries to run it.
- One or many files are missed in the package producing the "Archive.php
class file not found" error.
- you're wrong, PHP does not depend on system-wide installed pear, it
will simply use it if present
Does not matter how you call it. "Simply use it", or "depends on it", this
all is about the same.
Since php brings its own pear why not to use it?
Well, even if using system's pear unavoidable, why not to check its presense
and its version first and do not bother shell with attempts to run
non-existing stuff?
- nothing is missing. see http://pear.php.net/PHP_Archive
If installed, phar.phar will function (partially) without the phar
extension being present.
Same goes here.
Presense of PHP_Archive can be also checked without misleading error
messages in the make's output.
""jvlad"" dmda@yandex.ru wrote in message
news:38.7A.20019.C9D6F3A4@pb1.pair.com...
Did you hear about crashes under Solaris and MacOSX, and compiler
failures
under all *BSD systems?
They were posted against RC3 and the problems are still the same in RC4.We fixed several compile failures recently (both FreeBSD related and
GCC2), it probably didn't make it into RC4 though.As of php5.3-200906221030, the problem under *BSD platforms that I'm
talking about is still the same.
Oops, sorry, I waited 1 more minute and it went on.
Just hanged on the same file much more than on the others and I though it
hanged forever like before.
FreeBSD 6 is [OK].
Now I'm going to check the other BSD systems, and Solaris 8.
Did you hear about crashes under Solaris and MacOSX, and compiler
failures
under all *BSD systems?
They were posted against RC3 and the problems are still the same in RC4.We fixed several compile failures recently (both FreeBSD related and
GCC2), it probably didn't make it into RC4 though.-Hannes
Further investigation shown that compiler takes about 1GB(!) of memory when
it compiles php5.3-200906221030/ext/fileinfo/libmagic/apprentice.c
On some systems this amount of memory is not available and may lead to
errors such as hangs or crashes.
Is it a known problem?
Is this requirement specified somewhere?
Can it be fixed or improved?
jvlad wrote:
Did you hear about crashes under Solaris and MacOSX, and compiler
failures
under all *BSD systems?
They were posted against RC3 and the problems are still the same in RC4.
We fixed several compile failures recently (both FreeBSD related and
GCC2), it probably didn't make it into RC4 though.-Hannes
Further investigation shown that compiler takes about 1GB(!) of memory when
it compiles php5.3-200906221030/ext/fileinfo/libmagic/apprentice.c
On some systems this amount of memory is not available and may lead to
errors such as hangs or crashes.Is it a known problem?
Is this requirement specified somewhere?
Can it be fixed or improved?
Try compiling with -O0
Further investigation shown that compiler takes about 1GB(!) of memory
when
it compiles php5.3-200906221030/ext/fileinfo/libmagic/apprentice.c
On some systems this amount of memory is not available and may lead to
errors such as hangs or crashes.Is it a known problem?
Is this requirement specified somewhere?
Can it be fixed or improved?Try compiling with -O0
unfortunately, it did not help (tried with fresh sources):
/bin/sh
/home/jvlad/php/php5.3-200906221030/libtool --silent --preserve-dup-deps --mode=compile
gcc -I/home/jvlad/php/php5.3-200906221030/ext/fileinfo/libmagic -Iext/fileinfo/
-I/home/jvlad/php/php5.3-200906221030/ext/fileinfo/ -DPHP_ATOM_INC -I/home/jvlad/php/php5.3-200906221030/include
-I/home/jvlad/php/php5.3-200906221030/main -I/home/jvlad/php/php5.3-200906221030
-I/home/jvlad/php/php5.3-200906221030/ext/date/lib -I/home/jvlad/php/php5.3-200906221030/ext/ereg/regex
-I/home/jvlad/php/install/include/libxml2 -I/home/jvlad/php/php5.3-200906221030/ext/sqlite3/libsqlite
-I/home/jvlad/php/php5.3-200906221030/TSRM -I/home/jvlad/php/php5.3-200906221030/Zend
-I/usr/pkg/include -I/usr/include -O0 -c
/home/jvlad/php/php5.3-200906221030/ext/fileinfo/libmagic/apprentice.c -o
ext/fileinfo/libmagic/apprentice.lo
gcc: Internal error: Killed (program cc1)
Please submit a full bug report.
See URL:http://www.netbsd.org/Misc/send-pr.html for instructions.
*** Error code 1
Stop.
make: stopped in /home/jvlad/php/php5.3-200906221030
jvlad wrote:
Further investigation shown that compiler takes about 1GB(!) of memory
when
it compiles php5.3-200906221030/ext/fileinfo/libmagic/apprentice.c
On some systems this amount of memory is not available and may lead to
errors such as hangs or crashes.Is it a known problem?
Is this requirement specified somewhere?
Can it be fixed or improved?
Try compiling with -O0unfortunately, it did not help (tried with fresh sources):
There really isn't much we can do about this. Restructuring perfectly
valid code because certain old versions of gcc use a lot of memory
compiling it isn't something I am very keen on. Compile on a box with
more memory or move to gcc4.
-Rasmus
Further investigation shown that compiler takes about 1GB(!) of memory
when
it compiles php5.3-200906221030/ext/fileinfo/libmagic/apprentice.c
On some systems this amount of memory is not available and may lead to
errors such as hangs or crashes.Is it a known problem?
Is this requirement specified somewhere?
Can it be fixed or improved?
Try compiling with -O0unfortunately, it did not help (tried with fresh sources):
There really isn't much we can do about this. Restructuring perfectly
valid code because certain old versions of gcc use a lot of memory
compiling it isn't something I am very keen on. Compile on a box with
more memory or move to gcc4.
This is a good suggestion, but can hardly be followed.
Even the most recent OpenBSD (ver 4.5) comes with gcc 2.95 and 3.3.5 (see
http://www.openbsd.org/45.html#new)
Ver4 is no an option under this platform.
I just tried on another hardware with 1GB RAM. It successfully passed
ext/fileinfo/libmagic/apprentice.c.
Now the problem is:
/bin/sh
/home/jvlad/php/php5.3-200906221030/libtool --silent --preserve-dup-deps --mode=compile
gcc -Iext/phar/ -I/home/jvlad/php/php5.3-200906221030/ext/phar/ -DPHP_ATOM_INC
-I/home/jvlad/php/php5.3-200906221030/include -I/home/jvlad/php/php5.3-200906221030/main
-I/home/jvlad/php/php5.3-200906221030 -I/home/jvlad/php/php5.3-200906221030/ext/date/lib
-I/home/jvlad/php/php5.3-200906221030/ext/ereg/regex -I/home/jvlad/php/install/include/libxml2
-I/usr/local/include -I/home/jvlad/php/php5.3-200906221030/ext/sqlite3/libsqlite
-I/home/jvlad/php/php5.3-200906221030/TSRM -I/home/jvlad/php/php5.3-200906221030/Zend
-I/usr/local/include -O0 -c
/home/jvlad/php/php5.3-200906221030/ext/phar/util.c -o ext/phar/util.lo
In file included from
/home/jvlad/php/php5.3-200906221030/ext/spl/spl_array.h:25,
from
/home/jvlad/php/php5.3-200906221030/ext/phar/phar_internal.h:59,
from
/home/jvlad/php/php5.3-200906221030/ext/phar/util.c:23:
/home/jvlad/php/php5.3-200906221030/ext/spl/php_spl.h:68: error: syntax
error before "intptr_t"
*** Error code 1
Stop in /home/jvlad/php/php5.3-200906221030 (line 750 of Makefile).
As I mentioned in bug#48593 replacing intptr_t with zend_intptr_t fixes the
problem completely.
Hi
2009/6/23 jvlad dmda@yandex.ru:
Now the problem is:
/bin/sh
/home/jvlad/php/php5.3-200906221030/libtool --silent --preserve-dup-deps --mode=compile
gcc -Iext/phar/ -I/home/jvlad/php/php5.3-200906221030/ext/phar/ -DPHP_ATOM_INC
-I/home/jvlad/php/php5.3-200906221030/include -I/home/jvlad/php/php5.3-200906221030/main
-I/home/jvlad/php/php5.3-200906221030 -I/home/jvlad/php/php5.3-200906221030/ext/date/lib
-I/home/jvlad/php/php5.3-200906221030/ext/ereg/regex -I/home/jvlad/php/install/include/libxml2
-I/usr/local/include -I/home/jvlad/php/php5.3-200906221030/ext/sqlite3/libsqlite
-I/home/jvlad/php/php5.3-200906221030/TSRM -I/home/jvlad/php/php5.3-200906221030/Zend
-I/usr/local/include -O0 -c
/home/jvlad/php/php5.3-200906221030/ext/phar/util.c -o ext/phar/util.lo
In file included from
/home/jvlad/php/php5.3-200906221030/ext/spl/spl_array.h:25,
from
/home/jvlad/php/php5.3-200906221030/ext/phar/phar_internal.h:59,
from
/home/jvlad/php/php5.3-200906221030/ext/phar/util.c:23:
/home/jvlad/php/php5.3-200906221030/ext/spl/php_spl.h:68: error: syntax
error before "intptr_t"
*** Error code 1Stop in /home/jvlad/php/php5.3-200906221030 (line 750 of Makefile).
As I mentioned in bug#48593 replacing intptr_t with zend_intptr_t fixes the
problem completely.
Or it could be possibly fixed by including <stdint.h>, like
"win32/php_stdin.h" is included on Windows thrus no compilation error
here. Let me know if the following patch fixes your problem:
Index: php_spl.h
RCS file: /repository/php-src/ext/spl/php_spl.h,v
retrieving revision 1.31
diff -u -r1.31 php_spl.h
--- php_spl.h 10 Mar 2009 23:39:38 -0000 1.31
+++ php_spl.h 23 Jun 2009 16:43:13 -0000
@@ -21,7 +21,9 @@
#include "php.h"
#if defined(PHP_WIN32)
-#include "win32/php_stdint.h"
+# include "win32/php_stdint.h"
+#else
+# include <stdint.h>
#endif
#include <stdarg.h>
--
regrads,
Kalle Sommer Nielsen
kalle@php.net
Or it could be possibly fixed by including <stdint.h>, like
"win32/php_stdin.h" is included on Windows thrus no compilation error
here. Let me know if the following patch fixes your problem:Index: php_spl.h
RCS file: /repository/php-src/ext/spl/php_spl.h,v
retrieving revision 1.31
diff -u -r1.31 php_spl.h
--- php_spl.h 10 Mar 2009 23:39:38 -0000 1.31
+++ php_spl.h 23 Jun 2009 16:43:13 -0000
@@ -21,7 +21,9 @@#include "php.h"
#if defined(PHP_WIN32)
-#include "win32/php_stdint.h"
+# include "win32/php_stdint.h"
+#else
+# include <stdint.h>
#endif
#include <stdarg.h>
yep, it fixed the problem.
Also I'd check for HAVE_STDINT_H like below:
#if defined(PHP_WIN32)
#include "win32/php_stdint.h"
+#else
+#ifdef HAVE_STDINT_H
+#include <stdint.h>
+#endif
#endif
#include <stdarg.h
Hi Lukas,
If issues are found/fixed please send the patches to internals for
review. Based on the importance and risk of the patch will then be
applied, however the next 2 days should really be focused on testing to
make sure we do not have critical issues, minor issues can always be
fixed in 5.3.1 and we better release with known minor issues than big
unknown issues caused by a last minute fix.
I have a minor issue with regard to spl_autoload_unregister /
spl_autoload_functions and closures in my backlog. I already committed
the patch & tests to HEAD [1]. I see this as extremely minor (since
spl_autoload_register was fixed a while ago and that is the only
really important use case in my eyes) so I'm perfectly happy to wait
until after 5.3.0 to merge it from HEAD. But just in case I've attached
the patch for 5.3 (NEWS file update not included in patch).
[1] http://news.php.net/php.cvs/58900
Regards,
Christian