[PHP-DEV] Re: Register Shutdown Function for Apache
Joseph, Your latest patch seems to be in the right direction (admittedly I haven't reviewed it until now). A couple of random points: - It sounds dangerous to me to move php_request_shutdown() to be called from Apache's shutdown without further inspection. At least one thing comes to mind - won't it screw up output buffers (they're supposed to autoflush on shutdown, and if I'm not mistaken, this autoflush will now happen when the connection is already closed)? Possibly some other things too. - Once we're all happy with the patch, we need to decide what to do with it. Right now, there are no plans to release any further 4.x versions, except for bug fixes. And the question arises - should this change be in a bugfix release or not. It certainly has potential to screw things up. Zeev At 18:38 23/01/2003, Joseph Tate wrote: I can have the patches ready to go in a very short amount of time. I'll work on and post them if I can be reasonably sure they'll be committed. I'm tired of spinning my wheels with this though. I've got a personally patched version of 4.3.0 that will be going into production in a few weeks, so I'm confident in the changes. I'd like to not use a personally patched version of PHP the next time a release comes down the pipe though. As a reminder, this patch will fix bug #15209 without breaking the new functionality of register_shutdown_function under !apache systems. I've appealed to the [EMAIL PROTECTED] for karma to apply them myself, but for the last two weeks have heard nothing either negative or positive. Joseph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Register Shutdown Function for Apache
On Tue, 28 Jan 2003, Zeev Suraski wrote: Your latest patch seems to be in the right direction (admittedly I haven't reviewed it until now). A couple of random points: - It sounds dangerous to me to move php_request_shutdown() to be called from Apache's shutdown without further inspection. At least one thing comes to mind - won't it screw up output buffers (they're supposed to autoflush on shutdown, and if I'm not mistaken, this autoflush will now happen when the connection is already closed)? Possibly some other things too. - Once we're all happy with the patch, we need to decide what to do with it. Right now, there are no plans to release any further 4.x versions, except for bug fixes. And the question arises - should this change be in a bugfix release or not. It certainly has potential to screw things up. I don't favor merging this to the PHP_4_3 branch, as it seems a huge change. (And it's broken for quite some time anyway). Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Another segfault running pear installer
$ gdb sapi/cli/php GNU gdb Red Hat Linux (5.1.90CVS-5) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux... (gdb) r -n -dsafe_mode=0 /data/src/php5/pear/install-pear.php /data/src/php5/pear/package-*.xml Starting program: /data/src/php5/sapi/cli/php -n -dsafe_mode=0 /data/src/php5/pear/install-pear.php /data/src/php5/pear/package-*.xml Warning: Invalid argument supplied for foreach() in /data/src/php5/pear/PEAR/Registry.php on line 489 /data/src/php5/pear/PEAR/Registry.php(489) : Warning - Invalid argument supplied for foreach() Warning: Cannot use a scalar value as an array in /data/src/php5/pear/PEAR/Installer.php on line 682 /data/src/php5/pear/PEAR/Installer.php(682) : Warning - Cannot use a scalar value as an array Warning: Invalid argument supplied for foreach() in /data/src/php5/pear/PEAR/Installer.php on line 682 /data/src/php5/pear/PEAR/Installer.php(682) : Warning - Invalid argument supplied for foreach() Program received signal SIGSEGV, Segmentation fault. 0x080817b9 in compile_branch (optionsptr=0x402be350, brackets=0x0, codeptr=0x1, ptrptr=0x0, errorptr=0x10, firstcharptr=0x402b19fc, reqcharptr=0x402c73bc, bcptr=0x1, cd=0x402b1ce4) at /data/src/php5/ext/pcre/pcrelib/pcre.c:2708 2708previous[1] = length; (gdb) bt #0 0x080817b9 in compile_branch (optionsptr=0x402be350, brackets=0x0, codeptr=0x1, ptrptr=0x0, errorptr=0x10, firstcharptr=0x402b19fc, reqcharptr=0x402c73bc, bcptr=0x1, cd=0x402b1ce4) at /data/src/php5/ext/pcre/pcrelib/pcre.c:2708 #1 0x0816c0fc in zend_do_fcall_common_helper (execute_data=0xbfffb0b0, op_array=0x402d5ac4) at /data/src/php5/Zend/zend_execute.c:2630 #2 0x0816c43c in zend_do_fcall_by_name_handler (execute_data=0xbfffb0b0, op_array=0x402d5ac4) at /data/src/php5/Zend/zend_execute.c:2694 #3 0x081677e2 in execute (op_array=0x402d5ac4) at /data/src/php5/Zend/zend_execute.c:1217 #4 0x0816c0fc in zend_do_fcall_common_helper (execute_data=0xbfffd630, op_array=0x400af464) at /data/src/php5/Zend/zend_execute.c:2630 #5 0x0816c43c in zend_do_fcall_by_name_handler (execute_data=0xbfffd630, op_array=0x400af464) at /data/src/php5/Zend/zend_execute.c:2694 #6 0x081677e2 in execute (op_array=0x400af464) at /data/src/php5/Zend/zend_execute.c:1217 #7 0x081569f6 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /data/src/php5/Zend/zend.c:996 #8 0x08123479 in php_execute_script (primary_file=0xb960) at /data/src/php5/main/main.c:1691 #9 0x081727bc in main (argc=7, argv=0xba04) at /data/src/php5/sapi/cli/php_cli.c:753 #10 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reducing the number of system calls for includes
Don't you have any FreeBSD kernel hackers in Y!? You could probably convince/bully one of them to fix it, that's what we always do with ours here ;-) Turns out that one of the problems is that the standard 0x80 way of doing a syscall is rather slow on the P4 chip. P3 and Athlon chips are much faster. As of Linux kernel 2.5.57 or so they are now using sysenter which is much quicker, but FreeBSD is still using 0x80 on the P4. This article has some interesting info on the subject: http://lwn.net/Articles/18411/ In the end it looks like I am simply going to turn off realpath() completely in virtual_file_ex() which means of course that if include_once/require_once is used to access the same file through two different paths due to a symlink, things will break. And you can symlink your way out of an open_basedir restriction. I'll happily trade those things for the extra 40-50 req/sec this is likely to give me. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Segmention fault in HEAD (zend_hash_find)
Fixed.
At 08:04 28/01/2003, Magnus Määttä wrote:
Hi!
This code produces this segfault under HEAD.
?php declare(ticks = 1); function test() { } ?
bt ( for the whole bt: http://novell.stoldgods.nu/~magnus/bt ):
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 31900)]
0x0825350c in zend_hash_find (ht=0x83bbdb4, arKey=0x1 Address 0x1 out of
bounds, nKeyLength=1, pData=0xbfffbcf4)
at /opt/DEV/php/php5/Zend/zend_hash.c:873
873 HANDLE_NUMERIC(arKey, nKeyLength, zend_hash_index_find(ht,
idx, pData));
(gdb) bt
#0 0x0825350c in zend_hash_find (ht=0x83bbdb4, arKey=0x1 Address 0x1 out
of bounds, nKeyLength=1, pData=0xbfffbcf4)
at /opt/DEV/php/php5/Zend/zend_hash.c:873
#1 0x0823bf0b in do_bind_function (opline=0x418a3334,
function_table=0x83bbdb4, class_table=0x83bbe64, compile_time=1)
at /opt/DEV/php/php5/Zend/zend_compile.c:1703
#2 0x0823c331 in zend_do_early_binding () at
/opt/DEV/php/php5/Zend/zend_compile.c:1792
#3 0x0822a55b in zendparse () at
/opt/DEV/php/php5/Zend/zend_language_parser.y:155
#4 0x0822fd8d in compile_file (file_handle=0xb800, type=2) at
/opt/DEV/php/php5/Zend/zend_language_scanner.l:297
#5 0x0824c75e in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /opt/DEV/php/php5/Zend/zend.c:992
#6 0x08213907 in php_execute_script (primary_file=0xb800) at
/opt/DEV/php/php5/main/main.c:1691
#7 0x0826dbfd in main (argc=2, argv=0xb894) at
/opt/DEV/php/php5/sapi/cli/php_cli.c:753
#8 0x40a7fa44 in __libc_start_main () from /lib/libc.so.6
(gdb) bt full
#0 0x0825350c in zend_hash_find (ht=0x83bbdb4, arKey=0x1 Address 0x1 out
of bounds, nKeyLength=1, pData=0xbfffbcf4)
at /opt/DEV/php/php5/Zend/zend_hash.c:873
tmp = 0x1 Address 0x1 out of bounds
h = 1099587512
nIndex = 1099587512
p = (struct bucket *) 0x418d1ffc
#1 0x0823bf0b in do_bind_function (opline=0x418a3334,
function_table=0x83bbdb4, class_table=0x83bbe64, compile_time=1)
at /opt/DEV/php/php5/Zend/zend_compile.c:1703
function = (union _zend_function *) 0x831b4a0
#2 0x0823c331 in zend_do_early_binding () at
/opt/DEV/php/php5/Zend/zend_compile.c:1792
opline = (struct _zend_op *) 0x418a3334
#3 0x0822a55b in zendparse () at
/opt/DEV/php/php5/Zend/zend_language_parser.y:155
zendchar = -2
zendlval = {op_type = 1, throw_list = 0x0, u = {constant = {value
= {lval = 138932069, dval = 4.3126331443290903e-314,
str = {val = 0x847ef65 \n\n}, len = 2}, ht = 0x847ef65, obj =
{handle = 138932069, handlers = 0x2}}, refcount = 1,
type = 1 '\001', is_ref = 0 '\0'}, var = 138932069, opline_num =
138932069, op_array = 0x847ef65,
previously_active_class_entry = 0x847ef65, jmp_addr = 0x847ef65, EA =
{var = 138932069, type = 2}}}
zendnerrs = 0
yystate = 71
yyn = 6
yyresult = 0
yyerrstatus = 0
yychar1 = 137
yyssa = {0, 1, 2, 71, 139, 246, 373, 458, 515, 563, 617, 656,
686, 709, 58, 0, 19124, 16686, 15188, 16385, 16124, 16385,
-12431, 2055, -11392, -16385, 28976, 16384, -12431, 2055, -29767, 1801,
24900, 2054, -11472, -16385, 16048, 16385, 58, 0, 19392,
16686, 0, 0, 1, 0 repeats 25 times, 30240, 27745, -17521, 0, -17440,
2107, -11480, -16385, -10352, 2085, -17448, 2107, 12736,
16778, 12644, 16569, -11384, -16385, 12736, 16778, -4548, 2, -11432,
-16385, -11713, 2085, -18957, 0, -17440, 2107, -11432,
-16385, -10352, 2085, -17448, 2107, 18480, 16778, -17184, 2107, 12620,
16778, 18480, 16778, -10292, 2, -11384, -16385, -11713,
2085, -17448, 2107, 12796, 16778, 5684, 0, 5684, 0, 12808, 16778, 1421,
0, 12668, 16778, 12796, 16778, 0, 0, 5684, 0, -11336,
-16385, 27860, 2083, 18476, 16778, -25604, 2105, 4, 0, -10352, 2085,
-17448, 2107, 12796, 16778, 12844, 16778, 704, 0, 5632, 0,
12808, 16778, -11288, -16385, 28348, 2083, 5632, 0, -20800, 2097, 48,
0, 0, 0, 0, 0, 12844, 16778, -17184, 2107, 12736, 16778, 0,
0, 60, 0, -11240, -16385, 16830, 2084, 0, 0, 5632, 0, 0, 0, -20800, 2097}
yyss = (short int *) 0xbfffd270
yyssp = (short int *) 0xbfffd276
around 60k more after that..
Regards
Magnus Määttä
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fw: [PHP - NOTES] note 28935 added to function.strftime
A user posted this note below. I do not know Catalan and cannot check it myself, however I decided not to ignore it and ask if anyone on the dev list could confirm that the user makes sense. If he does, then what? Maxim Maletsky [EMAIL PROTECTED] Forwarded by Maxim Maletsky [EMAIL PROTECTED] --- Original Message --- From:Iván@rack1.php.net To: [EMAIL PROTECTED] Date:28 Jan 2003 15:07:31 - Subject: [PHP-NOTES] note 28935 added to function.strftime PHP contains a bug in the Catalan (ca_ES) locale, as it has decembre for december, when it should be desembre. It also affects to the abbreviation dec, which should be des. Take this into account if you're coding locale-dependant for Catalan display settings... -- http://www.php.net/manual/en/function.strftime.php http://master.php.net/manage/user-notes.php?action=edit+28935 http://master.php.net/manage/user-notes.php?action=delete+28935 http://master.php.net/manage/user-notes.php?action=reject+28935 -- PHP Notes Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php - Original Message Ends -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fw: [PHP - NOTES] note 28935 added to function.strftime
On Tue, 28 Jan 2003, Maxim Maletsky wrote: A user posted this note below. I do not know Catalan and cannot check it myself, however I decided not to ignore it and ask if anyone on the dev list could confirm that the user makes sense. If he does, then what? It wouldn't be a bug in PHP, but in the locales installed on his system I guess. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fw: [PHP - NOTES] note 28935 added to function.strftime
Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 28 Jan 2003, Maxim Maletsky wrote: A user posted this note below. I do not know Catalan and cannot check it myself, however I decided not to ignore it and ask if anyone on the dev list could confirm that the user makes sense. If he does, then what? It wouldn't be a bug in PHP, but in the locales installed on his system I guess. Derick In fact, I did guess that. Anything we can do, though? At least, I think we should remove his note as it is unrelated to other locale's installations. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Register Shutdown Function for Apache
It also does not send the headers if there is not content. ?php header(Location: http://spidey.dealnews.com/;); exit(); ? Document Contains No Data. Brian. dealnews.com - Original Message - From: Brian Moon [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Joseph Tate [EMAIL PROTECTED] Cc: Php-Dev List [EMAIL PROTECTED]; PHP Group [EMAIL PROTECTED] Sent: Tuesday, January 28, 2003 10:16 AM Subject: Re: [PHP-DEV] Re: Register Shutdown Function for Apache | You are correct. The output buffer is not auto-flushed with this patch. | | Brian. | dealnews.com | | - Original Message - | From: Zeev Suraski [EMAIL PROTECTED] | To: Joseph Tate [EMAIL PROTECTED] | Cc: Php-Dev List [EMAIL PROTECTED]; PHP Group [EMAIL PROTECTED] | Sent: Tuesday, January 28, 2003 3:16 AM | Subject: [PHP-DEV] Re: Register Shutdown Function for Apache | | | | Joseph, | | | | Your latest patch seems to be in the right direction (admittedly I haven't | | reviewed it until now). A couple of random points: | | | | - It sounds dangerous to me to move php_request_shutdown() to be called | | from Apache's shutdown without further inspection. At least one thing | | comes to mind - won't it screw up output buffers (they're supposed to | | autoflush on shutdown, and if I'm not mistaken, this autoflush will now | | happen when the connection is already closed)? Possibly some other things | too. | | - Once we're all happy with the patch, we need to decide what to do with | | it. Right now, there are no plans to release any further 4.x versions, | | except for bug fixes. And the question arises - should this change be in | a | | bugfix release or not. It certainly has potential to screw things up. | | | | Zeev | | | | At 18:38 23/01/2003, Joseph Tate wrote: | | I can have the patches ready to go in a very short amount of time. I'll | | work on and post them if I can be reasonably sure they'll be committed. | I'm | | tired of spinning my wheels with this though. I've got a personally | patched | | version of 4.3.0 that will be going into production in a few weeks, so | I'm | | confident in the changes. I'd like to not use a personally patched | version | | of PHP the next time a release comes down the pipe though. As a | reminder, | | this patch will fix bug #15209 without breaking the new functionality of | | register_shutdown_function under !apache systems. | | | | I've appealed to the [EMAIL PROTECTED] for karma to apply them myself, but | for | | the last two weeks have heard nothing either negative or positive. | | | | Joseph | | | | | | -- | | PHP Development Mailing List http://www.php.net/ | | To unsubscribe, visit: http://www.php.net/unsub.php | | | | | | | | | -- | PHP Development Mailing List http://www.php.net/ | To unsubscribe, visit: http://www.php.net/unsub.php | | | -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Register Shutdown Function for Apache
Then, could we add a sapi_flush()/ob_flush() call at the end of apache_php_module_main after calling the normal register_shutdown_functions? What else might have problems? Joseph -Original Message- From: Brian Moon [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 11:23 AM To: Brian Moon; [EMAIL PROTECTED]; Joseph Tate Cc: Php-Dev List; PHP Group Subject: Re: [PHP-DEV] Re: Register Shutdown Function for Apache It also does not send the headers if there is not content. ?php header(Location: http://spidey.dealnews.com/;); exit(); ? Document Contains No Data. Brian. dealnews.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Register Shutdown Function for Apache
At 19:54 28/01/2003, Joseph Tate wrote: Then, could we add a sapi_flush()/ob_flush() call at the end of apache_php_module_main after calling the normal register_shutdown_functions? Yeah, something along these lines. What else might have problems? Might is a powerful word :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Register Shutdown Function for Apache
Give me a patch and I will tell you. ;) Brian Moon dealnews.com - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Joseph Tate [EMAIL PROTECTED] Cc: Brian Moon [EMAIL PROTECTED]; Php-Dev List [EMAIL PROTECTED]; PHP Group [EMAIL PROTECTED] Sent: Tuesday, January 28, 2003 4:03 PM Subject: RE: [PHP-DEV] Re: Register Shutdown Function for Apache | At 19:54 28/01/2003, Joseph Tate wrote: | Then, could we add a sapi_flush()/ob_flush() call at the end of | apache_php_module_main after calling the normal register_shutdown_functions? | | Yeah, something along these lines. | | What else might have problems? | | Might is a powerful word :) | | Zeev | | | -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fw: [PHP - NOTES] note 28935 added to function.strftime
Yes, you should remove that note. -- Regards. M.CHAILLAN Nicolas [EMAIL PROTECTED] www.WorldAKT.com Hébergement de sites internets. Maxim Maletsky [EMAIL PROTECTED] a écrit dans le message de news: [EMAIL PROTECTED] Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 28 Jan 2003, Maxim Maletsky wrote: A user posted this note below. I do not know Catalan and cannot check it myself, however I decided not to ignore it and ask if anyone on the dev list could confirm that the user makes sense. If he does, then what? It wouldn't be a bug in PHP, but in the locales installed on his system I guess. Derick In fact, I did guess that. Anything we can do, though? At least, I think we should remove his note as it is unrelated to other locale's installations. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
