Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
Quoting dan...@zoltak.com: Quoting dan...@zoltak.com: Quoting Scott MacVicar sc...@macvicar.net: Ideally both should be performed to ensure the error_log path is within the open_base. In the function OnUpdateErrorLog in main.c is there anyway to obtain the HTTP_HOST or SERVER_NAME variable or ideally the DOCUMENT_ROOT. I have tried using getenv() and sapi_getenv() without success. Are there any other methods? It appears there was a bug in PHP prior to 5.2.7 where PG(open_base_dir) had not been initialised in the OnUpdateErrorLog therefore the php_check_open_basedir() function was never being called if a custom error_log was specified in the .htaccess. So in fact the custom code we had should have never worked when the .htaccess had an error_log defined. I have now reworked our patch to perform some extra validation in our environment so this scenario works. Thanks to everyone that attempted to steer me in the right direction :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
Quoting dan...@zoltak.com: Quoting Scott MacVicar sc...@macvicar.net: Ideally both should be performed to ensure the error_log path is within the open_base. In the function OnUpdateErrorLog in main.c is there anyway to obtain the HTTP_HOST or SERVER_NAME variable or ideally the DOCUMENT_ROOT. I have tried using getenv() and sapi_getenv() without success. Are there any other methods? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
On 08/03/2009 07:52 AM, dan...@zoltak.com wrote:
Jani Taskinen wrote:
[snip]
You obviously do not have the correct sources then.
Try get them directly using SVN:
# svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_2/
And if those don't work either, you need to provide a GDB backtrace,
the
strace is useless for this. Also make sure you configure PHP using
--enable-debug !!
I have compile both apache and php using debug and run gdb with the
following result:
Obviously you haven't compiled using --enable-debug OR most likely are
not using the compiled libphp5.so. Check your phpinfo() that you
actually use the one you compiled first..
--Jani
#0 0x7f3e96df82eb in ?? () from /usr/lib64/apache2/modules/libphp5.so
#1 0x7f3e96dfb085 in zend_hash_find () from
/usr/lib64/apache2/modules/libphp5.so
#2 0x7f3e96d9229c in custom_open_base_check () from
/usr/lib64/apache2/modules/libphp5.so
#3 0x7f3e96d90c56 in php_check_specific_open_basedir () from
/usr/lib64/apache2/modules/libphp5.so
#4 0x7f3e96d9107f in php_check_open_basedir_ex () from
/usr/lib64/apache2/modules/libphp5.so
#5 0x7f3e96d90fd4 in php_check_open_basedir () from
/usr/lib64/apache2/modules/libphp5.so
#6 0x7f3e96d86adb in ?? () from /usr/lib64/apache2/modules/libphp5.so
#7 0x7f3e96e05346 in zend_alter_ini_entry_ex () from
/usr/lib64/apache2/modules/libphp5.so
#8 0x7f3e96e0511c in zend_alter_ini_entry () from
/usr/lib64/apache2/modules/libphp5.so
#9 0x7f3e96e77ded in apply_config () from
/usr/lib64/apache2/modules/libphp5.so
#10 0x7f3e96e77033 in ?? () from /usr/lib64/apache2/modules/libphp5.so
#11 0x00436633 in ap_run_handler ()
#12 0x00439511 in ap_invoke_handler ()
#13 0x004430b4 in ap_process_request ()
#14 0x00440706 in ?? ()
#15 0x0043ceb4 in ap_run_process_connection ()
#16 0x00446db7 in ?? ()
#17 0x00447012 in ?? ()
#18 0x004470ac in ?? ()
#19 0x00447cc8 in ap_mpm_run ()
#20 0x00425ab3 in main ()
The function custom_open_base_check() contains:
// Document root from Zend (pointer to pointer)
zval **document_root = NULL;
// Make sure DOCUMENT_ROOT is accessible from the global vars
if (!PG(http_globals)[TRACK_VARS_SERVER] ||
zend_hash_find(PG(http_globals)[TRACK_VARS_SERVER]-value.ht,
DOCUMENT_ROOT,
sizeof(DOCUMENT_ROOT), (void **) document_root) == FAILURE) {
// Unable to find DOCUMENT_ROOT
php_error_docref(NULL TSRMLS_CC, E_WARNING, fopen_wrapper_patch:
DOCUMENT_ROOT variable
is not set, cannot determine document root.);
// Can't check the document root - fail
return -1;
}
It crashing when its looking up the DOCUMENT_ROOT in the zend_hash_find.
This only occurs when the following is defined in an htaccess and with
the custom function in place:
[snip]
php_value error_log '/home/st/stu/studio1.com.au/www/logs/php_err.log'
Is it safe to access the DOCUMENT_ROOT this way at this point in the
code? If not is there an alternative or is there something wrong
somewhere else in the code?
If you could guide me on how to produce the necessary output to debug it
would be much appreciated.
Thanks
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
Quoting Jani Taskinen jani.taski...@sci.fi: On 08/03/2009 07:52 AM, dan...@zoltak.com wrote: Jani Taskinen wrote: [snip] Obviously you haven't compiled using --enable-debug OR most likely are not using the compiled libphp5.so. Check your phpinfo() that you actually use the one you compiled first.. --Jani Here is the correct backtrace. Hope it can bring some insight. #0 0x7f51031d12eb in _zend_is_inconsistent (ht=0x5a5a5a5a5a5a5a5a, file=0x7f510350bf58 /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/Zend/zend_hash.c, line=875) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/Zend/zend_hash.c:53 #1 0x7f51031d4085 in zend_hash_find (ht=0x5a5a5a5a5a5a5a5a, arKey=0x7f51034eee80 DOCUMENT_ROOT, nKeyLength=14, pData=0x7fff10fff068) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/Zend/zend_hash.c:875 #2 0x7f510316b29c in custom_open_base_check (basedir=0x3dd0f40 VIRTUAL_DOCUMENT_ROOT, resolved_name=0x7fff11003170 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/main/fopen_wrappers.c:709 #3 0x7f5103169c56 in php_check_specific_open_basedir (basedir=0x3dd0f40 VIRTUAL_DOCUMENT_ROOT, path=0x3dd0eb8 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/main/fopen_wrappers.c:118 #4 0x7f510316a07f in php_check_open_basedir_ex (path=0x3dd0eb8 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log, warn=1) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/main/fopen_wrappers.c:249 #5 0x7f5103169fd4 in php_check_open_basedir (path=0x3dd0eb8 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/main/fopen_wrappers.c:225 #6 0x7f510315fadb in OnUpdateErrorLog (entry=0x3bff8d0, new_value=0x3dd0eb8 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log, new_value_length=47, mh_arg1=0x68, mh_arg2=0x7f510386cc20, mh_arg3=0x0, stage=32) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/main/main.c:317 #7 0x7f51031de346 in zend_alter_ini_entry_ex (name=0x3e30680 error_log, name_length=10, new_value=0x3e20910 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log, new_value_length=47, modify_type=2, stage=32, force_change=0) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/Zend/zend_ini.c:293 #8 0x7f51031de11c in zend_alter_ini_entry (name=0x3e30680 error_log, name_length=10, new_value=0x3e20910 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log, new_value_length=47, modify_type=2, stage=32) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/Zend/zend_ini.c:248 #9 0x7f5103250ded in apply_config (dummy=0x3e21aa0) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/sapi/apache2handler/apache_config.c:195 #10 0x7f5103250033 in php_handler (r=0x3e262c8) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/sapi/apache2handler/sapi_apache2.c:531 #11 0x004369fc in ap_run_handler (r=0x3e262c8) at config.c:157 #12 0x00439aa4 in ap_invoke_handler (r=0x3e262c8) at config.c:372 #13 0x0044370c in ap_process_request (r=0x3e262c8) at http_request.c:282 #14 0x00440d85 in ap_process_http_connection (c=0x3e12138) at http_core.c:190 #15 0x0043d3f8 in ap_run_process_connection (c=0x3e12138) at connection.c:43 #16 0x0043d4ca in ap_process_connection (c=0x3e12138, csd=0x3e11f48) at connection.c:178 #17 0x00447814 in child_main (child_num_arg=value optimized out) at prefork.c:650 #18 0x004479a0 in make_child (s=0x66f850, slot=99) at prefork.c:746 #19 0x00447a00 in startup_children (number_to_start=1) at prefork.c:764 #20 0x00447ed7 in ap_mpm_run (_pconf=0x66a138, plog=value optimized out, s=value optimized out) at prefork.c:985 #21 0x00426039 in main (argc=27, argv=0x7fff11004b48) at main.c:740 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
On 08/03/2009 02:52 PM, dan...@zoltak.com wrote: Quoting Jani Taskinen jani.taski...@sci.fi: On 08/03/2009 07:52 AM, dan...@zoltak.com wrote: Jani Taskinen wrote: [snip] Obviously you haven't compiled using --enable-debug OR most likely are not using the compiled libphp5.so. Check your phpinfo() that you actually use the one you compiled first.. --Jani Here is the correct backtrace. Hope it can bring some insight. Well, this is using PHP 5.2.10. And you were supposed to test the snapshot. How about the backtrace using latest PHP_5_2 checkout? --Jani #0 0x7f51031d12eb in _zend_is_inconsistent (ht=0x5a5a5a5a5a5a5a5a, file=0x7f510350bf58 /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/Zend/zend_hash.c, line=875) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/Zend/zend_hash.c:53 #1 0x7f51031d4085 in zend_hash_find (ht=0x5a5a5a5a5a5a5a5a, arKey=0x7f51034eee80 DOCUMENT_ROOT, nKeyLength=14, pData=0x7fff10fff068) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/Zend/zend_hash.c:875 #2 0x7f510316b29c in custom_open_base_check (basedir=0x3dd0f40 VIRTUAL_DOCUMENT_ROOT, resolved_name=0x7fff11003170 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/main/fopen_wrappers.c:709 #3 0x7f5103169c56 in php_check_specific_open_basedir (basedir=0x3dd0f40 VIRTUAL_DOCUMENT_ROOT, path=0x3dd0eb8 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/main/fopen_wrappers.c:118 #4 0x7f510316a07f in php_check_open_basedir_ex (path=0x3dd0eb8 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log, warn=1) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/main/fopen_wrappers.c:249 #5 0x7f5103169fd4 in php_check_open_basedir (path=0x3dd0eb8 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/main/fopen_wrappers.c:225 #6 0x7f510315fadb in OnUpdateErrorLog (entry=0x3bff8d0, new_value=0x3dd0eb8 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log, new_value_length=47, mh_arg1=0x68, mh_arg2=0x7f510386cc20, mh_arg3=0x0, stage=32) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/main/main.c:317 #7 0x7f51031de346 in zend_alter_ini_entry_ex (name=0x3e30680 error_log, name_length=10, new_value=0x3e20910 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log, new_value_length=47, modify_type=2, stage=32, force_change=0) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/Zend/zend_ini.c:293 #8 0x7f51031de11c in zend_alter_ini_entry (name=0x3e30680 error_log, name_length=10, new_value=0x3e20910 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log, new_value_length=47, modify_type=2, stage=32) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/Zend/zend_ini.c:248 #9 0x7f5103250ded in apply_config (dummy=0x3e21aa0) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/sapi/apache2handler/apache_config.c:195 #10 0x7f5103250033 in php_handler (r=0x3e262c8) at /var/tmp/portage/dev-lang/php-5.2.10/work/php-5.2.10/sapi/apache2handler/sapi_apache2.c:531 #11 0x004369fc in ap_run_handler (r=0x3e262c8) at config.c:157 #12 0x00439aa4 in ap_invoke_handler (r=0x3e262c8) at config.c:372 #13 0x0044370c in ap_process_request (r=0x3e262c8) at http_request.c:282 #14 0x00440d85 in ap_process_http_connection (c=0x3e12138) at http_core.c:190 #15 0x0043d3f8 in ap_run_process_connection (c=0x3e12138) at connection.c:43 #16 0x0043d4ca in ap_process_connection (c=0x3e12138, csd=0x3e11f48) at connection.c:178 #17 0x00447814 in child_main (child_num_arg=value optimized out) at prefork.c:650 #18 0x004479a0 in make_child (s=0x66f850, slot=99) at prefork.c:746 #19 0x00447a00 in startup_children (number_to_start=1) at prefork.c:764 #20 0x00447ed7 in ap_mpm_run (_pconf=0x66a138, plog=value optimized out, s=value optimized out) at prefork.c:985 #21 0x00426039 in main (argc=27, argv=0x7fff11004b48) at main.c:740 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
Quoting Jani Taskinen jani.taski...@sci.fi: Well, this is using PHP 5.2.10. And you were supposed to test the snapshot. How about the backtrace using latest PHP_5_2 checkout? I downloaded the latest snap and tar.bz2 it in the php-5.2.10 folder so I could compiled it using the php-5.2.10 ebuild file in gentoo. Isn't the latest snap based off the SVN? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
On 08/03/2009 03:19 PM, dan...@zoltak.com wrote: Quoting Jani Taskinen jani.taski...@sci.fi: Well, this is using PHP 5.2.10. And you were supposed to test the snapshot. How about the backtrace using latest PHP_5_2 checkout? I downloaded the latest snap and tar.bz2 it in the php-5.2.10 folder so I could compiled it using the php-5.2.10 ebuild file in gentoo. Isn't the latest snap based off the SVN? Yes. You shouldn't really do it like that. Unpack it in separate directory. And build outside the sources: # tar zxfv php5.2-x.tar.gz # mkdir php_5_2 # cd php_5_2 # ../php5.2-x/configure --disable-all --enable-debug and the rest of relevant options here # make # make install --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
Quoting Jani Taskinen jani.taski...@sci.fi: Yes. You shouldn't really do it like that. Unpack it in separate directory. And build outside the sources: # tar zxfv php5.2-x.tar.gz # mkdir php_5_2 # cd php_5_2 # ../php5.2-x/configure --disable-all --enable-debug and the rest of relevant options here # make # make install I've tried to compile from SVN and recieved the following error: configure: error: Found invalid flex version: 2.5.33. Supported flex versions are: 2.5.4. Is there a simple fix for this? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
On 4 Aug 2009, at 00:08, dan...@zoltak.com wrote: Quoting Jani Taskinen jani.taski...@sci.fi: Yes. You shouldn't really do it like that. Unpack it in separate directory. And build outside the sources: # tar zxfv php5.2-x.tar.gz # mkdir php_5_2 # cd php_5_2 # ../php5.2-x/configure --disable-all --enable-debug and the rest of relevant options here # make # make install I've tried to compile from SVN and recieved the following error: configure: error: Found invalid flex version: 2.5.33. Supported flex versions are: 2.5.4. Is there a simple fix for this? The fix is very very simple, you just Install flex 2.5.4. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
Quoting Jani Taskinen jani.taski...@sci.fi: # tar zxfv php5.2-x.tar.gz # mkdir php_5_2 # cd php_5_2 # ../php5.2-x/configure --disable-all --enable-debug and the rest of relevant options here # make # make install Well I have flex-2.5.4 installed. Not sure why it requires this version when the release versions work with flex-2.5.3x? I have tried compiling the SVN version on a Gentoo and Fedora machine and both are failing with the following errors: /usr/lib64/libc-client.a(osdep.o): In function `ssl_onceonlyinit': (.text+0x6ae1): warning: the use of `tmpnam' is dangerous, better use `mkstemp' ext/standard/basic_functions.o: In function `zif_highlight_file': /usr/local/src/PHP_5_2/ext/standard/basic_functions.c:5511: undefined reference to `highlight_file' ext/standard/basic_functions.o: In function `zif_php_strip_whitespace': /usr/local/src/PHP_5_2/ext/standard/basic_functions.c:: undefined reference to `zend_save_lexical_state' /usr/local/src/PHP_5_2/ext/standard/basic_functions.c:5556: undefined reference to `open_file_for_scanning' /usr/local/src/PHP_5_2/ext/standard/basic_functions.c:5557: undefined reference to `zend_restore_lexical_state' /usr/local/src/PHP_5_2/ext/standard/basic_functions.c:5565: undefined reference to `zend_destroy_file_handle' /usr/local/src/PHP_5_2/ext/standard/basic_functions.c:5566: undefined reference to `zend_restore_lexical_state' ext/standard/basic_functions.o: In function `zif_highlight_string': /usr/local/src/PHP_5_2/ext/standard/basic_functions.c:5600: undefined reference to `highlight_string' ext/wddx/wddx.o: In function `php_wddx_deserialize_ex': /usr/local/src/PHP_5_2/ext/wddx/wddx.c:1098: undefined reference to `XML_ParserCreate' /usr/local/src/PHP_5_2/ext/wddx/wddx.c:1100: undefined reference to `XML_SetUserData' /usr/local/src/PHP_5_2/ext/wddx/wddx.c:1101: undefined reference to `XML_SetElementHandler' /usr/local/src/PHP_5_2/ext/wddx/wddx.c:1102: undefined reference to `XML_SetCharacterDataHandler' /usr/local/src/PHP_5_2/ext/wddx/wddx.c:1104: undefined reference to `XML_Parse' /usr/local/src/PHP_5_2/ext/wddx/wddx.c:1106: undefined reference to `XML_ParserFree' main/main.o: In function `php_execute_script': /usr/local/src/PHP_5_2/main/main.c:1950: undefined reference to `zend_file_handle_dtor' main/main.o: In function `php_lint_script': /usr/local/src/PHP_5_2/main/main.c:2140: undefined reference to `zend_destroy_file_handle' Zend/zend_ini_scanner.o: In function `zend_ini_close_file': /usr/local/src/chr/PHP_5_2/Zend/zend_ini_scanner.l:98: undefined reference to `zend_file_handle_dtor' Zend/zend_compile.o: In function `build_runtime_defined_function_key': /usr/local/src/PHP_5_2/Zend/zend_compile.c:78: undefined reference to `language_scanner_globals' Zend/zend_compile.o: In function `init_compiler': /usr/local/src/PHP_5_2/Zend/zend_compile.c:161: undefined reference to `zend_file_handle_dtor' Zend/zend_compile.o: In function `zend_do_halt_compiler_register': /usr/local/src/PHP_5_2/Zend/zend_compile.c:3175: undefined reference to `zend_get_scanned_file_offset' Zend/zend_compile.o: In function `zendlex': /usr/local/src/PHP_5_2/Zend/zend_compile.c:4175: undefined reference to `lex_scan' /usr/local/src/PHP_5_2/Zend/zend_compile.c:4184: undefined reference to `language_scanner_globals' /usr/local/src/PHP_5_2/Zend/zend_compile.c:4184: undefined reference to `language_scanner_globals' Zend/zend_highlight.o: In function `zend_highlight': /usr/local/src/PHP_5_2/Zend/zend_highlight.c:127: undefined reference to `language_scanner_globals' /usr/local/src/PHP_5_2/Zend/zend_highlight.c:127: undefined reference to `language_scanner_globals' /usr/local/src/PHP_5_2/Zend/zend_highlight.c:152: undefined reference to `language_scanner_globals' Zend/zend_highlight.o:/usr/local/src/PHP_5_2/Zend/zend_highlight.c:152: more undefined references to `language_scanner_globals' follow Zend/zend_highlight.o: In function `zend_highlight': /usr/local/src/PHP_5_2/Zend/zend_highlight.c:103: undefined reference to `lex_scan' Zend/zend_highlight.o: In function `zend_strip': /usr/local/src/PHP_5_2/Zend/zend_highlight.c:204: undefined reference to `language_scanner_globals' /usr/local/src/PHP_5_2/Zend/zend_highlight.c:204: undefined reference to `language_scanner_globals' /usr/local/src/PHP_5_2/Zend/zend_highlight.c:207: undefined reference to `lex_scan' /usr/local/src/PHP_5_2/Zend/zend_highlight.c:208: undefined reference to `language_scanner_globals' /usr/local/src/PHP_5_2/Zend/zend_highlight.c:208: undefined reference to `language_scanner_globals' /usr/local/src/PHP_5_2/Zend/zend_highlight.c:216: undefined reference to `language_scanner_globals' /usr/local/src/PHP_5_2/Zend/zend_highlight.c:216: undefined reference to `language_scanner_globals' /usr/local/src/PHP_5_2/Zend/zend_highlight.c:187: undefined reference to `lex_scan' Zend/zend.o: In function `zend_startup':
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
dan...@zoltak.com wrote: Quoting Jani Taskinen jani.taski...@sci.fi: # tar zxfv php5.2-x.tar.gz # mkdir php_5_2 # cd php_5_2 # ../php5.2-x/configure --disable-all --enable-debug and the rest of relevant options here # make # make install Well I have flex-2.5.4 installed. Not sure why it requires this version when the release versions work with flex-2.5.3x? The release tarballs come with a pre-built scanner built using flex-2.5.4. You don't even need flex installed to build from the release tarballs. It is only developers who run buildconf from the svn checkout that needs to have the right tools installed. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
Quoting Jani Taskinen jani.taski...@sci.fi: Yes. You shouldn't really do it like that. Unpack it in separate directory. And build outside the sources: # tar zxfv php5.2-x.tar.gz # mkdir php_5_2 # cd php_5_2 # ../php5.2-x/configure --disable-all --enable-debug and the rest of relevant options here # make # make install I couldn't get the direct SVN checkout to compile so I compiled the latest SNAP as above with the same result with the previous gdb. Again the segmentation fault occurs when an .htaccess is defined with an error_log and the custom_open_base_check is introduced that does a DOCUMENT_ROOT lookup. In PHP 5.2.6 this worked without issue. I have noticed the problem is intermittent i.e. it fails about 9/10 times. My questions are: 1. Is it safe to lookup the DOCUMENT_ROOT in fopen_wrappers. If not is there an alternative? 2. Why was this working in PHP 5.2.6 but now broken in 5.2.1x? 3. Is the problem related to Zend doing something it shouldn't? Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fd8fa117750 (LWP 20693)] 0x7fd8f432b04f in _zend_is_inconsistent (ht=0x5a5a5a5a5a5a5a5a, file=0x7fd8f4649ea8 /usr/local/src/php5.2-200908040030/Zend/zend_hash.c, line=875) at /usr/local/src/php5.2-200908040030/Zend/zend_hash.c:53 53 /usr/local/src/php5.2-200908040030/Zend/zend_hash.c: No such file or directory. in /usr/local/src/php5.2-200908040030/Zend/zend_hash.c (gdb) bt #0 0x7fd8f432b04f in _zend_is_inconsistent (ht=0x5a5a5a5a5a5a5a5a, file=0x7fd8f4649ea8 /usr/local/src/php5.2-200908040030/Zend/zend_hash.c, line=875) at /usr/local/src/php5.2-200908040030/Zend/zend_hash.c:53 #1 0x7fd8f432ddd7 in zend_hash_find (ht=0x5a5a5a5a5a5a5a5a, arKey=0x7fd8f462d0f0 DOCUMENT_ROOT, nKeyLength=14, pData=0x7fff0211e188) at /usr/local/src/php5.2-200908040030/Zend/zend_hash.c:875 #2 0x7fd8f42c55b0 in custom_open_base_check (basedir=0x3d4f990 VIRTUAL_DOCUMENT_ROOT, resolved_name=0x7fff02122290 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log) at /usr/local/src/php5.2-200908040030/main/fopen_wrappers.c:709 #3 0x7fd8f42c3f95 in php_check_specific_open_basedir (basedir=0x3d4f990 VIRTUAL_DOCUMENT_ROOT, path=0x3d4f908 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log) at /usr/local/src/php5.2-200908040030/main/fopen_wrappers.c:118 #4 0x7fd8f42c43ad in php_check_open_basedir_ex (path=0x3d4f908 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log, warn=1) at /usr/local/src/php5.2-200908040030/main/fopen_wrappers.c:249 #5 0x7fd8f42c4303 in php_check_open_basedir (path=0x3d4f908 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log) at /usr/local/src/php5.2-200908040030/main/fopen_wrappers.c:225 #6 0x7fd8f42b9f44 in OnUpdateErrorLog (entry=0x3bfe8a0, new_value=0x3d4f908 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log, new_value_length=47, mh_arg1=0x68, mh_arg2=0x7fd8f498db80, mh_arg3=0x0, stage=32) at /usr/local/src/php5.2-200908040030/main/main.c:317 #7 0x7fd8f433804e in zend_alter_ini_entry_ex (name=0x3dab150 error_log, name_length=10, new_value=0x3da1480 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log, new_value_length=47, modify_type=2, stage=32, force_change=0) at /usr/local/src/php5.2-200908040030/Zend/zend_ini.c:293 #8 0x7fd8f4337e24 in zend_alter_ini_entry (name=0x3dab150 error_log, name_length=10, new_value=0x3da1480 /home/c-web/cf/4e/tweek.com.au/logs/php_err.log, new_value_length=47, modify_type=2, stage=32) at /usr/local/src/php5.2-200908040030/Zend/zend_ini.c:248 #9 0x7fd8f43aaa22 in apply_config (dummy=0x3da2610) at /usr/local/src/php5.2-200908040030/sapi/apache2handler/apache_config.c:195 #10 0x7fd8f43a9c69 in php_handler (r=0x3dafda8) at /usr/local/src/php5.2-200908040030/sapi/apache2handler/sapi_apache2.c:531 #11 0x00436633 in ap_run_handler () #12 0x00439511 in ap_invoke_handler () #13 0x004430b4 in ap_process_request () #14 0x00440706 in ?? () #15 0x0043ceb4 in ap_run_process_connection () #16 0x00446db7 in ?? () #17 0x00447012 in ?? () #18 0x004470ac in ?? () #19 0x00447cc8 in ap_mpm_run () #20 0x00425ab3 in main () -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
On 4 Aug 2009, at 03:14, dan...@zoltak.com wrote: Quoting Jani Taskinen jani.taski...@sci.fi: Yes. You shouldn't really do it like that. Unpack it in separate directory. And build outside the sources: # tar zxfv php5.2-x.tar.gz # mkdir php_5_2 # cd php_5_2 # ../php5.2-x/configure --disable-all --enable-debug and the rest of relevant options here # make # make install I couldn't get the direct SVN checkout to compile so I compiled the latest SNAP as above with the same result with the previous gdb. Again the segmentation fault occurs when an .htaccess is defined with an error_log and the custom_open_base_check is introduced that does a DOCUMENT_ROOT lookup. In PHP 5.2.6 this worked without issue. I have noticed the problem is intermittent i.e. it fails about 9/10 times. My questions are: 1. Is it safe to lookup the DOCUMENT_ROOT in fopen_wrappers. If not is there an alternative? Not at the point the function is being executed on a fresh child start PHP hasn't always been fully started by the time it's doing the config merging. None of the SAPI variables have been imported. You might be able to use sapi_getenv(DOCUMENT_ROOT, sizeof(DOCUMENT_ROOT)) Another solution is to skip doing you check before the SAPI is loaded :-) 2. Why was this working in PHP 5.2.6 but now broken in 5.2.1x? Are you sure you were using 5.2.6? We never checked the error_log value until 5.2.4, it's the first version to have it. 3. Is the problem related to Zend doing something it shouldn't? Doubtful, the reason its erroring is because the hash table you've given it isn't a hash table at that point. It's random memory. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
Quoting Scott MacVicar sc...@macvicar.net: 1. Is it safe to lookup the DOCUMENT_ROOT in fopen_wrappers. If not is there an alternative? Not at the point the function is being executed on a fresh child start PHP hasn't always been fully started by the time it's doing the config merging. None of the SAPI variables have been imported. You might be able to use sapi_getenv(DOCUMENT_ROOT, sizeof(DOCUMENT_ROOT)) This method dosen't appear to work. Another solution is to skip doing you check before the SAPI is loaded :-) If we do this then we cannot determine if the error_log is in the DOCUMENT_ROOT. 2. Why was this working in PHP 5.2.6 but now broken in 5.2.1x? Are you sure you were using 5.2.6? We never checked the error_log value until 5.2.4, it's the first version to have it. Yes I am positive it was PHP 5.2.6 - It worked with 5.2.4 and 5.2.5 as well. It would be intresting to understand why it worked in these versions. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
On 4 Aug 2009, at 04:49, dan...@zoltak.com wrote: Quoting Scott MacVicar sc...@macvicar.net: 1. Is it safe to lookup the DOCUMENT_ROOT in fopen_wrappers. If not is there an alternative? Not at the point the function is being executed on a fresh child start PHP hasn't always been fully started by the time it's doing the config merging. None of the SAPI variables have been imported. You might be able to use sapi_getenv(DOCUMENT_ROOT, sizeof(DOCUMENT_ROOT)) This method dosen't appear to work. Any chance of a clarification on doesn't appear to work? Does it fail to compile or is it killing unicorns :-) Another solution is to skip doing you check before the SAPI is loaded :-) If we do this then we cannot determine if the error_log is in the DOCUMENT_ROOT. This was the vulnerability that we were fixing in the first place and no doubt the source of the error. 2. Why was this working in PHP 5.2.6 but now broken in 5.2.1x? Are you sure you were using 5.2.6? We never checked the error_log value until 5.2.4, it's the first version to have it. Yes I am positive it was PHP 5.2.6 - It worked with 5.2.4 and 5.2.5 as well. It would be intresting to understand why it worked in these versions. Do you know the first version it stopped working? 5.2.7 - 5.2.10 is about 15 months worth of bug fixes. Narrowing it down to a particular version would help. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
Quoting Scott MacVicar sc...@macvicar.net: On 4 Aug 2009, at 04:49, dan...@zoltak.com wrote: Quoting Scott MacVicar sc...@macvicar.net: [snip] You might be able to use sapi_getenv(DOCUMENT_ROOT, sizeof(DOCUMENT_ROOT)) This method dosen't appear to work. Any chance of a clarification on doesn't appear to work? Does it fail to compile or is it killing unicorns :-) To clarify it returns a NULL value. [snip] Do you know the first version it stopped working? 5.2.7 - 5.2.10 is about 15 months worth of bug fixes. Narrowing it down to a particular version would help. I will determine the first version it stopped working with and get back to you. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
Quoting dan...@zoltak.com: Quoting Scott MacVicar sc...@macvicar.net: [snip] Do you know the first version it stopped working? 5.2.7 - 5.2.10 is about 15 months worth of bug fixes. Narrowing it down to a particular version would help. I will determine the first version it stopped working with and get back to you. The issue starts from 5.2.8 only had a single fix over 5.2.7 in the change log. Looking over the 5.2.7 change log I found: Added logging option for error_log to send directly to SAPI. (Stas) This sounds like it could be the cause. Anyway of tracking what the changes were? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
On 4 Aug 2009, at 05:36, dan...@zoltak.com wrote: Quoting dan...@zoltak.com: Quoting Scott MacVicar sc...@macvicar.net: [snip] Do you know the first version it stopped working? 5.2.7 - 5.2.10 is about 15 months worth of bug fixes. Narrowing it down to a particular version would help. I will determine the first version it stopped working with and get back to you. The issue starts from 5.2.8 only had a single fix over 5.2.7 in the change log. Looking over the 5.2.7 change log I found: Added logging option for error_log to send directly to SAPI. (Stas) That adds an option to the PHP function error_log() no changes to the actual SAPI code. http://svn.php.net/viewvc?view=revisionrevision=268964 It could be related to the following patch to do with evaluation order of per directory configuration http://svn.php.net/viewvc?view=revisionsortby=daterevision=269640 Again it's another security issue that was resolved. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
Quoting Scott MacVicar sc...@macvicar.net: It could be related to the following patch to do with evaluation order of per directory configuration http://svn.php.net/viewvc?view=revisionsortby=daterevision=269640 Again it's another security issue that was resolved. I'm not sure if this is the cause either? The issue is that in the backtrace it appears to crash in the function _zend_is_inconsistent intermittently. If the function was working correctly the code I wrote would just return -1 everytime instead of random crashes? The other options is to stop the check by checking to see if the SAPI has been initialised before calling the zend_hash_find function - how can I do this? Or/and do the error_log open_base check after the SAPI has be initialised - again not sure how to do this? Ideally both should be performed to ensure the error_log path is within the open_base. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
Jani Taskinen wrote:
[snip]
There is a bug in 5.2.10 that might cause this, try latest SVN
checkout of PHP_5_2
branch, it should be fixed now.
I've download and tested the latest snap (php5.2-200908020630) and I
am still having the same issue. I have performed an strace with the
following result:
6717 stat(/home/c-web/cf/4e/tweek.com.au/public/www/index.php,
0x7fff6adf59a0) = -1
ENOENT (No such file or directory)
6717 lstat(/home, {st_mode=S_IFDIR|0755, st_size=61440, ...}) = 0
6717 lstat(/home/c-web, {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
6717 lstat(/home/c-web/cf, {st_mode=S_IFDIR|0755, st_size=8192, ...}) = 0
6717 lstat(/home/c-web/cf/4e, {st_mode=S_IFDIR|0755, st_size=4096,
...}) = 0
6717 lstat(/home/c-web/cf/4e/tweek.com.au, {st_mode=S_IFDIR|0755,
st_size=4096, ...})
= 0
6717 lstat(/home/c-web/cf/4e/tweek.com.au/public,
{st_mode=S_IFDIR|0755, st_size=4096,
...}) = 0
6717 lstat(/home/c-web/cf/4e/tweek.com.au/public/www,
{st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
6717 lstat(/home/c-web/cf/4e/tweek.com.au/public/www/index.php,
0x7fff6adf59a0) = -1
ENOENT (No such file or directory)
6717 stat(/home/c-web/cf/4e/tweek.com.au/public/www/index.html,
{st_mode=S_IFREG|0644,
st_size=14369, ...}) = 0
6717 lstat(/home, {st_mode=S_IFDIR|0755, st_size=61440, ...}) = 0
6717 lstat(/home/c-web, {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
6717 lstat(/home/c-web/cf, {st_mode=S_IFDIR|0755, st_size=8192, ...}) = 0
6717 lstat(/home/c-web/cf/4e, {st_mode=S_IFDIR|0755, st_size=4096,
...}) = 0
6717 lstat(/home/c-web/cf/4e/tweek.com.au, {st_mode=S_IFDIR|0755,
st_size=4096, ...})
= 0
6717 lstat(/home/c-web/cf/4e/tweek.com.au/logs,
{st_mode=S_IFDIR|0771, st_size=4096,
...}) = 0
6717 lstat(/home/c-web/cf/4e/tweek.com.au/logs/php_err.log,
{st_mode=S_IFREG|0644,
st_size=2036814, ...}) = 0
6717 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
The apache_error_log is also reporting some errors when I have the
error_log enabled in
the .htaccess file:
[snip apache_error_log]
(process:3857): GLib-WARNING **: getpwuid_r(): failed due to:
Permission denied.
[notice] child pid 6216 exit signal Segmentation fault (11)
[end snip]
I think I found the original bug report,
http://bugs.php.net/bug.php?id=48993edit=1,
which has a similar strace output and is reported to have been fixed
however I do believe
this is the same bug and it still is unresolved.
Should we create a new bug entry or reopen #48993?
Hopefully the additional information will provide some assistance in
tracking this one
down.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
Dan Zoltak wrote: Jani Taskinen wrote: [snip] There is a bug in 5.2.10 that might cause this, try latest SVN checkout of PHP_5_2 branch, it should be fixed now. I've download and tested the latest snap (php5.2-200908020630) and I am still having the same issue. I have performed an strace with the following result: You obviously do not have the correct sources then. Try get them directly using SVN: # svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_2/ And if those don't work either, you need to provide a GDB backtrace, the strace is useless for this. Also make sure you configure PHP using --enable-debug !! --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
Jani Taskinen wrote: Dan Zoltak wrote: Jani Taskinen wrote: [snip] There is a bug in 5.2.10 that might cause this, try latest SVN checkout of PHP_5_2 branch, it should be fixed now. I've download and tested the latest snap (php5.2-200908020630) and I am still having the same issue. I have performed an strace with the following result: You obviously do not have the correct sources then. Try get them directly using SVN: # svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_2/ And if those don't work either, you need to provide a GDB backtrace, the strace is useless for this. Also make sure you configure PHP using --enable-debug !! Jani, if you mean the fix for bug #48880, then that doesn't apply here. That was 5.3/6 only because it was in the new code that lets you tighten the open_basedir restrictions at runtime. I don't see any 5.2 fopen_wrappers.c changes for the past many months. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
Rasmus Lerdorf wrote: Jani Taskinen wrote: Dan Zoltak wrote: Jani Taskinen wrote: [snip] There is a bug in 5.2.10 that might cause this, try latest SVN checkout of PHP_5_2 branch, it should be fixed now. I've download and tested the latest snap (php5.2-200908020630) and I am still having the same issue. I have performed an strace with the following result: You obviously do not have the correct sources then. Try get them directly using SVN: # svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_2/ And if those don't work either, you need to provide a GDB backtrace, the strace is useless for this. Also make sure you configure PHP using --enable-debug !! Jani, if you mean the fix for bug #48880, then that doesn't apply here. That was 5.3/6 only because it was in the new code that lets you tighten the open_basedir restrictions at runtime. I don't see any 5.2 fopen_wrappers.c changes for the past many months. No, I was thinking the issue here was fixed by fixing bug #48247. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
Jani Taskinen wrote:
[snip]
You obviously do not have the correct sources then.
Try get them directly using SVN:
# svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_2/
And if those don't work either, you need to provide a GDB backtrace, the
strace is useless for this. Also make sure you configure PHP using
--enable-debug !!
I have compile both apache and php using debug and run gdb with the
following result:
#0 0x7f3e96df82eb in ?? () from /usr/lib64/apache2/modules/libphp5.so
#1 0x7f3e96dfb085 in zend_hash_find () from
/usr/lib64/apache2/modules/libphp5.so
#2 0x7f3e96d9229c in custom_open_base_check () from
/usr/lib64/apache2/modules/libphp5.so
#3 0x7f3e96d90c56 in php_check_specific_open_basedir () from
/usr/lib64/apache2/modules/libphp5.so
#4 0x7f3e96d9107f in php_check_open_basedir_ex () from
/usr/lib64/apache2/modules/libphp5.so
#5 0x7f3e96d90fd4 in php_check_open_basedir () from
/usr/lib64/apache2/modules/libphp5.so
#6 0x7f3e96d86adb in ?? () from /usr/lib64/apache2/modules/libphp5.so
#7 0x7f3e96e05346 in zend_alter_ini_entry_ex () from
/usr/lib64/apache2/modules/libphp5.so
#8 0x7f3e96e0511c in zend_alter_ini_entry () from
/usr/lib64/apache2/modules/libphp5.so
#9 0x7f3e96e77ded in apply_config () from
/usr/lib64/apache2/modules/libphp5.so
#10 0x7f3e96e77033 in ?? () from /usr/lib64/apache2/modules/libphp5.so
#11 0x00436633 in ap_run_handler ()
#12 0x00439511 in ap_invoke_handler ()
#13 0x004430b4 in ap_process_request ()
#14 0x00440706 in ?? ()
#15 0x0043ceb4 in ap_run_process_connection ()
#16 0x00446db7 in ?? ()
#17 0x00447012 in ?? ()
#18 0x004470ac in ?? ()
#19 0x00447cc8 in ap_mpm_run ()
#20 0x00425ab3 in main ()
The function custom_open_base_check() contains:
// Document root from Zend (pointer to pointer)
zval **document_root = NULL;
// Make sure DOCUMENT_ROOT is accessible from the global vars
if (!PG(http_globals)[TRACK_VARS_SERVER] ||
zend_hash_find(PG(http_globals)[TRACK_VARS_SERVER]-value.ht,
DOCUMENT_ROOT,
sizeof(DOCUMENT_ROOT), (void **) document_root) == FAILURE) {
// Unable to find DOCUMENT_ROOT
php_error_docref(NULL TSRMLS_CC, E_WARNING,
fopen_wrapper_patch: DOCUMENT_ROOT variable
is not set, cannot determine document root.);
// Can't check the document root - fail
return -1;
}
It crashing when its looking up the DOCUMENT_ROOT in the
zend_hash_find. This only occurs when the following is defined in an
.htaccess and with the custom function in place:
[snip]
php_value error_log '/home/st/stu/studio1.com.au/www/logs/php_err.log'
Is it safe to access the DOCUMENT_ROOT this way at this point in the
code? If not is there an alternative or is there something wrong
somewhere else in the code?
If you could guide me on how to produce the necessary output to debug
it would be much appreciated.
Thanks
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fopen_wrappers.c DOCUMENT_ROOT .htaccess error
On 07/31/2009 03:10 AM, dan...@zoltak.com wrote: [snip] The above code has been works fine in PHP 5.2.6. In PHP 5.2.10 it works except when an .htaccess is defined with the following: --BEGIN SNIP .htaccess-- php_value error_log '/home/st/stu/studio1.com.au/www/logs/php_err.log' --END SNIP-- There is a bug in 5.2.10 that might cause this, try latest SVN checkout of PHP_5_2 branch, it should be fixed now. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
