[PHP-DEV] Re: PHP 4.3.9RC3 Released
Ilia Alshanetsky wrote: The final release candidate of PHP 4.3.9 is now available for testing. Hf no new problems are uncovered, this release will be re-released as 4.3.9 at the end of the week. If you have any patches (4.X tree) for non-critical problems please hold them off either until we decide that another RC is needed or until after 4.3.9 is released. Bug 25570 which appeared in 4.3.2 and was fixed in 4.3.4 has appeared again somewhere before 4.3.9 -- Lester Caine - L.S.Caine Electronic Services -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
Yeah I'll try and see what can be done. It might be a bit tricky because TSRM doesn't "know" PHP but I think it can be solved. Andi At 04:33 PM 9/14/2004 -0700, Rasmus Lerdorf wrote: On Tue, 14 Sep 2004, Andi Gutmans wrote: > a) I will try and send internals@ an updated version of the realpath() > cache in the next few days. This should give a lot of bang for the buck > because realpath() is probably the suckiest system call in the startup. Make sure you update it to use the new sapi_get_request_time() call to get the time on each request to avoid a gettimeofday() syscall. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
On Tue, 14 Sep 2004, Andi Gutmans wrote: > a) I will try and send internals@ an updated version of the realpath() > cache in the next few days. This should give a lot of bang for the buck > because realpath() is probably the suckiest system call in the startup. Make sure you update it to use the new sapi_get_request_time() call to get the time on each request to avoid a gettimeofday() syscall. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
At 11:30 AM 9/14/2004 -0700, Rasmus Lerdorf wrote: On Tue, 14 Sep 2004, Andi Gutmans wrote: > Can you describe the other non-essential syscalls? I want to be sure we > really can't cover those (probably some of them we can't). > As far as the realpath patch goes (which is probably the biggest problem), > I think that if we have the realpath cache in CVS that part of your patch > won't be needed because I think the additional few K of memory wouldn't > make it any noticeably slower even on loaded systems. So let me put some > gas on that patch and that would allow to at least cut down your patch a bit. Well, you can mostly just read the part of the patch that addresses streams.c. I skip the check to see if we are dealing with a pipe in the _php_stream_fopen_from_file() call. This change trickles down and removes a number of small bits that check that is_pipe flag. And I also don't care what position the file pointer is at, so I skip the ftell() just after that which also eliminates a seek in _php_stream_cast(). And in _php_stream_fopen() there is an include/require sanity check fstat() that I also have no use for. It's mostly just looking at the common path and watching the syscalls and getting rid of anything that isn't logically needed to serve up a normal PHP page. I understand that some of these checks are necessary for edge-case things, but when an edge-case check slows down the common case I sacrifize that edge. Yep it seems like some of these are things which a realpath() cache patch would not address. As I mentioned earlier we should make your patch available but I think it's a bad idea to have it in the default distro. I suggest the following: a) I will try and send internals@ an updated version of the realpath() cache in the next few days. This should give a lot of bang for the buck because realpath() is probably the suckiest system call in the startup. b) Maybe Wez & Sara can take one more look to double check if there aren't any checks they can possibly save without impairing functionality. c) Create a new version of your patch based on (a) & (b) and make sure we find an accessible place for it with the disclaimer. Maybe Steph can take care of that. Thanks, Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 4.3.9RC3 Released
The final release candidate of PHP 4.3.9 is now available for testing. Hf no new problems are uncovered, this release will be re-released as 4.3.9 at the end of the week. If you have any patches (4.X tree) for non-critical problems please hold them off either until we decide that another RC is needed or until after 4.3.9 is released. The release files can be found at: http://qa.php.net/ Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Sefault in clone
name = 'Copy'; ?> $ php5 test.php Warning: __clone method called on non-object in /usr/home/thekid/test.php on line 6 [Wed Sep 15 00:07:35 2004] Script: 'test.php' --- /usr/home/thekid/devel/php/php/Zend/zend_variables.c(179) : Block 0x083B67F0 status: /usr/home/thekid/devel/php/php/Zend/zend_execute.h(62) : Actual location (location was relayed) Beginning: Overrun (magic=0x, expected=0x7312F8DC) Segmentation fault (core dumped) - Timm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
On Tue, 14 Sep 2004, Andi Gutmans wrote: > Can you describe the other non-essential syscalls? I want to be sure we > really can't cover those (probably some of them we can't). > As far as the realpath patch goes (which is probably the biggest problem), > I think that if we have the realpath cache in CVS that part of your patch > won't be needed because I think the additional few K of memory wouldn't > make it any noticeably slower even on loaded systems. So let me put some > gas on that patch and that would allow to at least cut down your patch a bit. Well, you can mostly just read the part of the patch that addresses streams.c. I skip the check to see if we are dealing with a pipe in the _php_stream_fopen_from_file() call. This change trickles down and removes a number of small bits that check that is_pipe flag. And I also don't care what position the file pointer is at, so I skip the ftell() just after that which also eliminates a seek in _php_stream_cast(). And in _php_stream_fopen() there is an include/require sanity check fstat() that I also have no use for. It's mostly just looking at the common path and watching the syscalls and getting rid of anything that isn't logically needed to serve up a normal PHP page. I understand that some of these checks are necessary for edge-case things, but when an edge-case check slows down the common case I sacrifize that edge. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Segfault in str_replace()
Hello,
I'm experiencing very weird segfaults (and cannot reproduce them with a
small script) in PHP4 (to be exact: PHP4.3.8) - a backtrace is attached.
Now the weird thing is:
#0 0x080e3ff3 in php_char_to_str (str=0x0, len=1515870810, from=34 '"',
to=0x85d5f54 "\"\"", to_len=2,
result=0x860104c) at
/root/php-src/php-4.3.8/ext/standard/string.c:2529
2529if (*source == from) {
The place where this comes from is an escaping routine (userland PHP)
for SQL queries, where $sql= '"'.str_replace('"', '""', $arg).'"' is
executed (hence the above arguments).
>From scanning string.c, I could not figure out how its "str" argument
could ever be NULL. php_char_to_str() is called from
php_str_replace_in_subject() (search is not IS_ARRAY, so this:
if (Z_STRLEN_P(search) == 1) {
php_char_to_str(Z_STRVAL_PP(subject),
Z_STRLEN_PP(subject),
Z_STRVAL_P(search)[0],
Z_STRVAL_P(replace),
Z_STRLEN_P(replace),
result);
is what is being executed. Before that,
convert_to_string_ex(subject);
Z_TYPE_P(result) = IS_STRING;
is called. How could this result in "subject" being NULL?
Maybe someone has an idea or has experienced this behaviour before. I'll
try to find a simple reproduce script ASAP.
- Timm
#0 0x080e3ff3 in php_char_to_str (str=0x0, len=1515870810, from=34 '"', to=0x85d5f54
"\"\"", to_len=2,
result=0x860104c) at /root/php-src/php-4.3.8/ext/standard/string.c:2529
2529if (*source == from) {
(gdb) bt
#0 0x080e3ff3 in php_char_to_str (str=0x0, len=1515870810, from=34 '"', to=0x85d5f54
"\"\"", to_len=2,
result=0x860104c) at /root/php-src/php-4.3.8/ext/standard/string.c:2529
#1 0x080e4711 in php_str_replace_in_subject (search=0x85f6c74, replace=0x85f7d3c,
subject=0x8504494,
result=0x860104c) at /root/php-src/php-4.3.8/ext/standard/string.c:2681
#2 0x080e4e6b in zif_str_replace (ht=3, return_value=0x860104c, this_ptr=0x0,
return_value_used=1)
at /root/php-src/php-4.3.8/ext/standard/string.c:2758
#3 0x08153943 in execute (op_array=0x845f154) at
/root/php-src/php-4.3.8/Zend/zend_execute.c:1635
#4 0x08153b41 in execute (op_array=0x8450b1c) at
/root/php-src/php-4.3.8/Zend/zend_execute.c:1679
#5 0x08153b41 in execute (op_array=0x8424c9c) at
/root/php-src/php-4.3.8/Zend/zend_execute.c:1679
#6 0x08153b41 in execute (op_array=0x8520e6c) at
/root/php-src/php-4.3.8/Zend/zend_execute.c:1679
#7 0x08153b41 in execute (op_array=0x852844c) at
/root/php-src/php-4.3.8/Zend/zend_execute.c:1679
#8 0x08153b41 in execute (op_array=0x8524c54) at
/root/php-src/php-4.3.8/Zend/zend_execute.c:1679
#9 0x08153b41 in execute (op_array=0x84faf7c) at
/root/php-src/php-4.3.8/Zend/zend_execute.c:1679
#10 0x08153b41 in execute (op_array=0x84fb004) at
/root/php-src/php-4.3.8/Zend/zend_execute.c:1679
#11 0x08153b41 in execute (op_array=0x8203b84) at
/root/php-src/php-4.3.8/Zend/zend_execute.c:1679
#12 0x08142a79 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /root/php-src/php-4.3.8/Zend/zend.c:891
#13 0x0810f863 in php_execute_script (primary_file=0xbaa0) at
/root/php-src/php-4.3.8/main/main.c:1734
#14 0x08159a5b in main (argc=6, argv=0xbb24) at
/root/php-src/php-4.3.8/sapi/cli/php_cli.c:822
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
At 10:52 AM 9/14/2004 -0700, Rasmus Lerdorf wrote: The patch doesn't just address realpath though. We have a number of other redundant/non-essential syscalls in the streams code, for example. And the realpath cache is still heavier than not worrying about the full path at all. Can you describe the other non-essential syscalls? I want to be sure we really can't cover those (probably some of them we can't). As far as the realpath patch goes (which is probably the biggest problem), I think that if we have the realpath cache in CVS that part of your patch won't be needed because I think the additional few K of memory wouldn't make it any noticeably slower even on loaded systems. So let me put some gas on that patch and that would allow to at least cut down your patch a bit. I do agree that however people get this patch, they need to understand that they are not running standard PHP and it is likely to break many things. At the same time, having it in CVS and maintainable by others and having a single known version of this would help the people who use it and the people who want to tweak their extensions to support it. Perhaps we need a central php.net hosted and CVS-backed place for unsupported patches and nasty hacks like this? Useful ideas that are applicable to a wider audience do often grow out of some of these crazy hacks. Yes, I definitely think that is needed because there have been some patches floating around which probably shouldn't be in the core distribution but should be out there with big disclaimers for people who want to use them. I know Steph was working on something like that because she also felt there needs to be easier access to such patches (and I agree). I'm not sure where that project is at right now. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
The patch doesn't just address realpath though. We have a number of other redundant/non-essential syscalls in the streams code, for example. And the realpath cache is still heavier than not worrying about the full path at all. I do agree that however people get this patch, they need to understand that they are not running standard PHP and it is likely to break many things. At the same time, having it in CVS and maintainable by others and having a single known version of this would help the people who use it and the people who want to tweak their extensions to support it. Perhaps we need a central php.net hosted and CVS-backed place for unsupported patches and nasty hacks like this? Useful ideas that are applicable to a wider audience do often grow out of some of these crazy hacks. -Rasmus On Tue, 14 Sep 2004, Andi Gutmans wrote: > Hey Derick and all, > > As I mentioned in the past, I think solving it in a completely compatible > manner is the best way to go. > I sent out the realpath() cache patch which addresses the most problematic > file system issues (and if there are any other things we could probably > address too). > I think there's a big advantage in having something which is completely > compatible because we could enable it by default and all PHP users would > benefit from it. > I volunteer to put some gas on getting this patch production ready. Maybe I > can send a new version in a couple of days and discuss what else it is missing? > > Andi > > At 02:10 PM 9/14/2004 +0200, Derick Rethans wrote: > >Hei, > > > >This is Rasmus' patch including a configure option > >"--disable-path-normalization" to enable this patch. By default this > >option is of course turned off. > > > >I am planning to commit this patch after 4.3.9 is released too, in case > >there are no good objections. > > > >Derick > > > >-- > >Derick Rethans > >http://derickrethans.nl | http://ez.no | http://xdebug.org > >-- > >PHP Internals - PHP Runtime Development Mailing List > >To unsubscribe, visit: http://www.php.net/unsub.php > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP's error handler: xmlrpc_errors, entity encoding, and handler chaining
Personally I prefer today's approach vs. a more complex chaining solution. It only requires an additional if() in your error handler to handle different error codes differently. At 10:07 PM 9/13/2004 -0700, Sara Golemon wrote: > Having it trickle back through the stack would make sense to me too. > http://pecl.org/sara/error_chaining.diff Here's the basic idea of what I had in mind. This patch is actually not the way I'd like to see it implemented, but rather the most expedient demonstration as it doesn't involve seriously changing the way error handlers are registered and stored. And anyway, it's functional. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] Zend/zend_objects_API.c - bug #29980 (segfault while executing __destruct())
Yes I agree. At 02:02 PM 9/13/2004 +0300, Stanislav Malyshev wrote: AD>>ATM ZE2 calls destructor at the end of the request and no matter is AD>>there were a fatal error (which should probably stop executing the AD>>script). In some cases it leads to nasty segfaults (me and report's AD>>author can reproduce it, but others can't. weird..). Well, the cause of the faults is as follows: If we are in shutdown, and one of the destructors fails with fatal error, then other destructors for other objects are not called. Thus, their if they hold some objects, destructors for these objects will not be called. Later, when the storage is cleaned with zend_objects_store_free_object_storage(), engine will attempt to call dtors for objects that didn't have their dtors called before. However, on that stage engine is already unable to run PHP code (function and class tables are already cleaned, etc.) - so it crashes. What I would propose is to inhibit calling destructors after shutdown_destructors() was finished. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] Zend/zend_objects_API.c - bug #29980 (segfault while executing __destruct())
At 02:02 PM 9/13/2004 +0300, Stanislav Malyshev wrote: AD>>ATM ZE2 calls destructor at the end of the request and no matter is AD>>there were a fatal error (which should probably stop executing the AD>>script). In some cases it leads to nasty segfaults (me and report's AD>>author can reproduce it, but others can't. weird..). Well, the cause of the faults is as follows: If we are in shutdown, and one of the destructors fails with fatal error, then other destructors for other objects are not called. Thus, their if they hold some objects, destructors for these objects will not be called. Later, when the storage is cleaned with zend_objects_store_free_object_storage(), engine will attempt to call dtors for objects that didn't have their dtors called before. However, on that stage engine is already unable to run PHP code (function and class tables are already cleaned, etc.) - so it crashes. What I would propose is to inhibit calling destructors after shutdown_destructors() was finished. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
At 19:29 14/09/2004, Derick Rethans wrote: > And yes, there is no doubt that this patch can critically alter the way > PHP works and has the potential to break all sorts of stuff. Anything > that relies on PHP knowing the full path will break. I had to fix both > xdebug and APC, for example. At the same time, enough people have asked > me about it that it probably should be more accessible. I agree, there are a lot of people who might benefit from it (and do already!) and thus the reason for me to put it into something usable for everybody so that 1) rasmus doesn't have to maintain the patch anymore and 2) users don't have to keep updating their PHP whenever they upgrade PHP. I don't disagree that it can be useful. But such a feature should not come bundled as an option in PHP. The Right(tm) solution here is to provide the realpath cache, which will speed performance up without breaking compatibility, and hopefully we'll have that one real soon now. We can maybe look into backporting it to PHP 4 as an optional feature (just to make sure we don't break apps in case it's buggy). Adding this patch as an option goes against everything that we've been trying to do in the last few years. This useful patch should be made available so that those who really need it can find it, but it should come up with a huge disclaimer, and it should not be trivial for users to enable it in the form of --enable-foo. I see the fact that people have to invest some work in using it as a good thing, since if a lot of people start using it, it can become a very big headache very quickly. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] zend_operators DVAL_TO_LVAL fix
Also <= LONG_MIN needed? I guess yes? At 03:22 PM 9/11/2004 +0200, Ard Biesheuvel wrote: Joe Orton wrote: The DVAL_TO_LVAL macro is quite weird, I'm not sure exactly what it's supposed to be doing but it probably isn't doing it. If the integral part of d is outside the range of a long, the conversion has undefined behaviour by the C99 standard; an explicit cast makes no difference AFAICT. GCC on IA64 does wierd things with this macro, though I think there's a GCC bug involved there too. This fixes the macro to have well-defined behaviour for all values of 'd', and avoids triggering the GCC bug on IA64 to boot (both PHP users on that platform will be happy): This probably has to do with the fact that on 64-bit systems, doubles lack the accuracy to distinguish LONG_MAX from LONG_MAX +1. To be on the safe side here, you might want to use >= LONG_MAX instead of > LONG_MAX, or cast the other way around. -- Ard -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
Hey Derick and all, As I mentioned in the past, I think solving it in a completely compatible manner is the best way to go. I sent out the realpath() cache patch which addresses the most problematic file system issues (and if there are any other things we could probably address too). I think there's a big advantage in having something which is completely compatible because we could enable it by default and all PHP users would benefit from it. I volunteer to put some gas on getting this patch production ready. Maybe I can send a new version in a couple of days and discuss what else it is missing? Andi At 02:10 PM 9/14/2004 +0200, Derick Rethans wrote: Hei, This is Rasmus' patch including a configure option "--disable-path-normalization" to enable this patch. By default this option is of course turned off. I am planning to commit this patch after 4.3.9 is released too, in case there are no good objections. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
Derick Rethans wrote: On Tue, 14 Sep 2004, Rasmus Lerdorf wrote: That should have been a #ifndef SKIP_PATH_CHECKS there. And it is there to get rid of a non-critical ftell(). Attached is the patch with this corrected, and corrected white space. And yes, there is no doubt that this patch can critically alter the way PHP works and has the potential to break all sorts of stuff. Anything that relies on PHP knowing the full path will break. I had to fix both xdebug and APC, for example. At the same time, enough people have asked me about it that it probably should be more accessible. I agree, there are a lot of people who might benefit from it (and do already!) and thus the reason for me to put it into something usable for everybody so that 1) rasmus doesn't have to maintain the patch anymore and 2) users don't have to keep updating their PHP whenever they upgrade PHP. Derick Both points make sense. Just name the configure option well and put big warnings there that when the option is switched on this _may_ lead to crashing applications. Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] round 3
Yesterday that was a 'wrong fix' too :) Please can you at least commit that so that the win32 build works as advertised at least? You can worry about the mystery of other systems breaking later. > -Original Message- > From: Derick Rethans [mailto:[EMAIL PROTECTED] > Sent: 14 September 2004 17:21 > To: Steph > Cc: internals > Subject: Re: [PHP-DEV] [PATCH] round 3 > > > On Tue, 14 Sep 2004, Steph wrote: > > > Moved #if a few paces to the left on Wez's advice. Fussy old > compilers ;) > > > > Still does the same job (fixes win32 build and all builds where > there is no > > strcoll), only this time without breaking otherwise happy builds. > > It's still wrong. The only change needed is the #define HAVE_STRCOLL in > zend_config.w32.h > > Derick > > -- > Derick Rethans > http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
On Tue, 14 Sep 2004, Rasmus Lerdorf wrote:
> That should have been a #ifndef SKIP_PATH_CHECKS there. And it is there
> to get rid of a non-critical ftell().
Attached is the patch with this corrected, and corrected white space.
> And yes, there is no doubt that this patch can critically alter the way
> PHP works and has the potential to break all sorts of stuff. Anything
> that relies on PHP knowing the full path will break. I had to fix both
> xdebug and APC, for example. At the same time, enough people have asked
> me about it that it probably should be more accessible.
I agree, there are a lot of people who might benefit from it (and do
already!) and thus the reason for me to put it into something usable for
everybody so that 1) rasmus doesn't have to maintain the patch anymore
and 2) users don't have to keep updating their PHP whenever they upgrade
PHP.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org? php_test_results_20040914.txt
? ext/gd/testsbug27582.png
? ext/tokenizer/tests/bug26463.diff
? ext/tokenizer/tests/bug26463.exp
? ext/tokenizer/tests/bug26463.log
? ext/tokenizer/tests/bug26463.out
? ext/tokenizer/tests/bug26463.php
Index: configure.in
===
RCS file: /repository/php-src/configure.in,v
retrieving revision 1.396.2.125
diff -u -p -r1.396.2.125 configure.in
--- configure.in14 Sep 2004 04:33:09 - 1.396.2.125
+++ configure.in14 Sep 2004 16:27:01 -
@@ -748,6 +748,13 @@ if test "$PHP_IPV6" != "no" && test "$ac
AC_DEFINE(HAVE_IPV6,1,[Whether to enable IPv6 support])
fi
+PHP_ARG_ENABLE(path-normalization,whether to enable path normalization,
+[ --disable-path-normalization
+ Disable path normalization], yes, no)
+if test "$PHP_PATH_NORMALIZATION" == "no"; then
+ AC_DEFINE(SKIP_PATH_CHECKS,1,[Whether to disable path normalization])
+fi
+
AC_MSG_CHECKING([whether to enable versioning])
AC_ARG_ENABLE(versioning,
[ --enable-versioning Export only required symbols.
Index: Zend/zend_language_scanner.l
===
RCS file: /repository/Zend/Attic/zend_language_scanner.l,v
retrieving revision 1.54.2.26
diff -u -p -r1.54.2.26 zend_language_scanner.l
--- Zend/zend_language_scanner.l3 Feb 2004 14:31:19 - 1.54.2.26
+++ Zend/zend_language_scanner.l14 Sep 2004 16:27:02 -
@@ -41,6 +41,7 @@
%x ST_COMMENT
%x ST_ONE_LINE_COMMENT
%option stack
+%option never-interactive
%{
Index: main/fopen_wrappers.c
===
RCS file: /repository/php-src/main/fopen_wrappers.c,v
retrieving revision 1.153.2.9
diff -u -p -r1.153.2.9 fopen_wrappers.c
--- main/fopen_wrappers.c 16 Mar 2004 00:32:09 - 1.153.2.9
+++ main/fopen_wrappers.c 14 Sep 2004 16:27:03 -
@@ -106,7 +106,9 @@ PHPAPI int php_check_specific_open_based
char resolved_name[MAXPATHLEN];
char resolved_basedir[MAXPATHLEN];
char local_open_basedir[MAXPATHLEN];
+ char local_path[MAXPATHLEN];
int local_open_basedir_pos;
+ int local_path_pos;
int resolved_basedir_len;
int resolved_name_len;
@@ -128,9 +130,31 @@ PHPAPI int php_check_specific_open_based
strlcpy(local_open_basedir, basedir, sizeof(local_open_basedir));
}
+#ifdef SKIP_PATH_CHECKS
+ if (path[0] == '.' && path[1] == '/' && SG(request_info).path_translated &&
*SG(request_info).path_translated) {
+ strlcpy(local_path, SG(request_info).path_translated,
sizeof(local_path) );
+ local_path_pos = strlen(local_path) - 1;
+
+ /* Strip filename */
+ while (!IS_SLASH(local_path[local_path_pos]) && (local_path_pos >= 0))
{
+ local_path[local_path_pos--] = 0;
+ }
+
+ strncat(local_path, path + 2, MAXPATHLEN - (local_path_pos +
strlen(path)));
+ } else {
+#endif
+ /* Else use the unmodified path */
+ strlcpy(local_path, path, sizeof(local_path));
+#ifdef SKIP_PATH_CHECKS
+ }
+ if (strstr(local_path,"..")) {
+ return -1;
+ }
+#endif
+
/* Resolve the real path into resolved_name */
- if ((expand_filepath(path, resolved_name TSRMLS_CC) != NULL) &&
(expand_filepath(local_open_basedir, resolved_basedir TSRMLS_CC) != NULL)) {
- /* Handler for basedirs that end with a / */
+ if ((expand_filepath(local_path, resolved_name TSRMLS_CC) != NULL) &&
(expand_filepath(local_open_basedir, resolved_basedir TSRMLS_CC) != NULL)) {
+ /* Handler for basedirs that end with a / */
resolved_basedir_len = strlen(resolved_basedir);
if (basedir[strlen(basedir) - 1] == PHP_DIR_SEPARATOR) {
if (resolved_basedir[resolved_base
Re: [PHP-DEV] [PATCH] round 3
On Tue, 14 Sep 2004, Steph wrote: > Moved #if a few paces to the left on Wez's advice. Fussy old compilers ;) > > Still does the same job (fixes win32 build and all builds where there is no > strcoll), only this time without breaking otherwise happy builds. It's still wrong. The only change needed is the #define HAVE_STRCOLL in zend_config.w32.h Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] round 3
Moved #if a few paces to the left on Wez's advice. Fussy old compilers ;)
Still does the same job (fixes win32 build and all builds where there is no
strcoll), only this time without breaking otherwise happy builds.
- Steph
Index: Zend/zend_config.w32.h
===
RCS file: /repository/ZendEngine2/zend_config.w32.h,v
retrieving revision 1.36
diff -u -r1.36 zend_config.w32.h
--- Zend/zend_config.w32.h 8 Jan 2004 17:31:47 - 1.36
+++ Zend/zend_config.w32.h 14 Sep 2004 15:24:36 -
@@ -30,6 +30,8 @@
#include
#include
+#define HAVE_STRCOLL 1
+
#include
#ifndef ZEND_INCLUDE_FULL_WINDOWS_HEADERS
Index: Zend/zend_operators.c
===
RCS file: /repository/ZendEngine2/zend_operators.c,v
retrieving revision 1.196
diff -u -r1.196 zend_operators.c
--- Zend/zend_operators.c 11 Sep 2004 14:22:35 - 1.196
+++ Zend/zend_operators.c 14 Sep 2004 15:24:41 -
@@ -1222,7 +1222,6 @@
return SUCCESS;
}
-#if HAVE_STRCOLL
ZEND_API int string_locale_compare_function(zval *result, zval *op1, zval *op2
TSRMLS_DC)
{
zval op1_copy, op2_copy;
@@ -1249,7 +1248,6 @@
}
return SUCCESS;
}
-#endif
ZEND_API int numeric_compare_function(zval *result, zval *op1, zval *op2 TSRMLS_DC)
{
Index: ext/standard/array.c
===
RCS file: /repository/php-src/ext/standard/array.c,v
retrieving revision 1.274
diff -u -r1.274 array.c
--- ext/standard/array.c11 Sep 2004 14:22:35 - 1.274
+++ ext/standard/array.c14 Sep 2004 15:25:10 -
@@ -55,17 +55,19 @@
#define EXTR_OVERWRITE 0
#define EXTR_SKIP 1
#define EXTR_PREFIX_SAME 2
-#defineEXTR_PREFIX_ALL 3
-#defineEXTR_PREFIX_INVALID 4
-#defineEXTR_PREFIX_IF_EXISTS 5
-#defineEXTR_IF_EXISTS 6
+#define EXTR_PREFIX_ALL3
+#define EXTR_PREFIX_INVALID4
+#define EXTR_PREFIX_IF_EXISTS 5
+#define EXTR_IF_EXISTS 6
#define EXTR_REFS 0x100
#define SORT_REGULAR 0
#define SORT_NUMERIC 1
-#defineSORT_STRING 2
-#defineSORT_LOCALE_STRING 5
+#define SORT_STRING2
+#if HAVE_STRCOLL
+#define SORT_LOCALE_STRING 5
+#endif
#define SORT_DESC 3
#define SORT_ASC 4
@@ -115,7 +117,10 @@
REGISTER_LONG_CONSTANT("SORT_REGULAR", SORT_REGULAR, CONST_CS |
CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("SORT_NUMERIC", SORT_NUMERIC, CONST_CS |
CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("SORT_STRING", SORT_STRING, CONST_CS |
CONST_PERSISTENT);
+
+#if HAVE_STRCOLL
REGISTER_LONG_CONSTANT("SORT_LOCALE_STRING", SORT_LOCALE_STRING, CONST_CS |
CONST_PERSISTENT);
+#endif
REGISTER_LONG_CONSTANT("CASE_LOWER", CASE_LOWER, CONST_CS | CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("CASE_UPPER", CASE_UPPER, CONST_CS | CONST_PERSISTENT);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
On Tue, 14 Sep 2004, Derick Rethans wrote: > On Tue, 14 Sep 2004, Derick Rethans wrote: > > > On Tue, 14 Sep 2004, Wez Furlong wrote: > > > > > There's an #if 0 in there that probably shouldn't be > > > > Yeah, the whole stuff can be removed, as it's added in later again :) > > I'll create a new patch for it here. > > hmm, no, this was a different patch. No clue why he put that in; Rasmus, > can you clarify? That should have been a #ifndef SKIP_PATH_CHECKS there. And it is there to get rid of a non-critical ftell(). And yes, there is no doubt that this patch can critically alter the way PHP works and has the potential to break all sorts of stuff. Anything that relies on PHP knowing the full path will break. I had to fix both xdebug and APC, for example. At the same time, enough people have asked me about it that it probably should be more accessible. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
I don't think we should have this patch in the distribution. It shouldn't be that accessible as it has the potential to break behavior of both apps and plugins. I think it belongs in a patches repository such as http://www.zend.com/zend/week/pat/ (doesn't have to be that one in particular, but something like that). (There are also several coding style issues with the patch if we do decide to accept it) Zeev At 15:10 14/09/2004, Derick Rethans wrote: Hei, This is Rasmus' patch including a configure option "--disable-path-normalization" to enable this patch. By default this option is of course turned off. I am planning to commit this patch after 4.3.9 is released too, in case there are no good objections. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
To eliminate an fstat() most likely; it can stay, but it should probably changed to #ifndef SKIP_PATH_CHECKS instead. --Wez. On Tue, 14 Sep 2004 14:50:09 +0200 (CEST), Derick Rethans <[EMAIL PROTECTED]> wrote: > On Tue, 14 Sep 2004, Derick Rethans wrote: > > > On Tue, 14 Sep 2004, Wez Furlong wrote: > > > > > There's an #if 0 in there that probably shouldn't be > > > > Yeah, the whole stuff can be removed, as it's added in later again :) > > I'll create a new patch for it here. > > hmm, no, this was a different patch. No clue why he put that in; Rasmus, > can you clarify? > > > > Derick > > -- > Derick Rethans > http://derickrethans.nl | http://ez.no | http://xdebug.org > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
On Tue, 14 Sep 2004, Derick Rethans wrote: > On Tue, 14 Sep 2004, Wez Furlong wrote: > > > There's an #if 0 in there that probably shouldn't be > > Yeah, the whole stuff can be removed, as it's added in later again :) > I'll create a new patch for it here. hmm, no, this was a different patch. No clue why he put that in; Rasmus, can you clarify? Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
On Tue, 14 Sep 2004, Wez Furlong wrote: > There's an #if 0 in there that probably shouldn't be Yeah, the whole stuff can be removed, as it's added in later again :) I'll create a new patch for it here. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
There's an #if 0 in there that probably shouldn't be --Wez. On Tue, 14 Sep 2004 14:10:52 +0200 (CEST), Derick Rethans <[EMAIL PROTECTED]> wrote: > Hei, > > This is Rasmus' patch including a configure option > "--disable-path-normalization" to enable this patch. By default this > option is of course turned off. > > I am planning to commit this patch after 4.3.9 is released too, in case > there are no good objections. > > Derick > > -- > Derick Rethans > http://derickrethans.nl | http://ez.no | http://xdebug.org > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch: Rasmus statcallpatch with configure option
Hei,
This is Rasmus' patch including a configure option
"--disable-path-normalization" to enable this patch. By default this
option is of course turned off.
I am planning to commit this patch after 4.3.9 is released too, in case
there are no good objections.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.orgIndex: configure.in
===
RCS file: /repository/php-src/configure.in,v
retrieving revision 1.396.2.125
diff -u -p -r1.396.2.125 configure.in
--- configure.in14 Sep 2004 04:33:09 - 1.396.2.125
+++ configure.in14 Sep 2004 11:55:09 -
@@ -748,6 +748,13 @@ if test "$PHP_IPV6" != "no" && test "$ac
AC_DEFINE(HAVE_IPV6,1,[Whether to enable IPv6 support])
fi
+PHP_ARG_ENABLE(path-normalization,whether to enable path normalization,
+[ --disable-path-normalization
+ Disable path normalization], yes, no)
+if test "$PHP_PATH_NORMALIZATION" == "no"; then
+ AC_DEFINE(SKIP_PATH_CHECKS,1,[Whether to disable path normalization])
+fi
+
AC_MSG_CHECKING([whether to enable versioning])
AC_ARG_ENABLE(versioning,
[ --enable-versioning Export only required symbols.
Index: Zend/zend_language_scanner.l
===
RCS file: /repository/Zend/Attic/zend_language_scanner.l,v
retrieving revision 1.54.2.26
diff -u -p -r1.54.2.26 zend_language_scanner.l
--- Zend/zend_language_scanner.l3 Feb 2004 14:31:19 - 1.54.2.26
+++ Zend/zend_language_scanner.l14 Sep 2004 11:55:10 -
@@ -41,6 +41,7 @@
%x ST_COMMENT
%x ST_ONE_LINE_COMMENT
%option stack
+%option never-interactive
%{
Index: main/fopen_wrappers.c
===
RCS file: /repository/php-src/main/fopen_wrappers.c,v
retrieving revision 1.153.2.9
diff -u -p -r1.153.2.9 fopen_wrappers.c
--- main/fopen_wrappers.c 16 Mar 2004 00:32:09 - 1.153.2.9
+++ main/fopen_wrappers.c 14 Sep 2004 11:55:11 -
@@ -106,7 +106,9 @@ PHPAPI int php_check_specific_open_based
char resolved_name[MAXPATHLEN];
char resolved_basedir[MAXPATHLEN];
char local_open_basedir[MAXPATHLEN];
+ char local_path[MAXPATHLEN];
int local_open_basedir_pos;
+ int local_path_pos;
int resolved_basedir_len;
int resolved_name_len;
@@ -128,9 +130,30 @@ PHPAPI int php_check_specific_open_based
strlcpy(local_open_basedir, basedir, sizeof(local_open_basedir));
}
+#ifdef SKIP_PATH_CHECKS
+ if ( path[0] == '.' && path[1] == '/' && SG(request_info).path_translated &&
*SG(request_info).path_translated ) {
+ strlcpy(local_path, SG(request_info).path_translated,
sizeof(local_path) );
+ local_path_pos = strlen(local_path) - 1;
+
+ /* Strip filename */
+ while (!IS_SLASH(local_path[local_path_pos]) && (local_path_pos >= 0))
{
+ local_path[local_path_pos--] = 0;
+ }
+
+ strncat( local_path, path + 2, MAXPATHLEN - (local_path_pos + strlen(
path )) );
+ }
+ else {
+#endif
+ /* Else use the unmodified path */
+ strlcpy(local_path, path, sizeof(local_path));
+#ifdef SKIP_PATH_CHECKS
+ }
+ if(strstr(local_path,"..")) return -1;
+#endif
+
/* Resolve the real path into resolved_name */
- if ((expand_filepath(path, resolved_name TSRMLS_CC) != NULL) &&
(expand_filepath(local_open_basedir, resolved_basedir TSRMLS_CC) != NULL)) {
- /* Handler for basedirs that end with a / */
+ if ((expand_filepath(local_path, resolved_name TSRMLS_CC) != NULL) &&
(expand_filepath(local_open_basedir, resolved_basedir TSRMLS_CC) != NULL)) {
+ /* Handler for basedirs that end with a / */
resolved_basedir_len = strlen(resolved_basedir);
if (basedir[strlen(basedir) - 1] == PHP_DIR_SEPARATOR) {
if (resolved_basedir[resolved_basedir_len - 1] == '/') {
@@ -139,7 +162,7 @@ PHPAPI int php_check_specific_open_based
}
}
- if (path[strlen(path)-1] == PHP_DIR_SEPARATOR) {
+ if (local_path[strlen(local_path)-1] == PHP_DIR_SEPARATOR) {
resolved_name_len = strlen(resolved_name);
if (resolved_name[resolved_name_len - 1] != PHP_DIR_SEPARATOR)
{
resolved_name[resolved_name_len] = PHP_DIR_SEPARATOR;
@@ -533,6 +556,16 @@ PHPAPI char *php_strip_url_passwd(char *
*/
PHPAPI char *expand_filepath(const char *filepath, char *real_path TSRMLS_DC)
{
+#ifdef SKIP_PATH_CHECKS
+ int len = strlen(filepath);
+
+ if(filepath[len-1] == PHP_DIR_SEPARATOR) len--;
+ if(!real_path) real_path = estrdup(filepath);
+ else strcpy(real_
[PHP-DEV] Patch: Foreach Performance for 4.3
Hei,
I backported Marcus' performance-improvement-when-not-using-a-key-in-foreach
patch to 4.3 and attached it. I am planning to commit this after 4.3.9
is released. If there are any comments, please let me know.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org? php_test_results_20040914.txt
? ext/gd/testsbug27582.png
? ext/tokenizer/tests/bug26463.diff
? ext/tokenizer/tests/bug26463.exp
? ext/tokenizer/tests/bug26463.log
? ext/tokenizer/tests/bug26463.out
? ext/tokenizer/tests/bug26463.php
Index: Zend/zend_compile.c
===
RCS file: /repository/Zend/Attic/zend_compile.c,v
retrieving revision 1.240.2.7
diff -u -p -r1.240.2.7 zend_compile.c
--- Zend/zend_compile.c 29 Aug 2004 16:51:09 - 1.240.2.7
+++ Zend/zend_compile.c 14 Sep 2004 11:10:58 -
@@ -2147,9 +2147,9 @@ void zend_do_foreach_begin(znode *foreac
}
-void zend_do_foreach_cont(znode *value, znode *key, znode *as_token TSRMLS_DC)
+void zend_do_foreach_cont(znode *value, znode *key, znode *as_token, znode
*foreach_token TSRMLS_DC)
{
- zend_op *opline = get_next_op(CG(active_op_array) TSRMLS_CC);
+ zend_op *opline;
znode result_value, result_key, dummy;
if (key->op_type != IS_UNUSED) {
@@ -2159,18 +2159,10 @@ void zend_do_foreach_cont(znode *value,
tmp = key;
key = value;
value = tmp;
- }
- opline->opcode = ZEND_FETCH_DIM_TMP_VAR;
- opline->result.op_type = IS_VAR;
- opline->result.u.EA.type = 0;
- opline->result.u.opline_num = get_temporary_variable(CG(active_op_array));
- opline->op1 = *as_token;
- opline->op2.op_type = IS_CONST;
- opline->op2.u.constant.type = IS_LONG;
- opline->op2.u.constant.value.lval = 0;
- opline->extended_value = ZEND_FETCH_STANDARD; /* ignored in fetch_dim_tmp_var,
but what the hell. */
- result_value = opline->result;
+ /* Mark extended_value in case both key and value are being used */
+
CG(active_op_array)->opcodes[foreach_token->u.opline_num].extended_value |=
ZEND_FE_FETCH_WITH_KEY;
+ }
if (key->op_type != IS_UNUSED) {
opline = get_next_op(CG(active_op_array) TSRMLS_CC);
@@ -2181,9 +2173,23 @@ void zend_do_foreach_cont(znode *value,
opline->op1 = *as_token;
opline->op2.op_type = IS_CONST;
opline->op2.u.constant.type = IS_LONG;
+ opline->op2.u.constant.value.lval = 0;
+ opline->extended_value = ZEND_FETCH_STANDARD; /* ignored in
fetch_dim_tmp_var, but what the hell. */
+ result_value = opline->result;
+
+ opline = get_next_op(CG(active_op_array) TSRMLS_CC);
+ opline->opcode = ZEND_FETCH_DIM_TMP_VAR;
+ opline->result.op_type = IS_VAR;
+ opline->result.u.EA.type = 0;
+ opline->result.u.opline_num =
get_temporary_variable(CG(active_op_array));
+ opline->op1 = *as_token;
+ opline->op2.op_type = IS_CONST;
+ opline->op2.u.constant.type = IS_LONG;
opline->op2.u.constant.value.lval = 1;
opline->extended_value = ZEND_FETCH_STANDARD; /* ignored in
fetch_dim_tmp_var, but what the hell. */
result_key = opline->result;
+ } else {
+ result_value =
CG(active_op_array)->opcodes[foreach_token->u.opline_num].result;
}
zend_do_assign(&dummy, value, &result_value TSRMLS_CC);
@@ -2191,8 +2197,8 @@ void zend_do_foreach_cont(znode *value,
if (key->op_type != IS_UNUSED) {
zend_do_assign(&dummy, key, &result_key TSRMLS_CC);
CG(active_op_array)->opcodes[CG(active_op_array)->last-1].result.u.EA.type |=
EXT_TYPE_UNUSED;
+ zend_do_free(as_token TSRMLS_CC);
}
- zend_do_free(as_token TSRMLS_CC);
do_begin_loop(TSRMLS_C);
INC_BPC(CG(active_op_array));
Index: Zend/zend_compile.h
===
RCS file: /repository/Zend/Attic/zend_compile.h,v
retrieving revision 1.144.4.5
diff -u -p -r1.144.4.5 zend_compile.h
--- Zend/zend_compile.h 31 May 2003 01:37:43 - 1.144.4.5
+++ Zend/zend_compile.h 14 Sep 2004 11:10:58 -
@@ -326,7 +326,7 @@ void zend_do_unset(znode *variable TSRML
void zend_do_isset_or_isempty(int type, znode *result, znode *variable TSRMLS_DC);
void zend_do_foreach_begin(znode *foreach_token, znode *array, znode
*open_brackets_token, znode *as_token, int variable TSRMLS_DC);
-void zend_do_foreach_cont(znode *value, znode *key, znode *as_token TSRMLS_DC);
+void zend_do_foreach_cont(znode *value, znode *key, znode *as_token, znode
*foreach_token TSRMLS_DC);
void zend_do_foreach_end(znode *foreach_token, znode *open_brackets_token TSRMLS_DC);
void zend_do_declare_begin(TSRMLS_D)
Re: [PHP-DEV] Re: Bug #25570 Some requests cause Apache to crash/restart
Jacques Marneweck wrote: It would seem that this bug has appeared again, in 5.0.1 on Apache 2.0.50 I've had a report about it on the firebird-php list, and on checking it would seem that it can be reproduced. Could someone have a look and see if we are right please. Come on people - have two sites that have uninstalled PHP5 and returned to 4 because of this problem. Do I just post it as a new bug? Why not follow up by submitting a bug report. Does apache leave coredump files around? Was not sure if it should be a new report or just reopen the old one - not that I have ever actually used the bug site to enter stuff ;) There is notes on the bugs site on how to use gdb to get a backtrace for debugging the issues. I'm getting feedback second hand at present. It would seem that the problem is back in 4.3.9 and all versions of 5 so while it was apparently fixed in 4.3.4 it has returned later. Sites are currently running 4.3.1 and are stable, so I don't want to push it at that end. -- Lester Caine - L.S.Caine Electronic Services -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Bug #25570 Some requests cause Apache to crash/restart
On Tue, 14 Sep 2004 07:49:04 +0100, Lester Caine <[EMAIL PROTECTED]> wrote: > Lester Caine wrote: > > > It would seem that this bug has appeared again, in 5.0.1 on Apache 2.0.50 > > I've had a report about it on the firebird-php list, and on checking it > > would seem that it can be reproduced. > > Could someone have a look and see if we are right please. > > Come on people - have two sites that have uninstalled PHP5 and returned > to 4 because of this problem. Do I just post it as a new bug? Hi Lester, Why not follow up by submitting a bug report. Does apache leave coredump files around? There is notes on the bugs site on how to use gdb to get a backtrace for debugging the issues. Regards --jm -- Jacques Marneweck http://www.powertrip.co.za/blog/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] curl multi backport to PHP4
I needed the curl multi stuff for something, so I trivially backported it to PHP4's ext/curl. There is nothing really PHP5-specific in it and it is basically just a standalone extension keeping track with the 3rd-party library it is wrapping. Ilia, as RM of the 4.3 tree, do you see any reason not to commit this to ext/curl on the PHP_4_3 branch after 4.3.9 is out the door? -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
