Re: [PHP-DEV] Re: 5.3.0 stable release
On 23.06.2009, at 08:15, jvlad wrote: 1. you're wrong, PHP does not depend on system-wide installed pear, it will simply use it if present 2. 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 m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
1. you're wrong, PHP does not depend on system-wide installed pear, it will simply use it if present 2. 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
In other words, I see two bugs there: 1. PHP depends on the system-wide installed pear and tries to run it. 2. One or many files are missed in the package producing the Archive.php class file not found error. 1. 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? 2. 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
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? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
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) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
2009/6/23 jvlad d...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- regrads, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
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-internalsm=124524798321210w=2 here: http://marc.info/?l=php-internalsm=124524798321212w=2 and here: http://marc.info/?l=php-internalsm=124524798321213w=2 hope it helps. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
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 -O0 unfortunately, 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
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): 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
Hi 2009/6/23 jvlad d...@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 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. 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 - 1.31 +++ php_spl.h 23 Jun 2009 16:43:13 - @@ -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 ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
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 - 1.31 +++ php_spl.h 23 Jun 2009 16:43:13 - @@ -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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
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 Greg Please check all the info here: http://marc.info/?l=php-internalsm=124524798321210w=2 here: http://marc.info/?l=php-internalsm=124524798321212w=2 and here: http://marc.info/?l=php-internalsm=124524798321213w=2 Hi, I just ran a make install of PHP 5.3 on Solaris 32-bit: cel...@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) cel...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
Hi,
I just ran a make install of PHP 5.3 on Solaris 32-bit:
cel...@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)
cel...@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/bin
that 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 0xfff0
Let know if you want me to check the other variables.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
jvlad wrote:
Hi,
I just ran a make install of PHP 5.3 on Solaris 32-bit:
cel...@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)
cel...@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/bin
that 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 0xfff0
Let 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
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
5371INIT_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 0xfff0
(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);
}
}
?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
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
5371INIT_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 0xfff0
(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);
}
}
?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
On Mon, Jun 22, 2009 at 07:53, jvladd...@yandex.ru 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
On Mon, Jun 22, 2009 at 13:40, jvladd...@yandex.ru 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. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
jvlad d...@yandex.ru wrote in message news:38.7a.20019.c9d6f...@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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
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. It was http://bugs.php.net/?id=48593 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
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) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
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' -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
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'. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
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: 1. PHP depends on the system-wide installed pear and tries to run it. 2. One or many files are missed in the package producing the Archive.php class file not found error. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
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: 1. PHP depends on the system-wide installed pear and tries to run it. 2. One or many files are missed in the package producing the Archive.php class file not found error. 1. you're wrong, PHP does not depend on system-wide installed pear, it will simply use it if present 2. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
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: 1. PHP depends on the system-wide installed pear and tries to run it. 2. One or many files are missed in the package producing the Archive.php class file not found error. 1. you're wrong, PHP does not depend on system-wide installed pear, it will simply use it if present 2. 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.jo...@oracle.com Twitter: http://twitter.com/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
On Tue, Jun 23, 2009 at 12:39 AM, Christopher Joneschristopher.jo...@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 http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: 5.3.0 stable release
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 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
